1. Room 与 DataStore 分别是什么：核心概念、定位、官方背景、适用场景
1.1 概念速览
Room 是 Google 官方推出的 Android 持久化库，基于 SQLite 构建的 ORM（对象关系映射）框架。它将数据库表映射为 Kotlin / Java 数据类，把 SQL 查询封装为注解或 DAO 接口方法，让开发者用面向对象的方式操作关系型数据。
DataStore 同样是 Google 官方推出的轻量级数据存储方案，用来替代传统的 SharedPreferences。它基于协程和 Flow 构建，支持两种模式：Preferences DataStore（键值对）和 Proto DataStore（带类型协议缓冲）。
| 对比维度 | Room | DataStore |
|---|---|---|
| 底层存储 | SQLite 关系型数据库 | 文件（键值对 / Protobuf 序列化） |
| 数据模型 | Entity → 表，DAO → SQL 操作 | 键值对 或 预定义 Schema |
| 查询能力 | 完整 SQL：JOIN、聚合、分页、索引 | 仅按 Key 读取，无查询语言 |
| 异步支持 | 协程 + Flow + LiveData | 协程 + Flow（原生） |
| 类型安全 | 编译期校验 SQL + 实体映射 | Proto DataStore 支持；Preferences 为运行时 |
| 官方引入时间 | 2017（Google I/O） | 2020（替代 SharedPreferences） |
一句话定位：Room 是「本地关系数据库」，适合结构化、复杂查询、关系型数据；DataStore 是「轻量配置文件存储」，适合小型、简单、高频读写的键值数据。
1.2 官方背景与设计哲学
Room 和 DataStore 都来自 Android Jetpack 家族，由 Google 官方维护。两者定位互补，并非替代关系：
- Room 脱胎于 SQLite 的痛点：裸写 SQLite 需要大量模板代码（创建表、写 SQL、管理版本迁移），且无法在编译期校验 SQL 正确性。Room 用注解 + DAO 抽象解决了这些问题，同时保留了 SQL 的全部能力。
- DataStore 诞生于 SharedPreferences 的缺陷：SP 的同步读写会阻塞 UI、不支持类型安全、容易产生不一致状态。DataStore 用协程 + Flow 提供了响应式、一致性的异步数据访问。
关键认知：Google 从未表示 DataStore 会取代 Room。两者面向不同的存储层级——Room 管理「业务数据」，DataStore 管理「配置状态」。你在同一个 App 中完全可以同时使用两者。
1.3 核心差异类比：图书馆 vs 口袋笔记本
为了快速建立直觉，可以把 Room 想象成一座 图书馆，DataStore 想象成一本 口袋笔记本：
| 图书馆（Room） | 口袋笔记本（DataStore） |
|---|---|
| 有目录索引、分类架、查询系统 | 按页码或标签记录少量信息 |
| 适合存放成千上万本书（数据行） | 适合存放手机号、偏好设置等零散条目 |
| 支持复杂检索：按作者、年份、关键词联合查找 | 只能翻到特定页码看一条记录 |
| 需要管理员（DB 版本迁移）维护结构 | 随时涂改，无需预先规划结构（Preferences 模式） |
| 多个人（多个 DAO）可以同时查不同区域 | 单线程翻笔记本，但翻页很快 |
这个类比说明：工具的选择取决于你要存储的数据的规模、结构和查询需求。
1.4 概念关系图
1.5 常见误区
误区一：「DataStore 是 Room 的轻量版，未来会取代 Room。」
❌ 错误。两者解决的问题不同。Room 面向关系型持久化，DataStore 面向简单状态持久化。Google 官方文档明确将两者列为互补方案，而非替代关系。
❌ 错误。两者解决的问题不同。Room 面向关系型持久化，DataStore 面向简单状态持久化。Google 官方文档明确将两者列为互补方案，而非替代关系。
误区二：「Room 太重了，小项目应该用 DataStore 存所有数据。」
❌ 片面。如果 App 只有 3-5 个配置项，DataStore 确实更轻。但如果小项目也需要按条件查询、关联数据或保证数据一致性，Room 反而是更稳妥的选择。选择依据是 数据特征 而非项目大小。
❌ 片面。如果 App 只有 3-5 个配置项，DataStore 确实更轻。但如果小项目也需要按条件查询、关联数据或保证数据一致性，Room 反而是更稳妥的选择。选择依据是 数据特征 而非项目大小。
误区三：「DataStore 的 Preferences 模式没有类型安全，不如 Room 可靠。」
⚠️ 部分正确。Preferences DataStore 确实只在运行时校验类型，但 Proto DataStore 通过编译期生成的协议缓冲类提供了强类型保证。类型安全程度取决于你使用的模式。
⚠️ 部分正确。Preferences DataStore 确实只在运行时校验类型，但 Proto DataStore 通过编译期生成的协议缓冲类提供了强类型保证。类型安全程度取决于你使用的模式。
1.6 练习题（自检理解）
- 场景判断：你要存储用户登录后获取的 5000 条商品列表，支持按分类、价格区间搜索。应该选 Room 还是 DataStore？
- 场景判断：你要存储用户选择的主题颜色（light/dark/system）和字体大小（3 个档位）。应该选 Room 还是 DataStore？
- 概念辨析：简述 Room 的 DAO 和 DataStore 的 Flow 在数据观察方式上的核心区别。
- 误区修正：有同事说“DataStore 比 Room 快，所以所有存储都用 DataStore”。你如何反驳？请列出至少两个理由。
参考答案：① Room，因为需要复杂查询和大量结构化数据；② DataStore，因为数据量小且仅为配置键值；③ DAO 返回的 Flow 在表数据变化时自动重新发射，DataStore 的 Flow 在文件写入时发射，两者都是响应式但粒度不同；④ 理由之一：DataStore 不支持关联查询和索引，大数据量时全量读取性能衰退严重；理由之二：DataStore 没有 Schema 迁移机制，业务数据结构变化时难以管理。
1.7 应用边界速查表
| 数据特征 | 推荐方案 | 反例（不建议） |
|---|---|---|
| 结构化、多表关联、复杂查询 | Room | DataStore（无法 JOIN） |
| 简单键值对、配置开关、少量状态 | DataStore | Room（引入 SQLite 成本过高） |
| 需要编译期 SQL 校验 / 类型安全 | Room · Proto DataStore | Preferences DataStore（运行时风险） |
| 数据量极大（>10 万行）且需分页 | Room + Paging | DataStore（全量读入内存） |
| 需要数据版本迁移、Schema 演进 | Room（Migration 机制） | DataStore（无内置迁移，需手动处理） |
| 超高频读写（毫秒级，如 Sensor 状态） | DataStore（协程异步，无锁设计） | Room（SQLite 事务开销相对较高） |