一下文章摘录自Android插件化学习之路（二）之ClassLoader完全解析并添加了一些属于自己的理解
介绍
Android的Dalvik/ART虚拟机如同标准的JAVA的JVM虚拟机一样，在程序运行时首先需要将对应的类加载到内存中。因此，我们可以利用这一点，在程序运行时手动加载Class，从而达到动态加载可执行文件的目的。Android的Dalvik/ART虚拟机虽然与标准的JVM虚拟机不一样，ClassLoader棘突的加载细节不一样，但是工作机制都是类似的，也就是说在Android中同样可以采用类似的动态加载插件的功能，只是在Android应用中动态加载一个插件的工作要比Eclipse加载一个插件复杂许多。
java默认提供ClassLoader实例
1.BootStrap ClassLoader：称为启动类加载器，是Java类加载层次中最顶层的类加载器，负责加载JDK中的核心类库，如：rt.jar、resources.jar、charsets.jar等，可通过如下程序获得该类加载器从哪些地方加载了相关的jar或class文件。
2.Extension ClassLoader：称为扩展类加载器，负责加载Java的扩展类库，默认加载JAVA_HOME/jre/lib/ext/目下的所有jar
3.App ClassLoader：称为系统类加载器，负责加载应用程序classpath目录下的所有jar和class文件
注意： 除了Java默认提供的三个ClassLoader之外，用户还可以根据需要定义自已的ClassLoader，而这些自定义的ClassLoader都必须继承自java.lang.ClassLoader类，也包括Java提供的另外二个ClassLoader（Extension ClassLoader和App ClassLoader）在内，但是Bootstrap ClassLoader不继承自ClassLoader，因为它不是一个普通的Java类，底层由C++编写，已嵌入到了JVM内核当中，当JVM启动后，Bootstrap ClassLoader也随着启动，负责加载完核心类库后，并构造Extension ClassLoader和App ClassLoader类加载器
Android平台下的ClassLoader实例
我们先来看下在Android SDK 中ClassLoader的继承关系图：
其实跟我们热修复和插件化相关的是我圈出来的三个类：BaseDexClassLoader、PathClassLoader和DexClassLoader。
动态加载的基础是ClassLoader，它就是专门用来处理类加载工作的，所以它也叫类加载器，而且一个运行的APP不仅仅只有一个类加载器。
当我们在Activity的onCreate中调用以下代码时：
ClassLoader classLoader = getClassLoader();
if (classLoader != null) {
Log.v(TAG, "MainActivity classLoader===>" + classLoader.toString());
while (classLoader.getParent() != null) {
classLoader = classLoader.getParent();
Log.v(TAG, "MainActivity classLoader===>" + classLoader.toString());
}
}
会打印出以下日志
由此我们可以得出以下结论：一般一个app最少都会有两个ClassLoader，即PathClassLoader和BootClassLoader。下面就来介绍下两个ClassLoader：
BootClassLoader：Android系统启动时会使用BootClassLoader来预加载常用类，与Java中的BootClassLoader不同，它并不是由C/C++代码实现，而是由Java实现的。BootClassLoader是ClassLoader的内部类，并继承自ClassLoader。BootClassLoader是一个单例类，需要注意的是BootClassLoader的访问修饰符是默认的，只有在同一个包中才可以访问，因此我们在应用程序中是无法直接调用的
PathClassLoader:Android系统使用PathClassLoader来加载系统类和应用程序的类，如果是加载非系统应用程序类，则会加载data/app/目录下的dex文件以及包含dex的apk文件或jar文件，不管是加载那种文件，最终都是要加载dex文件，在这里为了方便理解，我们将dex文件以及包含dex的apk文件或jar文件统称为dex相关文件。PathClassLoader不建议开发直接使用。PathClassLoader继承自BaseDexClassLoader，很明显PathClassLoader的方法实现都在BaseDexClassLoader中。从PathClassLoader的构造方法也可以看出它遵循了双亲委托模式。
要了解Java和Android的ClassLoader的区别请参考：
Android解析ClassLoader（二）Android中的ClassLoader
创建我们自己的ClassLoader
如果我们要加载外部的dex文件，往往都会创建我们自己的ClassLoader实例来来加载dex中的Class，首先我们来看下ClassLoader的构造函数
private ClassLoader(Void unused, ClassLoader parent) {
this.parent = parent;
}
我们看到我们在创建自己的ClassLoader对象的时候会强制让我们传入一个现有的ClassLoader实例作为新创建的实例的Parent。这样一来，一个Android应用，甚至整个Android系统里所有的ClassLoader实例都会被一颗树所关联起来，这也是ClassLoader双亲委托得到特点。
在JVM中ClassLoader通过defineClass方法加载jar里面的Class，而在Android中这个方法被废弃了。
取而代之的方法是loadClass方法
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
try {
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) {
// If still not found, then invoke findClass in order
// to find the class.
c = findClass(name);
}
}
return c;
}
通过上面的代码我们可以发现类的加载过程如下：
1.查询当前实例是否已经被加载过，如果已经被加载过则直接返回
2.如果没有加载过，则查询parent是否已经加载过，如果已经加载过则直接返回
3.如果继承路上的ClassLoader都没有加载过，才由当前的ClassLoader执行加载工作
这样就做到了双亲委托的功能，加入一个类已经被父ClassLoader加载过，那么子ClassLoader就不会再去重新加载了。
如果你希望通过动态加载的方式，加载一个外部的dex文件，使用里面的新类去替换旧类，从而达到bug的修复，那么你必须保证新类在旧类之前被加载，否则新类则永远不会被加载了。
如果我们的旧类始终在新类之前被加载，我们也可以使用一个与加载旧类的ClassLoader没有树继承关系的另一个ClassLoader来加载新类，不过这里又会出现另一个问题，在Java中，当两个实例的类名、包名、以及其加载器都相同时，才会被认为是同一种类型。所以使用行的ClassLoader加载的新类与旧类并不是同一种类型，在实际使用过程中，会出现类型不匹配的问题。
同一个Class = 相同的（ClassName + PackageName + ClassLoader）
DexClassLoader与PathClassLoader
class DexClassLoader extends BaseDexClassLoader {
public DexClassLoader(String dexPath, String optimizedDirectory, String libraryPath, ClassLoader parent) {
super(dexPath, new File(optimizedDirectory), libraryPath, parent);
}
}
class PathClassLoader extends BaseDexClassLoader {
public PathClassLoader(String dexPath, ClassLoader parent) {
super(dexPath, null, null, parent);
}
public PathClassLoader(String dexPath, String libraryPath, ClassLoader parent) {
super(dexPath, null, libraryPath, parent);
}
}
可以看到两者都是对BaseDexClassLoader做了一层封装，具体的实现还是交给了父类。两者在调用父类构造方法时只是入参不同。我们来看下这个optimizedDirectory具体干什么的？
public BaseDexClassLoader(String dexPath, File optimizedDirectory, String libraryPath, ClassLoader parent) {
super(parent);
this.originalPath = dexPath;
this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
}
public DexPathList(ClassLoader definingContext, String dexPath, String libraryPath, File optimizedDirectory) {
……
this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory);
}
private static Element[] makeDexElements(ArrayList<File> files, File optimizedDirectory) {
ArrayList<Element> elements = new ArrayList<Element>();
for (File file : files) {
ZipFile zip = null;
DexFile dex = null;
String name = file.getName();
if (name.endsWith(DEX_SUFFIX)) {
dex = loadDexFile(file, optimizedDirectory);
} else if (name.endsWith(APK_SUFFIX) || name.endsWith(JAR_SUFFIX) || name.endsWith(ZIP_SUFFIX)) {
zip = new ZipFile(file);
}
……
if ((zip != null) || (dex != null)) {
elements.add(new Element(file, zip, dex));
}
} return elements.toArray(new Element[elements.size()]);
}
private static DexFile loadDexFile(File file, File optimizedDirectory) throws IOException {
if (optimizedDirectory == null) {
return new DexFile(file);
} else {
String optimizedPath = optimizedPathFor(file, optimizedDirectory);
return DexFile.loadDex(file.getPath(), optimizedPath, 0);
}
}
/**
* Converts a dex/jar file path and an output directory to an * output file path for an associated optimized dex file.
*/
private static String optimizedPathFor(File path, File optimizedDirectory) {
String fileName = path.getName();
if (!fileName.endsWith(DEX_SUFFIX)) {
int lastDot = fileName.lastIndexOf(".");
if (lastDot < 0) {
fileName += DEX_SUFFIX;
} else {
StringBuilder sb = new StringBuilder(lastDot + 4);
sb.append(fileName, 0, lastDot);
sb.append(DEX_SUFFIX);
fileName = sb.toString();
}
}
File result = new File(optimizedDirectory, fileName);
return result.getPath();
}
我们可以看到，optimizedDirectory是用来缓存我们需要加载的dex文件，并创建一个DexFile对象，如果它为null，那么会直接使用dex文件原有的路径来创建DexFile对象。
optimizedDirectory必须是一个内部存储路径，还记得我们之前说过的，无论哪种动态加载，加载的可执行文件一定要存放在内部存储。DexClassLoader可以指定自己的optimizedDirectory，所以它可以加载外部的dex，因为这个dex会被复制到内部路径的optimizedDirectory；而PathClassLoader没有optimizedDirectory，所以它只能加载内部的dex，这些大都是存在系统中已经安装过的apk里面的。
类的加载过程
上面只是创建了类加载器的实例，然后内部创建了一个DexFile实例，用来保存dex文件，我们猜想这个实例就是用来加载类的。
Android中，ClassLoader用loadClass方法来加载我们需要的类。
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;
}
loadClass方法调用了findClass方法，而BaseDexClassLoader重载了这个方法，得到BaseDexClassLoader看看
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
Class clazz = pathList.findClass(name);
if (clazz == null) {
throw new ClassNotFoundException(name);
}
return clazz;
}
结果还是调用了DexPathList的findClass
public Class findClass(String name) {
for (Element element : dexElements) {
DexFile dex = element.dexFile;
if (dex != null) {
Class clazz = dex.loadClassBinaryName(name, definingContext);
if (clazz != null) {
return clazz;
}
}
}
return null;
}
这里遍历了之前所有的DexFile实例，其实也就是遍历了所有加载过的dex文件，再调用loadClassBinaryName方法一个个尝试能不能加载想要的类，真是简单粗暴
public Class loadClassBinaryName(String name, ClassLoader loader) {
return defineClass(name, loader, mCookie);
}
private native static Class defineClass(String name, ClassLoader loader, int cookie);
看到这里想必大家都明白了，loadClassBinaryName中调用了Native方法defineClass加载类。
至此，ClassLoader的创建和加载类的过程的完成了。有趣的是，标准JVM中，ClassLoader是用defineClass加载类的，而Android中defineClass被弃用了，改用了loadClass方法，而且加载类的过程也挪到了DexFile中，在DexFile中加载类的具体方法也叫defineClass，不知道是Google故意写成这样的还是巧合.
Android程序比起使用动态加载时麻烦在哪里
通过上面的分析，我们知道使用ClassLoader动态加载一个外部的类是非常容易的事情，所以很容易就能实现动态加载新的可执行代码的功能，但是比起一般的Java程序，在Android程序中使用动态加载主要有两个麻烦的问题：
Android中许多组件类（如Activity、Service等）是需要在Manifest文件里面注册后才能工作的（系统会检查该组件有没有注册），所以即使动态加载了一个新的组件类进来，没有注册的话还是无法工作；
Res资源是Android开发中经常用到的，而Android是把这些资源用对应的R.id注册好，运行时通过这些ID从Resource实例中获取对应的资源。如果是运行时动态加载进来的新类，那类里面用到R.id的地方将会抛出找不到资源或者用错资源的异常，因为新类的资源ID根本和现有的Resource实例中保存的资源ID对不上；
