很早之前就想深入的研究和学习一下热修复，由于时间的原因一直拖着，现在才执笔弄起来。
Android而更新系列：
Android热更新一：JAVA的类加载机制
Android热更新二：理解Java反射
Android热更新三：Android类加载机制
Android热更新四：热修复机制
Android热更新五：四大热修复方案分析
Android热更新六：Qzone热更新原理
Android热更新七：Tinker热更新原理
Android热更新八：AndFix热更新原理
Android热更新九：Robust热更新原理
Android热更新十：自己写一个Android热修复
既然本次主题是热修复，在深入研究之前，要先搞清楚它涉及到的关键技术
类加载机制
Java反射
正所谓磨刀不误砍柴工，我们这个笔记将对Android类加载机制进行初步学习和理解。
学习Android类加载机制之前，我们先要了解JAVA的类加载机制和JAVA反射。
一. 虚拟机与加载器
我们知道Android系统也是仿照java搞了一个虚拟机，不过它不叫JVM，它叫Dalvik/ART VM。
Dalvik/ART VM 虚拟机加载类和资源也是要用到ClassLoader，不过Jvm通过ClassLoader加载的class字节码，而Dalvik/ART VM通过ClassLoader加载则是dex。
Android的类加载器分为两种,PathClassLoader和DexClassLoader，两者都继承自BaseDexClassLoader
PathClassLoader代码位于libcore\dalvik\src\main\Java\dalvik\system\PathClassLoader.java
DexClassLoader代码位于libcore\dalvik\src\main\java\dalvik\system\DexClassLoader.java
BaseDexClassLoader代码位于libcore\dalvik\src\main\java\dalvik\system\BaseDexClassLoader.java
PathClassLoader
用来加载系统类和应用类
DexClassLoader
用来加载jar、apk、dex文件.加载jar、apk也是最终抽取里面的Dex文件进行加载.
二. Dalvik虚拟机类加载流程
Dalvik虚拟机毕竟不算是标准的Java虚拟机，因此在类加载机制上，Dalvik虚拟机与Java虚拟机有许多不同之处，例如，在使用标准Java虚拟机时，我们经常自定义继承自ClassLoader的类加载器。然后通过defineClass方法来从一个二进制流中加载Class。然而，这在Dalvik虚拟机上是行不通的。
Dalvik虚拟机类加载流程如下图所示：
三. Dalvik虚拟机类加载器源码分析
Android的类加载器主要有两个PathClassLoader和DexClassLoader，其中PathClassLoader是默认的类加载器，下面我们就来说说两者的区别与联系。
- PathClassLoader：支持加载DEX或者已经安装的APK（因为存在缓存的DEX）。
- DexClassLoader：支持加载APK、DEX和JAR，也可以从SD卡进行加载。
DexClassLoader和PathClassLoader都属于符合双亲委派模型的类加载器（因为它们没有重载loadClass方法）。也就是说，它们在加载一个类之前，回去检查自己以及自己以上的类加载器是否已经加载了这个类。如果已经加载过了，就会直接将之返回，而不会重复加载。
PathClassLoader还是DexClassLoader继承于BaseDexClassLoader，BaseDexClassLoader继承鱼ClassLoader，下面我们就以一个类的加载流程来分析各个加载器的源码实现，详细的源码在下方附录中给出。
要加载一个类，必须先初始化一个类加载器实例，我们拿DexClassLoader来举例，它的构造方法如下所示：
public DexClassLoader(String dexPath, String optimizedDirectory,
String libraryPath, ClassLoader parent) {
super(dexPath, new File(optimizedDirectory), libraryPath, parent);
}
该函数中的参数含义如下所示:
- String dexPath：加载APK、DEX和JAR的路径。这个类可以用于Android动态加载DEX/JAR。
- String optimizedDirectory：是DEX的输出路径。
- String libraryPath：加载DEX的时候需要用到的lib库，libraryPath一般包括/vendor/lib和/system/lib。
- ClassLoader parent：DEXClassLoader指定的父类加载器
关于DexClassLoader，除了它的构造函数以外，它的源码注释里还提到以下三点：
- 这个类加载器加载的文件是.jar或者.apk文件，并且这个.jar或.apk中是包含classes.dex这个入口文件的，主要是用来执行那些没有被安装的一些可执行文件的。
- 这个类加载器需要一个属于应用的私有的，可以的目录作为它自己的缓存优化目录，其实这个目录也就作为下面，这个构造函数的第二个参数，至于怎么实现，注释中也已经给出了答案；
- 不要把上面第二点中提到的这个缓存目录设为外部存储，因为外部存储容易收到代码注入的攻击。
通过DexClassLoader的构造函数，我们可以发现DexClassLoader的构造函数会调用父类的构造函数进行初始化，DexClassLoader的父类就是BaseDexXClassLoader，我们继续来看一下BaseDexClassLoader的构造函数：
public BaseDexClassLoader(String dexPath, File optimizedDirectory,
String libraryPath, ClassLoader parent) {
super(parent);
this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
}
我们可以发现在执行BaseDexClassLoader的构造函数时，会先调用父类ClassLoader的构造方法：
/**
* Constructs a new instance of this class with the system class loader as
* its parent.
*/
protected ClassLoader() {
this(getSystemClassLoader(), false);
}
/**
* Constructs a new instance of this class with the specified class loader
* as its parent.
*
* @param parentLoader
* The {@code ClassLoader} to use as the new class loader's
* parent.
*/
protected ClassLoader(ClassLoader parentLoader) {
this(parentLoader, false);
}
/*
* constructor for the BootClassLoader which needs parent to be null.
*/
ClassLoader(ClassLoader parentLoader, boolean nullAllowed) {
if (parentLoader == null && !nullAllowed) {
throw new NullPointerException("parentLoader == null && !nullAllowed");
}
parent = parentLoader;
}
通过ClassLoader的构造函数源码可以发现，BaseDexClassLoader里的parentLoader对象经过层层传递，传递给了parent对象，parent对象是ClassLoader类里的私有变量，如下所示：
/**
* The parent ClassLoader.
*/
private ClassLoader parent;
这一步做完以后，BaseDexClassLoader的构造函数紧接着就初始化了一个DexPathList对象，这是一个描述DEX文相关资源文件的条目列表。
接下来看下DexPathList的构造函数
public DexPathList(ClassLoader definingContext, String dexPath,
String libraryPath, File optimizedDirectory) {
if (definingContext == null) {
throw new NullPointerException("definingContext == null");
}
if (dexPath == null) {
throw new NullPointerException("dexPath == null");
}
if (optimizedDirectory != null) {
if (!optimizedDirectory.exists()) {
throw new IllegalArgumentException(
"optimizedDirectory doesn't exist: "
+ optimizedDirectory);
}
if (!(optimizedDirectory.canRead()
&& optimizedDirectory.canWrite())) {
throw new IllegalArgumentException(
"optimizedDirectory not readable/writable: "
+ optimizedDirectory);
}
}
this.definingContext = definingContext;
ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
suppressedExceptions);
if (suppressedExceptions.size() > 0) {
this.dexElementsSuppressedExceptions =
suppressedExceptions.toArray(new IOException[suppressedExceptions.size()]);
} else {
dexElementsSuppressedExceptions = null;
}
this.nativeLibraryDirectories = splitLibraryPath(libraryPath);
}
可以看到DexPathList里比较重要dexElements也是在这里被初始化，热修复就是倒腾这个东东做到修复bug的。
this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory, suppressedExceptions);
