1. Room数据库简介与优势：为什么选择Room作为本地持久化方案

1.1 本地持久化，Android 开发绕不开的坎

说实话，做 Android 这么多年，我最怕的就是数据丢了。用户辛辛苦苦填的表单、缓存好的列表、离线收藏的内容——一旦 App 进程被系统杀掉，没有本地存储，全白搭。你想想看，用户是不是立马就卸载你的 App？

我刚开始用原生 SQLite 的时候，SQL 语句全是手写字符串，拼个条件都得小心翼翼。后来出了 ORM 框架，GreenDAO、Realm 都试过。但直到 Room 出现，我才觉得这才是 Android 官方该有的样子。我个人习惯是：只要 App 需要离线数据，首推 Room。

1.2 Room 是什么？它解决了哪些痛点？

Room 是 Google 官方推出的持久化库，属于 Jetpack 的一部分。说白了，它是对 SQLite 的一层抽象封装。但它不只是在外面包层皮，而是解决了很多我以前踩过的坑：

  • 编译时 SQL 校验：我以前最怕运行时才发现 SQL 写错了。Room 在编译阶段就能查出语法错误、表字段名不对的问题。
  • 减少样板代码：手写 ContentValues、Cursor 循环读取？Room 用注解自动帮你生成了。
  • 原生支持协程和 Flow：我的项目现在全是 Kotlin + Compose，Room 的 DAO 可以返回 Flow，数据一变 UI 自动更新，爽。
  • 迁移策略清晰：数据库升级时表结构变化，Room 提供 Migration 类，不用自己写那些麻烦的 ALTER TABLE 脚本。
  • 与架构组件天然集成：配合 ViewModel、LiveData、Paging 3，几乎不需要额外的桥接代码。

⚠️ 避坑提醒：我曾在一个项目里直接操作 SQLiteDatabase，结果升级数据库时忘记处理旧数据迁移，导致用户升级后 App 闪退。后来换成 Room，Migration 一步步写清楚，再也没出过类似问题。

1.3 Room vs 其他方案：一张表看明白

特性原生 SQLiteGreenDAORealmRoom
编译时 SQL 校验❌❌❌✅
协程/Flow 支持需自己封装需适配部分支持✅ 原生
迁移工具手动脚本手动自动迁移有限✅ 完整 Migration API
学习成本低中中高低（会 SQL 即会用）
与 Jetpack 集成❌❌❌✅ 官方一等公民

嗯，光看表就知道，Room 几乎在所有关键维度上都占优。但要注意，它不是银弹——如果项目极度简单（比如只存一个 key-value），首选用 DataStore 可能更轻量。

1.4 Room 的三剑客：Entity、DAO、Database

要理解 Room 怎么工作，记住这三个角色就够了：

  1. Entity：数据实体类，对应数据库中的一张表。用 @Entity 注解标记，每个字段就是一张表的列。
  2. DAO（Data Access Object）：数据访问对象，定义了你对表的增删改查操作。用 @Dao 注解，方法上写 SQL。
  3. Database：数据库持有者，管理数据库的创建、版本、迁移。用 @Database 注解，是个抽象类。

我个人喜欢把 DAO 的查询方法返回 Flow 或 LiveData，这样数据一变化，UI 层（比如 Compose 的 ViewModel）自动收到通知，省去了手动通知的麻烦。

一个简单的代码示例

// Entity
@Entity(tableName = "users")
data class User(
    @PrimaryKey val id: Int,
    val name: String,
    val age: Int
)

// DAO
@Dao
interface UserDao {
    @Query("SELECT * FROM users")
    fun getAllUsers(): Flow<List<User>>

    @Insert
    suspend fun insertUser(user: User)

    @Delete
    suspend fun deleteUser(user: User)
}

// Database
@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

💡 我的小技巧：写 DAO 时，如果方法返回 Flow，Room 会自动在后台线程监听数据变化。但记得 @Insert、@Update、@Delete 要加上 suspend 关键字，否则会阻塞主线程。

1.5 Room 的架构位置 & 数据流

下面这张关系图能帮你快速理解 Room 在整个 App 数据层中的角色：

Room 数据库架构与核心组件 应用层 (UI / ViewModel / Repository) App / ViewModel Repository Room Database 数据层 (DAO / Entity / SQLite) DAO Entity SQLite Database 🔍 核心优势 ✅ 编译时 SQL 校验 — 写错表名/字段立即报错 ✅ 自动生成代码 — 无需 Cursor、ContentValues 样板

你看，App 层通过 Repository 与 Room Database 交互，Room 内部通过 DAO 操作 Entity 对应的表，最终落盘到 SQLite 文件。整个链条清晰且分层，每个角色各司其职。

1.6 上手 Room 的第一行配置

在 build.gradle（模块级）添加依赖：

// 如果你用 KSP（推荐）
plugins {
    id 'com.google.devtools.ksp' version '2.0.21-1.0.28'
}

dependencies {
    def room_version = "2.6.1"
    implementation "androidx.room:room-runtime:$room_version"
    implementation "androidx.room:room-ktx:$room_version"
    ksp "androidx.room:room-compiler:$room_version"
}

注意，Room 的编译器推荐用 KSP（Kotlin Symbol Processing）而不是 KAPT，编译速度能快不少。我曾从 KAPT 切到 KSP，大型项目构建时间缩短了 40%。

⚠️ 重要提醒：Room 不支持直接在主线程操作数据库（除非调用 allowMainThreadQueries()，但强烈不建议）。写 DAO 时记得用 suspend 函数或返回 Flow，Room 会自动切换到后台线程执行。

1.7 小结：为什么我坚定的选 Room？

啰嗦了这么多，总结一下我这些年用 Room 的感受：

  • 它把你从繁琐的 SQLite 细节中解放出来，让你专注写业务逻辑。
  • 编译时检查 SQL 错误，节省大量调试时间。
  • 原生支持 Kotlin 协程和 Flow，和 Compose 的 state 同步简直天作之合。
  • 官方维护，迁移升级有保障。
← 上一章 📖 返回目录 下一章 →