Qihoo360/RePlugin 插件的管理

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

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

大致目录:

写在最前

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

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

外置插件

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

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

安装插件

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

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

注意

  • 无论安装还是升级,都会将“源文件“移动”(而非复制)到插件的安装路径(如app_p_a)上,这样可大幅度节省安装和升级时间,但显然的,“源文件”也就会消失
    • 若想改变这个行为,您可以参考RePluginConfig中的 setMoveFileWhenInstalling() 方法
    • 升级插件和此等同,故不再赘述

最佳实践

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

  • 除非是基础和核心功能插件,否则请尽量减少“静默安装”(指的是用户无感知的情况下,偷偷在后台安装)插件的情况,以减少内部存储空间的消耗,降低对用户的影响。
  • 若插件需要下载,则请覆写RePluginCallbacks.onPluginNotExistsForActivity方法,并在此打开您的下载页面并控制其逻辑
  • 下载插件前建议告知用户其“插件大小”,尤其针对运营商网络的情况

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

安装或升级失败?

安装或升级失败(返回值为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”的警告。如是,则需要告知用户去清理手机。

升级插件

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

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

注意

  • 如果插件正在运行,则不会立即升级,而是“缓存”起来。直到所有“正在使用插件”的进程结束并重启后才会生效
  • 升级可能会占用“内部存储空间”(因为要释放新的APK)
  • 不支持“插件降级”,但可以“同版本覆盖”(在 RePlugin 2.1.5版本中开始支持)

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

最佳实践

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

  • 大部分情况下,应尽可能“静默升级”,以减少对用户的打扰
  • 针对升级而言,可在后台线程做一次“预加载”,提前释放Dex。具体做法:
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代码”。只需两步即可:

  • 将APK改名为:[插件名].jar
  • 放入主程序的assets/plugins目录

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

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

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

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

删除内置插件

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

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

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

使用内置插件的时机

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

  • 将内置插件释放到数据目录下(近似于调用install方法)
  • 若需要加载Dex,则还会释放“优化后的Dex”到数据目录下,这可能会需要一些时间

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

内置插件的升级

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

  • 主程序随包升级:当用户升级了带“新版本内置插件”的主程序时,则RePlugin会在使用插件前先做升级
  • 通过install方法升级:若通过 RePlugin.install 方法做的升级(大多为用户从服务器上下载并更新),则RePlugin在调用install方法时开始做升级。当然,其规则仍遵循安装插件的规则,例如“插件运行时先不覆盖”等。

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

  • 内置插件:只要APK的时间戳和大小发生变化就升级,若两者均无变化,则不会升级。(在 RePlugin 2.1.5版本中开始支持)
  • 外置插件:只要调用 RePlugin.install 方法即可将“内置插件”转化为“外置插件”。同样的,需遵循安装插件规则。

最佳实践

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

  • 需控制“内置插件”的数量,因为会占用主程序APK的大小
  • 比较适合成为“内置插件”的有:
    • 核心业务插件:没有它就等于“核心功能缺失”。比如360手机卫士的“首页体检”、“清理”插件等
    • 基础插件:各插件都需要用到,且为必须的。比如“安全WebView”、“下载”插件等
    • 启动时必备插件:明确要在启动时要用到的功能。比如360手机卫士的“Push”、“常驻服务管理”等
  • 可将一些启动时必须要加载的,以及经常要用到的内置插件做一次“预加载”。具体做法:
RePlugin.preload("exam");

预加载插件

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

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

预加载不会做下列事情:

  • 不会“启动插件”
  • 不会加载其Application对象
  • 不会打开Activity和其它组件等。

换言之,预加载的目的非常单纯,就是提前释放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.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才会校验。以下是具体用法:

@OverrideprotectedRePluginConfig createConfig() { RePluginConfig c =newRePluginConfig(); c.setVerifySign(!BuildConfig.DEBUG); ...return c; }

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

RePluginConfig c =newRePluginConfig(); 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采用的设计,可供您参考:

  • 强烈建议开启安全和签名校验
  • 若在调用 install 方法前就已对APK做了校验(例如,手机卫士是 云控加密MD5 + V5签名校验),则可关闭,以避免重复校验
  • 请尽量不要使用和“主程序”一样的签名,而是单独创建一个

插件管理进程

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

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

(默认)以“常驻进程”作为“插件管理进程”

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

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

  • 以后台服务为主要业务的应用,例如:手机安全类、健身和健康监控类、OS内应用等
  • 需要有常驻通知栏的应用,例如:音乐类、清理类等
  • 需保持常连接(例如Push等)的应用,如:即时通讯类、泛社交类等

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

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

  • 各进程启动时,插件信息的获取速度会更快(因直接通过Binder从常驻进程获取)
  • 只要常驻进程不死,其它进程杀掉重启后,仍能快速启动(热启动,而非“冷启动”)

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

缺点:

  • 若应用为“冷启动”(无任何进程时启动),则需要同时拉起“常驻进程”,时间可能有所延长
  • 若应用对“进程”数量比较敏感,则此模式会无形中“多一个进程”

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

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

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

优点:

  • 无需额外启动任何进程,例如你的应用只有一个进程的话,那采用此模型后,也只有一个进程
  • 应用冷启动(无任何进程时启动)的时间会短一些,因为无需再拉起额外进程

缺点:

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

如何使用?

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

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

apply plugin: 'replugin-host-gradle' repluginHostConfig { // ... 其它RePlugin参数// 设置为“不需要常驻进程” persistentEnable =false }

插件的目录结构

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

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

以下为简化起见,将“/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

文件的组织形式

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

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

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

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


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