Android 架构演进：MVC、MVP 与 MVVM 深度解析

2. MVC 的历史贡献与局限

贡献：

• 首次将'分层'思想带入 Android，打破'上帝类'垄断。
• 推动开发者思考'数据'与'界面'的边界。

局限：

• 角色混淆：Activity 既是 View 又是 Controller，解耦不彻底。
• 测试瓶颈：关键逻辑仍在 Activity 中，无法进行纯 JVM 单元测试。
• 生命周期耦合：Model 若持有 Activity 引用，极易内存泄漏。

2025 年回看：MVC 更像是一次'思想启蒙'，而非实用方案。它暴露了 Android 框架设计与经典 MVC 的天然冲突，为 MVP 的登场埋下伏笔。

第三章：MVP（Model-View-Presenter）——解耦的极致追求

MVP 通过引入 Presenter 彻底切断 View 与 Model 的直接联系，实现'被动视图'理念。

1. 核心组件与交互流

• View：由 Activity / Fragment 实现的接口，仅暴露 UI 操作方法（如 showLoading()、updateList()）。
• Presenter：纯 Kotlin/Java 类，持有 View 接口引用，负责所有业务逻辑。
• Model：数据源（Repository、API、DB）。

View(Activity) -> Presenter -> Model(Repo)
onUserClick()      fetchData()
                    return data
                    showData(data)

2. MVP 的革命性优势

1. 彻底解耦：View 与 Model 零依赖，Presenter 成为唯一中介。
2. 高可测试性：Presenter 可在 JVM 上通过 Mockito Mock View 和 Model 进行完整单元测试。
3. 职责清晰：View 只负责'显示什么'，Presenter 决定'显示什么'。

3. MVP 的沉重代价

1. 生命周期陷阱：
   • Presenter 持有 View 引用 → 屏幕旋转时若未解绑，导致内存泄漏。
   • 需手动实现 onSaveInstanceState / onRestoreInstanceState 保存 Presenter 状态。
2. Presenter 肿胀：复杂页面的所有逻辑涌入 Presenter，演变为'新上帝类'。

样板代码爆炸：

interface MainContract {
    interface View {
        fun showUsers(users: List<User>)
        fun showError(msg: String)
    }
    interface Presenter {
        fun loadUsers()
    }
}

每个页面需定义 Contract 接口，Presenter 与 View 方法一一对应。

2025 年反思：MVP 是'为了解耦而解耦'的典型。它解决了 MVC 的痛点，却引入了新的复杂性。其兴盛（约 2016–2019）恰逢 Android 单元测试文化兴起，但最终被更优雅的 MVVM 取代。

第四章：MVVM（Model-View-ViewModel）——数据驱动的现代范式

MVVM 的崛起，离不开 Google Jetpack 的强力推动。它不再依赖'接口回调'，而是通过 可观察数据 + 生命周期感知 实现自动同步。

1. 核心组件与响应式流

• ViewModel：继承 androidx.lifecycle.ViewModel，持有 LiveData / StateFlow 封装的 UI 状态。
• View：Activity / Fragment 通过 observe() 监听状态变化，自动更新 UI。
• Model：通常由 Repository 统一管理多数据源（网络 + 本地缓存）。

class MainViewModel : ViewModel() {
    private val _users = MutableLiveData<List<User>>()
    val users: LiveData<List<User>> = _users

    fun loadUsers() {
        viewModelScope.launch {
            _users.value = repository.getUsers()
        }
    }
}
// Activity 中
viewModel.users.observe(this) { users ->
    adapter.submitList(users)
}

2. MVVM 的四大支柱优势

1. 声明式 UI 更新：数据变 → UI 自动变，无需手动调用 setText() / notifyDataSetChanged()。
2. 生命周期安全：LiveData 仅在 LifecycleOwner（如 Activity）处于 STARTED/RESUMED 时通知，避免空指针与内存泄漏。
3. 配置变更无忧：ViewModel 由 ViewModelProvider 管理，在屏幕旋转等场景下自动保留实例。
4. 测试友好：ViewModel 不依赖 Android Context，可轻松单元测试。

3. MVVM 的挑战与应对

• 调试难度：数据流隐式传递，错误堆栈不直观。 → 解决方案：使用 Kotlin Flow + StateFlow 提供更清晰的调试信息；配合 Compose Preview 实时预览状态。
• 过度依赖绑定：滥用 Data Binding 可能导致 XML 逻辑膨胀。 → 最佳实践：View Binding + 手动 observe 成为主流，平衡简洁性与可控性。

2025 年现状：MVVM 已成为 Android 官方推荐架构的核心，尤其与 Jetpack Compose 结合后，形成'状态驱动 UI'的终极形态。

第五章：超越 MVVM —— 2025 年的架构新范式

MVVM 并非终点。随着应用复杂度提升与声明式 UI 的普及，新一代架构思想正在融合演进：

1. MVI（Model-View-Intent）：单向数据流的胜利

MVI 将用户操作抽象为 Intent，状态变更通过 Reducer 生成新 State，形成严格单向流：

sealed class MainIntent {
    object LoadUsers : MainIntent()
}

data class MainState(
    val isLoading: Boolean = false,
    val users: List<User> = emptyList(),
    val error: String? = null
)

class MainViewModel : ViewModel() {
    private val _state = MutableStateFlow(MainState())
    val state: StateFlow<MainState> = _state.asStateFlow()

    fun processIntent(intent: MainIntent) {
        when (intent) {
            is MainIntent.LoadUsers -> loadUsers()
        }
    }

    private fun loadUsers() {
        // 更新 state via _state.update { ... }
    }
}

优势：状态可预测、可回溯、易于时间旅行调试（Time Travel Debugging）。 契合 Compose：Compose 的 @Composable 函数天然适配'State → UI'映射。

2. 分层架构（Layered Architecture）：Google 官方推荐

Google 在 Guide to app architecture 中明确推荐三层架构：

┌──────────────┐
│ UI Layer     │ ← ViewModel + Compose/ViewBinding
├──────────────┤
│ Domain Layer │ ← UseCase (封装复杂业务)
├──────────────┤
│ Data Layer   │ ← Repository + DataSource (Retrofit, Room)
└──────────────┘

• ViewModel 不再直接调用 Repository，而是通过 UseCase（领域层）间接访问。
• 实现 业务逻辑与数据获取的进一步解耦，提升复用性与可测试性。

3. Kotlin 协程与 Flow：异步编程的基石

• LiveData 逐渐被 StateFlow / SharedFlow 取代，因其支持冷流、背压、组合操作符。
• ViewModel.viewModelScope 成为协程默认作用域，自动取消未完成任务。
• Repository 层全面拥抱 suspend 函数，简化异步链路。

总结：架构演进的本质是'状态管理'的进化

架构没有银弹，只有权衡（Trade-offs）。 MVC 教会我们'分层'，MVP 教会我们'解耦'，MVVM 教会我们'响应式'，MVI 教会我们'状态即真理'。

站在 2025 年，我们不再争论'用 MVP 还是 MVVM'，而是思考：

• 如何设计不可变的状态模型？
• 如何构建可组合的 UseCase？
• 如何利用 Compose + Coroutines + Flow 实现声明式、响应式、可测试的现代 Android 应用？

而这一切的起点，正是当年那个试图从'上帝 Activity'中挣脱出来的你。

结语： 理解 MVC、MVP、MVVM，不是为了怀旧，而是为了看清—— 所有架构的本质，都是对'复杂性'的驯服。 愿你在未来的代码中，始终握紧这把名为'关注点分离'的罗盘。