Replugin与DroidPlugin框架比较

如果读者对插件化还有些陌生，请参考我这篇文章"大型移动应用解决之道 - 插件化"

Replugin与DroidPlugin相信读者对这两个框架都有了一些了解，这篇文章主要是笔者对这两个框架的技术实现不同的地方进行的一个总结，希望能帮助读者理解这两个框架。

Replugin与DroidPlugin共同面临的问题

1. 插件中的组件(Activity等)启动的问题？

2. 插件中的Class如何加载？

3. 插件中组件的Context如何与插件的资源绑定？

下面举例中，都以启动Activity为例。

1. 插件中组件启动的问题？

我们知道如果不在mainfest中声明组件是无法启动的，但凡插件框架都会面临这个问题。对于这个问题，两个框架的思路是相同，即采用“坑位”的方式。所谓坑位，就是在宿主app中预先声明各种类型的组件节点。

解决方法：启动坑位中定义的Activity，从而达到欺骗AMS的目的，当回到ActivityThread后在将坑位Activity替换成插件目标Activity。

两个框架都是在宿主Host App的Mainfest中预先定义各种组件(比如：Activity的每种LaunchMode都各定义一个Activity节点，每种LaunchMode+声明为独立的进程名各定义一个Activity节点，每种LaunchMode+Theme为Dialog的各定义一个Activity节点等等)，那么当启动插件中的Activity时，需要获取这个Activity在插件mainfest中的定义信息（LaunchMode,Process,Theme等），然后找到与Host App中坑位信息匹配的Activity进行启动。那么启动的Activity就是坑位中实际存在的Activity，就达到了欺骗AMS的目的。但是，要达到这个目的，两个框架的实现不同。

 

1.1 坑位的声明定义方法不同？

DroidPlugin坑位的声明是手动配置。而Replugin是根据Gradle插件在Gradle文件中定义的DSL来动态生成的。

1.2 坑位的分配方法不同？

对于使用插件的开发者，要启动一个Activity，通过DroidPlugin启动是使用系统的接口startActivity，而使用Replugin则使用框架本身提供的启动activity的接口Replugin#startActivity。DroidPlugin主要hook系统接口IActivityManager的startActivity方法，通过拦截这个方法，从而截获intent，根据intent的信息来查找坑位并分配，并将本次要启动的Intent中的Activity替换成坑位的，而目标要展示的Activity做为参数存储在了intent中。而Replugin没有Hook和拦截的过程，在Replugin#startActivity接口内部直接根据Intent信息来查找和分配坑位，并同时建立了坑位与目标展示activity之间关系。

 

对于以上，DroidPlugin插件的开发者面向的是Android系统标准接口开发，而Replugin插件开发者面向的是Replugin框架接口进行开发。

 

2. 插件中的Class如何加载？

在讲解之前，我们要先了解一下LoadedApk，LoadedApk可以认为是Apk在内存中表现，那么获取APK中的资源，Dex中的class，以及Classloader，包括生成Application对象都是通过LoadedApk来完成的。

 

通过上面的介绍，我们就不难知道每个组件的Class的加载是通过LoadedApk中的ClassLoader来加载的。

那么我们从LoadedApk的ClassLoader找到切入点就好了，没错，DroidPlugin与Replugin均是Hook的LoadedApk的ClassLoader，来拦截ClassLoader#loadClass。 但是实现落有不同。

Droidplugin拦截ActivityThread#handleLaunchActivity通过反射修改ActivityClientRecord#intent将坑位替换成目标Activity，然后反射创建插件的LoadedApk，同时创建插件的DexClassloader，并将DexClassLoader注入到LoadedApk中，如果插件的Application没有创建，则通过反射调用LoadedApk#makeApplication创建Application并执行Applicaton#attah,Application#onCreate，那么Application和插件的LoadedApk进行了绑定。经过以上流程之后，在ActivityThread#performLaunchActivity被调用时使用的正是插件的LoadedApk#mClassLoader来加载class，这样就完成了加载插件class的流程。

其实从这，我们能看出，DroidPlugin把插件做为一个普通的应用去进行了加载，插件的内存结构基本与普通应用一致。

Replugin通过Hook宿主Application#LoadedApk中的ClassLoader对象（通常一个应用对应一个LoadedApk对象，而Application中的LoadedApk就是在应用启动时创建的，在ActivityThread#handleBindApplication完成的，那么应用组件的Class的加载都是基于这个LoadedApk来完成的），所以，这也是Replugin唯一的hook点。然后将Replugin中自定义的PathClassLoader注入到LoadedApk中，这个PathClassLoader是对宿主PathClassLoader的代理（比如：自定义的PathClassLoader重写了findResource，而findResource中的实现是调用的原LoadedApk中的PathClassLoader的findResource方法），并重写了loadClass方法，按照Classloader的双亲委托模型，先到父loader上去找，没有找到在去插件的ClassLoader中去查找，每个插件也有自己的DexClassLoader，如果插件的Classloader找不到再到宿主Classloader中去查找，在loadClass的时候，如果发现这个className是一个坑位的Class，并且能够找到这个坑位和目标class的对应关系，那么loadClass返回的就是目标的Class。 这样就完成了加载插件class的流程。

 

3. 插件中组件的Context如何与插件的资源绑定？

Droidplugin中每个插件都有自己的LoadedApk，在通过插件的LoadedApk创建完activity实例之后，都会通过ContextImpl#createActivityContext来创建Activity的Context对象，在创建ContextImpl对象时就通过LoadedApk#getResource创建了Resource并且赋值给了ConetextImpl#mResource对象，然后调用Activity#attach方法将Context对象赋值给ContextWrapper#mBase(由于Activity继承ContextWrapper)，这样插件的Resource就与Activity绑定在了一起。 上面的流程其实也是普通应用Activity与Resource对象绑定的流程。

在Replugin中，是通过继承ContextThemeWrapper来自定义了一个PluginContext，从上面我们知道，正常情况下Context的getResource方法是通过LoadedApk来获取的，而对于replugin来说，插件是没有LoadedApk的，所以PluginContext重写了Context#getResource(这个返回值是通过PackageManager#getResourcesForApplication来返回的)，PluginContext的getResource返回的就是插件的Resource对象。 而activity与这个PluginContext如何绑定的呢？ 在Replugin中需要继承PluginActivity(如果没有继承也会通过gradle插件在编译后，动态的替换Class)，PluginActivity中重写了attachBaseContext，然后在attachBaseContext方法中获取这个Activity对应的插件的PluginContext，然后赋值给ContextWrapper#mBase，这样就完成了绑定。