Android 的插件化浅析

近一段时间由于业务上的需要 一直在做Android 插件化方面的工作，略有一些收获，于是写出来和大家分享。
文章按照以下逻辑来组织：

• 背景知识
• 插件化可以做什么
• 插件化的原理
• 插件化框架应该具备的能力

下面会分别阐述

背景知识

对于一个初创公司来说，可以说插件化是无用武之地的，产品初期的目标在于发展业务，迭代功能，争取用户，而只有产品和业务发展到一定规模，技术架构遇到一定瓶颈时，才会产生对插件化的需求。
对于Android平台而言， 插件大致分为两类：独立插件 与 非独立插件

• 独立插件即为独立的apk， 插件与app无异，插件框架更像一个沙盒容器，比如类似Lbe的平行空间, 360手机助手 加载的均为此类插件

• 非独立插件，宿主与插件间有一定的约定规范，开发插件需要遵循制定的规则来进行开发，具有一定的弱侵入性，这种方式主要用于产品内部的业务模块插件化解耦。

独立插件对于技术上的要求更高，需要完整的支持四大组件的全部特性，类似成熟的框架有360开源的DroidPlugin, ACDD 等等， 而对于很多产品形态而言，更多的是需要非独立插件式框架，解耦产品内部的业务模块,类似的框架有 Small 本篇文章着重介绍后者。

插件化可以做什么

• 动态更新， 减小Apk大小，同时也可以解决MultiDex的问题。
  将用户可选择使用的功能模块做成独立的插件动态下发，减少主APK的大小，当然这种行为只适用于国内市场，google play 是不允许这种行为的。
• 解耦主项目，方便不同业务的并行开发。
  每个业务作为独立的插件进行开发，可以大大减轻合并不同分支带来的工作量
• 提升编译效率
  从编译整个项目到只需要编译独立的插件，尤其对于大中型项目来说可以节约不少时间。 Instant-Run 虽然解决了增量编译的问题，但偶尔还是会遇到代码同步后未更新的bug。

当然，插件化也会带来不方便的地方，比如开发习惯上的不同，需要满足一些插件框架约束条件；如果项目开发到一定规模再进行分拆业务模块的话，还会存在很大的重构成本。

插件化原理

本质上讲插件化的原理可以概括为：动态加载
这其中包括代码的动态加载 和 资源的动态加载，下面逐一介绍。

• 代码的动态加载

  • 动态加载dex
    ClassLoader 机制：ClassLoader是通过双亲委托模型来搜索类的， 每个ClassLoader实例都有一个父类加载器的引用， 当进程在启动的时候，并不会一次性加载程序所要用的所有class文件，而是根据程序的需要，通过Java的ClassLoader 来动态加 载某个class文件到内存当中的，从而只有class文件被载入到了内存之后，才能被其它class所引用。
    针对Android 平台，研究DexClassLoader的加载机制可以发现最终的dex文件都会存放在dexPathList 对象的Element[] 数组中，因此我们可以通过反射扩展element数组load 多个dex. 具体参考MultiDex源码
  • 动态加载系统组件
    对于Activity Service 这类系统的组件不只是一个java对象， Android还赋予了他们各自的生命周期。对于这块的逻辑需要研究Activity、Service、Broadcast、 ContentProvider四大组件各自的启动过程，通过拦截关键的节点进行组件intent的替换，各大主流的插件框架的原理大致相同，具体 hook的节点存在一些差异。对于这块具体的分析可以参考weishu博客，作者在这博客对于四大组件的插件化分析比较清晰，不在此赘述。
  • 动态加载.so 文件
    https://segmentfault.com/a/1190000004062899

• 资源的动态加载
  对于动态加载插件资源这块大体的做基本类似，通过反射调用AssetManager中的addAssetPath 加载插件中的资源，还有另外一个问题如何解决资源id的冲突，一个资源ID值主要包含三个部分，package段 type段 以及value段，如果不加处理很容易造成不同插件间的资源冲突, 具体原理参考 这块的解决方案大致有两种

  • 修改aapt的源码，在编译期修改package字段，保证不同插件间的packageId不同 避免冲突。
  • 在编译后期删除原来的R，重新生成自定义packageId的R.class。参考small的编译工具。

插件化框架应具备的能力

• 稳定 兼容性强， 尽量减少对framework 层的hook
• 版本管理：在插件升级后保证每个进程加载dex的一致性。
• 安全校验：保证加载的插件不被篡改，可以采用非对称加密的方案。
• 监控回调：当插件加载失败时通知宿主，不影响宿主的正常运行。
• 提供完整的编译插件的工具链

后记

介绍了这么多，其实会发现目前主流的插件化框架均为国内团队开发的，而国外对于动态更新选择了react native 的开发方式，为什么在插件化的技术层面国内与国外的开发方式存在巨大的差别，笔者赞同OasisFeng 的回答 ： Google Play的开发者协议不允许绕开Google Play Store进行代码层面的更新，并非不想使用这个技术 。正式由于国内app的分发 脱离了google play的生态才造成了插件化百家争鸣的现状， 所以说 趋势在哪？还请大家自行斟酌。

参考资料:
https://github.com/wequick/Small
https://github.com/bunnyblue/ACDD
https://github.com/DroidPluginTeam/DroidPlugin
http://weishu.me/
Android动态加载基础 ClassLoader工作机制
instant-run 源码
multi-dex 源码