Qihoo360/RePlugin 插件的组件

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

先看下这个效果……

我们曾在GMTC上展示,RePlugin是可以跑起来“桌面”插件的:

RePlugin Framework

仅从这张图可以看到:

  • 支持桌面涉及到的近乎所有特性
  • 支持TaskAffinity(卫士、桌面和美化手机,在不同的Task里)
  • 支持多进程坑位(“美化手机”为单独的进程,因为耗资源)
  • 各Activity的标题和Logo可以自定义

是不是很激动?

也许大多数业务没有那么复杂,不过没关系,以下我们将针对常用场景,来简单的向您介绍。

而更多的深层内容,欢迎您凭借自己的好奇心,继续探究,并分享您的研究战果。

如何声明组件?

RePlugin的其中一个优势在于,开发RePlugin插件几乎和开发“单品”无异。

仅举一例,比如我们有个插件——其中一个Activity比较“耗资源”,需要放在单独的进程(:wff),且单独的TaskAffinity,而且还得是SingleTask,则您可以这么玩:

<activityandroid: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-dataandroid: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 =newIntent(v.getContext(), ThemeDialogActivity.class); context.startActivity(intent);

打开服务呢?当然,如法炮制:

Intent intent =newIntent(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 =newContentValues(); cv.put("address", "beijing"); Uri urii = context.getContentResolver().insert(uri, cv);

当然了,还有大名鼎鼎的BroadcastReceiver:

Intent intent =newIntent(); intent.setAction("com.qihoo360.repluginapp.replugin.receiver.ACTION1"); intent.putExtra("name", "jerry"); context.sendBroadcast(intent);

是的,都和单品保持一致

插件外组件

如果要打开“插件外”的组件呢?其实,和“插件内”的基本一致,唯一不同的是:ComponentName为插件名(可以是包名,也可以是别名),也可以是Action。

例如,您可以这么玩:

// 方法1(最“单品”)Intent intent =newIntent(); intent.setComponent(newComponentName("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(), newIntent(), "demo2", "com.qihoo360.replugin.sample.demo2.databinding.DataBindingActivity");

当然,我们还支持Action,例如打开Demo2的一个Activity:

Intent intent =newIntent( "com.qihoo360.replugin.sample.demo2.action.theme_fullscreen_2"); RePlugin.startActivity(v.getContext(), intent, "demo2", null);

是不是很简单?

插件调用主程序组件

插件若要使用主程序的,则更加简单了。主程序怎么调的,插件就可以这么调。唯一的区别是,需要传递“字符串”。

Intent intent =newIntent(); intent.setComponent(newComponentName("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库等。

更多

如果您想了解更多的内容,您可以:

  • 参考Sample工程,我们会经常加入新的特性
  • 参考我们的JavaDoc文档,内有详细说明
  • 如有可能,欢迎阅读我们的源代码,了解其中原理

此外,虽然我们支持了近乎所有的单品特性,但仍有一些是正在搞定,或“短时间内无法搞定”的。我们写到了局限和未来大计划内,供您们参考。

RePlugin虽发源于360手机卫士RePlugin Team团队,但它从“正式开源”起,就已经转化成了一个社区开源项目。因此,非常欢迎大家贡献自己的力量,进一步让咱们的RePlugin项目变得更好!