MVI 架构

Android童话镇

2025-05-23 168 阅读3分钟

这篇文章主要聊了 Google 在 Android 应用架构指南中推荐使用 MVI 架构的事儿，咱们可以这样通俗易懂地理解：

一、Google 为啥推荐 MVI？

以前大家常用 MVVM 架构，而现在 Google 更新了架构指南，更推荐 MVI（Model-View-Intent）。核心变化是：

强调单向数据流动：就像水流只能从上游流到下游，数据只能从模型流向视图，避免双向绑定带来的混乱。
状态集中管理：把页面所有状态（比如登录状态、列表数据、加载状态）统一放在一个 “状态类” 里，视图只需要订阅这个状态类的变化，不用像 MVVM 那样管理多个数据流。

二、MVI 架构长啥样？

MVI 架构主要分三层：

界面层（UI Layer） ：只负责显示数据和响应用户操作，比如 Activity/Fragment。
数据层（Data Layer） ：管理数据获取和存储，比如 Repository。
网域层（Domain Layer，可选） ：处理复杂业务逻辑，避免界面层和数据层太臃肿。

三、界面层的核心：UI State 集中管理

什么是 UI State？
把页面需要的所有状态封装成一个不可变的类，比如：

kotlin
```
data class NewsUiState(
    val isSignedIn: Boolean,    // 登录状态
    val newsList: List<NewsItem>,  // 新闻列表
    val isLoading: Boolean        // 加载状态
)
```
所有状态都在这个类里，视图只需要订阅这一个类的变化，不用像 MVVM 那样订阅多个 LiveData。
怎么更新状态？
用户操作（比如点击按钮）会触发 ViewModel 更新 UI State，视图收到通知后刷新界面。整个过程是 “用户事件→ViewModel 处理→状态更新→UI 刷新”，单向流动，不会混乱。

四、MVI 对比 MVVM 有啥优势？

数据一致性更好：所有状态集中管理，避免多个数据源冲突（比如 MVVM 中可能同时修改多个 LiveData 导致数据不一致）。
代码更简洁：添加新状态只需要在 UI State 类里加个属性，不用新增 LiveData，减少模板代码。
可测试性更强：ViewModel 只负责处理状态转换，逻辑独立，容易写单元测试。
更适配 Compose：Compose 本身基于单向数据流，MVI 和它天生契合，Google 可能为了统一架构而推荐。

五、实际开发怎么用？

定义 UI State：用不可变类封装所有页面状态。
ViewModel 管理状态：接收用户事件，更新 UI State。
视图订阅状态：比如用 Kotlin Flow 或 LiveData 监听状态变化，刷新界面。
局部刷新：用distinctUntilChanged等方法避免全量刷新，提升性能。

六、要不要换 MVI？

推荐场景：
- 新项目或用 Compose 开发的项目，MVI 更贴合。
- 希望代码更清晰、数据更可控的项目。
注意点：
- 网域层不是必须的，小项目可以先不用，避免过度设计。
- 如果现有项目用 MVVM 且 DataBinding 用得很多，切换成本较高；但如果没用 DataBinding，切换成本很低。

总结

Google 推荐 MVI 是为了让 Android 架构更统一、更适合现代开发（尤其是 Compose）。MVI 通过 “状态集中管理 + 单向数据流” 让代码更清晰、更易维护，虽然不是所有项目都必须用，但值得开发者了解和尝试。