Android 全面插件化 RePlugin 流程与源码解析

转自

Android 全面插件化 RePlugin 流程与源码解析

RePlugin，360开源的全面插件化框架，按照官网说的，其目的是“尽可能多的让模块变成插件”，并在很稳定的前提下，尽可能像开发普通App那样灵活。那么下面就让我们一起深入♂了解它吧。 （ps ：阅读本文请多参考源码图片 (￣^￣)ゞ ）

一、介绍

　　RePlugin对比其他插件化，它的强大和特色，在于它只Hook住了ClassLoader。One Hook这个坚持，最大程度保证了稳定性、兼容性和可维护性，详见《全面插件化——RePlugin的使命》。当然，One Hook也极大的提高了实现复杂程度性，其中主要体现在：

• 增加了Gradle插件脚本，实现开发中自动代码修改与生成。
• 分割了插件库和宿主库的代码实现。
• 代码中存在很多不少@deprecated、TODO和临时修改。
• 初始化、加载、启动等逻辑比较复杂。

 

图一 Replugin项目结构

 

　　本篇将竭尽所能，为各位介绍其流程和内部实现，如果存在一些地方存在纰漏，还请指出。文章篇幅较长，需耐心阅读，阅读时可结合图片源码，同时欢迎收藏，或选择感兴趣点阅读，下面主要涉及：

• 二、ClassLoader基础知识。
• 三、Replugin项目原理和结构分析。
• 四、Replugin的ClassLoader。
• 五、Replugin的相关类介绍。
• 六、Replugin的初始化。
• 七、Replugin启动Activity。

 

此处应有图

 

二、ClassLoader基础知识

　　既然Replugin选择Hook住ClassLoader，那先简单介绍下ClassLoader的基本知识吧，如熟悉者请略过。

　　ClassLoader又叫类加载器，是专门处理类加载，一个APP可以存在多个ClassLoader，它使用的是双亲代理模型，如下图所示，创建一个ClassLoader，需要使用一个已有的ClassLoader对象，作为新建的实例的ParentLoader。

 

抽象基类ClassLoader

 

　　这样的条件下，一个App中所有的ClassLoader都联系了起来。当加载类时，如果当前ClassLoader未加载此类，就查询ParentLoader是否加载过，一直往上查找，如果存在就返回，如果都没有，就执行该Loader去执行加载工作。这样避免了类重复加载的浪费。其中常见的Loader有：

• BootClassLoader 是系统启动时创建的，一般不需要用到。
• PathClassLoader 是应用启动时创建的，只能加载内部dex。
• DexClassLoader 可以加载外部的dex。

RePlugin中存在两个主要ClassLoaer：

• 1、RePluginClassLoader： 宿主App中的Loader，继承PathClassLoader，也是唯一Hook住系统的Loader。

• 2、PluginDexClassLoader： 加载插件的Loader，继承DexClassLoader。用来做一些“更高级”的特性。

三、Replugin项目原理和结构分析

1、基础原理

　　简单来说，其核心是hook住了 ClassLoader，在Activity启动前：

• 记录下目标页 ActivityA，替换成已自动注册在 AndroidManifest 中的坑位 ActivityNS。
• 在 ClassLoader 中拦截ActivityNS的创建，创建出ActivityA返回。
• 返回的ActivityA占用着 ActivityNS 这个坑位，坑位由Gradle编译时自动生成在AndroidManifest中。

　　在编译时，replugin-replugin-library脚本，会替换代码中的基础类和方法。如下图【官方原理图】所示，替换的基类里会做一些初始化，所以这一块稍微有点入侵性。此外，replugin-host-library会生成AndroidManifest、配置相关信息、打包等，也由Gradle插件自动完成。

　　打包独立APK，或者打包为插件，可单可插，这就是RePlugin。

　　

官方原理图

 

2、项目结构

　　RePlugin整个项目结构，目前分为四个module，其中又分为两个gradle插件module，两个library的java module，详细如开头【图一 Replugin项目结构】，本文主要分析library相关，如果对gradle插件感兴趣的，可以查看结尾其他推荐。

2.1、replugin-host-gradle :

　　对应com.qihoo360.replugin:replugin-host-gradle:xxx依赖，主要负责在主程序的编译期中生产各类文件：

• 根据用户的配置文件，生成HostBuildConfig类，方便插件框架读取并自定义其属性，如：进程数、各类型占位坑的数量、是否使用AppCompat库、Host版本、pulgins-builtin.json文件名、内置插件文件名等。

• 自动生成带 RePlugin 插件坑位的 AndroidManifest.xml文件，文件中带有如：

  <activity 
    android:theme="@style/Theme.AppCompat" 
    android:name="com.qihoo360.replugin.sample.host.loader.a.ActivityN1STTS0"
    android:exported="false" 
    android:screenOrientation="portrait"
    android:configChanges="keyboard|keyboardHidden|orientation|screenSize" 
  />

2.2、replugin-host-library：

　　对应com.qihoo360.replugin:replugin-host-lib:xxx依赖，是一个Java工程，由主程序负责引入，是RePlugin的核心工程，负责初始化、加载、启动、管理插件等。

2.3、replugin-plugin-gradle：

　　对应com.qihoo360.replugin:replugin-plugin-gradle:xxx ，是一个Gradle插件，由插件负责引入，主要负责在插件的编译期中：配置插件打包相关信息；动态替换插件工程中的继承基类，如下，修改Activity的继承、Provider的重定向等。

    /* LoaderActivity 替换规则 */
    def private static loaderActivityRules = [
            'android.app.Activity'                    : 'com.qihoo360.replugin.loader.a.PluginActivity',
            'android.app.TabActivity'                 : 'com.qihoo360.replugin.loader.a.PluginTabActivity',
            'android.app.ListActivity'                : 'com.qihoo360.replugin.loader.a.PluginListActivity',
            'android.app.ActivityGroup'               : 'com.qihoo360.replugin.loader.a.PluginActivityGroup',
            'android.support.v4.app.FragmentActivity' : 'com.qihoo360.replugin.loader.a.PluginFragmentActivity',
            'android.support.v7.app.AppCompatActivity': 'com.qihoo360.replugin.loader.a.PluginAppCompatActivity',
            'android.preference.PreferenceActivity'   : 'com.qihoo360.replugin.loader.a.PluginPreferenceActivity',
            'android.app.ExpandableListActivity'      : 'com.qihoo360.replugin.loader.a.PluginExpandableListActivity'
    ]

2.4、replugin-plugin-library：

　　对应com.qihoo360.replugin:replugin-plugin-lib:xxx依赖，是一个Java工程，由插件端负责引入，主要提供通过“Java反射”来调用主程序中RePlugin Host Library的相关接口，并提供“双向通信”的能力，以及各种基类Activity等
　　
　　其中的RePlugin、RePluginInternal、PluginServiceClient都是反射宿主App ：replugin-host-library 中的 RePlugin 、 RePluginInternal 、PluginServiceClient 类方法。

四、Replugin的ClassLoader。

　　这里主要介绍，宿主和插件使用的ClassLoader，以及它们的创建和Hook住时机。这是RePlugin唯一的Hook点，而其中插件ClassLoader和宿主ClassLoader是相互关系的，如下图。

 

将就的图

 

1、宿主的ClassLoader

　　RePluginClassLoader，宿主的ClassLoader，继承 PathClassLoader，构造方法使用原ClassLoader，和原ClassLoader的Parent生成。其中ParentLoader是因为双亲代理模型，创建ClassLoader所需，而原Loader用于保留在后期使用，如下图。

 

 

　　如下两图，RePluginClassLoader 在创建时，浅拷贝原Loader的资源到 RePluginClassLoader 中，用于欺骗系统还处于原Loader，并且从原Loader中反射出常用方法，用于重载方法中使用。

 

拷贝资源

 

 

方式方法

 

　　宿主Loader中，主要是重载了 loadClass，其中从 PMF（RePlugin中公开接口类）中查找class，如果存在即返回插件class，如果不存在就从原Loader中加载。从而实现了对加载类的拦截。

　　这里的 PMF 在加载class时，其实用的是下面【2、插件的ClassLoader 】：PluginDexClassLoader，这个后面流程会讲到。

 

 

2、插件的ClassLoader

　　PluginDexClassLoader，继承DexClassLoader，构造时持有了宿主的ClassLoader，从宿主ClassLoader中反射获取loadClass方法，当自己的loadClass方法找不到类时，从宿主Loader中加载。

 

　　

 

3、创建和Hook

　　创建：上面1、2中两个Loader，是宿主在初始化时创建的，初始化时可以选择配置RePluginCallbacks，callback中提供方法默认创建Loader，你也可以实现自定义的ClassLoader，但是需要继承以上的Loader，如下图。

//初始化方式创建
RePlugin.getConfig().getCallbacks()
.createClassLoader(oClassLoader.getParent(), oClassLoader);

 

RePluginCallbacks

 

　　Hook：初始化时，PatchClassLoaderUtils会在Application的attachBaseContext()中，通过patch(application)Hook住宿主的ClassLoader，patch内部如下图。

 

hook ClassLoader

 

五、Replugin的相关类介绍

　　提前介绍一些功能类，后面就不做详细介绍。

1、RePlugin ：RePlugin的对外入口类，提供install、uninstall、preload、startActivity、fetchPackageInfo、fetchComponentList，fetchClassLoader等等统一的方法入口，用户操作的主要是它。
　　
2、RePlugin.App：RePlugin中的内部类，针对Application的入口类，所有针对插件Application的调用应从此类开始和初始化，想象成插件的Application吧。

3、PmBase：RePlugin常用mPluginMgr变量表示，可以看作插件管理者。初始化插件、加载插件等一般都是从它开始。

4、PluginContainers：插件容器管理中心。

5、PmLocalImpl：各种本地接口实现，如startActivity，getActivityInfo，loadPluginActivity等。

6、PmInternalImpl：类似Activity的接口实现，内部实现了真正startActivity的逻辑、还有插件Activity生命周期的接口。
　　
- 　　

 

准备好了吗，骚年

 

六、Replugin的初始化

　　那就是从 Application 初始化开始看起，枯燥的流程就要开始了，忍住兄弟，我们能赢。首先我们先看下面这流程图，大致了解启动流程：

 

将就的看吧

 

1、attachBaseContext

　　首先是从 Application 的 attachBaseContext 初始化开始。如下图，这里主要是配置 RePluginConfig 和 RePluginCallbacks ，然后根据 Config 去初始化插件。值得注意的是，RePluginConfig 中的 RePluginCallbacks 提供了默认方法创建 RePlugin 的 ClassLoader，还记得上面的介绍吗？

 

看图看图

 

2、插件App.attachBaseContext

　　继续上面的流程，进入RePlugin.App.attachBaseContext(this, c)，如下图，这里主要是初始化插件相关的进程、配置信息、插件的主框架和接口、根据默认路径、加载默认插件等。插件的初始化从这里开始，其中主要为 PMF.init() 和 PMF.callAttach()。

 

继续看图看图

 

3、主程序接口 PMF.init()／PMF.callAttach()

　　先进入到 PMF.init() ，如下图，这里主要实例化了 PmBase 类，并初始化了它，创建了内部使用的 PmLocalImpl 和 PmInternalImp 接口 ，同时Hook住主程序的 ClassLoader，替换为 RePluginClassLoader，所以接下来的流程，主要是在 PmBase 。

 

PMF.init()，看图吧

 

　　PmBase，按照项目中的变量名 mPluginMgr，可以理解为插件的管理者，它管理内部直接或间接的，管理着坑位分配、ClassLoader、插件、进程、启动\停止页面的接口等，如下图。

 

PmBase创建，还是看图

 

　　PmBase 的初始化，也就是插件的初始化，这里会启动各类进程，初始化各种默认插件集合，为后续加载做准备。其中默认插件和配置文件的位置，一般默认是在 assert 的 plugins-builtin.json 和 "plugins" 文件夹下。

 

PmBase.init() 看图看图

 

　　接着PMF.callAttach() 其实就是 PmBase.callAttach()，如下图这里开始真正加载插件，初始化插件的 PluginDexClassLoader 、加载插件、初始化插件环境和接口。其中在执行 p.load() 的时候，会通过 Plugind.callAppLocked() 创建插件的 Application，并初始化。

 

PMF.callAttach() 看图呗

 

　　以上是在主APP的初始化，深入 PmBase 中，Plugin.load()在加载时，会调用PluginDexClassLoader， 通过类名加载 Entry 类，然后反射出create方法，执行插件的初始化。其中 Entry 位于Plugin-lib库中。这里初始化就去到了插件中了，插件中初始化时，会通过反射的到宿主host类的方法。

 

 

4、Application的onCreate

　　这里主要是切换handler到主线程，注册各种广播接收监听，如增加插件、卸载插件、更新插件，可以看出这里设计很多内部进程通信的。

 

　　　
- 　　 　　

 

七、Replugin启动Activity

　　这里仅描述了Activity启动的其中一个流程，也是简化版的，实际代码逻辑复杂多了，但是万变不离其宗，这里帮你梳理流程，描述一些关键的点，让你快速理解Activity的启动流程。

 

再将就下吧，看图

 

1、startActivity

　　从上面的流程图我们知道，启动插件Activity可以从RePlugin.startActivity开始，startActivity经历了 Factory 、 PmLocalImpl ，其实大部分启动的逻辑其实主要在 PmInternalImpl 中。

　　具体流程如下图，这里简化了实际代码，关键在于 loadPluginActivity。这里获取了插件对应的坑位，然后保存了目标Activity的信息，通过系统启动坑位。

　　因为已经Hook住了ClassLoader，在 loadClass 时再加载出目标Activity，这样坑位中承载的，便是绕过系统打开的目标Activity。下面我们进入 loadPluginActivity。

 

说了看图

 

2、loadPluginActivity

　　loadPluginActivity 其实是 PmBase 中的 PmLocalImpl 内部方法。如下图，这里主要是根据获取到 ActivityInfo，然后根据坑位去为目标Activity分配坑位。

　　其中 getActivityInfo 是通过插件名称，获得插件对象 Plugin， Plugin可能是初始化中已加载的，如果未加载就加载返回，然后根据 Plugin 中缓存的坑位信息，返回 ActivityInfo。

　　下面进入 allocActivityContainer 看坑位的分配，只有分配到坑位，插件的Activity才可以启动，这是一个IPC过程。

 

看图没？

 

2、allocActivityContainer

　　allocActivityContainer 在类 PluginProcessPer 中，还记得我们在 PmBase.init() 时初始化过它么？ 分配坑位也是RePlugin的核心之一。

　　在 allocActivityContainer 中， 主要逻辑是bindActivity ，如下图，bindActivity 去找到目标Activity匹配的容器，然后加载目标Activity判断是否存在，并建立映射，返回容器。然后分配的逻辑，在 PluginContainers.alloc 中。

 

看我大图

 

3、PluginContainers.alloc

　　alloc / alloc2 方法分配坑位，最后都是到了 allocLocked 方法中，其实RePlugin中，如下图，便是坑位分配的逻辑：

• 如果存在未启动的坑位，就使用它。
• 如果没有就找最老的：已经被释放的、或者时间最老的。
• 如果还不行，那么挤掉最老的一个。

 

看图说话

 

4、PulginActivity

　　上面的流程总结，是替换目标Activity，加载插件，分配坑位，启动目标坑位，拦截ClassLoader的loadClass去加载返回目标Activity。

　　这个时候启动的Activity还不完整，从模块框架中我们知道，在编译时，RePlugin会把继承的Activity替换为如 PluginActivity（当前还有AppComPluginActivity等）。这时候加载启动的目标Activity，其实是继承了 PluginActivity。

　　如下图， PluginActivity 重载Activity中的一些方法，实现了Activity的补全和自定义操作，如坑位管理，启动宿主Activity等。

 

 

　　至此，一个插件Activity就启动起来了，头晕目眩了没？为了实现 One Hook 这个信念，RePlugin 实现了复杂的流程，从代码中可以看出，这些年作者们从中走的的各种坑、各种妥协与坚持、复杂的技术积累、已经经历了多年的严酷考验。

　　不知道有多少人能完整看到这，码字不易，如有疏漏还是多多包涵，由于篇（tou）幅（lan）原因，关于Service等的就不多做叙述了，不知道本文对你是否能有些帮助，欢迎留言讨论。

最后说“一”句

　　为什么要去了解一个库实现原理呢？学习框架的架构思想？这是一个原因。但是归根结底，是帮助你在使用库的过程中，能靠自己解决各种问题。程序员的日常一般都忙于各种工作，各种技术群中的大佬们，大部分时候，没办法一一解答你的各种咨询，所以使用它、了解它、多尝试靠自己去探索突破吧。

其他推荐

• RePlugin Github 官方库

• RePlugin源码解析之replugin-host-gradle（宿主gradle插件） —— @osan

• RePlugin源码解析之replugin-plugin-gradle（插件的gradle插件） —— @osan

• To My Github

来源：https://www.cnblogs.com/xinmengwuheng/p/7232395.html