插件化、组件化、模块化的思考——App架构从开发到构建

android

核心参考

从代码组织层面，我们可以参考这样下面的图片去进行。

三面立体，上面作为职责划分，前面作为代码层级划分，右面作为功能划分。也就是说，可以从三个维度去思考，然后在每个维度里面，又从三个层次去区别和划分！这个位置是指导我们进行架构内部的模块化设计。

如果从顶层的架构设计考虑的化，这里又有两个维度，一个是架构思维，一个是架构原则。思维是我们的思考方式，是我们解决问题的方法。原则是我们思考问题的方向，是我们解决问题的一些标准。

那么我们为什么要去进行架构？
1. 项目需求扩张，旧的架构不适应新的需求；
2. 开发团队人员增加，协作要求变高；
3. 新技术引入；
4. 更高的软件质量要求；
5. 更灵活的开发；

其优势在于：
1. 进行了模块化的解耦，产品相对独立，应对需求变化、技术更新更加灵活，团队协作更加方便，并减少了许多是无用功，也给团队留下了一些技术积累；
2. 进行了必要的统一规范，组织结构更加清晰，系统更加健康；
3. 引入了新的技术框架，，产品获得更好的体验；
4. 进行了系统的优化工作，软件的品质更高，体验更好；

产出依据

架构设计之前，首先要去确立架构的产出依据，也就是我们设计或者采用这样的架构方式，是根据什么产出的。这里主要有两点：

1. 产品开发需求
   在目前绝大部分app中，还是以业务驱动为主，首先要做到的是满足需求内容，在这里就需要去解决业务需求和开发之间的矛盾。反映在架构层级，就是做到快速出成果，所以前期可以不考虑复杂的架构设计，可以直接去编写。但是考虑业务系统的发展，当达到一定层次和规模时，当前的架构并不满足业务的变化内容，就可以考虑对当前项目进行架构变更。说这么多还有一层意思，就是不要过度优化和过度架构，也就是不要为了架构而架构！

2. App的性能和质量
   在app上线后，会收到各种各样的反馈意见，以及终端用户对于app内部错误的上报，那么上报后就需要考虑如何去复现、去定位到最终修改，推送用户升级。那么这个过程中，就会涉及到关于app性能的问题，比如卡顿和内存泄漏这样的问题，我们在去复现问题到解决问题的过程中可能会碰到各种各样的困难，这些困难会促使我们重新思考app的架构，是否可测试、是否够清晰、边界是否考虑周全等等这样的问题。各种各样的问题也会反馈给我们，促使我们去变更当前的app架构。

架构之前

1. 拥抱变化
   拥抱变化并不是指，我们要考虑到所有的会变化的部分去做到一个非常灵活的层次，而是去确定变和不变的层次，再进行编码。要确定在一段时间内不变的东西，考虑到可预见的变化即可。树立不要过度优化的思维！

2. 没有永远完美的架构
   任何架构都不是完美的，任何架构都不会做到适应所有的场景或者是所有的业务逻辑，但是我们需要考虑在当前有限范围内最合理、最适用的就好。

3. 选择当下最合适的
   同上

4. 进化和演变
   随着业务系统的发展，我们需要不断调整自身的架构，适应需求！需求是不断在变化的，但是总会在一定的时间内是不变的。我们需要做的是根据这种变和不变进行架构的调整和进化！

框架/依赖库选型

• 选取原则

1.1 稳定性
所有依赖库在选择的时候首先要考虑稳定性的问题，比如在GitHub上找到一个网络请求框架，我们需要考量的是当前该框架是否还有人维护、是否有很多人star或者fork、是否有很多issue待解决、待解决和已解决的比例有多大等等，毕竟用起来出现了问题，还得依靠从GitHub获取的知识去解决。

1.2 学习成本
所有依赖库在选择的时候都要去看看它是如何去使用的，如何去编写，是否快速上手，遇到问题是否可查，源代码要能去读去看，有条件的可以对源码进行分析审查，再决定是否使用。再一个就是组内人员水平不一的情况下，如何进行培训和指导也要考虑在内！

1.3 优缺点
这一点主要针对多个相同或者相似功能的依赖库对比时，需要明确各个依赖库的优缺点，简单的可以根据上面学习成本中概述的几点去考虑，复杂一些的需要阅读源代码进行。

1.4 应用场景
比如说，各种相似功能的控件应用在界面上是否合适，各种网络请求框架是否符合现在的架构场景。这个需要具体问题具体分析！

1.5 选择标准
1.业界著名的（如Square, Google的）且经过大量使用验证的框架
2. 长期维护且比较活跃（如提交issue）的框架
3. 选择合适的框架，尽量小而精，不要大而全。这可能有些矛盾，因为大部分框架都会考虑通用性，如果仅需要其中一两个功能，就需要权衡了
4. 根据开源级别，尽量选择允许修改源码的，这样一旦框架出现问题，可自行修改
5. 对于国内的库，千万不要只相信star数量

• 原生层面框架挑选

2.1 基础框架
基础框架的分类如下：

• 网络请求与解析
• 事件总线
• 依赖注入
• 图片加载
• 图片/文件选择
• 数据库
• 传感器相关（相机/蓝牙/NFC等）
• 多媒体（注意视频播放部分）
• 性能优化
• 常用的View以及动画效果

挑选参考：
- awesome-android-ui
- 自己总结的Android开源项目及库
- Android第三方库收藏汇总

2.2 第三方服务
- 地图
高德/百度
- 推送
极光/友盟/各大厂商自有（不止集成一个，提高到达率）
- 数据统计
友盟/百度统计
- 分享
ShareSDK/友盟
- 第三方登录
QQ/微信/微博
- IM
- 支付
支付宝/微信/银联/聚合支付
- 广告变现
有米/百度推广首页开屏
- 短信验证码
- 直播平台

• H5/混合开发层面

3.1 WebView
- 腾讯X5浏览内核
- CrossWalk
- AgentWeb（轻量级）

3.2 网页加载优化/预加载
- VasSonic--网页预加载秒开

3.3 和原生代码交互——JsBridge

3.4 混合开发框架
- PhoneGap
- Ionic/Cordova
- AppCan/ApiCloud/mui（国产）
- Weex
- ReactNative （可直接嵌入原生）
- Flutter（独立渲染，可直接嵌入原生）

注: 混合开发这块需要开新坑来研究讲解

• 对现有方案的权衡和改造

4.1 变更成本评估
主要评估下面三个维度：
- 对当前业务逻辑的影响
- 对当前项目运行的影响
- 对内部项目成员的影响

4.2 替换
对当前不符合应用场景的内容进行替换，使其符合当下编写需要

4.3 保留
可用内容要延续，并且可以考虑适当重构

4.4 新增
增加符合业务场景的框架

4.5 是否需要自研替代
对于开源库/框架不满意的情况下，考虑自研内容来代替，可以去改造开源框架来实现，也可以自己造轮子！

代码架构编织

• 前提：三统一
  统一开发环境，统一开发配置，统一代码风格

• 原生代码部分
  原生代码部分可以通过业务拆分为以下内容：

• Base部分
  基础代码，例如基本的网络请求封装和BaseActivity这样的代码
• Common部分
  通用技术，就是在各个模块之间可以通用的代码信息，例如推送、支付这样的通用性强的模块
• Business部分
  特定业务逻辑，到具体的业务场景和业务流程，需要考虑的是，在模块化场景下如何连接各个模块信息，也就是不同模块之间如何跳转的问题。
• Router
  具体模块之间的沟通桥梁
• Others部分
  非业务层面，针对app监控的内容。
• bug监控和问题反馈
  根据监控和上报的信息做出修复，关联后续的热修复部分
• 数据统计信息
  统计点击路径和用户行为

• 内存监控
  可借助工具进行分析，排查内存泄漏的问题

• Web/混合开发部分

• 本地代码
  不常更新，使用频繁的web代码，直接嵌入assets中调用的
• 在线访问
  活动页面，经常进行变更的部分，URL存本地或者从后端获取
• 和原生混合——RN/Flutter
  利用混合开发做部分原生代码的事情，适用场景同上

• 和原生交互——JsBridge
  web层面需要调用原生层面的代码，例如读取手机内联系人这样的场景，或者是和原生逻辑进行交互

• Business层开发模式

• MVC
  传统思维，存在Activity过度冗余的情况
• MVP
  分层，C层变更会引起P层变更，联系紧密
• MVVM
  ViewModel数据绑定，从事件驱动到数据驱动
• Clean Architecture
  分层更清晰，降低耦合
• Jetpack
  官方开发套件

上述方式可根据需要进行挑选，或者团队内部分工编写每一层的代码。

• 热更新/热修复
• 并非银弹
  热更新和热修复并非万能，存在数据包变大、差量包管理复杂的问题，而且还需要注意推送热更代码的到达率，避免出现推送用户群体错误的问题，以防止影响用户使用。

• 分类/使用场景
  可以根据替换的资源范围（类、so、res资源）、是否即时生效、修复粒度来进行选择，可以由下面的内容进行参考：
  Android 热修复 - 各框架原理学习及对比
  Android 热修复方案对比
  Android热修复技术原理详解（最新最全版本）

• 组件化、插件化、模块化

• 模块化：一个程序按照其功能做拆分，分成相互独立的模块（例如：登陆，注册）。模块化的具体实施方法分为插件化和组件化。
• 组件化：开发模式下面module本来就是一个独立app，只是发布模式下变成library。
• 插件化：就是不存在发布模式开发模式，每个组件业务就是一个独立apk开发，然后通过主工程app动态加载部署业务组件apk。

插件化和组件化的异同：

相同点：

都必须能够实现单独调试、集成编译、数据传输、UI 跳转、生命周期和代码边界这六大功能。

不同点：

• 插件化：可以动态增加和修改线上的模块。

• 组件化：动态能力相对较弱，只能对线上已有模块进行动态的加载和卸载，不能新增和修改。

根据需要，建议优先进行组件化的工作，先进行代码分层和抽取，然后再进行插件化和模块化的工作。切记不可提前优化！

参考文章：[Android] 组件化 & 模块化 & 插件化演进

• 快速开发

• 核心：减少重复代码的编写
  一个是现有项目的封装的工具类和功能聚合，另一个是借助模板库和插件来减少重复代码的编写，交给机器自动创建，专注编写业务逻辑

• 模板库——Live Template
  通过编写Android Studio里面的模板库来消除重复代码的内容，例如自动创建相应的文件夹和类代码

• 辅助插件
  例如json解析，自动生成JavaBean这样的代码，还有就是序列化代码的自动生成，将这样的工作交给插件去完成。

持续构建

• 核心：自动化打包和构建
  通过进行持续构建，达到随时产出可用app的目标，将人力从打包的场景下解脱出来，专注业务的开发

• 随时/定时构建
  确定构建的频次，确定产出的内容可以随时被测试，提供手动进行构建的选项，方便测试人员的工作

• 版本管理

  1. 提交文件要少，而且要写清楚代码具体做了哪些工作，禁止一大坨代码一并提交或者一天工作后一提交的行为
  2. 稳定版本打TAG，做标记
  3. 代码最好可以多备份一次，防止丢失。可以在每次稳定版本交付后进行备份。

• 代码质量控制——CodeReview
  提高产出的代码质量，可以进行互相审查，不是为了挑错，而是首先保证代码可读，然后讨论优缺点以及改进方案，最后是提升代码质量和产品质量。能否真正实施，还需要视当前开发进度和团队内部情况决定，但是可以优先统一以下代码风格和Lint静态审查规则。

• 测试
  测试人员根据当前提交的内容，进行自己的工作，然后反馈问题即可。
  开发人员是否需要编写单元测试，视团队情况而定。

• 项目交付
  做到每个小功能一交付，每天一个小交付，通过这样的方式去累积交付内容，达到最终交付的时候能够平稳顺利！

总结

试着将我们的工作任务进行分离，减少每项任务之间的交叉，避免东一榔头西一棒子，有条理的完成各项工作。这样一来，你的工作目标是清晰的，也更加容易的完成既定目标。同样的，我们可以通过这一理论还规划自己的人生。将我们的事业、家庭、兴趣爱好分离，再对每一项分离出更细的关注点，每个关注点在不同的阶段定下自己小目标。这样，我们对自己就可以有了更清晰的认识，认识自己已经拥有什么？最终想要什么？计划怎么做？当前怎么做？当然，并不是每一步都是能够按照既定目标走的，我们需要不断的更新对自己的认识，做出更加合适的决策。

最后，需要注意的是
1. 切记不要提前/过度优化
2. 适应当前需要
3. 结合团队实际情况
4. 仅总结了大体的思路和框架，细节尚需去具体讨论，需要各位的补充信息

参考文章

Android开发架构思考及经验总结
模块化？组件化？插件化？热更新？热修复？