插件的组件

本文重点讲解插件的组件部分。大致内容如下：

先看下这个效果……

我们曾在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。我们的邮箱：replugin@gmail.com。您的贡献我们会放在“贡献者名单”中。感谢！

如何使用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库等。

Provide feedback

Saved searches

Use saved searches to filter your results more quickly