Android插件化——类加载器机制

需求

必要特性

1. 支持加载插件的dex代码，包括插件中的四大组件类；
2. 支持插件访问宿主的类，且该类只会被加载一次；

补充特性

1. 支持分别加载不同插件中类名相同但内容不同的类；

技术基础

1. class加载的双亲委派模型: class文件优先由父类加载器加载，保证了一个class文件只会被一个类加载器加载一次；
2. BaseClassLoader: 支持对一个apk进行加载，当然加载apk也是自动解析并加载其内部的dex文件。BaseClassLoader内含有一个dexElements数组，代表dex的查找路径。class的查找过程就是顺序遍历dexElements来查找相关类。

              类查找方向
=========================================> 
     |           |          |         |
|---------| |--------| |---------|   ...
 dex1.dex    dex2.dex   dex3.dex

BaseDexClassLoader有两个子类：PathClassLoader， 加载已经安装过的apk，即正在运行的应用的类加载器都是PathClassLoader。DexClassLoader，加载外置的apk。

3. 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问题。