系统架构之组件化、插件化和热修复

一、背景

        公司里的产品层负责尝试、预测和理解用户的喜好，技术层也需要思考如何支持快速试错，反馈调整，帮助业务线不断前行，因此产生出新需求，

1. 希望业务越来越丰富，但不期望逻辑越来越臃肿
2. 希望支撑业务快速试错，但不期望频繁升级的叨扰用户
3. 需要很大程度改变程序架构，但不能停止需求迭代，不能过分冒险，需要综合考虑团队整体的学习曲线

所以，落实到技术方案目标：期望实现一个支持热更新，可以把业务分拆为可单独试错的插件化服务集合，支持服务运营，不断分析用户数据的大数据思路调优服务重点。

二、概念

1、组件化
将一个app分成多个模块，组件化强调功能拆分，单独编译，单独开发，根据需求动态配置业务组件

2、插件化
将整个app拆分成很多模块，这些模块包括一个宿主和多个插件，每个模块都是一个apk（组件化的每个模块是个lib），最终打包的时候将宿主apk和插件apk分开或者联合打包，插件化更关注动态扩展、热更新（热修复）

3、热修复（热更新）
通过发布补丁包，在不需要二次安装应用的前提下修复已知的bug

组件化与插件化.png

热修复原理.png

技术	单位	解决痛点	特性	加载状态	优点	缺点	典型框架
组件化	module(模块)	解耦模块，加快编译，隔离不关注的部分	组件之间低耦合，可独立或组合组件编译打包	静态加载	1、组件独立运行 2、代码复用性高 3、明确业务边界，代码结构更清晰	1、开发前期大量时间做模块拆分 2、可能会带来更多重复的代码	CC/阿里ARouter
插件化	apk	解耦模块，加快编译，可实现热更新	每个插件能作为完全独立的apk运行，也可组合集成为一个apk	动态加载，只有真正使用某个插件时才加载	1、支持热部署、支持多业务自然的分拆 2、复用Android API，能在满足动态的同时，提供native的体验 3、宿主和插件分开编译 4、按需下载模块 5、减小APK体积	1、使用大量反射实现，稳定性差 2、插件和宿主一起打包，每次更新宿主，插件都要重新下载 3、只适用于android，无法与ios保持方案统一	携程DynamicAPK/任玉刚dynamic-load-apk/轻量级Small/360DroidPlugin、RePlugin/滴滴VirtualAPK/腾讯Shadow
热修复/ 热更新	.class或资源文件	动态修复bug	相比于插件化，仅提供修复bug功能	动态加载，无需冷启动就可修复bug			腾讯Tinker/饿了么Amigo/美团Robust/阿里AndFix/Qzone等

由此得出，

• 组件化拆分是实现插件化的必经之路，组件化是编译期分模块，插件化是在运行期
• 对于热修复，多模块插件分拆发力不够，插件化能做到的事情更多

三、插件化技术对比

        尽管对比可知插件化更贴合目前开发系统的需求，但插件化代表一种热更新、分拆的概念，具体实现技术很多。技术没有绝对的好坏，终究还是要回归到场景和需求驱动。当进行技术选型时，一定不是跟风，跟热，而是关注负责的业务。