1. 持久化技术全景
1.1 概念解释：什么是持久化？
持久化（Persistence） 是指将程序运行过程中产生的易失性数据，保存到能够长期存储的介质中，使得数据在应用重启、设备断电甚至系统升级后依然可以完整恢复。在 Android 语境下，持久化是所有需要跨生命周期保留数据的技术总称——无论是用户的偏好设置、聊天记录、离线缓存，还是数据库中的业务数据，都依赖持久化技术来保证数据不丢失。
核心判断标准：一个 Android 组件是否属于持久化技术，只需看它是否满足 “写入 → 重启 → 读取一致” 这个闭环。满足则属于持久化范畴，否则只是运行时内存状态。
持久化是应用架构中 数据层（Data Layer） 的基础设施。选错持久化方案，轻则导致性能瓶颈，重则引发数据丢失、UI 卡顿、ANR 甚至应用崩溃。因此，在开始编码之前建立完整的持久化技术认知，是 Android 开发者从“能用”走向“会选”的关键一步。
1.2 分类体系：Android 持久化技术全景
Android 持久化技术可以从 存储形态 和 数据模型 两个维度划分。下表梳理了当前主流方案及其核心特征：
| 分类 | 代表技术 | 数据模型 | 典型场景 | 线程安全 | 跨进程 |
|---|---|---|---|---|---|
| 键值对存储 | SharedPreferences、DataStore、MMKV | Key-Value | 用户设置、轻量配置 | 部分支持 | 部分支持 |
| 关系型数据库 | SQLite、Room | 表 / SQL | 结构化业务数据、搜索 | 支持 | 支持 |
| 文件存储 | 内部存储、外部存储、沙箱文件 | 字节流 / 序列化对象 | 图片缓存、日志、大文件 | 需自行控制 | 不支持 |
| 云端持久化 | Firebase、云存储 SDK、自研 API | 远程 JSON / 对象 | 多端同步、离线缓存 | 网络层保证 | 天然跨设备 |
| 专用引擎 | ObjectBox、LevelDB、RocksDB | 对象 / LSM-Tree | 高性能 IoT、边缘计算 | 支持 | 部分支持 |
选型第一定律：没有“最好的持久化技术”，只有“当前场景最匹配的技术”。键值对不擅长复杂查询，关系型数据库在小数据量下有过重启动成本，文件存储缺乏结构化能力——理解每个方案的能力边界比记住 API 更重要。
下图直观展示了 Android 持久化技术的完整图景，帮助你建立全局视角：
1.3 历史演进：从 Android 1.0 到现代
Android 持久化技术的演进本质是 对开发效率、性能和安全三者不断平衡 的过程。以下按时间线梳理关键里程碑：
- Android 1.0–2.3（2008–2011）：SQLite 作为系统内置数据库，SharedPreferences 提供轻量键值存储，文件 API 直接暴露。开发者手动管理 Cursor 和线程，模板代码多、易泄漏。
- Android 3.0–5.0（2011–2014）：LoaderManager 辅助异步加载，但仍需手写 SQLiteOpenHelper。ContentProvider 成为跨进程数据共享标准，但学习曲线陡峭。
- Android 6.0–9.0（2015–2018）：Google 推出 Room（Jetpack 组件），编译时校验 SQL、自动协程支持，彻底终结手写 SQLite 时代。SharedPreferences 的 ANR 问题开始被广泛讨论。
- Android 10–12（2019–2021）：DataStore 以 Flow 响应式方案替代 SharedPreferences；MMKV（腾讯开源）以 mmap 零拷贝方案切入高性能场景。云端持久化 借助 Firebase 和 Paging 3 成为主流。
- Android 13+（2022 至今）：多设备协同、跨端数据同步成为新战场。本地 + 云端融合方案（如 Room + RemoteMediator）被写入官方架构指南。持久化选型从“单机存储”升级为“分布式数据策略”。
关键转折点：Room 的推出不仅降低了 SQLite 的使用门槛，更重要的是让持久化层纳入了 Android 官方 架构组件（Architecture Components） 体系，选型从此不再是“哪个 API 好用”，而是“哪个方案能和 ViewModel / Flow / Paging 协同”。
1.4 选型重要性：为什么要在第 1 章强调？
持久化技术选型在 Android 开发中属于 前期架构决策，一旦在项目中后期更换方案，重构成本极高。以下是选型失误的典型代价：
- 性能雪崩：用 SharedPreferences 存储高频传感器数据 → 主线程 IO 导致 ANR。
- 数据不一致：多进程同时写 SQLite 未配置 WAL 模式 → 脏读、数据损坏。
- 功能受阻：选了不支持游标分页的键值引擎 → 无法实现聊天记录按时间倒序加载。
- 团队效率损失：引入学习成本极高的专用引擎（如 ObjectBox）但团队无人熟悉 → 维护断层。
最佳实践：在项目技术方案评审阶段，用本节给出的 “选型四维决策模型”（数据特性、访问频次、一致性要求、团队技术栈）对候选技术逐一打分，先定数据层策略，再写业务代码。
1.5 类比：用生活场景理解持久化
| 生活场景 | 对应持久化概念 | 关键区别 |
|---|---|---|
| 📋 便签纸（临时记录） | 内存变量 / Bundle | 应用结束即清除 |
| 📁 文件柜（长期归档） | 文件存储 / SQLite | 结构化 vs 非结构化 |
| 🔑 钥匙箱（按标签找东西） | SharedPreferences / DataStore | 键值对快速存取 |
| 📚 图书馆管理系统（复杂检索） | Room / SQLite | SQL 查询、索引优化 |
| ☁️ 云盘（随处访问） | Firebase / 云存储 API | 依赖网络、多端同步 |
选型时问自己：你要解决的是“找钥匙”还是“查书”？“找钥匙”用键值对，“查书”用数据库，两者混用就是把图书馆目录写在便签纸上——初期能跑，规模一大就崩溃。
1.6 常见误区
- 误区一：数据库万能论 —— 所有数据都放 Room，导致简单 KV 操作也要写 DAO 接口，增加无用模板代码。纠正：键值数据用 DataStore，结构化数据用 Room，各司其职。
- 误区二：SharedPreferences 只是“慢”而已 —— 它的问题不仅是慢，而是 commit() 阻塞主线程 + apply() 异步丢失风险 + 跨进程不安全。新项目应直接使用 DataStore 或 MMKV。
- 误区三：持久化等同于“存起来就行” —— 忽略 数据一致性、迁移方案、备份策略。比如不做版本迁移的 Room 数据库，一次 Schema 变更就会导致用户数据全丢。
- 误区四：云端持久化可以完全替代本地 —— 网络不可用时应用将完全不可用。正确的做法是 本地优先（Local-First），云端作为同步背书。
1.7 练习题
以下题目用于检验你对本章内容的理解：
-
<