ApkBus|聊聊大型 APP 架构演进之路
昨天的ApkBus Android开发者论坛上海站 本人分享了关于架构的东西，晚上有很多听众微信给我说“有没有具体的文章出来啊，PPT看的有点不过瘾”，本文以大会上分享的课题为蓝图，专门写个文章出来, 错过的朋友可以回顾一下！
注明：本文未经本公众号开发者技术前线授权，转载其他网站或抄袭排版来盈利的个人和组织都将追究责任.
随着公司业务需求的不断扩大，单一的App已经无法满足业务需求，从主App分离出的某一业务，需要构建新的App项目，也随着团队人员规模的增加，开发者将从不同功能的角度并行开发，逐渐就会发现，效率和业务冲突几乎是无法避免的，单一的混乱架构已显得力不存心，因此进行组件化架构已是势在必行。
本文会大致介绍下Android客户端 目前的架构体系，并通过介绍怎么从既有的单一项目进行架构之路来讨论 ，来分析动态化方案在项目成熟后期的优势。
1
背景
平安好房Android团队从2015年底就开始了全面的组件化之路探索，前期只是将业务和框架剥离，到后期的拆分模块化多人协同开发，目前全部已进行的组件化后的持续集成。完成了一个App从无架构到目前形成的灵活的组件化，历经差不多2年时间。 但是组件化和模块化在目前的既有项目，再进行新APP需求的场景下，还是显得力不从心。于是我们寻求了要探索引进新的技术来弥补目前业务存在的不足。
2
基础架构
App大致包含三层：业务层，中间层，和基础层。业务层包含了支撑业务功能的门面，中间层负责业务和底层的交互适配，底层包含了项目最基本的组件功能！
下图是基本的垂直分层结构:
业务层： 负责APP首要用户感官和功能的交互，列入 注册登录， 首页，列表，个人中心，IM 通讯等。 中间层： 负责App基础功能和底层的交互调度， 实现上层和基础层的一些初始化，适配调用工作，具体化的UI模块等 大致：全局配置， 路由， API辅助类，其他一些变化不大的App升级功能, 地图， 浏览模块， 第三方SDK的封装类等 基础层： 提供上层调用的，基本上比较固定的模块。我们称之为sdk。主要有网络框架，路由框架，统计埋点框架，工具库， 图片加载框架 ，抽象基础UI组件，安全反作弊等。
实际上细分的话还有第四层，比如JNI， Hook等的Native层 ， 目前很多项目采用自定义的so很少，这里就不在为这个新开一个层级，如果是多媒体，直播视频类APP建议还要做一层Native C层。
3
模块化
模块化概念其实已经算是成熟的，讨论多的一个概念，早在Web端流行的时候，前端早已提出了模块化的概念，后在移动端不断实践得到认可。 模块化其实是个很玄乎的东西，一个大功能可以是个模块，一个小功能也是个模块，无论是出自什么样的格式输出都算是， 例如 android中的sdk， library, aar, package，module实际上都是属于模块化范畴。
接下来继续对上面的分层进行细化！
事实上，上图远远达不到大日货级的app，第二层实际上还有三方SDK的 Warper，用来支持适配封装原生的第三方SDK，例如地图，推送，统计等。
目前APP也应该有自己的埋点框架，因为大日活大数据就是价值。
4
组件化
组件化是基于模块化的提出的概念，模块化针对第一层和第二层比较多，组件化则侧重于全部三层而言，也就说拿到一个功能可以直接用，就好比我们拿到android提供的一些Api就可以使用一样，无需做过多的修改和兼容。 模块化的优势是让业务细胞单元化，组件化则让业务灵活通用化！ 动态插件化后文再细说！
到底是什么？ 优势哪里？ 我们不妨继续看看下图：
通过上图，我们不难发现A， B , C, D , E 都可称为组件，这组件是由什么东西组成？ 实际上一个业务模块可称之为组件，一个依赖库实际上也是组件，只不过列属A，B,Ｃ，D， E内的组件而已，只是没通过路由中间件来做桥接。
基础组件通过APPBus来进行时序的控制，水平方向的业务组件 则采用AOP编程，注重空间的概念，目前的Darger2就已经能做到懒加载作用。
什么是组件化？
编程宏观来讲：组件（Component）是对数据和方法功能的简单封装。 组件可以有自己的属性和方法。属性是组件数据的简单访问者。 方法则是组件的一些简单而可见的功能。使用组件可以实现拖放式编程、快速的属性处理以及真正的面向对象的设计。
从设计模式来讲：实际上组件化就是面向Aop编程！ 项目开发客观来讲： 组件化就是对业务功能的封装。 组件有自己的逻辑和功能，逻辑是组件的重要组成部分，功能时组件的一些方法体的具体表现。
优势哪里？
从图2我们大致上做了一个对项目的结构整理，可以看出来有不同业务单元和库单元，假设我们在需求变动不大情况下，各自负责开发的人可以是完全有能力做到协调。
假设在一个业务版本变换很大的情况下，那么各自负责开发业务的人之间就要私自去协商， 协定，去做业务交互，无论是通过是删代码还是屏蔽依赖，因此，这个过程中带来的会耗费很多的精力，后续还要联调各个业务单元的完整性。
那么组件化就是做到让各个模块间无直接交互，通过中间件来进行交互，如果在上面的需求变化很大的情况下，中间件来进行调度加载就行，无论是整个业务时序总线问题，还是遇到业务变动很大的场景，组件化的中间间 可以做到灵活适配，灵活调度。
5
插件化
插件化实际上是和组件化有点异曲同工之妙，只不过插件可以独立运行，也可以在某个app宿主载体中运行。插件化也是Android近年来的核心技术。各大互联网公司已对这块做了技术支持。业务模块可以做成对立的插件，我们先看一个典型的案列。
典型案例
以美团APP为列：
美团客户端本身就是一个独立的APK, 里面集成的四个业务实际上也是能够独立运行的APK， 无论去掉其中一子app, 还是新增一个app，都是很容易实现的事情，这些独立的App, 我们称之为插件APK， 而这个美团APP称之为载体APP。无论怎样的形式代码只有一份，一次编译到处运用。
以上只是理想状态，目前美团客户端一部分首页模块使用H5进行更新的。
这种场景在一个主app拆分多个app时候，就发挥很大作用。这里就有人提出来，我直接从主app copy代码不行吗，恩，是可以，但是以后在项目合并的情况，又要重新copy，各种联调，剔除各种依赖 ，这样被折腾几次 ，你是否觉得这方案合理吗？
目前很多大型App后期都会有拆分业务成多个独立的App，那么可以参考插件化方案，将拆分的业务当做插件来看。
实现原理
插件原理实际上目前行业内已经有成熟的框架，主要利用三种方案实现 1 修改注入app的context 2 利用修改aapt打包机制 3 载体动态代理插件组件。
开源框架
目前市场上主流的插件框架如下表：
Dynamicapk:携程 github: https://github.com/CtripMobile/DynamicAPK VirtualAPK:滴滴 github: https://github.com/didi/VirtualAPK DroidPlugin ：360 https://github.com/DroidPluginTeam/DroidPlugin Small https://github.com/wequick/Small Dynamic-load-apk 任玉刚 https://github.com/singwhatiwanna/dynamic-load-apk
各种框架自己的不同点对比（图来自任玉刚老师的微信号）
本身插件化方案是为了做本地加载的，目前已运用到了服务端下发插件，进行动态化加载，也起到了一部分热更新功能，但是插件化不代表是热更新或热修复。
相对热修复而言目前主流的有AndFIx，HotFIx, 阿里百川Shopix, 美团的Robust, nuwa, 微信的Thinker. 如果有条件的团队可进行自我研究这快的即使，开发新框架。开发新框架也等于造轮子，轮子造多了 也就成了自己的东西，这里不再对热修复过多介绍。
6
动态插件化
动态插件化 概念 是将插件部署到服务器上，进行对插件版本动态下发，本地载体App动态加载器插件的机制，客户端前期，可以进行本地的不动态插件，等运用成功后可以进一步做动态化插件技术引进。 动态化不代表就是容器，Atlas原理可以看这里：Atlas 带你畅游动态性容器框架之旅实现要点.
业务必须先实现到 模块化—组件化—插件化的前提下，方可结合框架进行动态加载插件化的方案。
1 客户端：
开发需遵守各插件APP和载体App的标准协定，包括ID区间，资源前缀， 包区分，接 口统一，依赖库统一等
2 Web端
需要提供一套完整部署插件控制的API接口。客户端需从web端下载目标apk，来进行 本地的load功能。
优势：
1 .App分离组合简单化
组合业务，拆分功能很容易。
2.产品业务更新实时化
无需再发包,业务增量更新化.
3 .Apk瘦身化和微量化
载体Apk等于是个壳子，首次发包体积为微量化。
4. 项目管理开发敏捷化
协同开发更明确，更灵活。
7
最后
本文并没有对Weex和RN进行加入，两者方案只能算是跨平台方案，并不是属于架构之路的范畴当中，其他一些容器框架实际上也是等于跨平台技术，也并非是一个客户端本身考虑的架构问题。如果你有什么疑问请加大白君（Tamic）的微信。
注明：本文未经本公众号开发者技术前线授权，转载或抄袭排版来盈利的个人和组织都将追究责任，尤其是XXX架构师微信号 偷偷截图发布的，用小密圈捞钱几万的的本人将采用法律途径，请尊重原创。
如果你觉得文章对你有用请随支持下本人，就如7月22日的大会本人提到阿里的数字基因，细胞核膜，电子指纹概念以及实现原理，也会在后续推出，希望得到你的支持。如果觉得文章对你有用，请分享一下也是种对我的支持！
精彩推荐
技术 - 思考 - 感悟
END