1. Room与DataStore核心定位对比：概念本质、适用数据模型、典型场景
1.1 概念本质
Room 是 Android 官方提供的 SQLite 抽象层（ORM），将关系数据库表映射为 Java/Kotlin 对象，通过注解（@Entity、@Dao）定义表和操作，编译时生成实现代码，提供 SQL 的全部表达能力。它的本质是一个关系型数据库持久化框架，依赖 SQLite 引擎运行在进程内部。
DataStore 是 Jetpack 家族中的轻量数据存储方案，本质是基于文件或 Protobuf 的键值存储系统（类似 SharedPreferences 但更安全、异步）。DataStore 分为两种：Preferences DataStore 存储键值对，Proto DataStore 存储结构化 Protobuf 对象。它不提供查询语言，所有操作通过键或类型安全的 API 完成。
1.2 适用数据模型
| 特性 | Room | DataStore |
|---|---|---|
| 数据模型 | 关系型：表、行、列，外键、索引、触发器 | 简单键值对（偏好设置）或 Protobuf 结构化对象 |
| 查询能力 | SQL 完整支持：JOIN、GROUP BY、子查询、聚合函数 | 无查询语言，仅按键读取或按类型读取整个对象 |
| 异步支持 | Flow、LiveData、RxJava、协同程序 | Flow（默认）、同步读取仅限测试 |
| 迁移/版本管理 | 内置 Migration 机制（SQL 脚本） | 使用 SharedPreferencesMigration 或 Protobuf 增量迁移 |
| 数据大小 | 适合千行以上，百万级性能良好 | 适合小型对象（<1MB），建议仅存储用户设置 |
1.3 典型场景对比
场景一：用户信息管理 — 需要存储用户资料、好友关系、历史记录，涉及复杂查询（搜索、排序、分页）。选择 Room，因为 SQL 可以高效处理关联查询。
场景二：应用偏好设置 — 主题、语言、是否首次启动等简单开关。选择 Preferences DataStore，代码简洁，无需定义实体。
场景三：离线缓存复杂业务数据 — 例如购物车、订单列表、缓存网络响应。Room 适合，因其支持 DAO 和分页库集成。
场景四：存储少量结构化配置 — 例如用户登录 、服务器端点、设备 ID。使用 Proto DataStore，类型安全且异步写入无阻塞。
1.4 核心定位框架图
1.5 实战选择清单
- ✅ 数据需要 SQL 查询（JOIN、排序、分页） → 选 Room
- ✅ 数据是简单的键值对（主题、开关、） → 选 DataStore
- ✅ 数据结构复杂且有对象关系 → 选 Room（实体建模）
- ✅ 需要类型安全且异步写入小数据 → 选 Proto DataStore
- ✅ 已有 SharedPreferences 且希望平滑迁移 → 选 Preferences DataStore
- ✅ 数据量超过 1MB 或需要增量索引 → 选 Room 或 SQLite
- ✅ 仅读时缓存网络返回的 JSON（需序列化） → Room（结合 Gson/TypeConverter）
- ⚠ 避免用 Room 存储单字段开关，避免用 DataStore 存储大数据或关联数据
核心原则： 如果问题可以表达为“键→值”或“类型→对象（单个）”，用 DataStore；如果问题需要“筛选、聚合、关联”，用 Room。二者不互斥，同一应用中可并用（例如用 Room 管理用户数据，用 DataStore 管理设置）。