作者：话唠扇贝

一 简介

遵循摩尔定律，手机终端随着每年的更新换代，其性能也飞速增长。依附于此的 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