4. MMKV 高性能方案：mmap 原理、多进程支持、性能对比、适用场景与限制

当应用需要频繁读写小数据（如用户设置、开关状态、缓存标记），传统的 SharedPreferences 可能会成为性能瓶颈——主线程写入可能触发磁盘 I/O 导致掉帧，序列化全量更新效率低下，且多进程场景下数据同步困难。MMKV（基于 mmap 的内存键值存储）正是为解决这些问题而被广泛采用的方案。理解其核心原理，才能判断何时应该使用、何时应该回避。

4.1 核心概念：什么是 mmap？

mmap（Memory-Mapped File，内存映射文件）是一种操作系统提供的文件访问机制。它将一个磁盘文件直接映射到进程的虚拟地址空间，使得对文件内容的访问如同访问普通内存一样。

4.2 MMKV 工作原理

MMKV 充分利用 mmap 的特性，构造了一个高性能的 KV 存储引擎：

1. 内存映射：应用启动时，MMKV 将数据文件通过 mmap 映射到虚拟内存。后续所有读写操作直接对这块内存进行，不再经过 Java Heap。
2. 增量写入：不同于 SP 的全量序列化写入，MMKV 只将变化的数据追加到 mmap 内存的末尾，避免全表拷贝。
3. 内存对齐 & CRC 校验：数据以紧凑的二进制格式存储，并附带 CRC 校验，确保 crash 后数据完整性。
4. 懒写回机制：mmap 写入操作实际修改的是操作系统页缓存，内核会在适当时机将脏页写回磁盘，或由开发者调用 mmap.sync() 显式控制。

4.3 类比：厨房备料与直接用餐

假设你在厨房（应用进程）需要频繁使用盐（小数据）：

• SharedPreferences 模式： 你需要每次都走到储藏室（磁盘文件），打开罐子，倒出一点，再放回去（两次拷贝）。如果有很多人（多线程/多进程）同时取盐，很容易混乱甚至打翻罐子。
• MMKV 模式： 你把一整盒盐直接放在料理台上（mmap 映射），伸手就能拿到，用完直接放回。如果盐用完了，内核会帮你去储藏室补货（写回磁盘），但你感知不到这个运输过程。

4.4 性能对比：MMKV vs. SharedPreferences

4.5 多进程支持原理

MMKV 的多进程能力源于 mmap 的本质：

• 共享同一文件映射： 进程 A 和进程 B 各自调用 mmap 映射同一磁盘文件，操作系统会让他们共享同一组物理内存页。进程 A 写入的数据，进程 B 可以几乎实时看见。
• 跨进程锁： MMKV 内部使用文件锁（flock）保证写操作的互斥，防止数据错乱。
• 进程级崩溃防护： 即使其中一个进程 crash，页缓存中的脏数据可能未落盘，但 MMKV 内部维护了写入序列号和 CRC 校验，重启后可以回滚或恢复最近的完整帧。

4.6 常见误区

• 误区二：“多进程模式下，使用同一个 mmapID 就可以了，不需要任何额外配置。” 实际需要确保两个进程使用相同的 mmap 文件路径，并且在初始化时都设置 MMKV.MULTI_PROCESS_MODE 标志。
• 误区三：“MMKV 比 SQLite 快，所以所有持久化场景都该用 MMKV。” MMKV 只适合 KV 小数据，不适合复杂查询、关系关联、结构化大数据。
• 误区四：“使用 mmap 就可以随意写入大量数据，不会有性能问题。” mmap 映射文件若过大（超过可用物理内存），会触发大量缺页中断，性能反而劣化。

4.7 练习题

1. 原理解释： 简述 mmap 对比传统 read/write 在数据拷贝次数上的差异，为什么这个差异对写入性能影响巨大？
2. 代码分析： 假设两个进程都使用同一个 mmapID 打开 MMKV，但进程 A 没有设置 MMKV.MULTI_PROCESS_MODE。此时进程 B 写入一个值，进程 A 能否立即读到？可能引发什么问题？
3. 场景决策： 你的 App 有一个“国家列表”配置（约 200 个键值对，每次启动读取一次，几乎不修改），以及一个“用户实时操作日志”（频繁写入，总量不超过 50 KB）。哪些数据适合用 MMKV？哪些更适合使用其他方式？
4. 性能估算： 按本章性能对比表中的数据，每周大约有 5000 次配置写入操作。如果使用 SharedPreferences（apply 模式，每次 50 μs）替换为 MMKV（每次 5 μs），每周可节省大约多少 ms 的写入耗时？

4.8 应用边界与限制