插件化总结一普通类的加载

1、

2、

3、

4、

5、

6、

7、

8、

首先无论是宿主apk还是Aar这种依赖工程，还是各个插件bundle，它们都是有自己的清单文件的。普通的Android工程，在依赖Aar也就是library工程的时候，就有了多个清单文件，所以gradle在构建最终的清单文件的时候，会将各个manifest文件merge到apk文件中。插件化会修改整个打包流程，在输出apk的mainifest文件的时候会将所有插件中的清单文件都合并到宿主清单文件中，这样宿主manifest就记录了所有Aar及各插件文件中的清单内容，这样会保证在后续调用插件中的一些组件的时候不会报错。所以，光是清单文件的这部分处理，其实就已经非常复杂了，你不仅需要了解gradle的打包原理，甚至需要会去修改它的流程，从而让它完成你想要的工作，因为它默认的打包流程是不会合并插件中的清单文件的。总结一下插件化框架对manifest的处理，它主要核心是两个工作，第一个工作是文件的合并，这一步其实比较简单，其实就是文件的io操作，将所有的清单文件都合并到一个总的清单文件中。第二个比较复杂，你需要修改整个的构建流程，这样新的构建流程才能将所有插件中的清单文件合并到宿主清单文件中。

9、

每个插件都是一个apk，既然是apk，它里面就有自己的dex文件，所有的字节码就存在各个插件的dex文件中。

如上图所示，首先会区分宿主apk和各个插件apk的。为什么要区分呢？由于宿主apk已经安装到了系统中，所以Android系统会给宿主apk创建它自己的classLoader，而无需我们手动去创建。所以宿主apk中的classLoader有pathClassLoader就够用了。

各个插件apk，由于各个业务apk并没有安装到系统中，所以各个插件apk本身是没有classLoader的。也就是Android系统不会为没有安装的apk创建classLoader。而要想加载插件中的apk文件，又必须要有classLoader，这时候就需要插件化框架了。插件化框架会给每个插件创建对应的classLoader，这样在加载每个插件apk时会使用插件化框架为每个插件创建的classLoader去加载对应文件中的class文件。也就是上图中第2句话的意思，BundleClassLoader的父对象一般都是BootClassLoader，并且BootClassLoader中包含了宿主的PathClassLoader，这样在宿主没有加载过这个类的时候呢，就调用插件化给它注入的这个BootClassLoader去完成类的加载。所以宿主Bundle和插件Bundle，Bundle就是插件的意思，就要分别对待。宿主Bundle核心就是系统帮它创建好了classLoader,而且还是PathClassLoader，而各个插件由于没有安装，所以是由插件化框架为其创建对应的classLoader去完成类的加载。

10、

是不是要为每个apk都创建一个classLoader?答案是肯定的。Android系统会为每个安装过的apk至少分配一个classLoader,就是pathClassLoader。插件化框架，这部分是替代系统的，所以它也要为每个插件创建一个classLoader,这是原因一。原因二是每个插件和宿主都有可能有同名的文件，如果不为每个插件创建单独的classLoader的话，那么这些路径一样的类，只有被加载过一次，就不再会被加载。这样就会导致插件中的类有可能永远没有机会去加载。出于这个原因也需要为每个类创建一个单独的classLoader.实际插件化框架中，不仅要为每个插件创建classLoader，还要为每个插件维护classLoader,保证每个插件的类都可以被加载到。