需求
必要特性
- 支持加载插件的dex代码，包括插件中的四大组件类；
- 支持插件访问宿主的类，且该类只会被加载一次；
补充特性
- 支持分别加载不同插件中类名相同但内容不同的类；
技术基础
- class加载的双亲委派模型: class文件优先由父类加载器加载，保证了一个class文件只会被一个类加载器加载一次；
- BaseClassLoader: 支持对一个apk进行加载，当然加载apk也是自动解析并加载其内部的dex文件。BaseClassLoader内含有一个
dexElements数组，代表dex的查找路径。class的查找过程就是顺序遍历dexElements来查找相关类。
类查找方向
=========================================>
| | | |
|---------| |--------| |---------| ...
dex1.dex dex2.dex dex3.dex
BaseDexClassLoader有两个子类：PathClassLoader， 加载已经安装过的apk，即正在运行的应用的类加载器都是PathClassLoader。DexClassLoader，加载外置的apk。
- JVM访问到一个内存不存在的class时，会优先使用调用者(当前类)的类加载器进行加载，
Class.forName(String className)方法同理。
技术方案
单ClassLoader方案
其原理和Tinker热修复的类加载机制一致。但相对简单的是由于插件化的原理天然支持CLASS_ISPREVERIFIED标志。 大致原理为：向应用的PathClassLoader中的dexElements`数组添加一个元素并赋值为插件apk路径：
类查找方向
=============================================>
| | | ｜
|---------| |--------| ... ｜--------｜
dex1.dex dex2.dex 插件.apk
这种类加载机制的模型相对简单，并且天然支持四大组件类加载。但是由于插件的代码和宿主的代码放在了同一个类加载器中，运行时插件的安装和卸载都伴随着对宿主类加载器的dexElements进行反射修改，这是一项非常危险的操作，容易对宿主运行稳定性产生影响。这种类加载模型对“独立安装”类型的插件也不友好，不支持加载不同插件中类名相同但内容不同的类。
多ClassLoader方案
每个插件对应一个自定义的DexClassLoader，用于加载各自的dex代码。
自定义DexClassLoader的类加载过程：
自定义DexClassLoader.loadClass()
=================宿主找到类就结束==============>
/ \
宿主ClassLoader.loadClass() \
\
自定义DexClassLoader.findClass()
上面的类加载过程符合抽象意义的双亲委派模型，优先从宿主的ClassLoader中查找类，即优先加载宿主的class，当宿主中没有该类时，再从插件的ClassLoader中查找。这种类加载模型并不用反射宿主的dexElements数组。
由技术基础中的第3点可知，在这种类加载模型下，宿主的类肯定是无法直接访问插件类的（默认由于组件化的限制，宿主本来就无法直接访问插件类），因此需要通过插件的ClassLoader.loadClass(String className) 来访问插件的类。当然在插件激活的时候向宿主注册插件的“功能服务”似乎是更加合理的选择。
多ClassLoader的模型还面临着一个问题——插件的四大组件的类加载。四大组件是由AMS通知ActivityThread启动的，实际上最终它们的class是由Application中的mPackageInfo的mClassLoader加载的。这一步避免不了反射，需要将mPakageInfo中的mClassLoader替换成我们的自定义的用于分发的ClassLoader。这里的自定义模型和上面的自定义DexClassLoader模型是一致的，优先从宿主进行加载，宿主找不到再从插件中加载。当然如果是四大组件都被代理的情况下，也还可以避免掉上述的这种反射问题。
多ClassLoader的模型需要较严格的项目组件化，但好处是反射较少。每个插件拥有独立的ClassLoader也能够解决不同插件中的“类重名”问题。
实际体验
单ClassLoader模型简单，但遇到的运行时兼容问题较多。多ClassLoader模型相对复杂，开发难度较高，但可以解决“类重名”问题，运行时的兼容问题很少。推荐使用多ClassLoader模型。
desc：如果使用了R8的话，插件的Kotlin代码会遇到伴生类或者lambda类被分包到宿主中去的情况。在多ClassLoader模型下，这会导致伴生/lambda类和它的宿主类分别被不同的类加载器加载，出现ClassNotFound问题。
