📚 课程目录第2章 Room与DataStore简介

Room与DataStore简介：两种持久化方案的定位与核心特性

说到 Android 本地持久化，你第一反应是什么？SharedPreferences？嗯，我当年也是。但说实话，SharedPreferences 在团队协作和复杂场景下真的挺头疼的。后来 Google 推出了 Room 和 DataStore，我才算真正找到了趁手的工具。这俩不是替代关系，而是分工不同。今天咱就聊聊它们各自的定位和核心能力。

一句话总结：Room 适合结构化关系数据，DataStore 适合键值对或小型对象存储。选错方案？我在项目里见过有人用 DataStore 存大量列表数据，结果序列化性能崩了；也有人用 Room 存个主题设置，杀鸡用牛刀。

两者的定位差异

维度	Room	DataStore
数据模型	关系型表结构（Entity + DAO）	键值对（Preferences）或 protobuf 对象
典型数据量	中等～大量（万级以上）	少量（几百个 key 以下）
查询能力	SQL 查询、索引、关联、聚合	只支持按 key 读写，无 SQL 能力
事务支持	完整 ACID 事务	单次原子写入（Preferences）/ 事务性（Proto）
迁移机制	Migration 类 + fallbackToDestructiveMigration	无内置迁移（Proto 需自行处理）
LiveData/Flow	原生支持 Flow、LiveData、RxJava	原生支持 Flow（读取时）
异步模型	必须协程或 Rx 操作（不允许主线程）	默认协程挂起，主线程安全
性能开销	较重（SQLite 引擎 + 反射/编译注解）	轻量（文件 I/O + 内存缓存）

看到这表你大概明白了——Room 是「大而全」，DataStore 是「小而精」。我个人习惯按数据特性来选：需要跨表关联、需要复杂条件查询？直接上 Room。要是只存个用户偏好、、最后阅读位置？DataStore 就够用了。

Room：结构化数据的守护者

Room 是 SQLite 的 ORM 封装。但别把它想得太重。我参与过一个聊天 App，消息表动不动几十万条，用 Room 的 Flow 配合分页查询，体验很顺。它的核心特性有三：

编译时 SQL 校验——写错表名或列名，编译直接报错。我记得刚转 Room 时，同事写了个 SELECT * FROM user WHERE id = :userId，拼写错误直接在 IDE 里标红，省了多少线上 bug。
自动协程适配——DAO 方法可以返回 Flow<List<User>>，数据一变 UI 自动刷新。但注意：@Insert 和 @Update 要写成挂起函数，否则会阻塞线程。
数据库迁移——你加个字段、改个类型，写个 Migration(1, 2) 就行。我曾经接手一个旧项目，数据库版本从 3 升到 9，迁移链一口气写了 6 个 Migration，Room 稳稳执行。

@Entity(tableName = "user")
data class User(
    @PrimaryKey val id: Long,
    val name: String,
    val age: Int?
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user WHERE age > :minAge")
    fun getUsersOlderThan(minAge: Int): Flow<List<User>>
    
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertUser(user: User)
}

避坑指南：Room 的 @PrimaryKey 必须是非空类型。我曾经踩过坑：把一个 String? 设为主键，结果插入空值时直接崩溃。后来统一用 Long 自增 id 解决了。

DataStore：轻量配置的现代替代

DataStore 是 SharedPreferences 的升级版。它有两种风味：Preferences DataStore 和 Proto DataStore。前者存键值对，后者存强类型对象（需要定义 protobuf schema）。

为什么我更推荐它而不是 SP？因为 DataStore 基于 Flow 和协程，天生异步且线程安全。SharedPreferences 的 apply() 虽然是异步，但一旦主线程调用 getString() 就可能导致卡顿。DataStore 的数据全部通过 dataStore.data 暴露为 Flow，读取时不会阻塞主线程。

注意：DataStore 没有内置迁移方案。如果你用 Proto DataStore，schema 变更时数据库会直接清空。我在项目中曾经改了一个字段名，用户数据全丢了。后来我们加了一层版本号判断，在首次读取时做兼容处理。

下面是一个 Preferences DataStore 的典型用法：

// 写入
context.dataStore.edit { preferences ->
    preferences[KEY_NIGHT_MODE] = true
}

// 读取
val nightMode: Flow<Boolean> = context.dataStore.data.map { preferences ->
    preferences[KEY_NIGHT_MODE] ?: false
}

说白了，DataStore 就是让你用协程舒服地读写小数据。但别想着用它存复杂对象——序列化成 JSON 进 String 可以，但查询、排序统统做不到，只能全量读取然后过滤。

选型心法：看数据关系复杂度

我在设计新模块时，一般先问自己三个问题：

数据之间有没有外键关联？（比如用户和订单）→ 有则 Room
需要做范围查询、排序、分组吗？→ 需要则 Room
数据量大不大？超过 1000 条吗？→ 大概率 Room

如果以上都是「否」，那 DataStore 就是你想要的。还有一个折中方案：用 DataStore 存 Room 的「数据库版本号」或「最后同步时间」，两个一起用。没错，它们不是互斥的。我个人习惯在同一个 App 里同时用 Room 管理业务数据、DataStore 管理用户配置。

核心原则：持久化方案的选择，本质上是对「数据关系复杂度」和「数据量级」的权衡。Room 解决的是「关系」问题，DataStore 解决的是「简单存储」问题。

画个图方便理解。左边分支走 Room 路线，右边走 DataStore 路线。你会注意到最下方那行总结：它们完全可以共存。我上个月重构的一个健康类 App，就用 Room 存运动记录和饮食数据，用 DataStore 存用户身高体重和偏好设置——各司其职，干净利落。