1. 快照一致性概述

什么是快照一致性？

快照一致性，说白了，就是你的数据在某一瞬间是“定格的、完整的、不矛盾的”。

举个例子：你正在用记账 App 记录一笔转账，从一个账户扣除 100 元，同时在另一个账户增加 100 元。如果写入过程刚走到减钱那一步，手机突然死机了，那重启之后账户余额会变成什么样？

没有快照一致性，你可能会看到 A 账户少了 100，B 账户没变。整个账本就不对了。快照一致性保证的是：要么两个操作都成功，要么都像没发生过一样——这就是“快照”的含义。

我早年刚做 Android 存储时，觉得本地读写嘛，SQLite 随手一写就能用。直到有一次线上 Bug：用户同时切换账号 + 后台同步数据，本地数据库出现了一堆幽灵记录——表中既有 A 用户的收藏，又有 B 用户的草稿。排查了整整两天，最终定位到是没有正确处理并发事务，导致数据“串了”。从那以后，我对快照一致性就有了执念。

为什么在 Android 本地存储中特别重要？

Android 本地存储面临几个典型挑战：

• 进程重启：Activity 被系统回收、App 崩溃、用户手动杀进程，都可能中断正在进行的写入。
• 多线程并发：主线程、后台 Service、WorkManager 任务同时读写同一份数据。
• 跨进程访问：ContentProvider、多进程场景下，数据一致性更难保证。
• 电量/内存压力：低内存下系统随时可能杀掉进程，来不及优雅关闭文件。

你想想看，如果你的笔记 App 没有快照一致性，用户辛辛苦苦打了一篇长文，在自动保存时 App 闪退，重启后内容只剩一半——这体验谁受得了？

快照一致性的三大基石

特性	含义	本地存储中的体现
原子性（Atomicity）	一组写入要么全部生效，要么全部回滚	SQLite 事务、DataStore 的原子文件替换
隔离性（Isolation）	并发写入互不干扰，每个读操作看到的都是完整快照	WAL 模式、ReentrantReadWriteLock
持久性（Durability）	已提交的数据不会因崩溃而丢失	fsync、Write-Ahead Logging

这三者合在一起，才构成了真正的快照一致性。缺少任何一个，你都可能在某个角落踩到坑。我当年修复那个“幽灵记录” Bug 时，做的就是给所有写操作加了一把全局互斥锁——虽然隔离性有了，但持久性还是没保证，后来改用 WAL 才彻底解决。

传统写入 vs 快照一致性写入

传统直接写文件的流程，很像“一边盖楼一边拆脚手架”：

// 典型的不安全写入
fun writeDataBad(path: String, data: String) {
    val file = File(path)
    file.writeText(data)          // 如果这里崩溃，文件可能只写了一半
}

快照一致性做法的核心思路是“写完再换”：

// 安全的快照式写入
fun writeDataSafe(path: String, data: String) {
    val tempFile = File(path + ".tmp")
    tempFile.writeText(data)
    tempFile.renameTo(File(path)) // 原子操作，成功则替换，失败不影响原文件
}

这种“写临时文件 → fsync → 原子重命名”的模式，就是快照一致性的经典实现。Room 的数据库文件、DataStore 的 protobuf 文件，底层都依赖这种机制。

Android 中的两个明星方案：Room 与 DataStore

Room 和 DataStore 是 Google 官方推荐的本地存储库，它们都天然具备快照一致性能力，但侧重点不同：

• Room：基于 SQLite，擅长结构化关系数据，支持 SQL 查询、DAO、迁移、复杂查询。
• DataStore：基于文件 + 协程，擅长键值对或小对象存储，轻量、无反射、异步友好。

我个人的习惯是：只要数据是“表格型的、需要关联查询的”，就用 Room；如果是“配置类、偏好类、非关系型小数据”，就用 DataStore。两者都做了快照一致性，但实现细节完全不同——这恰恰是后面章节要深入对比的部分。

快照一致性在 Android 生态中的位置

避坑指南：快照一致性不是银弹

快照一致性保证的是单次“批处理”的完整性，但如果你在外部循环里反复提交小事务，性能会急剧下降。我自己后来养成的习惯是：能用批量操作就别写逐条插入，能用协程的 withTransaction 就别自己造锁。

另外，DataStore 虽然是快照一致的，但它对多进程的支持相对较弱（官方不推荐多进程同时使用同一个 DataStore）。如果你需要多进程共享数据，Room + SQLite 的多进程模式会更稳妥。

小结

快照一致性，本质上是一种“要么不写，要写就写完整”的承诺。它不仅关乎数据不丢，更关乎数据不乱。在这个章节里，我们搞清楚了概念，也看到了 Room 和 DataStore 都是快照一致性的践行者。接下来的 29 个章节，我会带着你一步步拆解它们的具体实现、性能对比、选型决策树——嗯，保证干货满。