为什么 Room 缓存 + Compose 状态同步是个“硬骨头”？
说实话，我见过太多团队把 Room 当普通数据库用——存进去了，取出来了，完事。等到加 Compose 做 UI 时，问题全炸了：列表不刷新、数据显示旧值、页面滑一下就 OOM……
这是我最初接触这个组合时踩过的坑。咱今天就把核心矛盾掰开讲清楚。
核心问题： Room 的缓存本质是 异步数据流（Flow/LiveData），而 Compose 的状态管理是 同步快照式的重组模型。怎么让“慢数据”无缝流向“快 UI”？
1.1 缓存的本质是什么？
缓存不是“存了就好”。它要解决三个问题：什么时候存、存多久、什么时候淘汰。Room 帮我们把数据持久化到本地 SQLite，但 UI 层需要的是及时的最新状态。
- 网络缓存： 从服务器拉一次，存到 Room，后续优先读本地。
- 本地数据： 用户离线也能正常浏览。
- 更新策略： 是每次都重新拉，还是用数据库版本号做增量更新？
💡 我在项目里用过“先显示缓存，再后台刷新”的策略——体验比傻等网络好太多了。
1.2 Compose 状态同步的“坑”在哪里？
Compose 靠 State<T> 驱动重组。Room 的 Flow<T> 收集到新数据后，得能触发重组。听起来直接，但实际链路里藏着不少细节。
- 观测时机： Flow 的收集生命周期必须与 Compose 组合一致（用
collectAsState()）。 - 背压问题： 数据库写入快，UI 重组慢时，数据积压容易掉帧。
- 缓存一致性： 同一数据源在不同界面可能读到不同版本——必须用同一个 DAO 实例。
- 线程问题： Room 查询默认在主线程外，但组合收集回主线程时要留意上下文切换。
⚠️ 我曾经因为没注意 Flow 的 collect 在 CPU 密集场景下被阻塞，导致 Room 写操作排队超时。后来改成 flowOn(Dispatchers.IO) 才解决。
1.3 知识体系总览
先给你一张脑图，把整章要讲的东西串起来。仔细看这张图，后面每个小块都会对应详细展开。
这个体系中，最关键的不仅仅是 Room 和 Compose 各自的能力，而是三层之间的数据映射与生命周期对齐。我们接下来的课程会逐个击破。
1.4 你当前需要掌握的前置知识
| 知识点 | 掌握程度 | 说明 |
|---|---|---|
| Room 基础 | 熟悉 | 能用 DAO 做 CRUD，理解 Entity 注解 |
| Compose 状态 | 入门 | 懂 mutableStateOf 和 recomposition 概念 |
| Kotlin 协程 | 会基础用法 | 知道 scope、launch、Dispatchers |
| Flow | 了解 collect | 知道冷流与热流区别更好 |
如果你对其中某个点比较生疏，别急——本课程里用到时会拎出来解释。不过建议先翻一下官方文档补补基础，不然跟起来会有点吃力。
📌 我习惯在项目里用 object: CoroutineScopeProvider 统一管理 ViewModel 的 scope，这样 Room 和 Compose 不会在生命周期上打架。
1.5 第一个实践：最简单的“缓存数据展示”
先来一个极度精简的例子。我们把一个用户信息存到 Room，然后在 Compose 里显示出来。
// User.kt (Entity)
@Entity
data class User(
@PrimaryKey val id: Int,
val name: String,
val age: Int
)
// UserDao.kt
@Dao
interface UserDao {
@Query("SELECT * FROM User WHERE id = :userId")
fun getUserFlow(userId: Int): Flow<User?>
}
// ViewModel.kt
class UserViewModel(private val dao: UserDao) : ViewModel() {
val userState: StateFlow<User?> = dao.getUserFlow(1)
.stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), null)
}
// UserScreen.kt (Compose)
@Composable
fun UserScreen(viewModel: UserViewModel) {
val user by viewModel.userState.collectAsState()
Text(text = "用户名：${user?.name ?: "加载中..."}")
}
嗯，你看。就这么几步，缓存的 User 数据就能实时驱动 UI。但真实项目中你不会只有一个 DAO——多表关联、分页、冲突解决……我们后面会一层层加难度。
⚠️ 注意 stateIn 的 WhileSubscribed(5000)：我试过不设这个参数，屏幕旋转一下就重建了 Flow，浪费资源得很。
这一章是总览，后面每个小节都会深入细节。比如，“数据流策略”那一块，我会专门讲 Flow 和 LiveData 到底选哪个，“同步机制”里会聊 combine 和 flatMapLatest 的坑。准备好了吗？我们开始慢慢攻克它。