* 前言
* 如何声明组件
* 多进程坑位
* 如何使用组件
* 插件内组件
* 插件外组件
* 插件调用主程序组件
* 主程序调用插件组件
* 如何使用SO库
* 更多
一、前言
先看下这个效果，这是曾在 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"/>
除了常见的四大组件外，RePlugin 还支持“多进程”（此用法非常常见，尤其对性能、内存占用有要求的 App）、TaskAffinity 的处理，同时支持自定义 Application、自由使用 SO 库等等。
2.1 多进程坑位
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 来说，官方提供了两套分配策略供你选择。
2.1.1 静态分配
静态分配的意思是：由开发者在 Meta-data 中自行声明并决定这些“插件进程”应该跑在哪个“坑位进程”内。这是官方比较推荐的方式。
从官方的调研结果来看，很多原来在单品中的“自定义进程”，实际上是可以跑在常驻、UI 进程内的，没有必要“单独开辟一个进程”，这可节约一些宝贵的启动时间。
此外，由于进程坑位有限，若遇见那种“有十多个自定义进程”的插件（如“桌面”插件），则很可能出现“进程分配坑位不足”的情况（虽然官方也在内部做了兼容处理）
具体做法如下（以 360 的桌面插件为例，节选，为保密起见有修改）：
<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 进程以此类推
若“漏配置了”某个进程，则该进程默认将跑在主进程中。
2.1.2 动态分配
如果用户没有配置“静态分配”的坑位，则默认采用“动态分配”方案（目前还在测试阶段，见后）。
和“静态分配”不同，动态分配方案的特点是：
无需声明
Meta-data。自定义进程启动时，RePlugin会自动按顺序为其分配进程坑位当坑位不足时，无需开发者关心，
RePlugin会自动处理进程情况
由于“动态分配”的做法和单品近乎完全一致，所以这里不再赘述。
从 RePlugin 2.2.0 开始官方已完美支持“动态分配”进程。如需使用请直接升级到新版即可。
三、如何使用组件
3.1 插件内组件
插件内部组件的调用“和单品一致”。
例如你要打开一个 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);
是的，都和单品保持一致。
3.2 插件外组件
如果要打开“插件外”的组件呢？其实，和“插件内”的基本一致，唯一不同的是：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");
当然，RePlugin 还支持 Action，例如打开 Demo2 的一个 Activity：
Intent intent = new Intent(
"com.qihoo360.replugin.sample.demo2.action.theme_fullscreen_2");
RePlugin.startActivity(v.getContext(), intent, "demo2", null);
是不是很简单？
3.3 插件调用主程序组件
插件若要使用主程序的，则更加简单了。主程序怎么调的，插件就可以这么调。唯一的区别是，需要传递“字符串”。
Intent intent = new Intent();
intent.setComponent(new ComponentName("com.qihoo360.replugin.sample.host", "com.qihoo360.replugin.sample.host.MainActivity"));
context.startActivity(intent);
3.3.1 插件获取主程序 Context
要获取主程序的 Context，需要调用 RePlugin.getHostContext() 方法即可。例如：
Context hostContext = RePlugin.getHostContext();
...
当然，获取其它内容（如 ClassLoader 等）也如法炮制，可直接调用 RePlugin 类中的相应方法即可。
3.4 主程序调用插件组件
出于稳定性的考虑，和插件相比，主程序调用插件组件的做法略有区别（除了 BroadcastReceiver 仍旧保持一致），好在大部分用法基本一致。
请记得我们的原则：1 Hook！（且足够灵活）
3.4.1 打开插件的 Activity
要打开一个插件的 Activity，你需要调用 RePlugin.startActivity() 方法。例如：
RePlugin.startActivity(MainActivity.this, RePlugin.createIntent("demo1",
"com.qihoo360.replugin.sample.demo1.MainActivity"));
3.4.2 获取插件的 Context
要获取插件的 Context，可以调用 RePlugin.fetchContext() 方法。例如：
Context examContext = RePlugin.fetchContext("exam");
...
当然，获取其它内容（如 ClassLoader 等）也如法炮制，可直接调用 RePlugin 类中的相应方法即可。
3.4.3 启动、绑定插件的 Service
可以使用 PluginServiceClient 类中的相应方法来操作。例如，若你想“绑定”一个服务，则可以：
PluginServiceClient.bindService(RePlugin.createIntent(
"exam", "AbcService"), mServiceConn);
其它方法都在 PluginServiceClient 里，和系统参数完全一致，这里不赘述。
3.4.4 使用插件的 Content-Provider
同样的，使用 PluginProviderClient 类中的方法即可操作 Provider，具体做法如下：
PluginProviderClient.query(xxx);
3.5 为什么主程序和插件的玩法不一样？
来自官方：
我们不会做 Binder Hook，其核心原则只有一个 —— 1 Hook！（且足够灵活）
当然，我们有计划将“动态编译方案”中的修改代码部分，推广到主程序上。这样可以实现“和插件一致”的效果。
不过我们暂时没这么做，主要因为：
毕竟是要改主程序的调用关系，必须经过大量的验证才放心（虽然验证基本足够，但在我们看来，还是不够）。
绝大多数情况下，主程序调用插件都会指定“插件名”，做这事儿的意义远没有“插件”那么的大。
四、如何使用 SO 库
RePlugin 支持使用 SO 库，无论是放置 SO 的方法，或者使用 SO 库的办法，都和“单品”一致。
此外，插件还可以支持“无缝”使用宿主的 SO，且作为开发者而言，无需关心 SO 是放在宿主还是插件中，均只需要调用 Android API 中提供的方法即可实现。
然而，在实际使用过程中，仍需要注意这个和 RePlugin 并无关系的重要一点 —— 32/64 位指令集问题。
4.1 32 位 / 64 位指令集问题
无论采用 RePlugin 还是其他支持 SO 库的方案，都会面临一个问题：32 位和 64 位的 SO 库不能混用。很多同学经常碰见的 “UnsatisfiedLinkError”，大多和这个问题有关。
虽然位数不能混用（32 和 64 位，他俩指令集完全不同），但同一位数下的指令集是向后兼容的，例如放置了
armeabi-v7a和armeabi，这两个是可以混用的，不会出现问题。
4.1.1 为什么？
Android 在安装一个应用时，会根据主程序 APK 中的 SO 指令集信息，来判断该应用是否支持 “64 位”。如果你的手机支持 64 位指令集，且满足下列条件之一：
宿主内没有放置任何 SO
放置了 64 位指令集的 SO 库（无论 32 位是否放置）
则 Android 会判定你的应用是 “64 位模式” 应用，否则为 “32 位兼容模式” 应用。两者的 Zygote 进程不同（分别为 Zygote 和 Zygote64），导致他们所处的运行时环境也是不同的。这时若强行加载 SO，则会出现指令集混用的异常。
4.1.2 怎么办？
这根据你的实际情况来判断。
如果你的应用被要求“同时支持 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 库等。
