RePlugin 关于插件管理

RePlugin GitHub 主页

RePlugin Wiki 主页

RePlugin Wiki 插件的管理

RePlugin 原理剖析

全面插件化：RePlugin 的使命

大致目录：

* 前言

* 外置插件

  * 安装插件

  * 升级插件

  * 卸载插件

* 内置插件

  * 添加内置插件

  * 删除内置插件

  * 使用内置插件的时机

  * 内置插件的升级

* 预加载插件

* 插件的运行

* 安全与签名校验

* 插件管理进程

* 插件的目录结构

一、前言

无论是插件还是主程序，都可以对自己和其它插件做相应的插件管理工作。但需要理解的是：不是所有的 APK 都能作为 RePlugin 的插件并安装进来的。必须要严格按照《插件接入指南》中所述完成接入，其编译出的 APK 才能成为插件，且这个 APK 同时也可以被安装到设备中。

二、外置插件

外置插件是指可通过“下载”、“放入SD卡”等方式来安装并运行的插件。以下是外置插件的管理方案：

2.1 安装插件

要安装一个插件，只需使用 RePlugin.install() 方法，传递一个 APK 路径即可。

RePlugin.install("/sdcard/exam.apk");

注意

• 无论安装还是升级，都会将源文件移动（而非复制）到插件的安装路径（如 app_p_a）上，这样可大幅度节省安装和升级时间，但显然的，源文件也就会消失。

  • 若想改变这个行为，你可以参考 RePluginConfig 中的 setMoveFileWhenInstalling() 方法

  • 升级插件和此等同，故不再赘述

2.1.1 最佳实践

以下为 360 手机卫士或其它合作 App 采用的设计，可供你参考：

• 除非是基础和核心功能插件，否则请尽量减少“静默安装”（指的是用户无感知的情况下，偷偷在后台安装）插件的情况，以减少内部存储空间的消耗，降低对用户的影响。

• 若插件需要下载，则请覆写 RePluginCallbacks.onPluginNotExistsForActivity() 方法，并在此打开你的下载页面并控制其逻辑

• 下载插件前建议告知用户其插件大小，尤其针对运营商网络的情况

有关“插件下载”的处理，以及针对插件安装失败原因做进一步的操作，请阅读《自定义您的 RePlugin》 中“在插件不存在时，提示下载”一节。

2.1.2 安装或升级失败？

安装或升级失败（返回值为 Null）的原因有如下几种：

• 是否开启了“签名校验”功能且签名不在“白名单”之中？—— 通常在 Logcat 中会出现 “verifySignature: invalid cert: ”。如是，则请参考安全与签名校验一节，了解如何将签名加白，或关闭签名校验功能（默认为关闭）

• 是否将 replugin-host-lib 升级到 2.1.4 及以上？—— 在 2.1.3 及之前版本，若没有填写 “meta-data”，则可能导致安装失败，返回值为 null。官方在 2.1.4 版本中已经修复了此问题（卫士和其它 App 的所有插件都填写了 meta-data，所以问题没出现）

• APK 安装包是否有问题？—— 请将插件 APK 直接安装到设备上（而非作为插件）试试。如果在设备中安装失败，则插件安装也一定是失败的。

• 是否没有 SD 卡的读写权限？—— 如果你的插件 APK 放到了 SD 卡上，则请务必确保主程序中拥有 SD 卡权限（主程序 Manifest 要声明，且 ROM 允许），否则会出现权限问题，当然，放入应用的 files 目录则不受影响。

• 设备内部存储空间是否不足？—— 通常出现此问题时其 Logcat 会出现 “copyOrMoveApk: Copy/Move Failed” 的警告。如是，则需要告知用户去清理手机。

2.2 升级插件

为了简化操作，升级插件的做法和安装是一样的，仍可以直接调用 RePlugin.install() 方法。

RePlugin.install("/sdcard/exam_new.apk");

注意

• 如果插件正在运行，则不会立即升级，而是“缓存”起来。直到所有“正在使用插件”的进程结束并重启后才会生效

• 升级可能会占用内部存储空间（因为要释放新的 APK）

• 不支持“插件降级”，但可以“同版本覆盖”（在 RePlugin 2.1.5 版本中开始支持)

出于稳定性和实际需求考虑，RePlugin 暂时没有计划支持“热修复”方案。

2.2.1 最佳实践

以下为 360 手机卫士或其它合作 App 采用的设计，可供你参考：

• 大部分情况下，应尽可能“静默升级”，以减少对用户的打扰

• 针对升级而言，可在后台线程做一次“预加载”，提前释放 Dex。具体做法：

PluginInfo pi = RePlugin.install("/sdcard/exam_new.apk");
if (pi != null) {
    RePlugin.preload(pi);
}

• 若插件正在运行，则会有两种场景，需分别对待：

  • 若是遇到严重问题，需要“强制升级”，则应立即提示用户，待同意后则重启进程

  • 通常情况下，建议在“锁定屏幕”后重启进程，让其在后台生效

• 若插件没有运行，则可直接升级

2.3 卸载插件

要卸载插件，则需要使用 RePlugin.uninstall() 方法。只需传递一个“插件名”即可。

RePlugin.uninstall("exam");

注意

• 如果插件正在运行，则不会立即卸载插件，而是将卸载诉求记录下来。直到所有“正在使用插件”的进程结束并重启后才会生效

• 由于内置插件是捆在主程序包内的，故无法卸载“内置插件”（此处有待官方优化）。

出于稳定性和实际需求考虑，RePlugin 暂时没有计划支持“热卸载”方案。

2.3.1 最佳实践

以下为 360 手机卫士或其它合作 App 采用的设计，可供你参考：

• 在卸载时弹出对话框，提示用户“是否同意卸载”

• 若插件在运行时需要被卸载，则有两种做法：

  • 提示用户“需要重新启动应用才能生效”

  • 在“锁定屏幕”后重新启动进程，让其在后台生效

• 若插件没有运行，则可以直接卸载，无需提示用户

三、内置插件

内置插件是指可以“随着主程序发版”而下发的插件，通常这个插件会放到主程序的 Assets 目录下。

针对内置插件而言，开发者无需调用安装方法，由 RePlugin来“按需安装”。

“内置插件”是可以被“升级”的。升级后的插件等同于“外置插件”。

3.1 添加内置插件

添加一个内置插件是非常简单的，甚至可以无需任何 Java 代码。只需两步即可：

• 将 APK 改名为：[插件名].jar （[ ] 在实际上不需要添加）

• 放入主程序的 assets/plugins 目录

这样，当编译主程序时，RePlugin 的“动态编译方案”会自动在 assets 目录下生成一个名叫 “plugins-builtin.json” 文件，记录了其内置插件的主要信息，方便运行时直接获取。

必须改成 “[插件名].jar” 后，才能被 RePlugin-Host-Gradle 识别，进而成为“内置插件”。

[插件名] 可以是“包名”，也可以是“插件别名”。有关这方面的说明，请阅读《插件的信息》中“插件命名”一节。

3.2 删除内置插件

删除内置插件非常简单，直接移除相应的 Jar 文件，其余均交给 RePlugin 来自动化完成。

注意：若用户已使用了内置插件，则即便用户升级主程序，其包内已不带这个内置插件，但用户仍可继续使用它

这样可防止出现“用户升级主程序后，发现内置插件突然用不了”的情况。

3.3 使用内置插件的时机

不同于“外置插件”需要先调用 RePlugin.install 方法后才能使用，内置插件可无需调用此方法。而一旦插件被使用，则 RePlugin 会在触发相应逻辑前，为你做下列操作：

• 将内置插件释放到数据目录下（近似于调用 install() 方法）

• 若需要加载 Dex，则还会释放优化后的 Dex 到数据目录下，这可能会需要一些时间

这样做的好处是，不会占用太多的“内部存储空间”，毕竟不是所有内置插件，都一定会被用到。

3.4 内置插件的升级

内置插件的升级分为两种情况：主程序随包升级、通过 install() 方法升级

• 主程序随包升级：当用户升级了带“新版本内置插件”的主程序时，则 RePlugin 会在使用插件前先做升级

• 通过 install() 方法升级：若通过 RePlugin.install() 方法做的升级（大多为用户从服务器上下载并更新），则 RePlugin 在调用 install() 方法时开始做升级。当然，其规则仍遵循安装插件的规则，例如“插件运行时先不覆盖”等。

值得注意的是，无论采用何种方式，均“不支持降级”，但支持“同版本覆盖”升级，也即：

• 内置插件：只要 APK 的时间戳和大小发生变化就升级，若两者均无变化，则不会升级。（在 RePlugin 2.1.5 版本中开始支持)

• 外置插件：只要调用 RePlugin.install() 方法即可将“内置插件”转化为“外置插件”。同样的，需遵循安装插件规则。

3.5 最佳实践

以下为 360 手机卫士或其它合作 App 采用的设计，可供你参考：

• 需控制“内置插件”的数量，因为会占用主程序 APK 的大小

• 比较适合成为“内置插件”的有：

  • 核心业务插件：没有它就等于“核心功能缺失”。比如 360 手机卫士的“首页体检”、“清理”插件等

  • 基础插件：各插件都需要用到，且为必须的。比如“安全 WebView”、“下载”插件等

  • 启动时必备插件：明确要在启动时要用到的功能。比如 360 手机卫士的 “Push”、“常驻服务管理”等

• 可将一些启动时必须要加载的，以及经常要用到的内置插件做一次“预加载”。具体做法：

RePlugin.preload("exam");

四、预加载插件

什么是预加载？一言以蔽之，就是将插件的 Dex “提前做释放”，并将 Dex 缓存到内存中，这样在下次启动插件时，可无需走 dex2oat 过程，速度会快很多。

预加载不会做下列事情：

• 不会“启动插件”

• 不会加载其 Application 对象

• 不会打开 Activity 和其它组件等。

换言之，预加载的目的非常单纯，就是提前释放 Dex，仅此而已。

4.1 预加载的用法

如之前所述，预加载有两种做法：

• 预加载当前安装的插件
  此为绝大多数用到的场景。直接预加载当前安装的插件即可，如果当前正在运行这个插件，则调用此方法则是无效的，毕竟当前插件已经早就被使用过了。

可使用 RePlugin.preload(pluginName)，例如：

RePlugin.preload("exam");

• 预加载新安装的插件
  此场景主要用于“后台升级某个插件”。如果此插件“正在被使用”，则必须借助 RePlugin.install() 方法的返回值（新插件的信息）来做预加载。

可使用 RePlugin.preload(PluginInfo)，例如：

PluginInfo pi = RePlugin.install("/sdcard/exam_new.apk");
if (pi != null) {
    RePlugin.preload(pi);
}

4.2 最佳实践

以下为 360 手机卫士或其它合作 App 采用的设计，可供你参考：

• 建议将 RePlugin.preload() 方法的调用放到“工作线程”中进行。由于此方法是“同步”的，所以直接在 UI 线程中调用时，可能会卡住，甚至导致 ANR 问题。

• 如果正在 preload 某插件，则无论在哪个进程和线程，在过程中加载这个插件时，可能会出现卡顿，这和为了安全起见，做了进程锁有关。建议在 preload 做完后再打开此插件。

五、插件的运行

插件运行的场景有很多，包括：

• 打开插件的四大组件

• 获取插件的 PackageInfo/Context/ClassLoader 等

• 预加载（preload）

• 使用插件 Binder

如果想判断插件是否在运行，可使用 RePlugin.isPluginRunning() 方法。

六、安全与签名校验

作为一家安全公司旗下的开源项目，其“安全性”是作为其重点之一来考虑的。曾经有几个 App 在使用动态加载 Dex 方案（非 RePlugin）时，被爆出有可能携带“病毒”，经追查发现是由于没有对外来的 Dex 和 Apk 做“校验”导致。所以说，一旦不做校验，则不排除恶意人会劫持 DNS 或网络，并通过网络来下发恶意插件，对你的应用造成很不好的影响。

若开启此开关，则一旦签名校验失败，则会在 Logcat 中提示 “verifySignature: invalid cert”，且 install() 方法返回 null。

此外，出于性能考虑，内置插件无需做“签名校验”，仅“外置插件”会做。

要打开签名校验也是非常简单的。只需两步：

第一步：打开开关

例如，若你继承 RePluginApplication，则请在创建 RePluginConfig 时调用其 setVerifySign(true) 即可。

当然，更推荐的做法是传递 !BuildConfig.DEBUG 参数。这表示：若为 Debug 环境下则无需校验签名，只有 Release 才会校验。以下是具体用法：

    @Override
    protected RePluginConfig createConfig() {
        RePluginConfig c = new RePluginConfig();
        c.setVerifySign(!BuildConfig.DEBUG);
        ...
        return c;
    }

如果你是“非继承式”，则需要在调用 RePlugin.App.attachBaseContext() 的地方，传递RePluginConfig，并设置 setVerifySign 即可。以下是具体用法：

RePluginConfig c = new RePluginConfig();
c.setVerifySign(!BuildConfig.DEBUG);
...
RePlugin.App.attachBaseContext(context, c);

自 RePlugin 2.1.4 版本开始，默认将“关闭”签名校验，之前默认为“开启”。

第二步：加入合法签名

光是打开其开关还是不够的，还应该将“合法的签名”加入到 RePlugin 的“白名单”中，可调用 RePlugin.addCertSignature() 来完成。例如：

// Add signature to "White List"
RePlugin.addCertSignature("379C790B7B726B51AC58E8FCBCFEB586");

其中，其参数传递的是签名证书的 MD5，且去掉“：”’。

请务必去掉“：”，且不要传递 SHA1 或其它非签名 MD5 内容

获取签名的做法有很多，比较推荐的是使用 keytool 工具，可参见此文档的介绍。

出于性能考虑，RePlugin 不会自动将“主程序签名”加入进来。如有需要，建议你自行加入。

6.1 最佳实践

以下为 360 手机卫士或其它合作 App 采用的设计，可供你参考：

• 强烈建议开启安全和签名校验

• 若在调用 install() 方法前就已对 APK 做了校验（例如，手机卫士是云控加密 MD5 + V5 签名校验），则可关闭，以避免重复校验

• 请尽量不要使用和“主程序”一样的签名，而是单独创建一个

七、插件管理进程

由于 RePlugin 支持独特的“跨进程安全通讯”（见 IPC 类）以及复杂的插件管理机制，为保证插件能统一由“一个中心”来管理，提高每个进程的启动、运行速度，官方团队在设计 RePlugin 之初，就设计了一个“插件管理进程”，所有插件、进程等信息均在此进程中被记录，各进程均从此中获取、修改等，而无需像其它那样，要求“每个进程各自初始化信息”。RePlugin 的这种做法有点像 AMS。

7.1 目前我们有两种进程可以作为“插件管理进程”：

7.1.1 以“常驻进程”作为“插件管理进程”（默认）

在 RePlugin 2.1.7 及以前版本，这是唯一的方式。RePlugin 默认的“常驻进程”名为“：GuardService”，通常在后台运行，存活时间相对较久。这样的最大好处是：应用“冷启动”的概率被明显的降低，大部分都变成了“热启动”，速度更快。

适合作为常驻进程的场景包括：

• 以后台服务为主要业务的应用，例如：手机安全类、健身和健康监控类、OS 内应用等

• 需要有常驻通知栏的应用，例如：音乐类、清理类等

• 需保持常连接（例如 Push 等）的应用，如：即时通讯类、泛社交类等

目前市面上多数应用都集成了推送功能（例如友盟、极光推送），常驻进程可以挂载在那里。

优点，这是结合“常驻进程”长期存活的特点而展开的：

• 各进程启动时，插件信息的获取速度会更快（因直接通过 Binder 从常驻进程获取）

• 只要常驻进程不死，其它进程杀掉重启后，仍能快速启动（热启动，而非“冷启动”）

如果做得好的话，甚至可以做到 “0 秒启动”，如 360 手机卫士。

缺点：

• 若应用为“冷启动”（无任何进程时启动），则需要同时拉起“常驻进程”，时间可能有所延长

• 若应用对“进程”数量比较敏感，则此模式会无形中“多一个进程”

7.1.2 以“主进程”作为“插件管理进程”

和“常驻进程”不同的是，自 RePlugin 2.2.0 开始，主进程也可以作为“插件管理进程”。这样做的最大好处是：应用启动时，可以做到“只有一个进程”（注意，这不代表你不能开启其它插件进程，这里只是说没有“常驻进程”了而已）。当然，代价是享受不到“常驻进程”时的一些好处。

从适用场景上来看，只要是不符合上述“常驻进程”中所涉及到的场景的，本模式都适合。

优点：

• 无需额外启动任何进程，例如你的应用只有一个进程的话，那采用此模型后，也只有一个进程

• 应用冷启动（无任何进程时启动）的时间会短一些，因为无需再拉起额外进程

缺点：

“冷启动”的频率会更高，更容易被系统回收，再次启动的速度略慢于“热启动”

7.2 如何使用？

若不设置，则默认是以“常驻进程”作为“插件管理进程”。

如需切换到以“主进程”作为“插件管理进程”（也即不产生额外进程），则需要在宿主的 app/build.gradle 中添加下列内容，用以设置 persistentEnable 字段为 False：

apply plugin: 'replugin-host-gradle'
repluginHostConfig {
    // ... 其它RePlugin参数

    // 设置为“不需要常驻进程”
    persistentEnable = false
}

八、插件的目录结构

无论是内置插件，还是外置插件，为了保证稳定性，RePlugin 会把经过验证的插件放到一个特殊的目录下，以防止“源文件”被删除后的一些问题。

由于历史原因，内置插件和外置插件的存放路径略有不同。以下将分别予以说明。以下为简化起见，将 “/data/data/[你的主程序包名]” 统一简化成“主程序路径”：

外置插件（未来将只有这一种目录）：

• APK 存放路径：主程序路径/app_p_a

• Dex 存放路径：主程序路径/app_p_od

• Native 存放路径：主程序路径/app_p_n

• 插件数据存放路径：主程序路径/app_plugin_v3_data

内置插件 & 旧 P-N 插件（未来将等同于外置插件）：

• APK 存放路径：主程序路径/app_plugin_v3

• Dex 存放路径：主程序路径/app_plugin_v3_odex

• Native 存放路径：主程序路径/app_plugin_v3_libs

• 插件数据存放路径：主程序路径/app_plugin_v3_data

8.1 文件的组织形式

• 外置插件：为了方便使用，插件会有一个 JSON 文件，用来记录所有已安装插件的信息。目前位于 “主程序路径/app_p_a/p.l” 中。有兴趣的朋友可以自行打开此文件来阅览其中内容。

• 内置插件：不同于外置插件，内置插件 的 JSON 文件只存放于主程序 “assets/plugins-builtin.json” 文件下。每次会从那里获取信息。

官方计划将“内置插件”的管控做到和“外置插件”的一致。届时两者的管理将变得统一起来。

• P-N 插件（即将废弃）：由于历史原因，P-N 插件不采用记录 Json 的形式，而是在 “主程序路径/files” 下，检索所有 “p-n-” 开头，且末尾为 “.jar” 的文件，并读取其内容头，进而找到插件的信息，并记录到内存中。由于该方案即将废弃（虽然截止到 2017 年 7 月，卫士多数插件仍然在用，同样稳定），故这里不再赘述。