最新版本:插件的管理 · Qihoo360/RePlugin Wiki · GitHub

无论是插件还是主程序，都可以对自己和其它插件做相应的插件管理工作。

这篇文档主要讲解有关插件管理方面的基本用法。分为：外置插件（主要）和内置插件。并在文章的最后介绍“插件的路径”和一些基本信息。

大致目录：

写在最前

无论是内置，还是外置插件，还需理解：不是所有的APK都能作为 RePlugin 的插件并安装进来的。必须要严格按照《插件接入指南》中所述完成接入，其编译出的APK才能成为插件，且这个APK同时也可以被安装到设备中。

PS：想了解RePlugin和“双开类框架”的区别，请参见《FAQ》中所述，这里不再赘述。

外置插件

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

以下是“外置插件”的管理方案。

安装插件

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

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

注意最佳实践

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

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

安装或升级失败？

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

升级插件

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

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

注意

出于稳定性和实际需求考虑，RePlugin暂时没有计划支持“热修复”方案。然而，如您有0 Hook（极其稳定的前提下）能和RePlugin融合的“热修复”方案，欢迎提出您的PR，我们非常期待您的贡献。

最佳实践

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

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

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

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

RePlugin.uninstall("exam");

注意

出于稳定性和实际需求考虑，RePlugin暂时没有计划支持“热卸载”方案。然而，如您有0 Hook（极其稳定的前提下）能和RePlugin融合的方法，欢迎提出您的PR，我们非常期待您的贡献。

最佳实践

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

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

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

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

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

添加内置插件

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

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

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

[插件名]可以是“包名”，也可以是“插件别名”。

有关这方面的说明，请点击此处阅读《插件的信息》中“插件命名”一节。

删除内置插件

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

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

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

使用内置插件的时机

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

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

内置插件的升级

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

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

最佳实践

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

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

RePlugin.preload("exam");

预加载插件

其实在前面“外置”和“内置”插件章节中已经穿插了关于“预加载”的内容。这里仅做下更细致的说明。

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

预加载不会做下列事情：

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

预加载的用法

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

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

可使用 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);
}

最佳实践

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

插件的运行

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

如果想判断插件是否在运行，可使用 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不会自动将“主程序签名”加入进来。如有需要，建议您自行加入。

最佳实践

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

插件管理进程

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

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

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

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

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

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

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

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

缺点：

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

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

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

优点：

缺点：

如何使用？

若不设置，则默认是以“常驻进程”作为“插件管理进程”。未来我们可能会考虑切换默认值。

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

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

插件的目录结构

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

由于历史原因，内置插件和外置插件的存放路径略有不同。以下将分别予以说明。

以下为简化起见，将“/data/data/[你的主程序包名]”统一简化成“主程序路径”：

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

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

文件的组织形式

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

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

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

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

注：部分内容由社区爱好者提供，感谢您们的建议，文章已收录到《参考信息》内，聊表谢意。

文章来源:https://github.com/Qihoo360/RePlugin/wiki/%E6%8F%92%E4%BB%B6%E7%9A%84%E7%AE%A1%E7%90%86