插件化方案对比

1、插件化方案对比已有框架技术对比以下从是否支持四大组件、是否须在主manifest预注册等多个维度对主流开源框架进 行对比，从而筛选出比较符合项目的框架有VirtualAPK、RePlugin，atlas。特性SmallDroidPluginVirtualAPKRePluginAtlas支持四大组件只支持 Activity全支持全支持全支持全支持组件无需在宿主 manifest中预注 册X插件可以依赖宿 主X轻度依赖支持 PendingIntentXAndroid特性支持大部分几乎全部几乎全部几乎全部几乎全部兼容性适配中等高高高高插件构建Gradle 插件无Gradle 插 件Gradle 插

2、件部署 aapt, gradle 插件框架轻重相对轻量相对轻量相对轻量重量支持安卓版本API Level 15+API Level 9+atlas 5.1.0.9-rc26 支持至ij androidQ，这个版本开始 会失去某些特性接入难度中易难侧重阶段运行期运行期运行期编译期热修复能力无无无无有插件更新方式插件独立更 新插件独立 更新插件及宿主须同时 更新可以看到，VirtualApk、Replugin、atlas 三个支持的特性比较全面，那么我们将针对我们比较关心的几个方面去做实验，看看对比效果:插件RepluginVirtualApkAtlas备注安装和 卸载安装插件不需要重 启app生

3、效更新和卸载插件需 要重启app安装插件不需要重启app生效更新和卸载插件需要 重启app在需要的时候安装命名规 范允许插件和宿主“重 名”，优先使用插件 内的类，若插件类 找不到，才使用主 程序（或经过 registerHookingClas s跳转后的）的类 插件可以通过反射 直接使用宿主代码 （双亲委派原理）插件不能包含有主工 程的代码，但插件工 程在编译时应该可以 使用主工程代码协助 编译。如果插件和主app包 含同样的代码，以主 app代码为准不允许重名，重名会 调用的是host的代 码对于开发者来 说，重名的限制 会影响开发、维 护以及沟通成本（可能会导致发 布出去后发现某 个重名

4、导致的 bug）迁移成 本低，插件独立开发低，插件独立开发， 但必须指定host项 目路径集成成本比较高，文档不够友好，插件版本管理比较复 杂通信方 式插件间的耦合度比 较低，需要通过特 定方式（intent， binder， router， 反 射等）代码共享：host 和 plugin 使用 同一个aar，开发中 直接使用。打包时 plugin会剔除。插件之间的代码调用 同上bundle可以直接使 用host中的代码和 资源；插件间通信使 用 AIDL、serviceHub 以及Remote权限申 请必须在host的mainfest 注册插件支持动态权限 申请，申请后host 也生效插件的

5、Activity中不支持动态申请权限（会抛异常）插件允许权限申请动态权限申请会 影响插件开发的 灵活性组件化万案有专门的路由通信方案Router-RePlugin代码共享，可以 router方案都可以使 用atlas本身就是组件 化方案其他插件以apk形式下 发，插件apk可以插件工程目录必须配 置host的目录，打打包必须是host打，版本管理比较复当做个app安装 到手机上；通知展示由插件自 己管理，但图标等 资源必须使用宿主 的包脚本会根据host 的gradle依赖，剔1 除插件的依赖库。这 样项目管理会比较不 方便杂。bundle插件不 能独立运作对比结果Replugin :迁移成本低，插件包完全可以当做apk单独安装到手机上。插件项目和宿主项 目可以完全分离开发。插件间，插件和宿主间的通信需要以基础库或反射的形式相互调用Virtualapk :迁移成本低，插件包不能单独安装到手机上，插件项目对宿主项目依赖比较 强，打包时需要指定host的代码目录，不方便管理。插件间通信需要以基础库形式，发布 到maven上来提供到插件项目使用，需要单独维护maven库，不太方便Atlas : emas提供集成及发布的完整解决方案，不需要另作一套插件的下载更新方案；插件 打包完全依赖host，适合单