1、Android中有哪几种ClassLoader？它们的作用和区别是什么？
在 Android 开发者官网上的 ClassLoader的文档说明中我们可以看到，ClassLoader 是个抽象类，
其具体实现的子类有 `BaseDexClassLoader` 和 `SecureClassLoader` 。
SecureClassLoader 的子类是 URLClassLoader ，
BaseDexClassLoader 的子类是 PathClassLoader 和 DexClassLoader 。
(1)UrlClassLoader
其只能用来加载 jar 文件，这在 Android 的 Dalvik/ART 上没法使用的。
(2)PathClassLoader
只能加载已经安装在Android系统内APK文件（ /data/app 目录下）,其它位置的文件加载的时候都会出现
ClassNotFoundException。因为 PathClassLoader 会去读取 /data/dalvik-cache 目录下的经过 Dalvik 优化
过的 dex 文件，这个目录的 dex 文件是在安装 apk 包的时候由 Dalvik 生成的，没有安装的时候，
自然没有生成那个文件。
(3)DexClassLoader
可加载jar/apk/dex，可以从 SD 卡上加载包含 class.dex 的 .jar 和 .apk 文件
2、简述ClassLoader的双亲委托模型
image001.jpg
(1) 双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己
去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是
如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈
自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自
己去加载。
(2)使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着
它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在
rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加
载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有
使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为
java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object
类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。
可以尝试去编写一个与rt.jar类库中已有类重名的Java类，将会发现可以正常编
译，但永远无法被加载运行。
(3)实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass（）方法之中，
先检查是否已经被加载过，若没有加载则调用父加载器的loadClass（）方
法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出
ClassNotFoundException异常后，再调用自己的findClass（）方法进行加载。
protected synchronized Class＜?＞loadClass（String name,boolean resolve）throws ClassNotFoundException
{/
/首先，检查请求的类是否已经被加载过了
Class c=findLoadedClass（name）；
if（c==null）{
try{
if（parent！=null）{
c=parent.loadClass（name,false）；
}else{
c=findBootstrapClassOrNull（name）；
}}
catch（ClassNotFoundException e）{
//如果父类加载器抛出ClassNotFoundException
//说明父类加载器无法完成加载请求
}i
f（c==null）{
//在父类加载器无法加载的时候
//再调用本身的findClass方法来进行类加载
c=findClass（name）；
}}i
f（resolve）{
resolveClass（c）；
}r
eturn c；
}
3、简述双亲委托模型在热修复领域的应用
首先在Android中是通过BaseDexClassLoader的loadClassBinaryName 来完成类加载的。
但是BaseDexClassLoader如何寻找类的呢，可以分为3步：
(1)当传入一个完整的类名，调用 BaseDexClassLader 的 findClass(String name) 方法
(2)BaseDexClassLader 的 findClass 方法会交给 DexPathList 的 findClass(String name, List<Throwable> suppressed 方法处理
(3)在 DexPathList 方法的内部，会遍历 dexFile ，通过 DexFile 的 dex.loadClassBinaryName(name, definingContext,
suppressed) 来完成类的加载
这里看看DexPathList.findClass方法
public Class findClass(String name, List<Throwable> suppressed) {
// 遍历 dexElements 数组，依次寻找对应的 class，一旦找到就终止遍历
for (Element element : dexElements) {
DexFile dex = element.dexFile;
if (dex != null) {
Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
if (clazz != null) {
return clazz;
}
}
}
// 抛出异常
if (dexElementsSuppressedExceptions != null) {
suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
}
return null;
}
热修复实现的一个点，就是将补丁 dex 文件放到 dexElements 数组前面，这样在加载 class 时，优先找到
补丁包中的 dex 文件，加载到 class 之后就不再寻找，从而原来的 apk 文件中同名的类就不会再使用，从
而达到修复的目的
热修复实际使用注意: 体现双亲委托模型机制
在项目中使用 BaseDexClassLoader 或者 DexClassLoader 去加载某个 dex 或者 apk 中的 class 时，
是无法调用 findClass() 方法的，因为该方法是包访问权限，你需要调用 loadClass(String className) ，该方法其实是
BaseDexClassLoader 的父类 ClassLoader 内实现的：
public Class<?> loadClass(String className) throws ClassNotFoundException {
return loadClass(className, false);
}
protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
Class<?> clazz = findLoadedClass(className);
if (clazz == null) {
ClassNotFoundException suppressed = null;
try {
clazz = parent.loadClass(className, false);
} catch (ClassNotFoundException e) {
suppressed = e;
}
if (clazz == null) {
try {
clazz = findClass(className);
} catch (ClassNotFoundException e) {
e.addSuppressed(suppressed);
throw e;
}
}
}
return clazz;
}
因此在热修复领域中也使用了双亲委托模型，先查找当前的 ClassLoader 是否已经加载过，如果没有就交给父 ClassLoader 去加
载，如果父 ClassLoader 没有找到，才调用当前 ClassLoader 来加载，此时就是调用上面分析的 findClass() 方法了。
