RePlugin是什么？
RePlugin是一套完整的、稳定的、适合全面使用的，占坑类插件化方案。我们“逐词”拆开来解释这个定义：
- 完整的：让插件运行起来“像单品那样”，支持大部分特性
- 稳定的：如此灵活完整的情况下，其框架崩溃率仅为业内很低的“万分之一”
- 适合全面使用的：其目的是让应用内的“所有功能皆为插件”
- 占坑类：以稳定为前提的Manifest占坑思路
- 插件化方案：基于Android原生API和语言来开发，充分利用原生特性
针对主程序开发者
针对插件开发者
调试和运行
主程序接入指南
只需三步，就能让您的“主程序”接入RePlugin：
注意：目前有开发同学反馈，开启Instant Run时可能会出现运行时异常情况，请临时关掉此功能后再试。需要重新编译和安装之前因开启Instant Run的插件和宿主。我们正在为此做兼容处理。谢谢理解！
有关“混淆”
RePlugin的AAR自带Proguard文件，您无需关心，直接引入AAR即可生效。此外，其内部仅Keep了关键的接口类，大部分都是允许被混淆的，故对应用来说也没有影响。
第 1 步：添加 RePlugin Host Gradle 依赖
在项目根目录的 build.gradle（注意：不是 app/build.gradle） 中添加 replugin-host-gradle 依赖：
buildscript {
dependencies {
classpath 'com.qihoo360.replugin:replugin-host-gradle:2.2.4'
...
}
}
第 2 步：添加 RePlugin Host Library 依赖
在 app/build.gradle 中应用 replugin-host-gradle 插件，并添加 replugin-host-lib 依赖:
android {
// ATTENTION!!! Must CONFIG this to accord with Gradle's standard, and avoid some error
defaultConfig {
applicationId "com.qihoo360.replugin.sample.host"
...
}
...
}
// ATTENTION!!! Must be PLACED AFTER "android{}" to read the applicationId
apply plugin: 'replugin-host-gradle'
/**
* 配置项均为可选配置，默认无需添加
* 更多可选配置项参见replugin-host-gradle的RepluginConfig类
* 可更改配置项参见 自动生成RePluginHostConfig.java
*/
repluginHostConfig {
/**
* 是否使用 AppCompat 库
* 不需要个性化配置时，无需添加
*/
useAppCompat = true
/**
* 背景不透明的坑的数量
* 不需要个性化配置时，无需添加
*/
countNotTranslucentStandard = 6
countNotTranslucentSingleTop = 2
countNotTranslucentSingleTask = 3
countNotTranslucentSingleInstance = 2
}
dependencies {
compile 'com.qihoo360.replugin:replugin-host-lib:2.2.4'
...
}
务必注意
以下请务必注意：
- 请一定要确保符合Gradle开发规范，也即“必须将包名写在applicatonId”，而非AndroidManifest.xml中（通常从Eclipse迁移过来的项目可能出现此问题）。如果不这么写，则有可能导致运行时出现“Failed to find provider info for com.ss.android.auto.loader.p.main”的问题。具体可参见 #87 Issue的问答。
- 请将apply plugin: 'replugin-host-gradle'放在 android{} 块之后，防止出现无法读取applicationId，导致生成的坑位出现异常
- 如果您的应用需要支持AppComat，则除了在主程序中引入AppComat-v7包以外，还需要在宿主的build.gradle中添加下面的代码若不支持AppComat则请不要设置此项：
repluginHostConfig {
useAppCompat = true
}
开启useAppCompat后，我们会在编译期生成AppCompat专用坑位，这样插件若使用AppCompat的Theme时就能生效了。若不设置，则可能会出现“IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity.”的异常。
- 如果您的应用需要个性化配置坑位数量，则需要在宿主的build.gradle中添加下面的代码：
repluginHostConfig {
/**
* 背景不透明的坑的数量
*/
countNotTranslucentStandard = 6
countNotTranslucentSingleTop = 2
countNotTranslucentSingleTask = 3
countNotTranslucentSingleInstance = 2
}
更多可选配置项参见replugin-host-gradle的RepluginConfig类
第 3 步：配置 Application 类
让工程的 Application 直接继承自 RePluginApplication。
如果您的工程已有Application类，则可以将基类切换到RePluginApplication即可。或者您也可以用“非继承式”接入。
public class MainApplication extends RePluginApplication {
}
既然声明了Application，自然还需要在AndroidManifest中配置这个Application。
<application
android:name=".MainApplication"
... />
备选：“非继承式”配置Application
若您的应用对Application类继承关系的修改有限制，或想自定义RePlugin加载过程（慎用！），则可以直接调用相关方法来使用RePlugin。
public class MainApplication extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
RePlugin.App.attachBaseContext(this);
....
}
@Override
public void onCreate() {
super.onCreate();
RePlugin.App.onCreate();
....
}
@Override
public void onLowMemory() {
super.onLowMemory();
/* Not need to be called if your application's minSdkVersion > = 14 */
RePlugin.App.onLowMemory();
....
}
@Override
public void onTrimMemory(int level) {
super.onTrimMemory(level);
/* Not need to be called if your application's minSdkVersion > = 14 */
RePlugin.App.onTrimMemory(level);
....
}
@Override
public void onConfigurationChanged(Configuration config) {
super.onConfigurationChanged(config);
/* Not need to be called if your application's minSdkVersion > = 14 */
RePlugin.App.onConfigurationChanged(config);
....
}
}
针对“非继承式”的注意点
- 所有方法必须在UI线程来“同步”调用。切勿放到工作线程，或者通过post方法来执行
- 所有方法必须一一对应，例如 RePlugin.App.attachBaseContext 方法只在Application.attachBaseContext中调用
- 请将RePlugin.App的调用方法，放在“仅次于super.xxx()”方法的后面
插件的管理
无论是插件还是主程序，都可以对自己和其它插件做相应的插件管理工作。
这篇文档主要讲解有关插件管理方面的基本用法。分为：外置插件（主要）和内置插件。并在文章的最后介绍“插件的路径”和一些基本信息。
大致目录：
写在最前
无论是内置，还是外置插件，还需理解：不是所有的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才会校验。以下是具体用法：
@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采用的设计，可供您参考：
- 强烈建议开启安全和签名校验
- 若在调用 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月，卫士多数插件仍然在用，同样稳定），故这里不再赘述。
插件的组件
本文重点讲解插件的组件部分。大致内容如下：
先看下这个效果……
我们曾在GMTC上展示，RePlugin是可以跑起来“桌面”插件的：
仅从这张图可以看到：
- 支持桌面涉及到的近乎所有特性
- 支持TaskAffinity（卫士、桌面和美化手机，在不同的Task里）
- 支持多进程坑位（“美化手机”为单独的进程，因为耗资源）
- 各Activity的标题和Logo可以自定义
是不是很激动？
也许大多数业务没有那么复杂，不过没关系，以下我们将针对常用场景，来简单的向您介绍。
而更多的深层内容，欢迎您凭借自己的好奇心，继续探究，并分享您的研究战果。
如何声明组件？
RePlugin的其中一个优势在于，开发RePlugin插件几乎和开发“单品”无异。
仅举一例，比如我们有个插件——其中一个Activity比较“耗资源”，需要放在单独的进程（:wff），且单独的TaskAffinity，而且还得是SingleTask，则您可以这么玩：
<activity
android:name="com.hola.launcher.widget.waterfallsflow.activity.WaterfallsFlowActivity"
android:theme="@android:style/Theme.Translucent.NoTitleBar"
android:screenOrientation="portrait"
android:process=":wff"
android:launchMode="singleTask"
android:taskAffinity="com.hola.launcher.widget.waterfallsflow"/>
除了常见的四大组件外，我们还支持“多进程”（此用法非常常见，尤其对性能、内存占用有要求的App）、TaskAffinity的处理，同时支持自定义Application、自由使用SO库等等。
有关声明组件的具体内容，请参见 Android 官方文档：《Activity》
多进程坑位
RePlugin支持多个进程的分配，且同样可以“无需升级主程序”即可达成。避免“过分依赖单一进程”，是在开发中经常用到的一种特性。
从经验上来看，多进程最常见于下列场景：
- 在单独进程中运行一个Service（如“下载”服务等）
- 在“常驻进程”中运行长期工作的Service（如“Push”服务等）
- 隔离“过于消耗资源”的Activity（如“换肤主题”页面等）
- 对“非常复杂，不排除会出问题”的插件做“隔离”，防止进程崩溃时，对主进程造成冲击
- 双进程模型，可将大部分初始化操作（如用户帐号的加解密、文件IO操作等）放在常驻进程，其它进程直接“获取”即可，大幅度提高使用效率
当然，多进程也不是“全都是宝”，其副作用主要有（注意，以下指出的是“所有Android应用”都存在的副作用，而非RePlugin特有的）：
- 首次开启进程会有性能消耗，打开Activity可能会有“短暂的黑屏”或“无响应”（根据Theme）。从我们的经验上来看，大概在20ms~100ms不等（和Application类的复杂程度有关）
原因很容易理解：系统需要Zygote这个新进程，然后执行一系列和AMS的交互，最后调用Application，这一串下来，不可能很快的
跨进程的“交互”只能依靠Binder、Socket、文件等操作来解决，不支持反射（一想就懂）。尤其是Binder，双方通信时需要写一些AIDL
从“应用的内存占用”来说，每多运行一个进程，则会多出一些应用内存的占用。根据经验来看，一个空Application，无论单品还是插件，每增加一个进程大概多占用5M（Dalvik）~20M不等（ART）
当然，瑕不掩瑜，多进程的使用场景还是很多的，应根据自己的实际情况来进行选择。那么，对于RePlugin来说，我们提供了两套分配策略供您选择。
静态分配
静态分配的意思是：由开发者在Meta-data中自行声明并决定这些“插件进程”应该跑在哪个“坑位进程”内。这是我们比较推荐的方式。
从我们的调研结果来看，很多原来在单品中的“自定义进程”，实际上是可以跑在常驻、UI进程内的，没有必要“单独开辟一个进程”，这可节约一些宝贵的启动时间。
此外，由于进程坑位有限，若遇见那种“有十多个自定义进程”的插件（如“桌面”插件），则很可能出现“进程分配坑位不足”的情况（虽然我们也在内部做了兼容处理）
具体做法如下（以我们的桌面插件为例，节选，为保密起见有修改）：
<meta-data
android:name="process_map"
android:value="[
{'from':'com.qihoo360.launcher:wff', 'to':'$ui'},
{'from':'android.process.acore', 'to':'$p0'},
{'from':'com.qihoo360.accounts', 'to':'$p1'},
{'from':'com.qihoo360.launcher:livewallpaper', 'to':'$p2'}
]" />
其中：
- from：原来声明的进程名是什么。例如有个Activity，其进程名声明为“com.qihoo360.launcher:wff”
- to：要映射到的进程名，必须以“$”开头，表示“特殊进程”
- $ui：映射到UI进程
- $p0：映射到进程坑位0进程
- $p1：映射到进程坑位1进程
- 以此类推
若“漏配置了”某个进程，则该进程默认将跑在主进程中。
动态分配
如果用户没有配置“静态分配”的坑位，则默认采用“动态分配”方案（目前还在测试阶段，见后）。
和“静态分配”不同，动态分配方案的特点是：
- 无需声明Meta-data。自定义进程启动时，RePlugin会自动按顺序为其分配进程坑位
- 当坑位不足时，无需开发者关心，RePlugin会自动处理进程情况
由于“动态分配”的做法和单品近乎完全一致，所以这里不再赘述。
从 RePlugin 2.2.0 开始我们已完美支持“动态分配”进程。如需使用请直接升级到新版即可。
如何使用组件
插件内组件
插件内部组件的调用“和单品一致”。
例如您要打开一个Activity，则可以这么玩：
Intent intent = new Intent(v.getContext(), ThemeDialogActivity.class); context.startActivity(intent);
打开服务呢？当然，如法炮制：
Intent intent = new Intent(v.getContext(), PluginDemoService1.class);
intent.setAction("action1");
context.startService(intent);
使用Content-Provider也是如此：
Uri uri = Uri.parse("content://com.qihoo360.replugin.sample.demo1.provider2/test");
ContentValues cv = new ContentValues();
cv.put("address", "beijing");
Uri urii = context.getContentResolver().insert(uri, cv);
当然了，还有大名鼎鼎的BroadcastReceiver：
Intent intent = new Intent();
intent.setAction("com.qihoo360.repluginapp.replugin.receiver.ACTION1");
intent.putExtra("name", "jerry");
context.sendBroadcast(intent);
是的，都和单品保持一致。
插件外组件
如果要打开“插件外”的组件呢？其实，和“插件内”的基本一致，唯一不同的是：ComponentName为插件名（可以是包名，也可以是别名），也可以是Action。
例如，您可以这么玩：
// 方法1（最“单品”）
Intent intent = new Intent();
intent.setComponent(new ComponentName("demo2",
"com.qihoo360.replugin.sample.demo2.databinding.DataBindingActivity"));
context.startActivity(intent);
// 方法2（快速创建Intent）
Intent intent = RePlugin.createIntent("demo2",
"com.qihoo360.replugin.sample.demo2.databinding.DataBindingActivity");
context.startActivity(intent);
// 方法3（一行搞定）
RePlugin.startActivity(v.getContext(), new Intent(), "demo2",
"com.qihoo360.replugin.sample.demo2.databinding.DataBindingActivity");
当然，我们还支持Action，例如打开Demo2的一个Activity：
Intent intent = new Intent(
"com.qihoo360.replugin.sample.demo2.action.theme_fullscreen_2");
RePlugin.startActivity(v.getContext(), intent, "demo2", null);
是不是很简单？
插件调用主程序组件
插件若要使用主程序的，则更加简单了。主程序怎么调的，插件就可以这么调。唯一的区别是，需要传递“字符串”。
Intent intent = new Intent();
intent.setComponent(new ComponentName("com.qihoo360.replugin.sample.host", "com.qihoo360.replugin.sample.host.MainActivity"));
context.startActivity(intent);
插件获取主程序Context
要获取主程序的Context，需要调用 RePlugin.getHostContext() 方法即可。例如：
Context hostContext = RePlugin.getHostContext(); ...
当然，获取其它内容（如ClassLoader等）也如法炮制，可直接调用RePlugin类中的相应方法即可。
主程序调用插件组件
出于稳定性的考虑，和插件相比，主程序调用插件组件的做法略有区别（除了BroadcastReceiver仍旧保持一致），好在“大部分用法基本一致”。
请记得我们的原则：1 Hook！（且足够灵活）
打开插件的Activity
要打开一个插件的Activity，您需要调用 RePlugin.startActivity() 方法。例如：
RePlugin.startActivity(MainActivity.this, RePlugin.createIntent("demo1",
"com.qihoo360.replugin.sample.demo1.MainActivity"));
获取插件的Context
要获取插件的Context，可以调用 RePlugin.fetchContext() 方法。例如：
Context examContext = RePlugin.fetchContext("exam");
...
当然，获取其它内容（如ClassLoader等）也如法炮制，可直接调用RePlugin类中的相应方法即可。
启动、绑定插件的Service
可以使用我们的 PluginServiceClient 类中的相应方法来操作。例如，若您想“绑定”一个服务，则可以：
PluginServiceClient.bindService(RePlugin.createIntent(
"exam", "AbcService"), mServiceConn);
其它方法都在 PluginServiceClient 里，和系统参数完全一致，这里不赘述。
请参见 JavaDoc 文档了解更多。
使用插件的Content-Provider
同样的，使用 PluginProviderClient 类中的方法即可操作Provider，具体做法如下：
PluginProviderClient.query(xxx);
为什么主程序和插件的玩法不一样？
我们不会做Binder Hook，其核心原则只有一个——1 Hook！（且足够灵活）
当然，我们有计划将“动态编译方案”中的修改代码部分，推广到主程序上。这样可以实现“和插件一致”的效果。
不过我们暂时没这么做，主要因为：
- 毕竟是要改主程序的调用关系，必须经过大量的验证才放心（虽然验证基本足够，但在我们看来，还是不够）。
- 绝大多数情况下，主程序调用插件都会指定“插件名”，做这事儿的意义远没有“插件”那么的大。
如果您有更好的方案（不允许Hook，且对开发者透明），欢迎及时和我们沟通，并提交您的PR。我们的邮箱：[email protected]。您的贡献我们会放在“贡献者名单”中。感谢！
如何使用SO库
RePlugin 支持使用SO库，无论是放置SO的方法，或者使用SO库的办法，都和“单品”一致。
此外，插件还可以支持“无缝”使用宿主的SO，且作为开发者而言，无需关心SO是放在宿主还是插件中，均只需要调用 Android API 中提供的方法即可实现。
然而，在实际使用过程中，仍需要注意这个和RePlugin并无关系的重要一点——32/64位指令集问题。
32位/64位指令集问题
无论采用RePlugin还是其他支持SO库的方案，都会面临一个问题：32位和64位的SO库不能混用。很多同学经常碰见的“UnsatisfiedLinkError”，大多和这个问题有关。
虽然位数不能混用（32和64位，他俩指令集完全不同），但同一位数下的指令集是向后兼容的，例如放置了armeabi-v7a和armeabi，这两个是可以混用的，不会出现问题。
为什么？
Android在安装一个应用时，会根据主程序APK中的SO指令集信息，来判断该应用是否支持“64位”。如果您的手机支持64位指令集，且满足下列条件之一：
- 宿主内没有放置任何SO
- 放置了64位指令集的SO库（无论32位是否放置）
则Android会判定您的应用是“64位模式”应用，否则为“32位兼容模式”应用。两者的Zygote进程不同（分别为Zygote和Zygote64），导致他们所处的运行时环境也是不同的。这时若强行加载SO，则会出现指令集混用的异常。
怎么破？
这根据您的实际情况来判断。
如果您的应用被要求“同时支持32位和64位”，则无论是主程序还是插件，请务必同时放入32位和64位的SO库。
如果您的应用被要求“只支持32位”（绝大部分情况，毕竟考虑到APK大小），则：
- 宿主务必只放入32位SO库
- 若宿主没有SO库，则“务必放入一个空的32位SO库”（重要，见Sample）
- 对插件而言，64位的SO将不会生效，安装插件时也不会释放（因为主程序只在32位上运行）
如果您的应用和插件目前都没有SO库，则仍建议按照“只支持32位”的做法来处理。因为将来一旦有插件带SO，则不至于出现一些问题。
如果您的应用被要求“只支持64位”（不推荐，这样现有大部分旧机器将无法安装），则可以按照现在的做法，无需放入SO库，或只放入64位SO库。
再次重申，此问题和RePlugin无关，只不过可能其它官方文档中没有提及，或有的方案本身并不支持SO库等。