Architecture on zed的博客

从 MVVM 到 MVI：架构的「意图驱动」演进

Fri, 02 Jan 2026 21:00:00 +0800

在云游戏客户端的开发初期，我们采用了经典的 MVVM (Model-View-ViewModel) 架构。然而，随着业务复杂度的指数级上升——虚拟手柄状态、WebRTC 信令状态、视频流媒体状态、网络质量监控等多数据源的交织，MVVM 逐渐显露出疲态。

State 分散在多个 LiveData/StateFlow 中，View 层充斥着各种状态的监听和组合逻辑，“状态"变得难以追踪和预测。这促使我们向 MVI (Model-View-Intent) 架构迈出了关键的一步。

核心结论

MVVM 在状态少时足够轻量，但复杂页面容易出现状态分散和监听组合混乱。
MVI 的关键是把用户操作抽象成 Intent，把页面渲染抽象成单一 State。
一次性事件不要塞进 State，应通过 SideEffect 单独处理。
Consumer-Driven Design 的重点是先设计上层想要的接口，再倒逼底层实现。
架构升级的目标不是换名词，而是让状态流向更可预测。

1. 核心概念：心智模型的重构

MVI 并不仅仅是一个新的架构缩写，它本质上是一种心智模型 (Mental Model) 的重构。我们将 UI 交互抽象为一种 “请求-响应” (Request-Response) 机制。

Intent ≈ Request (意图即请求)

在 MVVM 中，View 直接调用 ViewModel 的方法（例如 vm.playGame()）。而在 MVI 中，我们将这些操作封装为 Intent 数据结构。View 不再发号施令，而是表达意图。

// 定义用户意图
sealed class GameIntent {
 data object Start : GameIntent()
 data object Pause : GameIntent()
 data class ChangeQuality(val quality: VideoQuality) : GameIntent()
 data class TouchEvent(val x: Float, val y: Float) : GameIntent()
}

// ViewModel 处理意图
fun dispatch(intent: GameIntent) {
 when (intent) {
 is GameIntent.Start -> handleStart()
 is GameIntent.ChangeQuality -> updateStreamQuality(intent.quality)
 // ...
 }
}

State ≈ Response (状态即响应)

ViewModel 经过处理后，不是分散地更新变量，而是发射一个新的、不可变的 State 对象。这就像服务器返回了一个完整的 HTML/JSON 响应。

// 定义单一状态源 (Single Source of Truth)
data class GameUiState(
 val isPlaying: Boolean = false,
 val isLoading: Boolean = false,
 val streamQuality: VideoQuality = VideoQuality.H720P,
 val debugInfo: String = "",
 val error: Throwable? = null
)

这种 Intent -> ViewModel -> State 的单向数据流 (Unidirectional Data Flow)，使得数据的流向清晰可追溯，极大地降低了调试难度。

2. SideEffect：处理那些"一次性"的烦恼

在 Android 开发中，一个经典的问题是：“屏幕旋转后，Toast 重复弹出”。这是因为 Toast 消息往往被包含在 State 中，View 重建后重新订阅 State，再次收到了包含旧错误信息的 State。

MVI 引入了 SideEffect (副作用) 概念来解决这个问题。SideEffect 专门用于处理一次性事件，如弹 Toast、页面导航、播放音效等。

我们通常使用 Channel 来实现 SideEffect，因为 Channel 具有"热流"且"消费后即消失"的特性。

sealed class GameSideEffect {
 data class ShowToast(val message: String) : GameSideEffect()
 data object NavigateToHome : GameSideEffect()
}

// ViewModel
private val _effect = Channel<GameSideEffect>(Channel.BUFFERED)
val effect = _effect.receiveAsFlow()

// 发送副作用
viewModelScope.launch {
 _effect.send(GameSideEffect.ShowToast("连接断开"))
}

// UI 层消费
LaunchedEffect(Unit) {
 viewModel.effect.collect { effect ->
 when (effect) {
 is GameSideEffect.ShowToast -> Toast.makeText(context, effect.message, ...).show()
 }
 }
}

这彻底解决了 MVVM 中 LiveData 倒灌 (“Sticky Event”) 的老大难问题。

3. 消费者驱动设计 (Consumer-Driven Design)

在重构过程中，我深刻体会到了 Consumer-Driven Design 的威力。这是一种反直觉的开发哲学。

错误姿势：从底向上

传统的开发往往是：

先看底层 SDK 提供了什么 API。
写 Repository 封装 SDK。
写 ViewModel 调用 Repository。
写 UI 适配 ViewModel。

这种方式导致 UI 层总是受制于底层的实现细节，代码充满了胶水逻辑。

正确姿势：从顶向下

Consumer-Driven 主张：

先写业务层 (Activity/ViewModel)：假装有一个完美的底层引擎接口。
设计最爽的调用方式：根据 UI 的交互需求，定义出最自然、最符合业务语义的 Intent 和 State。
倒逼底层实现：再去写 Repository 和 Engine 层，去实现这个"完美的接口”。

例如，在云游戏场景中，我们需要一个"切换码率"的功能。我先在 ViewModel 中写下：

engine.setBitrate(5000) // 假设接口是这样，简单明了

然后再去底层实现这个 setBitrate。如果发现底层 SDK 需要复杂的协商流程（暂停流 -> 发送重协商信令 -> 等待响应 -> 恢复流），我就在 Repository 层把这些脏活累活封装掉，绝不让这些实现细节泄露到 ViewModel 层。

这种"假装编程"的方法，确保了上层代码的纯净和高可读性，让架构真正服务于业务，而不是服务于底层库。

总结

从 MVVM 到 MVI，不仅是架构的升级，更是思维方式的转变。

Intent 让我们关注"用户想做什么"，而不是"如何操作对象"。
State 让我们关注"当前是什么样子"，而不是"哪些变量变了"。
Consumer-Driven 让我们关注"业务需要什么"，而不是"底层提供了什么"。

这套组合拳，成为了驾驭云游戏这种高复杂度客户端应用的坚实基石。

Now in Android：现代 Android 应用架构实践

Sun, 09 Nov 2025 10:45:37 +0800

Now in Android 不只是一个 Compose 示例，它更像是一份现代 Android 工程样板：UI、数据流、模块化、依赖注入、离线优先和 Gradle 构建组织都能在里面找到参考。

核心结论

UI 层只消费 UiState，用户操作通过事件向上发送。
数据层通过 Repository 屏蔽网络、本地数据库和同步策略。
模块化结构让 feature 与 core 边界清晰，避免功能模块互相依赖。
Hilt 负责对象装配，但架构稳定性来自清晰的接口边界。
build-logic 和 Version Catalog 是大型项目保持构建一致性的关键。

响应式架构

Now in Android 的核心心智模型是：

Repository / UseCase
 -> Flow
 -> ViewModel
 -> UiState
 -> Compose UI

UI 不主动拉取数据，而是观察状态流。状态变化后，Compose 自动重组对应区域。

值得学习的点：

StateFlow 暴露稳定的 UI 状态；
combine 聚合多个数据源；
map 把领域模型转换为 UI 模型；
UI 只负责展示状态和发送事件；
数据流方向稳定，调试路径清晰。

模块化结构

典型层次：

:app
:feature:*
:core:*

职责划分：

:app 负责应用入口、导航容器和全局装配；
:feature:* 负责具体业务页面；
:core:model 提供基础模型；
:core:data 提供 Repository 实现；
:core:database、:core:network 分别处理本地和网络数据源。

关键原则：

feature 模块不要相互依赖，公共能力下沉到 core。

这样可以避免功能之间形成横向耦合，也更利于并行开发和增量构建。

依赖注入

Hilt 的价值不是“省掉 new 对象”，而是把对象创建和依赖关系集中管理。

重点理解：

@HiltViewModel：让 ViewModel 进入 Hilt 图；
@Inject：声明构造函数依赖；
@Module：提供无法构造注入的对象；
@Binds：把接口绑定到实现；
@Provides：手动创建对象；
@InstallIn：声明对象所在组件和生命周期。

架构上更重要的是：ViewModel 依赖接口，而不是直接依赖具体数据源。

数据层和离线优先

Repository 是数据层的统一入口。它不只是简单转发网络请求，而是负责协调：

本地数据库；
网络接口；
同步策略；
缓存策略；
数据模型转换。

离线优先的基本思路：

UI 优先观察本地数据库
 -> 后台同步网络数据
 -> 写入数据库
 -> 数据库变化自动推动 UI 更新

这种结构的优点是：UI 响应快，弱网下仍有可用数据，数据来源也更稳定。

构建组织

Now in Android 里值得重点学习 build-logic 和 libs.versions.toml。

build-logic 解决重复 Gradle 配置：

Android application/library 公共配置；
Kotlin 编译配置；
Compose 配置；
Hilt 配置；
测试配置。

Version Catalog 解决依赖版本集中管理，让多模块项目不用到处硬编码版本号。

回看清单

现代 Android 架构重点是稳定数据流和清晰模块边界。
Compose 只是 UI 表达方式，真正的复杂度在状态和数据层。
Repository 应该屏蔽数据源细节。
feature 模块不要互相依赖。
构建逻辑也需要架构设计，不能只堆在每个模块脚本里。

Android 项目组织结构：从单模块到可维护工程

Fri, 17 Oct 2025 09:28:07 +0800

项目结构的目标不是显得“标准”，而是让代码边界清晰、依赖方向稳定、构建配置可维护。小项目可以简单，大项目则需要明确模块职责和构建约定。

核心结论

单模块项目先保持简单，不要一开始就过度拆分。
多模块项目通常按 app、feature、core 分层。
依赖应该从上层指向下层，避免 feature 之间互相依赖。
版本和插件声明集中管理，业务模块保持轻量。
库按需求引入，不存在所有项目都“必需”的 UI/架构套件。

单模块结构

适合学习项目、小工具或业务复杂度较低的应用。

project/
├── app/
│ ├── build.gradle.kts
│ └── src/main/
│ ├── AndroidManifest.xml
│ ├── java/com/example/app/
│ └── res/
├── gradle/
│ └── libs.versions.toml
├── build.gradle.kts
├── settings.gradle.kts
└── gradle.properties

单模块的重点是目录清楚：

ui/
domain/
data/
common/

即使不拆 Gradle 模块，也可以先在包结构里建立边界。

多模块结构

当业务变多、编译变慢、多人协作明显增加时，可以考虑多模块。

project/
├── app/
├── feature/
│ ├── home/
│ ├── detail/
│ └── settings/
├── core/
│ ├── model/
│ ├── data/
│ ├── network/
│ ├── database/
│ └── ui/
├── build-logic/
├── gradle/libs.versions.toml
└── settings.gradle.kts

职责建议：

模块	职责
`app`	应用入口、全局导航、依赖装配
`feature:*`	具体业务功能
`core:model`	基础领域模型
`core:data`	Repository 和数据协调
`core:network`	网络请求和 DTO
`core:database`	本地数据库和 DAO
`core:ui`	公共 UI 组件
`build-logic`	构建约定插件

依赖方向

推荐方向：

app
 -> feature
 -> core

避免：

feature:home -> feature:detail
feature:detail -> feature:home

如果两个 feature 需要共享模型、工具或 UI，优先下沉到 core。

依赖按需引入

常见选择：

Kotlin 扩展：androidx.core:core-ktx
传统 View：Material Components、ConstraintLayout、AppCompat
Compose：Compose BOM、Material3、Activity Compose
生命周期：ViewModel、Lifecycle Runtime
异步：Kotlin Coroutines
数据库：Room
网络：Retrofit/OkHttp/Ktor
依赖注入：Hilt/Koin

原则：

先根据项目架构和 UI 技术栈选择依赖，不要把模板里的库全部搬进来。

Version Catalog

gradle/libs.versions.toml 负责集中管理依赖版本：

[versions]
agp = "8.7.3"
kotlin = "2.1.0"
composeBom = "2024.12.01"

[libraries]
androidx-core-ktx = {
 module = "androidx.core:core-ktx",
 version = "1.15.0"
}
androidx-compose-bom = {
 module = "androidx.compose:compose-bom",
 version.ref = "composeBom"
}

[plugins]
android-application = {
 id = "com.android.application",
 version.ref = "agp"
}
kotlin-android = {
 id = "org.jetbrains.kotlin.android",
 version.ref = "kotlin"
}

模块中使用：

plugins {
 alias(libs.plugins.android.application)
 alias(libs.plugins.kotlin.android)
}

dependencies {
 implementation(libs.androidx.core.ktx)
}

为什么根项目常用 apply false

根项目通常只声明插件版本，不直接应用 Android 插件：

plugins {
 alias(libs.plugins.android.application) apply false
 alias(libs.plugins.android.library) apply false
 alias(libs.plugins.kotlin.android) apply false
}

原因：

根项目不是 Android App，不应该应用 Android Application 插件；
子模块可以复用统一插件版本；
插件声明集中，模块使用时更清晰。

可以把根项目理解为插件货架：根项目负责把插件放好，具体模块按需取用。

回看清单

小项目先简单，复杂度上来后再拆模块。
多模块重点是依赖方向，不是模块数量。
feature 不互相依赖，共享能力下沉 core。
Version Catalog 管版本，Convention Plugins 管构建约定。
依赖按需引入，不要让模板决定架构。

MMKV 与 SharedPreferences：轻量级键值存储选型

Tue, 01 Jul 2025 15:49:53 +0800

Android 中的 SharedPreferences 和 MMKV 都适合存储轻量级键值数据，例如开关、用户偏好、少量业务状态和本地缓存标记。它们看起来解决的是同一个问题，但底层模型完全不同，因此性能、可靠性和适用场景也不同。

一句话结论：

少量、低频、单进程配置可以继续使用 SharedPreferences；高频读写、多进程访问或对启动性能敏感的场景，更适合使用 MMKV。

核心对比

维度	SharedPreferences	MMKV
存储格式	XML 文件	Protobuf 编码
读写模型	内存 Map + 文件持久化	`mmap` 内存映射 + 文件持久化
写入方式	`apply()` 异步，`commit()` 同步	写入内存映射区域，由系统负责刷盘
性能特点	小数据、低频写入足够简单	高频读写更有优势
多进程	`MODE_MULTI_PROCESS` 已不推荐	原生支持多进程模式
接入成本	系统内置，无需依赖	需要引入第三方库
适合场景	简单配置、低频偏好	高频配置、跨进程状态、启动路径读写

SharedPreferences 的模型

SharedPreferences 是 Android 官方提供的轻量级键值存储 API，文件通常位于：

/data/data/<package_name>/shared_prefs/

它的核心模型可以理解为：

XML 文件
 -> 首次读取时加载到内存 Map
 -> 修改内存数据
 -> apply/commit 持久化回 XML

SharedPreferences 的优点

SharedPreferences 最大的优势是简单、稳定、系统内置。对于低频配置，例如是否首次启动、主题开关、简单用户偏好，它的使用成本很低。

常见写入方式有两个：

preferences.edit()
 .putBoolean("first_open", false)
 .apply()

apply() 会先更新内存，再异步写入磁盘，日常更常用。

val success = preferences.edit()
 .putString("token", token)
 .commit()

commit() 会同步等待写入结果，因此可以拿到成功或失败，但不适合在主线程频繁调用。

主要问题

SharedPreferences 的问题通常不是“不能用”，而是容易被用在不适合的场景。

频繁写入成本较高

它以 XML 作为持久化格式。数据变多后，序列化、反序列化和文件写入成本都会上升。
apply() 也可能影响主线程

apply() 虽然是异步写入，但未完成的写入任务会进入 QueuedWork。在 Activity 停止等生命周期阶段，系统可能等待这些任务完成。如果积压了大量写入，仍然可能拖慢主线程。
多进程场景不可靠

MODE_MULTI_PROCESS 已经不推荐使用。多个进程同时读写同一个配置文件时，很难保证状态实时一致。
不适合存储大对象

它只适合基础类型和字符串集合。复杂对象需要自行序列化，这会让边界变得模糊：配置存储逐渐变成小型数据库，但又没有数据库的事务、查询和迁移能力。

MMKV 的模型

MMKV 是微信开源的高性能键值存储组件。它的核心机制是 mmap：

文件
 -> mmap 映射到进程虚拟内存
 -> 读写像操作内存一样进行
 -> 操作系统负责把脏页刷回磁盘

它还使用 Protobuf 进行编码，相比 XML 更紧凑，也更适合频繁读写。

MMKV 的优点

读写性能更好

高频读写时，mmap 可以减少传统文件 I/O 的数据拷贝和系统调用成本。对于启动路径上需要读取多个配置项的场景，MMKV 通常更合适。
支持多进程

MMKV 提供多进程模式，内部通过文件锁等机制处理并发访问，比 SharedPreferences 的多进程方案可靠。
编码更紧凑

Protobuf 编码通常比 XML 更省空间，也减少了解析文本格式的开销。
API 仍然接近键值存储

它并没有引入复杂数据库模型，迁移成本相对可控。

需要注意的边界

MMKV 性能更强，但不意味着所有本地数据都应该塞进去。

它仍然是键值存储

如果数据需要复杂查询、关系建模、分页读取或事务保证，应该考虑 Room、SQLite 或专门的数据层方案。
跨语言或跨版本数据要关注兼容性

存储结构升级时，要考虑旧 key、默认值和异常数据。
第三方依赖需要纳入工程治理

引入 MMKV 后，要关注版本升级、初始化位置、多进程模式配置和崩溃兜底。

选型建议

继续使用 SharedPreferences

适合这些场景：

数据量很小；
写入频率低；
只在单进程访问；
不在启动关键路径上频繁读写；
不需要额外引入依赖。

典型例子：

是否首次启动
是否开启深色模式
用户选择的语言
简单实验开关

优先考虑 MMKV

适合这些场景：

启动阶段需要读取多个配置项；
配置更新比较频繁；
App 存在多进程访问；
对配置读写性能比较敏感；
原本的 SharedPreferences 已经出现卡顿或 ANR 风险。

典型例子：

启动配置缓存
跨进程共享开关
音视频或云游戏场景中的运行参数
频繁变化的轻量状态

迁移思路

从 SharedPreferences 迁移到 MMKV 时，不建议一次性全量替换。更稳妥的方式是按风险分层：

先迁移高频读写或启动路径上的配置；
保留旧 key 的读取逻辑，首次读取后写入 MMKV；
给默认值和异常值兜底；
观察一段时间后再清理旧数据；
避免在迁移过程中改变业务语义。

伪代码示例：

fun getBoolean(key: String, defaultValue: Boolean): Boolean {
 if (mmkv.containsKey(key)) {
 return mmkv.decodeBool(key, defaultValue)
 }

 val oldValue = sharedPreferences.getBoolean(key, defaultValue)
 mmkv.encode(key, oldValue)
 return oldValue
}

回看清单

SharedPreferences 简单可靠，但不适合大文件、高频写入和多进程同步。
apply() 不是完全没有主线程风险，生命周期阶段可能等待未完成写入。
MMKV 的优势来自 mmap 和 Protobuf，适合性能敏感的轻量级键值数据。
MMKV 不是数据库，不应该承担复杂数据模型和查询职责。
迁移时优先处理高风险 key，保持旧数据兜底，避免一次性重构引入新问题。