最近360推出了一个插件化方案RePlugin,
github地址具体特点和其他插件化方案有什么区别就在github上看吧，我就不再这里说明了
接入也非常简单，这里还是去看官方给出的文档就可以了
文档都非常详细，在这我要说的是一些文档上面没有涉及到，后者比较容易出错的地方
首先插件分为外置插件和内置插件
外置插件
外置插件是指可通过“下载”、“放入SD卡”等方式来安装并运行的插件。
以下是“外置插件”的管理方案。
安装插件
要安装一个插件，只需使用 RePlugin.install 方法，传递一个“APK路径”即可。
RePlugin.install("/sdcard/exam.apk");
升级插件
为了简化操作，升级插件的做法和“安装”是一样的，仍可以直接调用 RePlugin.install 方法。
RePlugin.install("/sdcard/exam_new.apk");
注意
如果插件正在运行，则不会立即升级，而是“缓存”起来。直到所有“正在使用插件”的进程结束并重启后才会生效
升级可能会占用“内部存储空间”（因为要释放新的APK）
不支持“插件降级”，但可以“同版本覆盖”
卸载插件
要卸载插件，则需要使用 RePlugin.uninstall 方法。只需传递一个“插件名”即可。
RePlugin.uninstall("exam");
下载插件可能还有点问题，就是卸载之后assets里的jar文件还在，导致插件还能运行，他们说正在修复
注意
如果插件正在运行，则不会立即卸载插件，而是将卸载诉求记录下来。直到所有“正在使用插件”的进程结束并重启后才会生效
由于内置插件是捆在主程序包内的，故无法卸载“内置插件”（此处有优化空间，我们还在商量对策）
上面是官方给出的一些内容，我在使用的时候发现了很多问题，比如gradle版本不能太高
classpath 'com.android.tools.build:gradle:2.1.3'
还有就在application中忽略签名设置，因为是开发环境都是debug版
@override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
//-------------- 开发的时候不验证签名 -----------
RePluginConfig config = new RePluginConfig();
config.setVerifySign(!BuildConfig.DEBUG);
RePlugin.App.attachBaseContext(this, config);
// ========================
}
还有就是安装外置apk之后外置apk就删除了，这时候再安装就会导致返回的plugininfo为空，所以你安装之前判断一下APK是否存在。
File externalStorageDirectory = Environment.getExternalStorageDirectory();
String path = externalStorageDirectory.toString() + "/RepluginTest/plugin01.apk";
if (fileIsExists(path)) {
Log.i(TAG, "存在:" + path);
} else {
showToast("外置插件不存在");
return;
}
PluginInfo pi = RePlugin.install(path);
if (pi != null) {
showToast("插件的描述信息:" + pi.toString());
boolean preload = RePlugin.preload(pi);
showToast("预加载插件:" + preload);
} else {
showToast("插件的描述信息Null");
}
内置插件
内置插件是指可以“随着主程序发版”而下发的插件，通常这个插件会放到主程序的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.2.0版本中开始支持)
外置插件：只要调用 RePlugin.install 方法即可将“内置插件”转化为“外置插件”。同样的，需遵循安装插件规则。
这里要说比较重要的2点
1 . 无论外置插件，还是内置插件都要在清单文件上注册版本号和名字,名字可以用来跳转的时候使用，而且上文说到卸载插件的时候可以传递一个名字就是这个名字，插件每一次更新都要增加，
android:name="com.qihoo360.plugin.name"
android:value="zhy" />
android:name="com.qihoo360.plugin.version.ver"
android:value="100" />
2 . 第二点比较重要，也是使用的时候一致困扰我的，就是在使用内置插件形式的时候，要在asstes文件夹下，新建一个plugins文件用来放我们的插件文件（xxx.jar）,这样没有问题，但是之前把官方demo下载并run的时候发现这样只能在内置的时候使用，外置不可以，几经磨难啊，发现在外置插件的时候要把plugins文件名改为replugin_plns,因为如果这个文件名不对会导致Plugins-builtin.json错误，
当编译主程序时，我们的“动态编译方案”会自动在Assets目录下生成一个名叫“Plugins-builtin.json”文件，所以文件名不对导致了json的错误
3 . 插件版本号的最佳实践
其中，第一位是大版本，第二位是功能版本，第三位是修复版本。
例如——101。其中第一位“1”为大版本，第二位“0”为功能版本，第三位“1”是修复版本
大版本：当插件发生“极其重要的变化”时，可调整此版本
功能版本：当插件增加了多个新功能，或优化了多个功能项时，可调整此版本
修复版本：当插件出现一些Bug需要修复，或一些很小的改动项，或做A/B Test时，可调整此版本
Replugin插件花方案使用比较简单，支持功能比较多，只是刚发布没多久，还有一些bug和需要优化的地方，有兴趣的同学可以自己去试一试。
