移动应用架构设计：MVVM实战——从项目困境到架构蜕变的真实经历
记得那是我刚接手一个中型社交类 App 的时候，项目已经开发了一年多，用户量也开始稳步增长。原本我以为这只是一个普通的迭代维护任务，结果一接手才发现这个 App 架构上存在很多问题。UI 与逻辑耦合严重、代码难以测试、多人协作时频繁冲突……这些问题就像一颗颗定时炸弹，在每次发布更新前让我提心吊胆。
当时团队规模不大，总共就五六个开发人员，每个人都在做不同模块。然而每当有人改动一些基础功能，其他模块就可能出现莫名其妙的 bug，定位起来非常困难。最夸张的一次，我们因为一个页面的数据绑定错误导致整个首页崩溃，影响了几万用户。那次事故之后，我和技术负责人痛下决心，要重构整个项目的架构。
我们决定采用 MVVM（Model-View-ViewModel） 架构模式，这是目前 Android 和 iOS 开发中都非常主流的一种解耦方式，尤其适合大型应用。虽然当时我也只是略懂皮毛，但在查阅了大量官方文档和社区分享后，我们开始了这场艰难但意义非凡的架构改造之旅。
🧨 遇到的问题：旧架构的噩梦
在开始之前，先简单介绍一下当时的架构情况。
原始项目采用的是典型的 MVC 模式，所有业务逻辑都写在 Activity 或 ViewController 里面，也就是所谓的“厚重视图控制器”。每个页面都包含数据获取、状态管理、网络请求甚至数据库操作，看起来就像是一个“全能选手”。刚开始人少的时候还能勉强应付，但随着产品功能越来越多，这套架构很快暴露出以下几个致命问题：
1. 视图层臃肿不堪
ViewController 中夹杂了太多非 UI 相关的代码，比如网络请求回调、数据解析、状态监听等。一个文件动辄几千行，改个文案都要小心翼翼地找半天位置，生怕破坏已有逻辑。
2. 数据源混乱
由于没有统一的状态管理中心，不同的页面各自持有一份数据副本，导致数据不一致。比如用户信息页面更新了昵称，首页的头像栏却还显示旧数据。
3. 缺乏测试能力
UI 层直接调用各种服务，导致单元测试几乎无法编写。即使写了，也是依赖真实网络请求或者本地数据库，效率极低。
4. 多人协作困难
多个开发同时修改一个页面时，经常出现合并冲突，尤其是涉及到界面生命周期处理的部分。每次上线前都得花大量时间做回归测试。
这些问题让我们意识到，必须尽快进行架构升级，否则后面会付出更大的代价。
✅ 我们的解决方案：使用 MVVM 实现高内聚低耦合
在研究了一圈之后，我们决定在 Android 端引入 Jetpack ViewModel + LiveData + Repository 这一套组合拳，并在 iOS 端尝试使用 Combine + SwiftUI（当时 SwiftUI 刚出不久）。整体目标是：
- 把业务逻辑从业务视图中剥离出来，集中到 ViewModel 层
- 使用统一的数据源（Repository）来管理数据状态，避免数据碎片化
- 所有数据流通过响应式机制驱动 UI 更新，减少手动状态管理
整体架构分层示意如下：
+---------------------+
| View |
| (Activity/Fragment) |
+----------+----------+
|
[Observing ViewModel]
|
+----------v----------+
| ViewModel |
| (Data Binding) |
+----------+----------+
|
[Observe Data Change]
|
+----------v----------+
| Repository |
| (Network, DB, Cache)|
+----------+----------+
具体怎么做呢？
1. 将页面状态提取到 ViewModel 中
以一个“用户资料页”为例，原来的 ViewController 里可能会有以下逻辑：
- 加载用户信息（调用接口）
- 刷新按钮点击事件（重新加载）
- 修改头像后的上传处理
- 数据更新后局部刷新 UI（比如昵称）
这些全部被移到了 ViewModel 中。例如，在 Android 中可以这样定义：
class ProfileViewModel : ViewModel() {
private val _user = MutableLiveData<User>()
val user: LiveData<User> get() = _user
fun loadUserInfo(userId: String) {
// 调用 UserRepository 获取数据
viewModelScope.launch {
val result = userRepository.fetchUser(userId)
_user.postValue(result)
}
}
fun updateAvatar(avatarUri: Uri) {
// 上传头像并更新本地缓存
...
}
}
然后在 Fragment 中观察 user 数据变化，自动更新 UI：
viewModel.user.observe(viewLifecycleOwner, Observer { user ->
binding.userName.text = user.name
})
这样 View 层就只负责渲染，不参与任何数据处理逻辑。
2. 引入 Repository 统一数据来源
我们把原来分散在各个页面的数据访问层抽离成统一的 Repository 类。例如：
class UserRepository {
suspend fun fetchUser(userId: String): User {
// 优先查缓存，再走网络
val cached = cache.get(userId)
return if (cached != null) {
cached
} else {
apiService.getUser(userId).also {
cache.save(it)
}
}
}
}
ViewModel 依赖 UserRepository，而不是直接调用网络接口或数据库。这样一来，数据流向更加清晰，也更容易 Mock 测试。
3. 响应式编程简化状态同步
不管是 Android 的 LiveData，还是 iOS 的 Combine，我们都利用了它们的响应式特性来减少手动状态管理。例如在 iOS 中：
class ProfileViewModel: ObservableObject {
@Published var user: User?
func loadUserInfo() {
userService.fetchUser()
.sink(receiveCompletion: { _ in })
receiveValue: { [weak self] user in
self?.user = user
}
}
}
结合 SwiftUI 的声明式 UI 特性，当 @Published 的数据发生变化时，页面会自动重绘，开发者不需要手动去调 tableView.reloadData() 或者设置某个 label 的 text。
4. 解决双向绑定问题
早期我们在实现登录表单的时候遇到一个问题：用户名输入框和密码输入框的值需要绑定到 ViewModel 中，用于判断登录按钮是否可点。
我们最终采用了 Android 的 androidx.lifecycle.viewModelScope 和 Kotlin 的 MutableStateFlow（Jetpack Compose） 来解决这个问题。具体做法是将 EditText 的内容绑定到 viewModel.userName 上：
binding.usernameEditText.doAfterTextChanged {
viewModel.setUserName(it.toString())
}
而在 ViewModel 内部通过两个 StateFlow 判断是否允许登录：
private val _userName = MutableStateFlow("")
private val _password = MutableStateFlow("")
val isLoginEnabled = combine(_userName, _password) { name, pwd ->
name.isNotBlank() && pwd.length > 6
}.asLiveData()
这样既实现了逻辑分离，又做到了响应式的 UI 控制。
📈 改造后的效果与收益
经过两个月的时间，我们完成了核心模块的重构，并逐步推广到了新页面。效果非常明显：
1. 可维护性大幅提升
现在每个页面的结构都非常清晰，View 只负责展示，ViewModel 负责状态管理，Repository 提供统一数据源。新人接手速度大大提升，也不容易踩坑。
2. 团队协作更顺畅
大家都遵循统一的架构规范，各司其职，冲突明显减少。以前改一个逻辑常常要牵扯多个页面，现在基本只需要改对应的 ViewModel 即可。
3. 易于测试和调试
有了 ViewModel 分离，我们可以很容易地模拟数据，写出高质量的单元测试。配合 Android 的 Espresso / iOS 的 XCTest，UI 测试也变得更加可靠。
4. 用户体验更稳定
因为数据流动变清晰了，页面状态不易出错，尤其是在旋转屏幕、页面跳转、前后台切换等常见场景下，再也不容易出现闪退或空指针异常。
💡 经验总结：给移动开发者的几点建议
回顾整个过程，我想给正在或准备实践 MVVM 架构的同学几点建议：
✅ 1. 不要一开始就追求完美架构
很多新手看到网上一些文章说“要用 Clean Architecture + MVI + KMM”，然后一股脑儿堆上去，最后反而把项目搞复杂了。正确的做法是从最小可行方案入手，比如先拆分出 ViewModel 和 Repository，后续再考虑进一步细化。
✅ 2. 合理控制 ViewModel 的粒度
不是所有的页面都需要独立的 ViewModel，有些简单的页面（比如纯静态页面），可以共用一个 BaseViewModel，避免过度设计。根据实际情况灵活调整。
✅ 3. 统一数据源至关重要
建议尽早引入统一的 Repository 层，否则后期不同页面各自调接口、存数据，会导致数据一致性问题，修复成本极高。
✅ 4. 注意跨平台适配问题
如果你要做跨平台项目（如 Jetpack Compose + SwiftUI），要注意两套平台对响应式编程的支持差异。比如 Combine 在 Swift 中的表现可能跟 Kotlin Flow 不太一样，需要做一定的封装抽象。
✅ 5. 优化性能别忽略
MVVM 本质上是一种架构设计，不代表它天然性能好。比如在 Android 中滥用 LiveData 或 StateFlow 可能会引起内存泄漏；iOS 中不当使用 Combine 也可能造成 retain cycle。建议在关键路径上做好清理工作，比如 ViewModel 销毁时取消协程或 subscription。
✅ 6. 学会合理取舍，不要为了 MVVM 而 MVVM
有时候一些简单的交互确实更适合在 View 层处理，比如点击动画、Toast 提示等。没必要强行塞到 ViewModel 里面，保持灵活性才是王道。
🎯 最后一点感悟
说实话，刚开始改造的时候我也怀疑过，觉得是不是有点“为改而改”，直到第一次版本灰度上线发现崩溃率下降了 50%，才真正感受到架构的力量。现在的我越来越体会到：好的架构不仅能提高开发效率，更能让你睡个安稳觉。
在这个过程中我们也踩了不少坑，比如一开始 ViewModel 泄漏、数据重复加载、UI 不更新等问题层出不穷。但也正是这些问题，帮助我们更好地理解架构的本质。我相信每一个经历过这类重构的团队，都会收获远比代码本身更宝贵的经验。
如果你想从今天开始实践 MVVM，请记住一句话：“架构不是炫技工具，而是解决问题的指南。”希望这篇文章能给你带来启发，也欢迎留言交流你的 MVVM 实践经验！
如果你喜欢这种来自一线的真实分享，欢迎点赞、收藏，也可以关注我的公众号【移动端成长笔记】，我会持续分享移动开发中的干货内容。
评论 0