MMKV原理与实战：高性能键值存储组件深度解析

1. 项目概述：为什么我们需要MMKV？

在移动端开发，尤其是Android和iOS平台上，数据持久化是一个绕不开的话题。如果你做过几年开发，肯定对SharedPreferences（Android）和NSUserDefaults（iOS）又爱又恨。爱的是它们简单易用，恨的是它们在性能、稳定性和多进程支持上的种种“坑”。比如，SharedPreferences的commit是同步的，会阻塞UI线程，而apply虽然是异步的，但在某些极端情况下（如进程被杀）可能导致数据丢失，更别提它那糟糕的多进程支持了。当你的应用需要存储一些简单的键值对，比如用户设置、登录状态、缓存标记时，你需要的不是一个重型数据库，而是一个快、稳、小的存储方案。

这就是MMKV诞生的背景。它是由微信团队开源的一个基于内存映射（mmap）的键值对存储组件。我第一次在项目里引入MMKV替换掉老旧的SharedPreferences时，最直观的感受就是“顺滑”——读取几乎无感，写入速度快得惊人，而且再也没遇到过因为存储导致的ANR（应用无响应）。它本质上解决的不是“能不能存”的问题，而是“存得是否高效可靠”的问题。对于中高级开发者来说，理解MMKV的原理，能让你在遇到复杂数据存储场景（如跨进程、大数据量、高并发写入）时，心里更有底。这篇文章，我就结合自己多次集成和封装的经验，把MMKV从里到外讲透，包括它的核心原理、基本使用、进阶技巧，以及如何根据项目需求进行二次封装，让你能真正“驾驭”这个利器，而不是仅仅停留在调API的层面。

2. MMKV核心原理深度拆解

要用好一个工具，必须理解它的工作原理。MMKV的高性能并非魔法，而是建立在几个关键的技术选择之上。

2.1 基石：内存映射（mmap）技术

这是MMKV所有特性的基石。传统文件IO（如Java的FileOutputStream）需要经过“用户缓冲区 -> 内核缓冲区 -> 磁盘”的多次拷贝。而mmap是一种将文件或设备直接映射到进程地址空间的方法。

它是如何工作的？当MMKV初始化时，它会通过系统调用，将一个文件（比如mmkv.default）映射到当前进程的一块虚拟内存区域。之后，你对这块内存的读写操作，操作系统会在背后自动同步到对应的文件上。这带来了几个根本性优势：

1. 极高的读写速度：省去了数据在用户态和内核态之间来回拷贝的开销。读取数据相当于直接读内存，写入数据也相当于写内存，由操作系统负责写回磁盘，效率极高。
2. 数据可靠性：由于映射关系由操作系统内核管理，即使进程意外崩溃，内核也会尽力确保已写入映射区域的数据同步到磁盘（取决于映射模式），这比SharedPreferences的apply机制更可靠。
3. 跨进程共享潜力：多个进程可以将同一个文件映射到各自的地址空间，从而实现内存共享，这是实现高效跨进程通信的基础。

注意：mmap有两种常见模式。MAP_SHARED表示映射区域的修改会写回文件，并允许其他映射了同一文件的进程看到更改，MMKV主要使用此模式。MAP_PRIVATE则创建写时复制（Copy-on-Write）的私有映射，修改不会影响原文件。

2.2 数据结构：Protobuf编码与顺序写入

MMKV没有采用B-Tree或LSM-Tree等复杂结构，它存储的是一系列键值对（Key-Value Pair）。其内部存储可以简化为一个连续的内存块（也是文件内容）。

写入过程： 当你调用mmkv.encodeInt(“key”, 123)时，MMKV并不是在原地修改某个值。它的流程是这样的：

1. 序列化：将键（“key”）和值（123）用Protocol Buffers（Protobuf）格式进行序列化，生成一段二进制数据。Protobuf编码非常紧凑，体积比XML或JSON小很多。
2. 追加写入：将序列化后的这条键值对数据，追加到当前内存映射区域的末尾。
3. 更新索引：在内存中维护一个哈希表（或字典），将键“key”映射到这条数据在内存映射区域中的起始位置（指针）和长度。
4. 标记旧数据：如果键“key”之前已经存在，那么旧数据所在的位置不会被立即擦除，而是被标记为“无效”。整个文件看起来就是一系列新旧数据交替的片段。

读取过程：

1. 当你要读取“key”时，MMKV先在内存的索引哈希表里查找。
2. 找到该键对应的最新数据的指针和长度。
3. 直接从内存映射区域的对应位置，读取二进制数据。
4. 用Protobuf反序列化，得到值123。

这种追加写入和内存索引的设计，使得写入操作几乎总是O(1)的复杂度（只需追加和更新哈希表），读取也是O(1)（哈希表查找）。而标记旧数据产生的“碎片”，则通过下面这个机制来处理。

2.3 空间回收：全量写入与重整

随着不断更新和删除键值对，文件中会积累大量被标记为无效的“碎片”空间。如果放任不管，文件会无限膨胀。MMKV采用了一种简单而有效的策略：空间不足时，触发全量重整。

触发时机：当一次新的写入操作发现剩余空间不足时（或者碎片太多，达到一定阈值），MMKV不会直接扩容，而是先尝试“垃圾回收”。

重整过程：

1. 遍历有效数据：MMKV遍历内存索引，找出所有未被标记为无效的、最新的键值对数据。
2. 写入新文件：将这些有效数据按顺序、紧凑地写入一个临时的新文件（或内存缓冲区）。
3. 原子替换：用这个新的、紧凑的数据文件，原子性地替换掉旧的、充满碎片的文件。在Android/iOS上，这通常通过重命名文件操作来完成，保证在替换瞬间发生崩溃，数据也不会损坏（要么是旧文件，要么是新文件）。
4. 重建内存映射：重新建立对新文件的内存映射，并重建内存索引哈希表。

这个过程类似于数据库的“VACUUM”操作。虽然是一次成本较高的操作，但由于MMKV存储的数据量通常不大（适合存储配置，而非大量业务数据），且发生频率不高，因此总体性能影响很小。这种设计在空间利用率和写入性能之间取得了很好的平衡。

2.4 多进程协同：文件锁与状态同步

MMKV宣称支持多进程访问，这是它比SharedPreferences强大的关键一点。其核心是通过文件锁来实现进程间同步。

基本原理：

1. 写锁（独占锁）：当一个进程需要写入时，它会尝试获取文件的写锁。如果获取成功，其他进程的读写操作都会被阻塞，直到该进程释放锁。这保证了写入的原子性，防止数据混乱。
2. 读锁（共享锁）：多个进程可以同时持有读锁，进行读取操作。但只要有一个进程持有写锁，其他进程就无法获取读锁。
3. 状态同步：仅仅锁住写入还不够。进程A写入后，进程B需要知道文件内容已经变了。MMKV通过比较文件的实际大小或一个CRC校验码来判断。每个进程在读取前，会检查这些元信息是否与上次读取时一致。如果不一致，说明有其他进程修改了数据，当前进程就需要重新加载整个文件（重新mmap并重建索引），以获取最新数据。

一个常见的坑： 假设进程A和B同时启动。A先写入，B后读取。如果B在初始化时加载了旧的数据快照，那么它可能读不到A刚写入的数据。因此，在多进程环境下，比较推荐的做法是，在每次读取关键数据前，主动调用MMKV.mmkvWithID()并指定MMKV.MULTI_PROCESS_MODE来获取实例，这个操作内部会检查并处理可能的更新。或者，使用MMKV提供的进程间通信通知（如Android上的ContentProvider或文件描述符通知），让一个进程的数据变更能主动通知到其他进程。

3. 从零开始：MMKV的集成与基础使用

理解了原理，我们来看看如何把它用起来。这里以Android平台为例，iOS的集成方式类似（主要通过CocoaPods或手动导入）。

3.1 环境集成与初始化

首先，在项目的build.gradle文件中添加依赖：

dependencies { implementation 'com.tencent:mmkv:1.3.4' // 请使用最新版本 }

然后，在Application的onCreate方法中进行初始化。这一步至关重要，必须在所有MMKV实例创建之前完成。

class MyApp : Application() { override fun onCreate() { super.onCreate() val rootDir = MMKV.initialize(this) Log.i("MMKV", "MMKV存储根路径: $rootDir") // 通常路径是 /data/data/your.package.name/files/mmkv/ } }

MMKV.initialize(Context)会设置默认的根目录。你也可以传入一个自定义的绝对路径字符串。

3.2 核心API使用详解

获取MMKV实例是最常见的操作。默认情况下，MMKV会提供一个单例的默认实例，对应一个名为mmkv.default的文件。

// 获取默认实例（单例，对应 mmkv.default 文件） val kv = MMKV.defaultMMKV() // 存储各种类型的数据 kv.encode("bool", true) kv.encode("int", 123) kv.encode("long", 456789L) kv.encode("float", 3.14f) kv.encode("double", 2.71828) kv.encode("string", "Hello MMKV") kv.encode("byteArray", byteArrayOf(1, 2, 3)) // 读取数据，第二个参数是默认值（当key不存在时返回） val b = kv.decodeBool("bool", false) val i = kv.decodeInt("int", 0) val s = kv.decodeString("string", "") // 删除数据 kv.removeValueForKey("key_to_remove") // 或删除多个 kv.removeValuesForKeys(arrayOf("key1", "key2"))

这里有个非常重要的细节：encode和decode系列方法都是强类型的。你不能用decodeString去读一个用encodeInt存储的key，否则会得到类型错误或默认值。MMKV在存储时，会将值的类型信息也一并编码。这就要求我们在设计Key的时候，最好保持其类型不变，或者有清晰的约定。

3.3 多实例与多进程模式

如果你的应用数据需要分类存储，或者需要多进程访问，就需要创建不同的MMKV实例。

// 1. 获取一个指定ID的实例，对应 mmkv.[mmapID] 文件 val separateKV = MMKV.mmkvWithID("myStorage") // 2. 获取一个指定ID且支持多进程的实例 val multiProcessKV = MMKV.mmkvWithID("interProcessData", MMKV.MULTI_PROCESS_MODE) // 3. 获取一个指定ID、支持多进程、且加密的实例 val cryptKey = "My-Encryption-Key".toByteArray() val secureKV = MMKV.mmkvWithID("secureData", MMKV.MULTI_PROCESS_MODE, cryptKey)

关于多进程模式的注意事项：

• MMKV.MULTI_PROCESS_MODE底层使用了文件锁，性能相比单进程模式有损耗，但比SharedPreferences的MODE_MULTI_PROCESS可靠得多。
• 加密功能使用的是AES CFB-128算法。密钥至关重要！如果密钥丢失，数据将无法解密。建议将密钥存储在安全的地方（如Android Keystore）。

3.4 与SharedPreferences的迁移

对于存量项目，MMKV贴心地提供了从SharedPreferences迁移数据的一键功能。这可以在初始化后立即进行。

class MyApp : Application() { override fun onCreate() { super.onCreate() MMKV.initialize(this) // 从默认的SharedPreferences迁移 MMKV.defaultMMKV()?.let { mmkv -> val oldSp = getSharedPreferences(“default_sp_name”, Context.MODE_PRIVATE) mmkv.importFromSharedPreferences(oldSp) oldSp.edit().clear().apply() // 可选：迁移后清空旧数据 Log.i(“MMKV”, “数据迁移完成”) } } }

迁移操作是增量的，且会覆盖MMKV中已有的同名Key。建议在版本升级时执行一次即可。

4. 进阶实践：性能优化与陷阱规避

掌握了基本用法，我们来看看如何用得更好、更稳。以下都是我在实际项目中踩过坑或优化后总结的经验。

4.1 性能关键：避免高频次写入与Value尺寸控制

MMKV的写入很快，但任何持久化操作都有成本。不当的使用模式会成为性能瓶颈。

反面案例：

// 在列表滚动时，频繁更新同一个标记位 fun onScrollStateChanged(newState: Int) { MMKV.defaultMMKV().encode(“last_scroll_state”, newState) // 错误！高频写入 }

优化方案：

1. 合并写入：对于非实时性要求极高的数据，可以积累多次变更，在一次事务中写入。MMKV本身不支持事务，但你可以通过封装来实现，比如先写入内存缓存，定时或特定时机（如页面onPause）再批量持久化。
2. 使用内存缓存：对于极高频读取、低频修改的数据，可以在内存中维护一份副本，直接读取内存，仅在数据变更时更新MMKV。
3. 控制Value大小：MMKV适合存储配置、状态等小数据。切勿将大型对象（如图片Bitmap、长JSON文本）直接序列化后存入。对于大文件，应该存储在文件系统中，而在MMKV里只存其路径或元信息。Protobuf虽然高效，但巨大的Value会导致每次写入和重整（GC）时内存和IO压力剧增。

4.2 多进程数据同步的“延迟”问题

正如原理部分提到的，MMKV的多进程同步依赖于文件锁和文件状态检查，这并非实时通知。进程B可能无法立刻感知进程A的写入。

解决方案：

1. 主动检查：在读取关键数据前，尤其是从后台进程切换到前台时，可以考虑调用mmkv.sync()或重新获取MMKV实例（MMKV.mmkvWithID(...)），强制进行一次同步检查。
2. 结合其他IPC：对于需要强实时同步的场景，可以结合使用其他IPC机制。例如，进程A写入后，通过Broadcast、ContentProvider或AIDL等通知进程B：“数据已变，请重新加载”。进程B收到通知后，再调用MMKV的重新加载逻辑。
3. 设计降级：从架构上思考，是否真的需要强实时？很多场景下，轻微延迟（几百毫秒）是可以接受的。明确业务对一致性的要求级别。

4.3 数据备份与恢复策略

MMKV文件虽然可靠，但存放在应用沙盒内。当用户清除应用数据或卸载重装时，数据会丢失。对于需要备份的配置（如用户个性化设置），需要有自己的备份方案。

常见方案：

1. 备份到云端：将关键的MMKV数据（通过mmkv.allKeys()和decode系列方法获取）在登录后同步到服务器。
2. 备份到外部存储：定期将MMKV文件（位于/data/data/package/files/mmkv/）拷贝到外部存储或应用专属目录。注意Android 11（API 30）以上的分区存储限制。
3. 导出为可读格式：可以提供一个“导出设置”功能，将MMKV中的数据转换为JSON或XML文件，让用户自己保存。

恢复时，逆向操作即可。但要注意版本兼容性，如果数据结构（Key或Value类型）在新版本中已改变，需要编写迁移代码。

4.4 监控与调试技巧

当存储出现异常时，如何排查？

1. 查看文件内容（仅限调试）： MMKV文件是二进制的，无法直接查看。但你可以：

   • 将文件从设备中拉取出来：adb pull /data/data/your.package/files/mmkv/mmkv.default .
   • 使用strings命令查看其中的字符串片段：strings mmkv.default
   • 或者写一个简单的调试工具，遍历所有Key并打印出来。

2. 关注日志： MMKV在初始化失败、文件读写错误、CRC校验失败时会打印错误日志到Logcat。关注MMKV这个Tag。

3. 性能监控： 在encode/decode前后打点，监控耗时。如果发现某个操作特别慢，可能是触发了全量重整（GC）。考虑是否该Value过大，或写入过于频繁。

5. 项目级封装：构建更易用的存储组件

直接使用MMKV的API虽然简单，但在大型项目中，散落的encode/decode调用会带来维护问题：Key的管理混乱、类型不安全、无法统一进行数据迁移或加密等。因此，对其进行二次封装是很有必要的。下面分享一种我在项目中常用的封装模式。

5.1 封装目标与设计

我们的封装要达到以下几个目标：

1. 集中管理Key：避免硬编码字符串散落各处。
2. 类型安全：利用Kotlin的强类型特性，在编译期就杜绝类型错误。
3. 提供默认值：每个Key都对应一个合理的默认值。
4. 支持多实例：方便按模块划分存储空间。
5. 可扩展性：方便未来替换存储实现（比如从MMKV换到其他库）或增加统一功能（如加密、迁移、监听）。

5.2 封装实现代码详解

我们采用“接口 + 委托”的方式，利用Kotlin的ReadWriteProperty属性委托特性。

第一步：定义存储接口

interface IStorage { fun putInt(key: String, value: Int) fun getInt(key: String, default: Int): Int fun putString(key: String, value: String) fun getString(key: String, default: String): String fun putBoolean(key: String, value: Boolean) fun getBoolean(key: String, default: Boolean): Boolean fun putLong(key: String, value: Long) fun getLong(key: String, default: Long): Long fun putFloat(key: String, value: Float) fun getFloat(key: String, default: Float): Float fun putStringSet(key: String, value: Set<String>) fun getStringSet(key: String, default: Set<String>): Set<String> fun remove(key: String) fun contains(key: String): Boolean fun clear() }

第二步：实现基于MMKV的存储类

class MMKVStorage private constructor(private val mmkv: MMKV) : IStorage { companion object { // 获取默认存储 fun default(): MMKVStorage { return MMKVStorage(MMKV.defaultMMKV()) } // 根据ID获取存储 fun withId(id: String, mode: Int = MMKV.SINGLE_PROCESS_MODE, cryptKey: String? = null): MMKVStorage { val kv = if (cryptKey != null) { MMKV.mmkvWithID(id, mode, cryptKey) } else { MMKV.mmkvWithID(id, mode) } return MMKVStorage(kv) } } override fun putInt(key: String, value: Int) = mmkv.encode(key, value) override fun getInt(key: String, default: Int): Int = mmkv.decodeInt(key, default) override fun putString(key: String, value: String) = mmkv.encode(key, value) override fun getString(key: String, default: String): String = mmkv.decodeString(key, default) ?: default // ... 其他类型方法的实现类似，注意decodeString可能返回null override fun putStringSet(key: String, value: Set<String>) = mmkv.encode(key, value) override fun getStringSet(key: String, default: Set<String>): Set<String> = mmkv.decodeStringSet(key, default) ?: default override fun remove(key: String) = mmkv.removeValueForKey(key) override fun contains(key: String): Boolean = mmkv.containsKey(key) override fun clear() = mmkv.clearAll() }

第三步：定义属性委托类这是实现类型安全和集中管理Key的核心。

class PreferenceDelegate<T>( private val storage: IStorage, private val key: String, private val defaultValue: T, private val save: IStorage.(String, T) -> Unit, private val read: IStorage.(String, T) -> T ) : ReadWriteProperty<Any?, T> { override fun getValue(thisRef: Any?, property: KProperty<*>): T { return storage.read(key, defaultValue) } override fun setValue(thisRef: Any?, property: KProperty<*>, value: T) { storage.save(key, value) } }

第四步：集中定义所有配置项（Key）

object AppSettings { // 获取存储实例（这里用默认的，也可以按模块分） private val storage: IStorage by lazy { MMKVStorage.default() } // 使用委托属性定义每一个配置项 var isFirstLaunch by PreferenceDelegate( storage, “is_first_launch”, true, save = { k, v -> putBoolean(k, v) }, read = { k, d -> getBoolean(k, d) } ) var userId by PreferenceDelegate( storage, “user_id”, “”, save = { k, v -> putString(k, v) }, read = { k, d -> getString(k, d) } ) var notificationEnabled by PreferenceDelegate( storage, “notification_enabled”, true, save = { k, v -> putBoolean(k, v) }, read = { k, d -> getBoolean(k, d) } ) var lastLoginTime by PreferenceDelegate( storage, “last_login_time”, 0L, save = { k, v -> putLong(k, v) }, read = { k, d -> getLong(k, d) } ) // 对于复杂对象，可以序列化为JSON字符串存储 var userProfileJson by PreferenceDelegate( storage, “user_profile”, “”, save = { k, v -> putString(k, v) }, read = { k, d -> getString(k, d) } ) // 然后提供扩展属性来方便地访问 val userProfile: UserProfile? get() = try { Gson().fromJson(userProfileJson, UserProfile::class.java) } catch (e: Exception) { null } fun saveUserProfile(profile: UserProfile) { userProfileJson = Gson().toJson(profile) } }

5.3 封装后的使用方式与优势

使用方式变得极其简洁和安全：

// 读取 val isFirst = AppSettings.isFirstLaunch val userId = AppSettings.userId // 写入 AppSettings.isFirstLaunch = false AppSettings.userId = “12345” AppSettings.saveUserProfile(UserProfile(“Tom”)) // 删除某个设置（如果需要） // 封装类可以增加一个删除特定key的方法

这种封装带来的好处：

1. 强类型：AppSettings.userId是String类型，不可能误赋值为Int。
2. Key集中管理：所有Key都在AppSettings对象中定义，查找、修改、重构都非常方便。
3. 默认值清晰：每个属性都明确了默认值。
4. 使用简单：像访问普通属性一样读写持久化数据。
5. 易于测试和替换：IStorage接口使得我们可以很容易地创建内存实现的MockStorage用于单元测试，或者未来更换底层存储库。

扩展思考： 你可以进一步扩展这个封装，例如：

• 增加数据变更监听：在PreferenceDelegate的setValue中通知观察者。
• 支持迁移：在AppSettings的init块中，编写从旧版存储（如SharedPreferences）迁移到新版MMKV的逻辑。
• 按模块划分：创建UserSettings、AppConfigSettings等不同对象，分别对应不同的MMKV实例ID，实现数据隔离。

6. 常见问题排查与实战技巧

即使理解了原理和封装，在实际开发中还是会遇到一些具体问题。这里我整理了一个排查清单和几个实战技巧。

6.1 问题排查速查表

6.2 实战技巧：监听数据变化

MMKV本身不提供数据变化监听回调，但我们可以利用Kotlin的Delegates.observable或自定义委托来实现一个简易的监听。

class ObservablePreferenceDelegate<T>( private val storage: IStorage, private val key: String, private val defaultValue: T, private val save: IStorage.(String, T) -> Unit, private val read: IStorage.(String, T) -> T, private val onChange: ((old: T, new: T) -> Unit)? = null ) : ReadWriteProperty<Any?, T> { private var currentValue: T = storage.read(key, defaultValue) override fun getValue(thisRef: Any?, property: KProperty<*>): T { return currentValue } override fun setValue(thisRef: Any?, property: KProperty<*>, value: T) { val oldValue = currentValue if (oldValue != value) { storage.save(key, value) currentValue = value onChange?.invoke(oldValue, value) } } } // 使用示例 object ObservableSettings { private val storage = MMKVStorage.default() var darkMode by ObservablePreferenceDelegate( storage, “dark_mode”, false, save = { k, v -> putBoolean(k, v) }, read = { k, d -> getBoolean(k, d) }, onChange = { old, new -> // 当主题模式改变时，通知UI更新 EventBus.post(DarkModeChangedEvent(new)) // 或者使用LiveData/Flow } ) }

6.3 实战技巧：数据加密与安全增强

MMKV提供了基础的AES加密，但密钥需要你自己管理。对于安全要求更高的场景（如存储登录Token），可以结合Android Keystore系统来管理加密密钥，避免密钥硬编码在代码中。

fun createSecureMMKV(context: Context, mmapID: String): MMKV { val alias = “mmkv_key_alias” val keyStore = KeyStore.getInstance(“AndroidKeyStore”) keyStore.load(null) // 尝试获取已有的密钥 val secretKeyEntry = keyStore.getEntry(alias, null) as? KeyStore.SecretKeyEntry val secretKey = secretKeyEntry?.secretKey if (secretKey == null) { // 生成新的密钥 val keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, “AndroidKeyStore”) val keyGenSpec = KeyGenParameterSpec.Builder( alias, KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT ) .setBlockModes(KeyProperties.BLOCK_MODE_GCM) // 使用GCM模式，更安全 .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE) .setKeySize(256) .build() keyGenerator.init(keyGenSpec) secretKey = keyGenerator.generateKey() } // 将密钥转换为字节数组（注意：此操作在Android P以上可能受限） // 更安全的方式是使用KeyStore的Cipher进行wrap/unwrap，这里简化为直接获取 val keyBytes = secretKey.encoded ?: throw IllegalStateException(“Failed to get key bytes”) // 使用密钥创建加密的MMKV实例 return MMKV.mmkvWithID(mmapID, MMKV.SINGLE_PROCESS_MODE, keyBytes) }

重要提示：密钥管理是安全的核心。上述示例是一种思路，实际生产环境中，尤其是在Android P（API 28）及以上版本，直接获取SecretKey.encoded可能返回null或受限。更安全的做法是利用KeyStore的Cipher进行加密解密操作，或者使用AndroidKeyStore的KeyStore类来保护密钥本身。建议仔细阅读Android官方关于AndroidKeyStore的文档，并根据目标API级别设计密钥管理方案。

6.4 性能压测建议

如果你担心MMKV在极端情况下的性能，可以设计简单的压测。例如，连续写入/读取1万次小数据，对比SharedPreferences的apply和commit。在我的测试中，MMKV的写入速度通常是SharedPreferences.commit的数十倍甚至上百倍，与apply相比也显著更快，且稳定性更高。读取速度更是内存级别的。这个测试可以让你对性能有更直观的信心。

最后，我个人在多个项目中用MMKV替换SharedPreferences后，最深的体会是：它把一件本该简单可靠的事情，真的做到了简单可靠。你不再需要担心ANR，担心多进程数据错乱，担心偶发的数据丢失。它就像一把锋利而趁手的瑞士军刀，对于移动端的轻量存储需求，几乎是目前最优解。当然，没有银弹，它不适合存储大量结构化数据或频繁更新的日志流，那是SQLite或专业时序数据库的领域。理解它的边界，在正确的场景使用它，才能最大化其价值。