Android插件化方案 - RePlugin超全使用手册

转载请注明出处：https://blog.csdn.net/mythmayor/article/details/134697588

Ⅰ、RePlugin简介

一、RePlugin —— 历经三年多考验，数亿设备使用的，稳定占坑类插件化方案

RePlugin是一套完整的、稳定的、适合全面使用的，占坑类插件化方案，由360手机卫士的RePlugin Team研发，也是业内首个提出”全面插件化“（全面特性、全面兼容、全面使用）的方案。

其主要优势有：

• 极其灵活：主程序无需升级（无需在Manifest中预埋组件），即可支持新增的四大组件，甚至全新的插件
• 非常稳定：Hook点仅有一处（ClassLoader），无任何Binder Hook！如此可做到其崩溃率仅为“万分之一”，并完美兼容市面上近乎所有的Android ROM
• 特性丰富：支持近乎所有在“单品”开发时的特性。包括静态Receiver、Task-Affinity坑位、自定义Theme、进程坑位、AppCompat、DataBinding等
• 易于集成：无论插件还是主程序，只需“数行”就能完成接入
• 管理成熟：拥有成熟稳定的“插件管理方案”，支持插件安装、升级、卸载、版本管理，甚至包括进程通讯、协议版本、安全校验等
• 数亿支撑：有360手机卫士庞大的数亿用户做支撑，三年多的残酷验证，确保App用到的方案是最稳定、最适合使用的

截止2017年6月底，RePlugin的：

特性	描述
插件数	103（核心57个）
插件占应用比	高达83%
年发版次数	高达596次（工作日均2次）
崩溃率	万分之一（0.01%），极低
时间	2014年应用，3年验证

目前360公司几乎所有的亿级用户量的APP，以及多款主流第三方APP，都采用了RePlugin方案。

有关RePlugin的详细介绍，请点击这里阅读《RePlugin 官方 WiKi》。

我们还支持以下特性

特性	描述
组件	四大组件（含静态Receiver）
升级无需改主程序Manifest	完美支持
Android特性	支持近乎所有（包括SO库等）
TaskAffinity & 多进程	支持（坑位方案）
插件类型	支持自带插件（自识别）、外置插件
插件间耦合	支持Binder、Class Loader、资源等
进程间通讯	支持同步、异步、Binder、广播等
自定义Theme & AppComat	支持
DataBinding	支持
安全校验	支持
资源方案	独立资源 + Context传递（相对稳定）
Android 版本	API Level 9+ （2.3及以上）

RePlugin 架构图

以360手机卫士为例：

• 系统层——Android：为Android Framework层。只有ClassLoader是Hook的，而AMS、Resources等都没有做Hook，确保了其稳定性。
• 框架层——RePlugin框架：RePlugin框架层，只有RePlugin是对“上层完全公开”的，其余均为Internal，或“动态编译方案”生效后的调用，对开发者而言是“无需关心”的。
• 插件层——各插件：“标蓝部分”是各插件，包括大部分的业务插件（如体检、清理、桌面插件等）。而其中“标黄部分”是支撑一个应用的各种基础插件，如WebView、Download、Share，甚至Protobuf都能成为基础插件。

已接入RePlugin的插件

目前已有的插件，可以分为以下几类，供各App开发者参考：

• 展示插件：如卫士首页（是的，你没看错）、体检、信息流等
• 业务插件：如清理、骚扰拦截、悬浮窗等
• 合作插件：如程序锁、免费WiFi、安全桌面等
• 后台插件：如Push、服务管理、Protobuf等
• 基础插件：如安全WebView、分享、定位等

二、RePlugin是什么？

RePlugin是一套完整的、稳定的、适合全面使用的，占坑类插件化方案。我们“逐词”拆开来解释这个定义：

• 完整的：让插件运行起来“像单品那样”，支持大部分特性
• 稳定的：如此灵活完整的情况下，其框架崩溃率仅为业内很低的“万分之一”
• 适合全面使用的：其目的是让应用内的“所有功能皆为插件”
• 占坑类：以稳定为前提的Manifest占坑思路
• 插件化方案：基于Android原生API和语言来开发，充分利用原生特性

三、插件管理服务—与RePlugin配套的插件管理、下发、统计服务

至今为止有数不清的用户联系我们让做配套的插件管理功能，所以 RePlugin 团队联合 360 Web 平台部，合力推出 RePlugin 插件管理服务，再次大幅降低了用户使用RePlugin的门槛，插件管理服务功能介绍如下：

• 插件版本管理：对APK插件包名、别名和版本号的交集限制，防止下发出错。

• 打点统计：上报即显示下发量、下载量、安装量和错误量数据。

• 升版管理：严格要求用户新建下发任务为面向虚拟用户或部分真实用户的“测试版”下发任务（适用于内测、AB和灰度），测试没问题以后才能切换到面对所有真实用户的“线上版”下发任务，防止出错。

• 下发限速：开发者可自定义自己想要的插件下发速度。

• 运营商和厂商限制：开发者可自定义自己想下发的运营商和目标终端厂商。

• 灵活的下发条件设置：根据用户群体对下发条件的要求程度，我们提供了4种条件设置功能，对下发条件要求不高的用户可直接使用便捷条件下发（包括按人数和指定设备下发）；对下发条件要求高的用户可使用自定义条件下发（包括文字条件编辑器和代码条件编辑器）。

PS：我们原创的文字版条件编辑器很有意思哦，它能将复杂繁琐的条件代码还原成有语法有逻辑的中国话，真的是能让非技术人员第一次使用就看得懂会操作的优秀功能，目前为止我们应该是第一个将体验做到如此细腻的产品。

使用地址：360移动开发者中心-RePlugin插件管理

四、我们是怎么实现的

看似用法简单、易于理解的RePlugin的背后，却有着复杂的技术积累，经历了多年的严酷考验。

这里有一篇发表至“移动开发前线”的专栏文章，请点击这里了解《全面插件化——RePlugin的使命》。

除此之外，我们还特别针对RePlugin做了一些原理剖析，在此您可以了解到具体实现原理和技术细节，甚至“为什么要这么做”，而不是“那样做”，我们当初是怎么想的，等等。

因为时间关系，剖析类文章我们会陆续提供，敬请期待。

有关技术原理上的实现，请点击这里阅读《RePlugin的原理》。

Ⅱ、快速上手

一、主程序接入指南

只需三步，就能让您的“主程序”接入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()”方法的后面

二、插件接入指南

只需两步，就能让您的App变成“RePlugin插件”：

有关“混淆”

RePlugin的AAR自带Proguard文件，您无需关心，直接引入AAR即可生效。此外，其内部仅Keep了关键的接口类，大部分都是允许被混淆的，故对应用来说也没有影响。

第 1 步：添加 RePlugin Plugin Gradle 依赖

在项目根目录的 build.gradle（注意：不是 app/build.gradle） 中添加 replugin-plugin-gradle 依赖：

buildscript {
    dependencies {
        classpath 'com.qihoo360.replugin:replugin-plugin-gradle:2.2.4'
        ...
    }
}

第 2 步：添加 RePlugin Plugin Library 依赖

在 app/build.gradle 中应用 replugin-plugin-gradle 插件，并添加 replugin-plugin-lib 依赖:

apply plugin: 'replugin-plugin-gradle'

dependencies {
    compile 'com.qihoo360.replugin:replugin-plugin-lib:2.2.4'
    ...
}

三、宿主调试

1.环境配置

1.1仓库配置

buildscript {
    repositories {

        jcenter()

    }

    dependencies {

        classpath 'com.qihoo360.replugin:replugin-host-gradle:2.2.4'

    }
}

1.2插件使用配置

（这个apply plugin尽量放在android配置之后吧，因为可以自动读取android中的配置项，方便以后升级。简单的说，就是放在你build.gradle文件末尾即可）

apply plugin: 'replugin-host-gradle'

// If use AppCompat, open the useAppCompat repluginHostConfig { useAppCompat = true }

2.插件的Gradle任务

2.1 rpGenerateDebugBuiltinJson或rpGenerateReleaseBuiltinJson等

生成内置插件的配置文件（一般很少使用，编译时会自动处理）

2.2 rpGenerateDebugHostConfig或rpGenerateReleaseHostConfig等

生成插件们的坑位配置文件（一般很少使用，编译时会自动处理）

2.3 rpShowPluginsDebug和rpShowPluginsRelease等

查看所有内置插件的信息

四、插件调试

1.环境配置

1.1仓库配置

buildscript {
    repositories {

        jcenter()

    }

    dependencies {

        classpath 'com.qihoo360.replugin:replugin-plugin-gradle:2.2.4'

    }
}

1.2插件使用配置

（这个apply plugin需要放在android配置之后，因为需要读取android中的配置项。简单的说，就是放在你build.gradle文件末尾即可）

apply plugin: 'replugin-plugin-gradle'

repluginPluginConfig {
    //插件名
    pluginName = "demo3"
    //宿主app的包名
    hostApplicationId = "com.qihoo360.replugin.sample.host"
    //宿主app的启动activity
    hostAppLauncherActivity = "com.qihoo360.replugin.sample.host.MainActivity"
}

2.插件的Gradle任务

一些Gradle任务依赖宿主中添加这行代码

RePlugin.enableDebugger(base, BuildConfig.DEBUG); 

2.1 rpForceStopHostApp

强制停止宿主程序

2.2 rpInstallAndRunPluginDebug或rpInstallAndRunPluginRelease等

安装插件到宿主并运行（常用任务）

2.3 rpInstallPluginDebug或rpInstallPluginRelease等

仅仅安装插件到宿主

2.4 rpRestartHostApp

重启宿主程序

2.5 rpRunPluginDebug或rpRunPluginRelease等

仅仅运行插件，如果插件前面没安装，则执行不成功

2.6 rpStartHostApp

启动宿主程序

2.7 rpUninstallPluginDebug或rpUninstallPluginRelease

仅仅卸载插件，如果完全卸载，还需要执行rpRestartHostApp任务

Ⅲ、详细教程

一、插件的管理

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

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

写在最前

无论是内置，还是外置插件，还需理解：不是所有的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月，卫士多数插件仍然在用，同样稳定），故这里不再赘述。

二、插件的信息

插件命名

RePlugin的插件可以有两种名字，分别是：插件包名、插件别名。

• 插件包名：顾名思义，就是插件的PackageName
• 插件别名：为了“精简包名”而设计的别名，也是RePlugin推荐大家使用的

值得注意的是，在您调用插件逻辑时，您既可以使用插件包名，也可以使用插件别名，两者可以混用而不受影响（在RePlugin 2.2.0中支持）

插件包名

插件包名可以任意起名，不受限制。

注意，若您的APK既作为单品，又作为插件，则建议分成两个包名，且Provider的Authority也建议改名，这样可针对不同的场景（插件还是单品）来做不同的处理。

插件别名

除了插件包名外，针对很多开发者的诉求（包名太长、有可能会改等），我们提出了“插件别名”的概念。

插件别名应做到尽可能的简短、易懂，并尽量为全小写。如：webview、push、protobuf等

要声明插件别名，需要在插件的AndroidManifest.xml中声明以下Meta-data：

<meta-data
	android:name="com.qihoo360.plugin.name"
	android:value="[你的插件别名]" />

注意

针对内置插件而言：

• 若不填写插件别名，则RePlugin会将内置插件的“文件名”作为其插件名
• 其优先级为：Meta-data声明的 > 文件名

而针对外置插件而言：

• 若不填写插件别名，则RePlugin只能允许使用“插件包名”
• P-n类型插件在生成“文件头”时就必须要设置别名，故不受影响

最佳实践

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

• 建议给主要的、经常用到的插件，声明其“插件别名”（虽然不硬性要求），这样代码会更加简洁。

试想一下，是每次用“com.qihoo360.mobilesafe.plugin.webview”好呢？还是“webview”好呢？

• 一些外部合作的插件（如360桌面等）可以只使用插件包名

插件的版本

RePlugin用到的版本可分为三种：插件版本号、“插件协议版本号”和“插件框架版本号”。

插件的VersionCode

插件版本号是很容易理解的，就是插件的VersionCode，可以自由发挥（当然了，毕竟是Integer类型，所以别超过32位最大值）。

插件的VersionName因其类型为String，故不作为我们的“插件版本”

最佳实践

为了更好的维护插件的版本，以360手机卫士的经验来看，建议可由“三位数”组成。

其中，第一位是大版本，第二位是功能版本，第三位是修复版本。

例如——101。其中第一位“1”为大版本，第二位“0”为功能版本，第三位“1”是修复版本

• 大版本：当插件发生“极其重要的变化”时，可调整此版本
• 功能版本：当插件增加了多个新功能，或优化了多个功能项时，可调整此版本
• 修复版本：当插件出现一些Bug需要修复，或一些很小的改动项，或做A/B Test时，可调整此版本

这样做的好处是显而易见的——各插件能做到“并行开发”，而不受其影响。当然，五位数、七位数都可以，可根据您们的业务需要来定。

插件协议版本号

为了让插件和主程序、插件和插件之间，在针对“巨大接口调整”后仍能确保没有问题，故设立了“插件协议版本号”。

绝大多数开发者可无需关注此版本号，目前设定的默认值是“10”。

我们为什么要设立这个呢？

在开发应用的过程中，难免会遇到一种情况：插件之间，插件与宿主间的交互相对比较频繁。

如果某个插件或主程序的接口发生了极其重大的变化（例如彻底的重构和删除），首先面临的一个问题是——旧插件将无法再使用，其次还要考虑到新插件要做“各种兼容”，例如“逐一判断”接口等，非常费时费力。

为此，我们引入了“插件协议版本号”的概念。

要声明插件协议版本号，您需要在插件的AndroidManifest.xml中声明以下Meta-data：

<meta-data
	android:name="com.qihoo360.plugin.version.low"
	android:value="[你的插件协议版本号]" />
<meta-data
	android:name="com.qihoo360.plugin.version.high"
	android:value="[你的插件协议版本号]" />

目前要求low和high应保持相等。

为什么会有low和high，而不是一个api_ver就搞定？

这个和我们之前RePlugin在2014年的更复杂的情形有关，时间关系不在此赘述。然而，随着目前框架的逐渐成熟，这个low和high其实完全可以“合二为一”（内部也是这么用的）。在未来版本，我们将做重构，确保只保留一个。

插件框架版本号

为了让插件兼容主程序的RePlugin框架，故设立了“插件框架版本号”。截止到2017年6月底，最新的版本号为“4”。

我们为什么要设立这个呢？

从2013年开始，RePlugin经历了数次非常大的改进，尤其以2017年的为甚。而仅以360手机卫士为例，截止到2017年6月底，我们已有102个插件，而有些插件仍需运行在早期的手机卫士上（例如杀毒、清理等），即便还在持续的更新。

若我们不设立这个版本号，则直接导致的结果是：旧插件在新、老手机卫士（或RePlugin架构）上的行为变得不可预测。

举个例子：有个插件是跑在早期手机卫士框架上，彼时还不支持“完全自定义Theme”方案。出于习惯，某Activity设置了一个特殊的，甚至是不正确的Theme。由于早期版本不生效，所以还一直相安无事。然而，如果没有“框架版本号”，则一旦框架突然支持了自定义Theme，则那个“有问题的”Theme就突然生效，导致行为不可预期的问题。

要声明插件框架版本号（绝大多数情况下不需要，默认为4），您需要在插件的AndroidManifest.xml中声明以下Meta-data：

<meta-data
	android:name="com.qihoo360.framework.ver"
	android:value="[你的框架版本号]" />

插件信息的获取

插件信息的类是 PluginInfo，无论是宿主还是插件均可使用。而要获取插件信息还是非常简单的：

• 调用 RePlugin.getPlugin() 方法，可获取任意插件的信息，也可以借此判断插件是否安装（若为null则表示没有安装）
• 调用 RePlugin.getPluginInfoList() 方法可获取所有已安装（包括内置插件）的信息
• 调用 RePlugin.install() 方法，其返回值是“安装成功后”的PluginInfo。若返回Null则表示“安装失败”

获取“待更新插件信息”

PluginInfo中有一个“神奇的”方法：getPendingUpdate，很多人对此方法有一定的疑惑。然而一旦您遇到这种情况，就会发现这个方法变得非常有必要了。例如：

当前正在运行“卫士体检”插件，后在进程没有重启的情况下，对此插件作了升级。而我想获取这两个信息：

• 当前正在运行的插件信息
• 新版本（只不过还没生效）的插件信息

以上两种情况都会遇到，应该怎么办？

我们的做法是：

• 当时调用了 RePlugin.install() 方法，其返回值就是“新版本插件信息”
• 使用 RePlugin.getPlugin() 方法，得到的是“当前正在运行的”插件信息（而非新插件的）
• 在这个“当前正在运行的”插件信息上，再调用 getPendingUpdate() 方法，则可以拿到这个“新版本插件信息”了。

代码说明一下：

// Fetch "Current Version" plugin.
PluginInfo pi = RePlugin.getPluginInfo("exam");
if (pi != null) {
	// Fetch "New Version" plugin
	PluginInfo newPi = pi.getPendingUpdate();
	if (newPi != null) {
		...
	} else {
		// No update
		...
	}
}

三、插件的组件

如何声明组件？

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库等。

更多

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

四、合作插件怎么办

如果您要接入的插件是由第三方公司提供，且不便于提供源代码，则以我们的经验来看，有两种方式：

为便于理解。以下将您所开发的项目称为“贵方”，将第三方合作项目称为“合作方”。

推荐：合作方负责自己开发插件，并提供给贵方

可做到“各司其职”，最大化的利用其组织效率，是我们比较推荐的一种方式。

贵方

1. 接入RePlugin的Host部分
2. 配置好下载、安装策略（通常会走自己的服务器）

合作方

1. 新建一个插件工程，并接入RePlugin的Plugin部分
2. 先确保“直接安装在设备上”并运行无问题后，再将插件APK提供给“贵方”，进行联调测试
3. 完成后，要求“贵方”将其上传到服务器、或作为内置插件放入主程序APK中

合作方提供AAR，贵方负责构建插件

还有一种形式，是合作方“不愿意开发插件”，而是要求“主程序方”来负责，且不会提供源代码。则“贵方”不仅要做主程序的开发，还要帮助开发其插件。

所幸在RePlugin里，这么做也是比较容易的：

贵方

1. 首先将主程序的接入、开发等部分都搞定（见上面）
2. 新建一个插件工程，并接入RePlugin的Plugin部分
3. 向“合作方”要项目AAR文件
4. 将此文件放入“贵方”建立的插件工程的Libs目录下，使其Compile进来
5. 确保“直接安装在设备上”，以及联调也没有问题后，将APK提供给“合作方”
6. 完成后，将其上传到服务器、或作为内置插件放入主程序APK中

合作方

1. 对其展现逻辑做适当修改（毕竟插件和单品可能有所不同，当然如果完全相同，则忽略此项）
2. 将工程内所有代码打包成AAR
3. 发送给“贵方”

为什么会有两种形式？

截止2017年6月底，RePlugin拥有103个插件。需求量大了，自然什么情况都有可能出现，所以在合作过程中，这两种方案都会涉及到。

Ⅳ、其他话题（原理、参考等）

一、RePlugin原理剖析

看似用法简单、易于理解的RePlugin的背后，却有着复杂的技术积累，经历了多年的严酷考验。

以下将具体列出一些涉及到“原理分析”的文章。这些文档有的来自官方，有的来自民间分析团体。在此像民间大神们表示感谢！

如果您能够分析RePlugin的核心原理，并整理成文，则欢迎与我联系。针对“高质量”文章，我们会放到WiKi上，永久留存（WiKi访问量不低）。我们在此期待大家的分析。

如果您想了解RePlugin粉丝和高手们的一些精彩文章，请参考《参考信息》一文了解更多。

为了能体现循序渐进的效果，以下以“文章发布时间”为顺序

视频和演讲

可作为入门来了解RePlugin的“前世今生”，为之后的“原理”做铺垫

• 《RePlugin 插件化框架漫谈（GMTC 2017，Youku视频）》—— @GMTC（全球移动技术大会）

此为首次对外公开RePlugin全部方案的演讲视频，循序渐进的讲解了插件化的好处、RePlugin的独特之处，以及核心技术的大致实现原理。由于是首次公开，内容不如后面同学发表的那么全面，故适合第一次接触到插件化方案的同学，做个”开胃菜“。

演讲时间：2017年6月10日，视频已在8月中旬得到了InfoQ的独家授权，准许发布。

• 《RePlugin，让插件化“飞入寻常应用家”》 —— @开源中国
• 《全面插件化——RePlugin的使命》 —— @Jiongxuan
• 《360手机卫士插件化RePlugin今日开源，官方全面解读》 —— @CSDN
• 《RePlugin框架实现原理和最佳实践》 —— @cundong

经典原理剖析

来自社区大神（包括RP组成员）的一些对原理的深入分析。

• 《RePlugin中如何打开插件中的自定义进程Activity》 —— @cundong
• 《Gradle插件在RePlugin中的应用》 —— @cundong
• 《Fresco在RePlugin中的最佳实践》 —— @cundong
• 《RePlugin源码解析之replugin-host-gradle（宿主gradle插件）》 —— @osan
• 《RePlugin源码解析之replugin-plugin-gradle（插件的gradle插件）》 —— @osan
• 《Android 全面插件化 RePlugin 流程与源码解析》 —— @恋猫de小郭
• 《RePlugin全面解析（1）——核心Hook点原理》 —— @神罗天征
• 《RePlugin全面解析（2）——坑位机制（Activity）》 —— @神罗天征
• 《RePlugin全面解析（3）——插件的加载和核心类图》 —— @神罗天征
• 《RePlugin全面解析（4）——Service方案原理》 —— @神罗天征
• 《RePlugin全面解析（5）——BroadcaseReceiver和ContentProvider》 —— @神罗天征
• 《唯一插件化RePlugin源码及原理深度剖析–工程职责》 —— @刘镓旗
• 《唯一插件化Replugin源码及原理深度剖析–初始化之框架核心》 —— @刘镓旗
• 《唯一插件化Replugin源码及原理深度剖析–唯一Hook点原理》 —— @刘镓旗
• 《唯一插件化Replugin源码及原理深度剖析–插件的安装、加载原理》 —— @刘镓旗
• 《Android全面插件化RePlugin流程与源码解析》 —— @恋猫月亮

二、参考信息

这里重点展示一些RePlugin粉丝爱好者们，在接入时遇到的一些小问题，并整理成文，方便后来的人。同时一些内容也已逐步补充到WiKi中。

虽然随着RePlugin的逐渐完备，有些问题早已经解决。但这些“帮助RePlugin更好的”朋友们的文章，会在这里留存下来，谨表感谢。

如果您能够分析RePlugin的心得体会，并整理成文，则欢迎与我联系。针对“高质量”文章，我们会放到WiKi上，永久留存（WiKi访问量不低）。我们在此期待大家的分析。

如您想了解和“原理”有关的内容，请查看上述内容RePlugin原理剖析了解更多。

综合话题

• 《全面插件化时代RePlugin来临》 —— @老王头
• 《RePlugin开源插件化解决方案教程》 —— @AlexByEarth
• 《使用RePlugin时wiki上没说的一些点》（PDF） —— @kuangye89757
• 《RePlugin外置插件使用》 —— @高富帅小小罗

接入分享

• 《RePlugin 本地编译新的插件的方法》 —— @goodev
• 《RePlugin插件安装说明》 —— @weikano
• 《如何运行 RePlugin 示例项目》 —— @goodev
• 《RePlugin初体验》 —— @softwindy_brother

三、局限和未来大计划

RePlugin可以支持绝大部分“单品”开发时的特性，包括常用的Activity中的LaunchMode、Task-Affinity、Theme（透明和非透明），Service、Provider、Receiver，以及android:process的支持等等，同时也支持“主程序加固”等。

然而，仍然有一些功能，是目前RePlugin所不能支持的。有些是“至少近期内明确不支持的”，也有一些是“未来可以支持的”。

以下将分别做说明。

未来很快将支持的

以下是各App接入方提出的一些，我们认为有必要在未来几个版本支持的特性。因为现在还不支持，为了“不坑大家”，故在此列出来，但将来版本支持后将“去掉”这些限制。

Application和主程序相关

交互

• 暂不支持“宿主和插件之间直接调用类和方法”（宿主和主程序形成父子类ClassLoader）方案
  • 建议：采用经过验证的“反射”、Binder等方式，可做到“天然的”版本控制。同时，近期会推出“稳定共享代码”方案（和业界做法不是很一样），敬请期待。
  • 原因：这是RePlugin的性质所决定的。也即——尽可能的稳定，不要有直接调用带来的问题。因篇幅所限，请点击此处阅读《FAQ》了解这块儿的更多内容。

---

近期明确不支持的

注意：这里列出的限制中，有些是出于系统原因，不仅RePlugin，而是各插件化方案都不能很好的支持。而非“仅RePlugin不支持”，特此说明。谢谢您的理解！

如果您有一个能“破除限制”的点子，且对稳定无影响（0 Hook），欢迎随时和我们联系，并提出您的PR。感谢！

Application和主程序相关

• 插件权限声明无效，只认主程序的
  • 建议：将真正需要用到的权限提前在“主程序”中声明好。
  • 原因：权限部分是系统在安装主程序时，会读取其AndroidManifest.xml中的权限部分，并放入系统的package.xml中，除了系统自己的核心应用（和Root）以外，外界根本无法修改。目前已知的插件化、热更新方案均不支持“动态权限的增删改”。

抛开技术细节不谈，其实我非常赞同新权限必须走“主程序升级”，这样可以保证Android生态的健康发展，且能让插件化方案能“走的更稳一些”。

• 插件声明Target SDK无效，只认主程序的
  • 建议：根据需要来调整主程序的Target SDK，同时插件和主程序最好同时调整。这样即便插件变成单品，也能做到“天然的适配”。
  • 原因同上，不赘述
• 不支持“双开应用”功能。也即：“不经修改，直接将任意APK放入RePlugin进行‘免安装运行’”
  • 建议：RePlugin的核心诉求是在“稳定（1 Hook，0 Binder Hook）的前提下”，尽可能保持灵活，且以最小的成本，产生更多的插件，而非“免修改APK直接运行”。
  • 如确实需要开发双开、免安装应用，或公司接入的插件均“只提供APK（不含混淆后的AAR）”的，可使用我们360的另一套成熟的框架：DroidPlugin，或 @Lody 罗迪的 VirtualApp。
  • 原理：要想实现这种效果，必须先Hook AMS、PackageManager，甚至还要做很多Native Hook的工作。Hook点会很多，也会有不少的适配工作。但只要Hook齐了，就能让一个应用“直接运行起来”，但代价是“适配量太大”，对未来新增的机型充满了“未知性”。

值得说明的是，360手机卫士的另一项作品：“360分身大师”就是自研了一套这样的双开方案，虽然有大量的Hook，但其双开效果还是非常不错的。

• 不支持Notification的Layout资源
  • 建议：可在主程序中预埋一些Layout模板，插件可以套用此模板。另外，“图片资源”以及文案等，是可以通过Drawable和String来透传的，是完美支持的。
  • 原因：RemoteViews的性质决定的。

Activity

• overridePendingTransition，仅支持使用宿主和系统的
  • 建议：将动画资源“预埋在主程序里”，且确保其ID为固定（利用public.xml），这样可以通过拿主程序的动画ID来传递给系统，实现相应效果。目前手机卫士等产品都是这样做的，效果不错。
  • 原因：此方法仅会传给AMS两个int值，且由AMS层进行资源解析并实现动画效果，根本到不了客户端。目前市面上所有插件化、热更新方案均无法实现此功能。

交互

• 不支持“宿主和主程序无缝使用资源”（共享资源）方案
  • 建议：采用更稳定的一些API来“迂回的”获取资源。顺便说一句，RePlugin支持“共享View”方案（例如公共UI库的使用等），这样“无缝获取资源”的场景，在其它方面也能得到满足。
  • 原因：这是RePlugin的性质所决定的。也即——尽可能的稳定，不要有适配代码。因篇幅所限，请点击此处阅读《FAQ》了解这块儿的更多内容。
• 不支持“主程序退出后”的静态广播
  • 建议：请尽量避免过分依赖“主程序停止后”的“静态广播”（Android 8.0以上更是如此，因为原生就禁用了）。此外，只要常驻进程存在，则静态广播将一直生效。
  • 原因：毕竟是“模拟的”静态广播，本质上仍是“动态注册广播”。这和系统直接唤起应广播所在进程，然后发送的“静态广播”是不一样的。

Android 8.0起，一旦应用退出（或被回收），则隐式广播将不再生效，也就是此限制将不再有用。此外，该行为和RePlugin无关，是系统默认行为。详细请参见《Android O 行为变更》部分

过去不支持，但现在已经支持的

• 暂不支持“同版本覆盖”

已在 RePlugin 2.1.5版本中解决。

Ⅴ、FAQ

RePlugin 主要疑惑解答

Q：您们的项目支持“插件使用一套基础库（如network、logger等）”吗？

A：如果是Jar包（不含资源）的话是完全支持的，虽然我们不鼓励这样做（2013年用到了很多坑，见后）。请参见Sample代码中的Fragment示例。

此外，出于对“极致稳定”的追求，我们和市面上大部分“共享ClassLoader”方案有所不同，具体表现在：

• 共享的范围：“插件可以使用主程序的公共类”，若结合 RePlugin.registerHookingClass()，还能做到“使用某个公共插件的公共类”。

从目前调研的情况来看，从公共代码库而言，可满足市面上大多数情况了。但我们不支持（也不打算支持）“所有插件和宿主都是一家亲”的完全耦合形态，因为这个有坑（见后）。

• 先后顺序：RePlugin的做法是，优先使用插件内的类，若插件类找不到，才使用主程序（或经过registerHookingClass跳转后的）的类
• 引入的方式：支持通过provided的方式来引入Jar包。但目前还不支持引入AAR（原因见后）
• 要求和限制：不同于一些要求“插件和宿主必须不能重名”的情况，RePlugin的方案是允许插件和宿主“重名”的，这样对开发者而言，束缚更小。

有人可能要问了，为什么我们“不鼓励”使用基础库方案呢？

其实我们早在2013年就研究出“共享代码”（当时是修改android.jar）方案了，大家可以反编译当年手机卫士的APK即可了解。但后来经过一年的尝试后发现：

• 最容易出现的，就是“插件间版本”导致的问题。

试想，无论是反射，还是走Binder，其实都要求“必须做Try-catch”才行，这样就“天然的”将版本情况考虑了进来。但“直接调用”则不需要*（例如你调用x.aa()方法，通常情况下，下意识里是不会想到做Try-Catch的）*。一旦调用的方法“被删改”，则会直接抛出NoSuchMethodError或者ClassNotFoundException等，对程序稳定性造成极为严重的影响。

我们曾在2013年底时，遇到过“主防”模块因重构而删除了一个类的方法，导致很多调用者“莫名其妙”的Crash掉。其原因就是没有做Try-Catch和版本判断。此情此景，历历在目。

• 其次，就是ClassLoader共享时，需要求各插件不能有“重复的包名和类名”，否则会出现强制类型转换问题。

大家可以看到，2013年的卫士APK里面的插件，其“类名”都带上了插件前缀，就是为了防止这个情况的出现。

• 再次，就是多出来Hook点了，因为需要做DexPathList的反射和修改，涉及到Hook点了，不排除会有兼容性问题

当然，和“共享资源”方案不同的是，代码共享方案不涉及到“ROM适配”情况，所以，在Hook点上稳定性还是可以的。现在Sample上已经提供了Fragment的方案（感谢 @Coder提供），欢迎大家参考。

回答者：@张炅轩

Q：您们的项目支持“插件直接使用公共资源（或AAR）的方案”吗？

A：我们支持插件间，插件和宿主间的资源交互，但不支持（也不打算支持，2013年踩了无数坑，后述）“直接使用资源”的方式。即便支持这一特性会减少改动量。

这里所说的“直接使用资源”是指：插件A通过“R.drawable.common_xxx”来使用插件B或主程序的资源。

那么，我们非常推荐的做法是：

• 通过反射来引入View（例如卫士的WebView、信息流等插件都是这么做的）。这也是我们最为推荐的做法。一方面，View本身是“一个整体”，内部可以通过代码来做版本判断、甚至动画等高难度的处理，兼容性很不错；另一方面，若View被删除了，则只要开发者在外面做判空处理即可，不用担心使用某个资源时出现的严重问题
• 通过使用公共类库（如XML引入的方式）来引入View（目前手机助手的换肤UI就是这么做的）。您可以参见Sample中的Fragment了解大致内容。
• 针对其它需要（例如不方便提供View的），则使用 RePlugin.fetchResources() 来获取Resources对象，并通过getIdentifier来反射获取资源。这样即便资源删除了，也可以通过判空来“天然的”（无需刻意判断版本的）解决版本问题

以上两种做法均有Sample，分别是Fragment和获取Layout的，欢迎大家参考。

补充：RePlugin会同时把Host和Plugin的Context传递给插件，供开发者选择。想用插件的就用插件，想用宿主的就用宿主，甚至用其它插件的也都可以。

有人可能要问了，为什么不能做到“像直接使用公共库”那样，顺带也支持“直接使用公共资源”呢？是你们做不到吗？

当然不是！这个和我们当年遇到的非常多的坑，有很大的关系：

其实我们早在2013年就研究出“共享资源”（修改Aapt）方案，当时是联合台湾团队一起搞的，没有任何的参考。大家可以反编译当年手机卫士的APK即可了解。但后来经过一年的尝试后发现：

• 和代码一样，资源同样有“插件间版本”导致的问题，而且还更加严重

正常情况下，直接调用类中的某个方法，至少可能还会做个Try-Catch（有些是习惯使然）。但资源呢？**有谁能想到“直接通过R.string.xxx”的东西，它一定是拿不到的呢？**但是，现实是残酷的。若直接使用跨插件、跨主程序的资源，则任何对资源的删改，都有可能导致“资源错乱”、崩溃等情况。

我们曾在2013年底时，遇到过二维码插件，因“直接使用主程序资源”，而恰逢主程序布局和资源调整，导致插件公共资源出现“显示错乱”的情况，且“必须升级主程序才能修改”（当然，后来也想过把资源都放公共插件里，最后还是放弃整套方案了）。

这还没完，等我们准备换用现在的方案前，惊讶的发现，为了兼容当时为数不多（也就10多个插件）的公共资源，避免这些插件出现显示异常，我们必须要在宿主中留下多种资源，即便这个资源已不再使用（但老插件能保证不用吗）。和代码一样，此情此景，历历在目。

• 机型适配，机型适配，机型适配！

我们曾在内部称之为“共享资源”方案——也即需要修改Aapt、做addAssetPath等。虽然其好处是插件和主程序可以“直接使用”各自的资源，交互更容易。但代价是需要做“资源分区”，以及针对不同机型（如ZTEResources、MiuiResources）等做适配，稳定性上值得考量。

也就是说，共享资源方案和RePlugin核心诉求——稳定是第一要义，是背离的。我们肯定不能做这个，即便通过巨大的努力，使其适配了市面上近乎所有的手机，但确实不能保证未来不会因某个手机，或ROM的修改，而出现新的问题。

• 当我们插件数量达到20多个时，会发现随着插件的增多，“资源分区ID”会越来越难管控，这对我们来说，同样也是一种挑战。

不同于“共享代码”方案，RePlugin是不会计划支持直接使用资源的方案，我们不想修改RePlugin的主打说明和宗旨，我们要做的，就是极致稳定，与众不同（1 Hook点，0 Binder Hook，无需厂商适配）。但请放心，我们会尽可能提供方便的办法，让开发者们可以“调用一些API”即可获取插件的资源，相对来讲，稳定又比较方便。

回答者：@张炅轩

Q：您们和360之前发的DroidPlugin的主要区别是什么？

A：这个问题问得很好。很多人都有这个疑惑——“为什么你们360要开发两套不同的插件化框架呢”？

其实归根结底，最根本的区别是——目标的不同：

• DroidPlugin主要解决的是各个独立功能拼装在一起，能够快速发布，其间不需要有任何的交互。目前市面上的一些双开应用，和DroidPlugin的思路有共同之处。当然了，要做到完整的双开，则仍需要大量的修改，如Native Hook等。
• RePlugin解决的是各个功能模块能独立升级，又能需要和宿主、插件之间有一定交互和耦合。

此外，从技术层面上，其最核心的区别就一个：Hook点的多少。

• DroidPlugin可以做到让APK“直接运行在主程序”中，无需任何额外修改。但需要Hook大量的API（包括AMS、PackageManager等），在适配上需要做大量的工作。
• RePlugin只Hook了ClassLoader，所以极为稳定，且同样支持绝大多数单品的特性，但需要插件做“少许修改”。好在作为插件开发者而言无需过于关心，因为通过“动态编译方案”，开发者可做到“无需开发者修改Java Code，即可运行在主程序中”的效果。

可以肯定的是，DroidPlugin也是一款业界公认的，优秀的免安装插件方案。我相信，随着时间的推移，RePlugin和DroidPlugin会分别在各自领域（全面插件化 & 应用免安装）打造出属于自己的一番天地。

回答者：@张炅轩

RePlugin 接入和类库开发解惑

Q：java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity.

A：请检查以下配置是否正确：

• 在插件 Mainifest 中，将主题声明为 AppCompat 类的主题（如 @style/Theme.AppCompat，也可以是自定义 AppCompat 主题）；
• 在宿主的 build.gradle 中修改 replugin-host-gradle 配置如下：

  apply plugin: 'replugin-host-gradle'
  repluginHostConfig {
    useAppCompat = true
  }

• 宿主和插件使用的 appcompat-v7 库版本要保持一致（因为内部用到了反射的方式来取 Theme 的 int 值，不同版本的 v7 库 int 值可能不一致）。

回答者：@Coder，@胡俊杰

Q: java.lang.ClassNotFoundException: Didn’t find class “xxx.loader.p.ProviderN1”

A：通常遇到这个问题是因为没有在主程序的AndroidManifest.xml中声明Application，或在Application中没有调用RePlugin.App.attachBaseContext等方法导致。

请严格按照“主程序接入指南”所述来完成接入，一共只有三个步骤，非常简单。同时，请关闭Instant Run防止出现未知问题（正在兼容）。

当然，如果在严格按照接入文档后，仍出现这个问题（这种情况非常罕见），请向我们提交Issue。Issue中应包括：完整的Logcat信息（含崩溃前后上下文）、手机型号、ROM版本、Android版本等。感谢您的理解。

回答者：@张炅轩

Q : 插件中使用透明主题的注意点？

A : 如下：

• 透明样式目前不能结合 AppCompact 使用；如果要使用透明样式，插件 manifest 中必须声明为以下四种主题之一：

/**
     * 手动判断主题是否是透明主题
     */
    public static boolean isTranslucentTheme(int theme) {
        return theme == android.R.style.Theme_Translucent
                || theme == android.R.style.Theme_Dialog
                || theme == android.R.style.Theme_Translucent_NoTitleBar
                || theme == android.R.style.Theme_Translucent_NoTitleBar_Fullscreen;
    }

原因： 由于 AppCompat 没有默认的透明主题，所以 HOST 中没有 AppCompat 的透明坑位。

计划：支持起来太过于复杂，暂不提供。

回答者 : @胡俊杰

Q : 如何解决插件中只希望通过provided方式引入的库，却在插件中其他第三方库存在依赖的问题？

A : 场景如下：

插件中只希望通过provided方式引入rxjava库，然而在插件依赖的某第三方库中依赖了rxjava，而该第三方库又无法修改，这时可以通过如下方式解决：

• 在dependencies统一指定transitive为false 或单独指定某依赖项的transitive为false
• 手动将未加入的依赖添加至dependencies

transitive用于自动处理子依赖项。默认为true，gradle自动添加子依赖项，形成一个多层树形结构；设置为false，则需要手动添加每个依赖项。

回答者 : @小志

Q：Clone了项目后如何使用本地的Gradle插件而不是使用jcenter托管的呢

A：需要遵循这两个步骤：

1. 首先你需要将host-gradle/plugin-gradle打开然后执行publishToMavenLocal来进行将你需要使用的插件发布到Maven本地仓库中
2. 在你需要使用本地插件的项目根目录的build.gradle加入如下配置
   

如果这样操作之后还是没有能使用到本地的插件则需要检查在你相应gradle工程中的版本配置是否与你使用的一致，参考文章 ：http://note.youdao.com/share/?id=61c0f27494c5a466a40642829da2938c&type=note#/

回答者：@Coder

Q : 插件中使用高德地图的经验分享？

A：

• 关于高德地图的key值，请用宿主的包名创建一个key值在插件的AndroidManifest.xml中，否则会显示key值不正确

解释：高德地图的key值，高德地图是用宿主的包名校验的，插件的包名没有校验

回答者 : @书生

Q : 插件中依赖jar或aar后导致的几种编译错误解决？

**A : **

• 编译错误：Error converting bytecode to dex:Cause: java.lang.RuntimeException: Exception parsing classes Caused by: com.android.dx.cf.iface.ParseException: class name (com/xxx/android/xxx/A) does not match path (com/xxx/android/xxx/a.class)

解决：这是因为jar混淆后类文件与类名大小写不一致，导致编译失败。与百度地图等大小写编译问题类似。解决方法是在混淆jar时，配置下混淆规则，来解决混淆后大小写不一致问题：

##混淆时不使用大小写混合，混淆后的类名为小写(尤其windows用户，因为windows大小写不敏感)

-dontusemixedcaseclassnames

回答者 : @osan

Q：如何解决webview加载asserts中的html等资源文件失败的问题？具体如：WebView.loadUrl(“file:///android_asset/xxx.html”)时提示：RR_FILE_NOT_FOUND

A：

1. 前提：设置webview的允许使用File协议，使能访问asset加载本地的HTML等资源文件。即：WebView.getSettings().setAllowFileAccess(true)，不过会存在WebView跨源攻击问题，你可以做一些相关的安全策略，规避风险规避；
2. 采用插件化框架后后，WebView并不能保证一定能读取主程序和插件内的assets中html等资源文件，其中，Android API < 19 只能读取插件assets中的html文件，而在 Android API >= 19 只能读取主程序assets中的html文件。

其具体原因是：在API 19开始，webview内核由WebKit过渡到了Chromium，其内部的getAssets方法的Context由mContext改ApplicationContext。

具体源码见：http://androidxref.com/5.0.0_r2/xref/external/chromium_org/content/public/android/java/src/org/chromium/content/browser/BrowserStartupController.java

可以看到： Context appContext = mContext.getApplicationContext();

问题解决方案：将assets中的html等文件提取拷贝到File System中（如插件的fils或者cache中），具体时机可以在webview插件初始化的时候或者在具体的loadurl之前完成即可。

回答者：@SkyEric

RePlugin 插件管理解惑

Q：内置插件可否按需选择是否默认加载呢？

A：只要放入了assets/plugins中的*.jar是不支持按需加载的，如果你真的需要按需加载的话也是可以如下操作的：

1. 将你需要按需加载的插件放入assets的其它目录中这样gradle就不会生成相关的内置插件信息
2. 释放你的插件到一个磁盘目录
3. 调用Replugin.install(path)方法来进行安装调用即可实现

回答者：@Coder

Q：您们是否支持DataBinding？

A：支持。我们有几个插件在用。除此之外，我们的Sample工程，其Demo2就是用DataBinding做的。您们可以体验一下。

回答者：@张炅轩

Q：插件中共享宿主的DataBinding库时的注意点？

A： 可能会有这种场景，例如当使用DataBindingUtil.inflate(LayoutInflater.from(pluginContext), R.layout.dialog_test, null, false)是 会报 view tag isn’t correct on view:layout这个异常。

原因：android.databinding.DataBindingUtil是jar包的类，但它里面的静态变量 android.databinding.DataBinderMapper 是编译器生成，也就是说每个apk，会有一个DataBinderMapper。这个类保存的是生成类 XXXBinding 与 layout的关系。由于宿主是最开始加载，所以android.databinding.DataBindingUtil里面的是宿主的DataBinderMapper。

解决方案：在插件工程建立一个android.databinding.PluginDataBindingUtil (即拷贝一份DataBindingUtil代码改个类名),之后再插件中就使用PluginDataBindingUtil即可。

回答者：@MinF

Q : 如何监听安装事件

A : 如图。也可参考最新的Sample工程。

回答者 : @志鹏-深圳

Q : 如何判断插件的各种 Activity 被成功替换成 PluginXXXActivity

A : 如图~

在继承AppCompatActivity的类中打印父类名，如果替换成功，上图会显示 PluginAppCompatActivity。这算是一个小技巧，更多的可以查看 Gradle Console的输出日志。

回答者 : @志鹏-深圳

Q : 插件中使用mutidex分包时的注意点？

A : 可能遇到情况如下：

• 无法启动插件activity：log提示java.lang.NoClassDefFoundError: library.d 或 java.lang.NoClassDefFoundError: com.qihoo360.replugin.Entry$1

原因： 插件过大，导致使用了mutidex的处理，而RePlugin的包恰好被分在class2.dex，然后就抛出找不到replugin相关类的异常，导致插件加载失败

解决方案：1.插件的代码尽量小，尽量保证在一个dex中；2.可以在gradle中，指定replugin插件库的类分配在主dex中。

还有一种可能，应该是插件被“分包”导致的问题，打包后虽然有主classes有找到com.qihoo360.replugin.Entry但还是报错，自己手动添加maindexlist.txt在里面添加com.qihoo360.replugin打包进去就好了，具体操作请参考http://blog.csdn.net/gaozhan_csdn/article/details/52024497

回答者 : @小志 @T-BayMax

Q : 多个插件希望使用相同的网络请求框架或其他有公共库时，最佳实践是？

A ：RePlugin团队提供了360手机卫士团队的实践思路作为参考

• 卫士的做法一：提供一些基础的插件（如WebView、分享等），各插件对它是反射调用，接口封装好的前提下，这种做法也是很清晰的。
• 卫士的做法二：如果是公共库的话，每个插件放一份，但混淆时会自动去掉无用类和方法，这样的好处是，公共库的任何版本更新不会影响到所有插件

回答者 : @张炅轩 360

Q：插件没有启动时，为什么无法收到静态广播？

**A：这个问题我们当初在内部讨论了很久。如果安装完成后就开始监听静态广播，则我们担心每次收到一个广播，就会“拉起”一堆的插件，对内存产生影响。为了减少其占用，我们采用的是“按需注册”，也就是加载插件后才去注册的方式。 当然，我们已经把“支持加载前就注册广播”作为未来支持的计划，但我们会有开关控制，方便大家选择。

回答者：@张炅轩

Q：插件怎么与宿主之间代码共享

A：

1. 宿主中有相应的实现代码将其制作为jar
2. 在插件中以provided的方式依赖这个jar（目的是为了骗过编译器）
3. 在宿中打开UseHostClassIfNotFound

注：插件和宿主应该可以有相同的类。只不过遵循“先插件后宿主”。

回答者：@Coder

Q：与百度加固冲突怎么解决？

A：

1. 百度加固后的应用程序，attachBaseContext()接口的调用，是通过Native代码反射Java代码来实现的；
2. RePlugin，默认打开双进程架构时，attachBaseContext()中会通过同步Binder来拉起一个新的管理进程，这一步和以上步骤冲突了；
3. 解决方式也很简单，关掉RePlugin的双进程架构即可；

回答者：@Cundong

Q：使用Fargemnt常见问题汇总？

错误1.“Fragment cannot be cast to android.support.v4.app.Fragment”问题（#378、#467）？

A：该类问题主要是由于Fragment继承自android.support.v4.app.Fragment，若直接继承android.app.Fragment不会有该类问题，两者的使用以及区别不再赘述。 插件内部出现该类问题，主要是由于在插件的dependencies中直接或间接引入v4包，包括引入第三方库时，其依赖关系导致最终引入与该第三方库版本相对应的v4包（尤其需要注意），以致插件与宿主host的都包含有v4包，最终导致宿主调用插件遇到类转化问题。

具体解决：

方式一：可以参照demo1。通过修改插件的build.gradle文件，以provided files(‘libs/fragment.jar’)方式，骗过编译期，并借助Gradle 的exclude语法来解决版本冲突，移除support-v4，即：

configurations { all*.exclude group: ‘com.android.support’, module: ‘support-v4’ }

方式二：也可以借助打包工具来处理，具体可参照：replugin-resolve-deps-conflict，同样可解决此类问题。@lijunjie

另外，如果存在通过provided方式引入的库，而在插件中第三方库存在依赖的问题，可参照解决

错误2."Unable to instantiate fragment com.xx.TestFragment: make sure class name exists, is public, and has an empty constructor that is public"问题(#292)？

A：该问题最可能的原因是由于自定义Fragment类缺少无参的public构造函数，其次看看是否由于混淆导致类名找不到。 另外，不建议通过静态的方式添加fragment，即使用标签的方式。提倡通过动态方式添加fragment，即使用add的方式动态添加。

回答者：@SkyEric

Q : PluginContext 中，为何删除了对getDatabasePath()方法的重写？

A : 这个问题比较复杂，需要详细介绍一下。

主要原因是为了适配 Android 8.1 及后续版本，我们从系统源码的角度来看一下这个问题：

SQLiteOpenHelper#getWritetableDatabase()方法中，会调用 SQLiteOpenHelper#getDatabaseLocked()方法：

SQLiteOpenHelper#getDatabaseLocked()中有打开数据库文件的逻辑，这个逻辑， 在Android 8.1中发生了变化，具体变化，可以通过源码来看：

android-8.0.0_r36： https://android.googlesource.com/platform/frameworks/base/+/android-8.0.0_r36/core/java/android/database/sqlite/SQLiteOpenHelper.java

android-8.1.0_r9： https://android.googlesource.com/platform/frameworks/base/+/android-8.1.0_r9/core/java/android/database/sqlite/SQLiteOpenHelper.java

可以看到，Android 8.1中，增加了一次对mContext.getDatabasePath()的使用。 而，如果当前传入的Context是插件上下文，真正实现逻辑位于RePlugin源码中PluginContext类，其内部对getDatabasePath()方法做了重写，重写后的逻辑就是：不再返回原数据库目录，而是返回一个自定义的拼接后的路径（如：plugins_v3_data），导致上述系统源码找不到数据库，因此也就不再创建文件了，插件创建数据库时，直接抛异常了。

为了适配 Android 8.1 这一改动，该方法不再重写，因此，需要各插件之间约定数据库名字，防止出现重名数据库的情况。