android 双亲委托机制,ClassLoader之双亲委托机制

一、前言

无论是做Java开发，还是Android开发，ClassLoader是少不了打交道的。即便我们不围绕它做点啥，它也默默的在为我们做着事情。

顾名思义，ClassLoader就是Java编译成Class文件后，通过它加载到JVM中来运行的。

Android本身有着和Java同源的血统，因此，ClassLoader的核心功能机制是不会变的：

IO读取Class文件，解析，分配栈、堆，加载到永久代(Perm区)；

双亲委托寻找 & 加载；

二、ClassLoader的类型和继承关系

2.1、Java中的ClassLoader

image.png

ClassLoader是一个抽象类，其中定义了ClassLoader的主要功能；

SecureClassLoader继承了抽象类ClassLoader；

它并不是ClassLoader的实现类，而是拓展了ClassLoader类加入了权限方面的功能，加强了安全性。

URLClassLoader类继承自SecureClassLoader，用来通过URl路径从jar文件和文件夹中加载类和资源；

ExtClassLoader和AppClassLoader都继承自URLClassLoader，它们都是Launcher 的内部类；

Launcher 是Java虚拟机的入口应用，ExtClassLoader和AppClassLoader都是在Launcher中进行初始化的。

2.2、Android中的ClassLoader

image1.png

ClassLoader是一个抽象类，其中定义了ClassLoader的主要功能。BootClassLoader是它的内部类；

SecureClassLoader继承了抽象类ClassLoader；

它并不是ClassLoader的实现类，而是拓展了ClassLoader类加入了权限方面的功能，加强了安全性。

URLClassLoader类继承自SecureClassLoader，用来通过URl路径从jar文件和文件夹中加载类和资源；

InMemoryDexClassLoader是Android8.0新增的类加载器，继承自BaseDexClassLoader，用于加载内存中的dex文件；

BaseDexClassLoader继承自ClassLoader，是抽象类ClassLoader的具体实现类，PathClassLoader和DexClassLoader都继承它；

2.3、Android各ClassLoader区别

BootClassLoader，它是 Android 中最顶层的 ClassLoader，继承自ClassLoader，C代码编写，不能被继承和修改。

PathClassLoader：只能加载已经安装到Android系统中的apk文件(/data/app目录)，是Android默认使用的类加载器。

DexClassLoader：可以加载任意目录下的dex/jar/apk/zip文件，比PathClassLoader更灵活，是实现热修复的重点。

三、类加载机制(双亲委托机制保证类的唯一性)

先来看看 DexClassLoader 和 PathClassLoader，只有继承，并没有重载 loadClass 这个类加载方法：

package dalvik.system;

public class DexClassLoader extends BaseDexClassLoader {

public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {

super(dexPath, null, librarySearchPath, parent);

}

}

///

package dalvik.system;

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);

}

}

loadClass 在 BaseDexClassLoader 中也没有重载，实际的实现，还是在 JDK的 ClassLoader 中：

protected Class> loadClass(String name, boolean resolve) throws ClassNotFoundException {

// 1. 先检查该类是否已经被当前 XxxClassLoader 加载

Class> c = findLoadedClass(name);

if (c == null) {

try {

// 2. 如果没有加载，且有父类加载器，就让父类重复该过程

if (parent != null) {

c = parent.loadClass(name, false);

} else {

c = findBootstrapClassOrNull(name);

}

} catch (ClassNotFoundException e) {

// ClassNotFoundException thrown if class not found

// from the non-null parent class loader

}

if (c == null) {

// 3. 如果没有找到, 调用自身查找方法，该方法需要子类Override实现，

// 否则抛异常：ClassNotFoundException

c = findClass(name);

}

}

return c;

}

protected final Class> findLoadedClass(String name) {

ClassLoader loader;

if (this == BootClassLoader.getInstance())

loader = null;

else

// DexClassLoader/PathClassLoader -> BaseDexClassLoader -> Native..

loader = this;

return VMClassLoader.findLoadedClass(loader, name);

}

回顾上面3个步骤：

除了顶层类加载器外，其他的类加载器都有自己的父类加载器，在加载类时首先判断这个类是否被加载过，如果已经加载则直接返回；

如果未被加载过，则先尝试让父加载器进行加载，最终所有加载请求都会传递给顶层的加载器中；

当父加载器发现未找到所需的类而无法完成加载请求时，子加载器的findClass方法中进行加载；

这就是双亲委托机制：当未加载类时，永远先委托父类去查找 / 加载！

不要觉得这是给父类『找麻烦』，这实际上是一种机制：保证一个类的唯一性！

双亲委托机制可以保证同一个全限定名的class，可以被同一个ClassLoader加载！

类的唯一性判断：

JVM 判定两个 class 是否相同：

判断两个类名是否相同；

判断是否由同一个类加载器实例加载；

只有两者同时满足的情况下，JVM 才认为这两个 class 是相同的。

注：同一个class，如果被两个不同的 ClassLoader 实例所加载，JVM 也会认为它们是两个不同 class。

四、热修复技术

一个APK，可能有一个或多个 dex 文件，如果 classes.dex 和 classes1.dex 有重复的类，当系统加载到这个重复类时，会如何？

一个 ClassLoader 可以有多个 dex 文件(存在 dexPathList 中)，每个 dex 文件是一个 Element，多个 dex 文件排列成一个有序的数组(dexElements)，当查找某个类时，会按顺序遍历 dex 文件，如果找到则返回；找不到则继续从下一个 dex 中查找。

因此靠前的 dex 文件会优先被选择(多个 dex 中有重复的类，则最靠前的被加载，后面的不会再被加载，因为有双亲委托机制)。

4.1、基于 dex 分包方案

基于DEX分包方案，使用了多DEX加载的原理。

大致的过程就是：把bug方法修复以后，放到一个单独的dex里，插入到dexElements数组的最前面，让虚拟机去加载修复完后的方法。

当patch.dex中包含Test.class时就会优先加载，在后续的DEX中遇到Test.class的话就会直接返回而不去加载，这样就达到了修复的目的。

详细步骤如下：

(1)通过获取到当前应用的Classloader，即为BaseDexClassloader；

(2)通过反射获取到他的DexPathList属性对象pathList；

(3)通过反射调用pathList的dexElements方法把patch.dex转化为Element[]；

(4)两个Element[]进行合并，把patch.dex放到最前面去；

(5)根据类的加载机制，加载Element[]，达到修复目的。

特点是产很灵活，对开发者透明，但是不支持即时生效，必须通过重启才能生效。另外当插入的dex比较多的时候影响启动性能比较大。

4.2、阿里的 AndFix 方案

AndFix提供了一种运行时在Native修改Filed指针的方式，实现方法的替换，达到即时生效无需重启，对应用无性能消耗的目的。

AndFix对ART设备同样支持，具体的过程与Dalvik相似。

替换流程如下：

Dalvik设备——>Native层找到被替换的类——>将类的状态设置为初始化完毕——>得到新旧方法的指针——>操作指针，指针指向新的替换方法——>完成新的方法替换。

特点是及时性强，不需要重启手机，生成的差量包小，性能损耗小，缺点是是不支持新增字段，也不支持对资源的替换，和ROM关系很大，一旦厂商修改ROM下发就失败了。