作者：话唠扇贝
一 简介
遵循摩尔定律，手机终端随着每年的更新换代，其性能也飞速增长。依附于此的 Android 应用规模也愈发复杂。截止 2023 年 4 月，最新版本 8.0.32 微信 apk 大小为 238MB，而对比 2011 年微信 1.0 版本 apk 包大小仅为 457KB，短短 12 年增长了 533 倍。
随着应用规模增大，功能扩展困难、测试规模大及并行开发难等问题愈发突出。为了从根本上解决这些问题，就需要对应用进行重构，此时应用架构设计就显得尤为重要。
Android 应用架构设计三步走：
- 现象： 程序代码和资源越来越多，代码耦合度高，扩展、维护及测试困难
- 手段： 分离代码，提炼模式
- 结果： 确保应用的稳健性、可测试性和可维护性
下文主要介绍三种常见的架构设计模式 MVC、MVP、MVVM。
二 MVC
MVC 全称 Model View Controller，是模型(Model)－视图(View)－控制器(Controller)的缩写。
-
View： 负责界面数据的展示，与用户进行交互；对应于
xml布局文件和 java 代码动态 view 部分； - Controller： 负责逻辑业务的处理；
- Model： 负责管理业务数据逻辑，如网络请求、数据库处理和 I/O 的操作等。
MVC 初步解决了 Activity 代码太多的问题，但 Activity 天然不可避免要处理 UI，也要处理用户交互，导致 Activity 里糅合了视图和业务的代码，分离程度不够。
优点：
- 耦合性较低，生命周期成本低，部署快，适用于快速开发的小型项目
缺点：
- 不适合中大型项目，View 层和 Controller 层连接过于紧密
- View 层对 Model 层的访问效率低
- 一般的高级 UI 页面工具和构造器不支持 MVC 模式
三 MVP
为了将 Activity 中的表现逻辑彻底分离出来，业界提出了 MVP 的设计。
MVP 全称 Model View Controller，是模型(Model)－视图(View)－呈现者(Presenter)的缩写。
-
View： 只负责显示 UI，只与 Presenter 层交互，与 Model 层没有耦合。对应于
Activity与XML； - Presenter： 负责处理业务逻辑，通过接口回调 View 层；
- Model： 负责管理业务数据逻辑，如网络请求、数据库处理和 I/O 的操作等。
在 MVP 模式中，Model 与 View 无法直接进行交互，所以 Presenter 层会从 Model 层获得数据，适当处理后交给 View 层进行显示。在 MVP 模式中，Presenter 层将 View 层和 Model 层进行隔离，使 View 和 Model 之间不存在耦合，同时将业务逻辑从 View 层剥离。
优点：
- 逻辑结构清晰，View 层代码不再臃肿，所有的交互都发生在 Presenter 内部
缺点：
- View 层和 Presenter 层的交互需要定义接口方法，当交互非常复杂时，需要定义很多接口方法和回调方法，增加维护复杂度
- Presenter 层 持有 View 层的引用，当用户关闭了 View 层，但 Model 层仍然在进行耗时操作，会有内存泄漏风险
四 MVVM
MVVM 全称 Model View ViewModel，模式改动在于中间的 Presenter 改为 ViewModel，MVVM 同样将代码划分为三个部分：
- View： 与 MVP 中 View 的概念相同；
- ViewModel： 连接 View 与 Model 的中间桥梁，ViewModel 与 Model 直接交互，通过 DataBinding 将数据变化反应给 View；
- Model： 负责管理业务数据逻辑，如网络请求、数据库处理和 I/O 的操作等。
在实现细节上，View 和 Presenter 从双向依赖变成 View 可以向 ViewModel 发指令，但 ViewModel 不会直接向 View 回调，而是让 View 通过观察者的模式去监听数据的变化，有效规避了 MVP 双向依赖的缺点。
优点：
- 模块间充分解耦，结构清晰，职责划分清晰
- 在 MVP 的基础上，MVVM 把 View 和 ViewModel 也进行了解耦
缺点：
- View 与 ViewModel 的交互分散，缺少唯一修改源，不易于追踪
- 复杂的页面需要定义多个 MutableLiveData，并且都需要暴露为不可变的 LiveData