Android 热修复核心原理：ClassLoader类加载机制_classloader热修复原理

 

---

一 前言介绍

从16年开始开始，热修复技术开始在安卓界流行，它以classloader类加载机制为核心，可以不发布新版本就修复线上 bug ，让线上版本有能力去进行全量或者增量更新。

常见的思路有两种：

1 类加载方案，即 dex 插桩。该方案以腾讯系为主，包括微信的 Tinker、饿了么的 Amigo；

2 底层替换，即修改替换 ArtMethod。方案以阿里系的 AndFix 等为主；

1.1 ART 和 Dalvik

Dex ：全称为Dalvik Executable Format，由很多 .class 文件处理压缩后的产物，最终可以在 Android 运行时环境执行。它适合于内存和处理器速度有限的系统。

Dalvik：Google设计的Android平台的Java虚拟机。支持转换为.dex格式的Java程序运行。DVM默认使用CMS垃圾回收器。

ART：Android Runtime，于Android 4.4 引入，在 Android 5.0 及更高版本作为默认的 Android 运行时。ART做出的具体改进可看安卓官方文档介绍：运行时：Android Runtime (ART) 和 Dalvik。ART 和 Dalvik 都是运行 Dex 字节码的兼容运行时，因此 ART 向下兼容Dalvik 开发的应用。 

AOT：ART在应用安装的时候预编译字节码到机器语言，这一机制叫Ahead-Of-Time(AOT)预编译。执行该操作后，应用程序安装会变慢，但是执行将更有效率，启动更快。

1.2 dexopt与dexaot

• dexopt

  在Dalvik虚拟机加载一个dex文件时，会对 dex 文件进行验证和优化，得到odex(Optimized dex) 文件。这个文件和 dex 文件很像，只是使用了一些优化操作码。

• dex2oat

  ART 预先编译机制，在安装时对 dex 文件执行dexopt优化之后，再将odex进行 AOT 提前编译操作，编译为OAT（实际上是ELF文件）可执行文件（机器码）。（相比做过odex优化，未做过优化的dex转换成OAT要花费更长的时间）

1.3 ART 和 Dalvik 对比

1、在Dalvik下，应用运行需要解释执行，常用热点代码通过即时编译器（JIT）将字节码转换为机器码，运行效率低。而在ART 环境中，应用在安装时，字节码预编译（AOT）成机器码，安装慢了，但运行效率会提高。

2、ART占用空间比Dalvik大（字节码变为机器码）， “空间换时间"。

3、预编译也可以明显改善电池续航，因为应用程序每次运行时不用重复编译了，从而减少了 CPU 的使用频率，降低了能耗。 

---

二 ClassLoader

2.1 基本介绍

java的ClassLoader和安卓的ClassLoader不尽相同，安卓是自己实现的 ART 或者 Dalvik 虚拟机，这篇主要讲安卓中的ClassLoader。

任何一个 Java 程序都是由一个或多个 class 文件组成，在程序运行时，需要将 class 文件加载到 JVM 中才可以使用，负责加载这些 class 文件的就是 Java 的类加载机制。

但Java程序启动时，并不是一次性加载所有类然后运行，而是先把保证运行的基础类加载到jvm，其它类要用时再加载。这样的好处是节省了内存的开销（因为java最早为嵌入式系统而设计的，内存宝贵）。用到时再加载这也是java动态性的一种体现。

ClassLoader 的作用简单来说就是加载 class 文件，提供给程序运行时使用。每个 Class 对象的内部都有一个 classLoader 字段来标识自己是由哪个 ClassLoader 加载的。

class Class<T> {
  ...
  private transient ClassLoader classLoader;
  ...
}

ClassLoader是一个抽象类，而它的具体实现类主要有：

Log.e(TAG, "Activity.class 由：" + Activity.class.getClassLoader() +" 加载");
Log.e(TAG, "MainActivity.class 由：" + getClassLoader() +" 加载");
 
//输出：
Activity.class 由：java.lang.BootClassLoader@b1202a1 加载
MainActivity.class 由：dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.enjoy.enjoyfix-1/base.apk"],nativeLibraryDirectories=[/data/app/com.enjoy.enjoyfix-1/lib/x86, /system/lib, /vendor/lib]]] 加载

它们之间的关系如下：

public class DexClassLoader extends BaseDexClassLoader {
	
    public DexClassLoader(String dexPath, String optimizedDirectory,
		String librarySearchPath, ClassLoader parent) {
		super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
	}
}
 
public class PathClassLoader extends BaseDexClassLoader {
 
    public PathClassLoader(String dexPath, ClassLoader parent) {
        super(dexPath, null, null, parent);
    }
 
	public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent){
		 super(dexPath, null, librarySearchPath, parent);
	}
}

可以看到两者唯一的区别在于：创建DexClassLoader需要传递一个optimizedDirectory参数，并且会将其创建为File对象传给super，而PathClassLoader则直接给到null。因此两者都可以加载指定的dex，以及jar、zip、apk中的classes.dex

PathClassLoader pathClassLoader = new PathClassLoader("/sdcard/xx.dex", getClassLoader());
 
File dexOutputDir = context.getCodeCacheDir();
DexClassLoader dexClassLoader = new DexClassLoader("/sdcard/xx.dex",dexOutputDir.getAbsolutePath(), null,getClassLoader());

其实optimizedDirectory参数就是dexopt的产出目录(odex)。那PathClassLoader创建时，这个目录为null，就意味着不进行dexopt？并不是，optimizedDirectory为null时的默认路径为：/data/dalvik-cache。

在API 26源码中，将DexClassLoader的optimizedDirectory标记为了 deprecated 弃用，实现也变得和PathClassLoader一摸一样了：

public DexClassLoader(String dexPath, String optimizedDirectory,
          String librarySearchPath, ClassLoader parent) {
  super(dexPath, null, librarySearchPath, parent);
}

2.2 双亲委托机制

可以看到创建ClassLoader需要接收一个ClassLoader parent参数。这个parent的目的就在于实现类加载的双亲委托。即：某个类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{
	
    // 检查class是否有被加载  
	Class c = findLoadedClass(name);
	if (c == null) {
		long t0 = System.nanoTime();
		try {
			if (parent != null) {
                //如果parent不为null，则调用parent的loadClass进行加载  
				c = parent.loadClass(name, false);
            } else {
                //parent为null，则调用BootClassLoader进行加载  
                c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {
		
        }
 
        if (c == null) {
            // 如果都找不到就自己查找
			long t1 = System.nanoTime();
            c = findClass(name);
        }
	}
	return c;
}

因此我们自己创建的ClassLoader: new PathClassLoader("/sdcard/xx.dex", getClassLoader());并不仅仅只能加载 xx.dex中的class。

值得注意的是：c = findBootstrapClassOrNull(name);按照方法名理解，应该是当parent为null时候，也能够加载BootClassLoader加载的类。但是实际上，Android当中的实现为：（Java不同）

private Class findBootstrapClassOrNull(String name)
{
  return null;
}	

2.3 类加载器的三个机制（约束）

委托：如上所述，委托机制是指将加载一个类的请求交给父类加载器，如果这个父类加载器不能够找到或者加载这个类，那么再加载它。

可见性：可见性的原理是子类的加载器可以看见所有的父类加载器加载的类，而父类加载器看不到子类加载器加载的类。

单一性：单一性原理是指仅加载一个类一次，这是由委托机制确保子类加载器不会再次加载父类加载器加载过的类。

2.4 findClass

可以看到在所有父ClassLoader无法加载Class时，则会调用自己的findClass方法。findClass在ClassLoader中的定义为:

protected Class<?> findClass(String name) throws ClassNotFoundException {
	throw new ClassNotFoundException(name);
}

其实任何ClassLoader子类，都可以重写loadClass与findClass。一般如果你不想使用双亲委托，则重写loadClass修改其实现。而重写findClass则表示在双亲委托下，父ClassLoader都找不到Class的情况下，定义自己如何去查找一个Class。而我们的PathClassLoader会自己负责加载MainActivity这样的程序中自己编写的类，利用双亲委托父ClassLoader加载Framework中的Activity。说明PathClassLoader并没有重写loadClass，因此我们可以来看看PathClassLoader中的 findClass 是如何实现的。

public BaseDexClassLoader(String dexPath, File optimizedDirectory,String 	
						librarySearchPath, ClassLoader parent) {
	super(parent);
	this.pathList = new DexPathList(this, dexPath, librarySearchPath, 		
                                    optimizedDirectory);
}
 
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
	List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
    //查找指定的class
    Class c = pathList.findClass(name, suppressedExceptions);
    if (c == null) {
		ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + 														name + "\" on path: " + pathList);
        for (Throwable t : suppressedExceptions) {
			cnfe.addSuppressed(t);
        }
            throw cnfe;
	}
	return c;
}

实现非常简单，从pathList中查找class。继续查看DexPathList：

public DexPathList(ClassLoader definingContext, String dexPath,
            String librarySearchPath, File optimizedDirectory) {
	//.........
    // splitDexPath 实现为返回 List<File>.add(dexPath)
    // makeDexElements 会去 List<File>.add(dexPath) 中使用DexFile加载dex文件返回 Element数组
    this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
                                           suppressedExceptions, definingContext);
	//.........
    
}
 
public Class findClass(String name, List<Throwable> suppressed) {
     //从element中获得代表Dex的 DexFile
	for (Element element : dexElements) {
		DexFile dex = element.dexFile;
		if (dex != null) {
            //查找class
        	Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
            if (clazz != null) {
            	return clazz;
        	}
    	}
    }
    if (dexElementsSuppressedExceptions != null) {
    	suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
    }
	return null;
}

---

三 热修复

PathClassLoader中存在一个Element数组，Element类中存在一个dexFile成员表示dex文件，即：APK中有X个dex，则Element数组就有X个元素。

在PathClassLoader中的Element数组为：[patch.dex , classes.dex , classes2.dex]。如果存在Key.class位于patch.dex与classes2.dex中都存在一份，当进行类查找时，循环获得dexElements中的DexFile，查找到了Key.class则立即返回，不会再管后续的element中的DexFile是否能加载到Key.class了。

因此实际上，一种热修复实现可以将出现Bug的class单独的制作一份fix.dex文件(补丁包)，然后在程序启动时，从服务器下载fix.dex保存到某个路径，再通过fix.dex的文件路径，用其创建Element对象，然后将这个Element对象插入到我们程序的类加载器PathClassLoader的pathList中的dexElements数组头部。这样在加载出现Bug的class时会优先加载fix.dex中的修复类，从而解决Bug。

热修复的方式不止这一种，并且如果要完整实现此种热修复可能还需要注意一些其他的问题(如：反射兼容)。

参考文章：

Android Runtime (ART) 和 Dalvik

Android 热修复核心原理,  ClassLoader类加载

【小家Java】从原理层面理解Java中的类加载器

一看你就懂，超详细java中的ClassLoader详解