一、前言
无论是做Java开发，还是Android开发，ClassLoader是少不了打交道的。即便我们不围绕它做点啥，它也默默的在为我们做着事情。
顾名思义，ClassLoader就是Java编译成Class文件后，通过它加载到JVM中来运行的。
Android本身有着和Java同源的血统，因此，ClassLoader的核心功能机制是不会变的：
IO读取Class文件，解析，分配栈、堆，加载到永久代（Perm区）；
双亲委托寻找 & 加载；
二、ClassLoader的类型和继承关系
2.1、Java中的ClassLoader
- ClassLoader是一个抽象类，其中定义了ClassLoader的主要功能；
- SecureClassLoader继承了抽象类ClassLoader；
它并不是ClassLoader的实现类，而是拓展了ClassLoader类加入了权限方面的功能，加强了安全性。 - URLClassLoader类继承自SecureClassLoader，用来通过URl路径从jar文件和文件夹中加载类和资源；
- ExtClassLoader和AppClassLoader都继承自URLClassLoader，它们都是Launcher 的内部类；
Launcher 是Java虚拟机的入口应用，ExtClassLoader和AppClassLoader都是在Launcher中进行初始化的。
2.2、Android中的ClassLoader
- 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下发就失败了。
