移动端的架构演化

是什么决定了物种的生存方式和形态？

环境

从08年HTC T-Mobile G1开始，我国算是掀开了Android智能机的时代，13年12月4日我国正式向三大运营商发放4G牌照。
4G时代的到来，给移动端带来了蓬勃发展。

---

第一阶段：业务探索阶段。

这个阶段的产品逻辑

一般有几个特点，产品逻辑，展示，交互简介，业务复杂度低，以商品的搜索、展示、购买等核心流程为主。

发布模式

以 需求收集、评审->测试用例生成、评审->开发设计、编码、评审->测试->发布->运营，单团队单线发布 为主。

• 这个阶段最主要的问题是 如何提高开发者的编码质量。

策略

资深人力资源对核心技术进行封装、高内聚、低耦合；
以最精简的API对外，降低使用复杂度，让开发人员专心于业务逻辑的开发。

最基本的软件设计理念：分层+解耦。

分层：数据流转处理采用责任链模式，保证各个环节的逻辑清晰明了
解耦：隔层之间添加标准的API代理，确保被依赖层可以正常的维护、升级。

---

第二阶段：业务拓展期。

这个阶段的产品逻辑

一般有几个特点，除了核心的商品搜索、展示、交易、评价，增加 社交、导购、物流 等 产品线，以满足用户使用过程的各种需求。

那么这个阶段

单线发布已经无法满足产品线的快速迭代，敏捷开发应运而生，多团队多线发布；

app的技术方面

插件化、热更新、APK加固，当然也包括DNS劫持，HTTP请求加速等诉求。这个阶段的App最艰辛。用户量暴增、机型多样化、网络环境更复杂、产品运营需求更多。就会有很多的什么 功能合并，接口升级等一系列需求。

体现在代码上

就是 代码复用，代码冗余，测试难度复杂，工程体量变大，测试面变大（在电商方面的体现，举个例子 商品变动居然 需要 用户相关场景通测一遍，这就是典型的耦合过大），还有各种闪退。

我们就需要

• App监控(比如说bugly之类，不过现在来看，这些三方监控手段也有很大的局限性)
• 完善的用户反馈机制，让用户可以便捷的反馈，让开发者可以第一时间收到反馈并解决问题
• MAA 做http加速，dns防劫持
• H5做混合
• 热更新，做动态修复等。

策略

在架构设计上，就必须要增加路由、消息机制，来实现业务模块间的解耦。
模块化、插件化，物理隔离不同性质的业务代码，一方面满足产品快速迭代的需求，另一方面减少蝴蝶效应，同时，责任明确，促进高效开发
对通用UI，抽离形成 高独立的控件，形成一套UI服务；对数据获取、处理、存储 也抽离出可方便拓展的单独库，这些数据相关内容也形成 服务。
还需要增加代理层，将adk层的数据进一步隔离，为日后的基础框架替换做准备。

---

第三阶段：业务爆发期。

这个阶段产品逻辑上

会增加 现在流行的人工智能、AR/VR、直播，商品销售定位更加精细。很多的商品的定向推送就是基于这些做法。

这个时候，app的体量会变大

更多的会关注 数据安全、网络速度、消息推送、前端页面更强体验；
甚至 产品独立(公司可能会 将部分产品功能 做大做强，形成独立App)，组织结构会不断拓展边界。

对技术上来说，

• 彻底落实模块化、插件化，所有产品线开辟独立工程，业务代码完全物理隔离，说白了就是用aar+plugin(apk)的方式对外提供，要不要上插件化，需要是研发团队体量决定的，一般来说，一个App 10人的开发团队是不需要上插件化，但是模块化，路由一定要做好，业务耦合必须解决掉。
• UI控件、数据服务精细化，业务研发，对这些服务的使用，必须达到自由取舍的程度。
• 基础的adk标准化，这就需要收集公司 所有app的技术需求，集中优秀人力资源打造超高性能adk，生成开发文档并推广，促进各产业app高效研发。

---

Android架构演变

基础组件化

从上往下依次是：
应用App层：统筹全部组件，并输出App
组件层：包含一些简单的业务
Base：基础库及对基础库的封装

模块化

从上往下依次是：
App应用层：加载初始化操作，并输出App
Module模块层：每个模块相当于一个业务，通过module来分隔每个业务的逻辑，一个模块由多个不同的页面a
Base基础层：对组件库的整合，提供给Module层使用
组件层：对Lib库的一些封装，整合Image、Network等基础功能
Lib库层：基础Lib库，会引入RxJava、RxBus、Retrofit供组件层二次封装，或者一些Util工具类等；这里可以 并入组件层（笔者是这么干的）

多模板化

这是在模板化的基础上，增加了 模板层，用于多个分发业务的组装。甚至多种客户、多种渠道

插件化

从上往下依次是：
应用层：对应插件化宿主App，也包含一些非常基础的业务功能：登陆、支付等账户模块的。
模块层：以独立业务为条件划分
组件层：添加 插件框架

基本上，到了这个层面，一般公司的业务都可以cover。

进程化

巨无霸App：支付宝、微信、淘宝这种，一个App动辄几百M内存。那么就需要多个进程使App获取更多的内存，运行更加流程。

小结

App框架的选择，并非越大越好。选择适合你现阶段需求、并充分考虑到未来3个月可能的需求的框架模式，才是最合理的。

一个初创团队，往往达到模块化就足矣；

项目是不断成长，架构也会不断改进，以使用项目的金华。

架构最重要的是对未来的思考、对未来的把控。

这需要非常长时间的迭代。