📚 课程目录第3章 SharedPreferences性能瓶颈

SharedPreferences 性能瓶颈：ANR 风险、全量读取、commit 与 apply 的差异及适用边界

1. 概念解释：轻量存储的“笨重”真相

SharedPreferences 是 Android 提供的一种键值对（Key-Value）持久化方案，底层使用 XML 文件存储。它的设计初衷是保存简单的用户配置（如开关状态、字符串、数字），但由于其 全量读取 与 同步/异步提交 机制，在高频写入或大数据量场景下会暴露严重的性能瓶颈。

每次调用 getSharedPreferences() 时，系统会将整个 XML 文件 全部读入内存，即使你只修改一个键。当文件体积增长到几 KB 甚至几百 KB 时，这一操作的耗时可能从几毫秒飙升到上百毫秒——如果发生在主线程，直接导致 UI 卡顿甚至 ANR。

⚠️ 核心矛盾：SharedPreferences 作为“进程内轻量存储”，实际上却在 IO 操作上采用了“全量加载 + 序列化”的笨重模型，与 Android 主线程性能要求严重冲突。

2. 原理图解：全量读取与提交路径

下面的 SVG 展示了 SharedPreferences 从读取到提交的全过程，突出显示可能导致 ANR 的瓶颈节点。

调用 getSharedPreferences() 全量读取 XML 文件
（主线程 IO，⚠️ ANR 风险）内存中构建 Map
（全量缓存）修改键值
（仅改内存 Map） commit() 同步写盘
（主线程阻塞，⚠️ ANR 风险） apply() 异步写盘
（旧值先提交，新值排队） edit() commit apply 👉 关键风险路径说明 • 红色节点：发生在主线程的阻塞 IO 操作，是 ANR 的主要来源。 • 蓝色节点：全量读取后，整个文件内容常驻内存，占用 App 堆空间。 • 绿色节点：apply() 虽然异步，但旧值写入与新值写入存在时序竞争，极端情况下仍可能丢失数据。 • 橙色节点：edit() 操作仅修改内存 Map，大量 edit() 后不 commit/apply 会造成内存泄漏。 • 深色虚线：表示修改后可以选择 commit 或 apply，两条路径的 ANR 风险截然不同。

3. 类比：慢速文件柜与快照复印

想象你有一个专门存放 个人设置 的纸质文件柜（相当于 XML 文件）：

每次你打开柜门（调用 getSharedPreferences()），必须把 整个柜子里的所有文件复印一份 拿到办公桌（全量读入内存）。
你只需要修改其中一张纸上的一个字（如改变主题颜色），却被迫复印整柜文件。
如果复印过程在 前台会议（主线程） 中进行，与会者只能干等——会议延迟（UI 卡顿）甚至直接散会（ANR）。
commit() 相当于复印完修改后，立刻把整柜文件 重新打印一份 放回去，并且必须在会议结束前完成（同步阻塞）。

这种设计在文件柜只有几页纸时还能接受，但当柜子变成几十页、几百页时，每次操作都会浪费大量时间和内存。

4. commit vs apply：核心差异对比

特性	commit()	apply()
执行模式	同步写入磁盘，阻塞调用线程	异步写入磁盘，直接返回
ANR 风险	高（主线程直接阻塞，文件越大风险越高）	低（磁盘写入由异步队列处理，不阻塞主线程）
返回值	返回 boolean，表示写入是否成功	无返回值（void）
写入时机	调用后立刻执行磁盘写入	将任务加入 Handler 消息队列，稍后执行；若进程在写入前被杀，数据丢失
内存刷新	立即写入磁盘，其他实例可读到最新值	内存中立即可见，磁盘写入有延迟；另一个进程/实例通过不同 SharedPreferences 实例获取时可能读到旧值
使用场景	需要立即确保数据落盘（如设置页返回键后）	大多数配置修改，不关心何时落盘（推荐默认选择）

💡 实践建议：除非你必须等待写入结果（例如检查是否写入成功），否则始终优先使用 apply()。在 Android 官方文档中，apply() 被标记为更安全的默认选择。

5. 常见误区

误区：SharedPreferences 只适合存小数据，所以性能没问题。
即使单个键值很小，但随着键数增多（如上百个配置项），XML 文件体积增长，全量读取的开销会线性增加。建议将频繁读写的配置限制在 100 个键以内。
误区：把 commit() 放到子线程就安全了。
虽然可以避免主线程阻塞，但 commit() 本身是同步锁写，多个子线程同时调用会导致线程排队阻塞，且对比 apply() 无内存优势。更推荐使用 apply() 或直接替换为 DataStore。
误区：apply() 是异步的，永远不会 ANR。
错误。apply() 在旧版本（API Level 9 之前）存在 Bug，大量高频 apply() 会导致 Handler 队列被填满，最终仍可能阻塞主线程。现代版本虽已优化，但极端场景（每秒数百次 apply）仍可能出现。
误区：SharedPreferences 跨进程安全。
完全错误。SharedPreferences 是进程内存储，不保证跨进程一致性。多进程场景请使用 ContentProvider 或 DataStore（MultiProcess 模式）等方案。

6. 适用场景边界

场景	推荐使用	不推荐（替代方案）
存储用户开关（如是否首次启动、主题色）	✅ SharedPreferences，键值数少于 100	—
存储少量字符串或数字（如用户名、偏好列表）	✅ SharedPreferences，但仅限简单类型	复杂对象需使用 JSON 序列化，此时优先考虑 Room 或 DataStore
高频写入（帧率、日志、统计计数）	❌ 避免	使用内存缓存 + 定时批量写入，或使用 DataStore（基于 Flow，异步写）
存储大型结构化数据（如用户偏好列表、缓存列表）	❌ 避免	Room 数据库，支持查询、索引、异步
跨进程共享配置	❌ 避免	ContentProvider / 文件 / DataStore MultiProcess
需要原子性批量写（多个键同时成功或失败）	❌ 不保证	Room 事务，或 DataStore 的 transaction

7. 练习题（自测）

选择：以下关于 commit() 和 apply() 的说法，哪一项是正确的？
A. commit() 比 apply() 更安全，因为它不会丢失数据。
B. apply() 一定不会导致 ANR。
C. commit() 同步写入，如果放在子线程可以提高性能。
D. apply() 异步写入，但写入结果不可知，适用于无需立即落盘的场景。

判断：SharedPreferences 的全量读取问题可以通过“只调用一次 getSharedPreferences()，后续复用实例”解决。（对/错？）

场景：你需要在 Activity 的 onStop 中保存用户最后一次滑动位置，并确保下次启动时读取到最新值。你会使用 commit() 还是 apply()？为什么？

    参考答案：

    Q1: D（A 错误，apply 可能丢数据；B 错误，极端情况仍可能 ANR；C 错误，子线程 commit 仍会阻塞该线程，且不如 apply 性能优）

    Q2: 错。即使复用实例，实例内部已经缓存了整个 XML，但后续 edit() 后的 commit/apply 仍会全量写入文件，不影响读取性能。但全量读取只发生一次，所以“全量读取”问题只在首次调用时出现。属于“部分正确但不够本质”。

    Q3: 建议使用 commit()。因为 onStop 后进程可能随时被杀，需要保证数据立即落盘，避免丢失。但注意不要在主线程频繁调用，可放到子线程。

8. 总结：SharedPreferences 的黄金法则

读取：在 Application.onCreate() 中预加载一次，后续复用实例；避免在主线程高频读取大文件。
写入：默认用 apply()，仅当需要同步确认时用子线程的 commit()。
容量：保持 XML 文件在 10 KB 以内（约 100～200 个键），超出则考虑 Room 或 DataStore。
替代：新项目直接使用 DataStore（Preferences），它基于 Flow、协程，天然异步，无全量读取问题。