android类的加载过程,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 suppressedExceptions = new ArrayList();

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