android 插件模式调研

前言：

          公司业务越来越大，apk包也是随着变大，而且每次开发功能都需要升级APK 版本才能到用户，而且还有一个版本覆盖的问题，对于运营来说比较不灵活，那么现在解决这样问题有两个方向，一个是插件方式，另一个是react native方式。

插件方式：

1、概念

Android 插件化 —— 指将一个程序划分为不同的部分，比如一般 App 的皮肤样式就可以看成一个插件

Android 组件化 —— 这个概念实际跟上面相差不那么明显，组件和插件较大的区别就是：组件是指通用及复用 性较高的构件，比如图片缓存就可以看成一个组件被多个 App 共用

Android 动态加载 —— 这个实际是更高层次的概念，也有叫法是热加载或 Android 动态部署，指容器（App）在运⾏状态下动态加载某个模块，从而新增功能或改变某⼀部分行为

2、目前相关的开源实现对比

目前开源的插件化框架有：

功能对比：

上图是Small作者总结的图片，可以看出一些基本的支持能力的区别，也有一些主观，供参考

经过比较分析，目前我们把方案集中 以下三种方案：

1，DroidPlugin（360方案，手机助手在用）

优点：

       插件APK完全不需做任何修改，可以独立安装运行、也可以做插件运行。也就是说apk可以不用安装就运行..... 是不是像病毒。

       插件里面的Android四大组件完全不需要在Host程序中注册，支持Service、Activity、BroadcastReceiver、ContentProvider四大组件动态注册，这个是摆脱了新增一个插件需要宿主先定义支持的问题。

       API低侵入性：极少的API，宿主接入简单。

       超强隔离：插件之间、插件与宿主之间完全的代码级别的隔离：不能互相调用对方的代码。通讯只能使用Android系统级别的通讯方法，能在宿主暴露一些需要插件调用的页面，插件才可以通过系统的方式访问。

        资源完全隔离：插件之间、与Host之间实现了资源完全隔离，不会出现资源窜用的情况，当然这我与我们也是一个不方便的地方，就会出现我们的插件每一个都是一套独立的代码和资源，这样插件的包会相应的变大。

        插件的宿主实现是通过Android里面的动态代理的方式hook 了系统的很多API 方法 ，欺骗了系统，突破了很多系统的限制，可以说是一套黑科技解决方案。 因为是hook系统，所以会有适配性问题，但是据说360手机助手插件运行的已经比较稳定了，填了很多坑，这块可以暂不担心吧.. 以后新版本Android系统如果更改了则需要重新适配，目前来看6.0以下都没有问题。

缺点：

         无法在插件中发送具有自定义资源的Notification。

         无法在插件中注册一些具有特殊Intent Filter的Service、Activity、BroadcastReceiver、ContentProvider等组件以供Android系统、已经安装的其他APP调用。

         缺乏对Native层的Hook，对某些带native代码的apk支持不好，可能无法运行。就是 说插件尽量简单，不能包含.so 的动态库，这块支持不好。

          插件和插件，插件和宿主之前共享资源需要解决。

2，DynamicAPK （携程方案，携程旅行APP在用）

优点：

        迁移成本较少，不是通过代理的方式实现，不需要改动太多现有工程的代码。

        提升编译速度 ，修改了APPT 过程，这个待验证。

        Hot fix (包含代码和资源，附件功能)

        按需下载和加载任意功能模块(包含代码和资源)

缺点：

         插件工程不支持so库。

         插件工程支持lib工程依赖、aar依赖、maven远程依赖等各种高级依赖特性。（对于我们改动较大）

3，small  （个人开发者，解决思路不同，有优点）

优点：        

        共享资源文件，支持联调插件

        加载.so后缀插件

        加载非独立插件

        解决方案比较小，核心代码简单。

         社区解决问题比较活跃

缺点：

        没有经过商业项目验证，版本才到0.9 

        很多功能在不断完善，bug 比较多。

4,VirtualApp

类似LBE平行空间，VirtualApp是一个App虚拟引擎的开源实现。 VirtualApp在你的App进程内创建一个虚拟空间，你可以在虚拟空间内任意的安装、启动和卸载APK， 这一切都与外部隔离，就如同一个沙盒。VirtualApp亦是一个插件化框架，运行在VirtualApp的插件不需要任何的约束。

总结：

            比较下来看，觉得DroidPlugin 可以作为优先选择，DroidPlugin 本身的宿主和插件，插件和插件之前有着比较清晰的界限，彼此的通信方式清晰，插件和宿主之间，插件和插件之间的不能相互影响，这里面就会省去我们很多宿主，插件的版本管理和兼容问题，虽然这回带来资源冗余的问题，这可以通过我么我们的产品策略和实现流程规避掉，比如更多资源放置网络上，或是做一个插件公用资源包让用户第一次来下载。至于代码层面的冗余这块对包的大小影响不大，可以不计，另外DroidPlugin 在适配这块基于360助手的适配面，我们使用会少很多适配的工作，目前DroidPlugin 基本集成已经炉石在项目上测试下，插件也宿主之间的页面页面之前的调用已经OK，资源的共享的方式可以通过资源包的方式解决，至于这里面还会有哪些坑，只有在使用过程中慢慢解决。另外在DroidPlugin和腾讯的IM SDK 不兼容，这个还要想办法解决。。。