简介
MMKV作为微信开源的高性能键值存储框架，通过内存映射和增量更新技术，彻底解决了SharedPreferences全量更新导致的ANR问题。本文将深入剖析SP的ANR根源，详细解析MMKV的技术原理，并提供从零开始的完整集成指南和代码实战。通过性能对比和实际案例，您将看到MMKV如何实现零ANR、微秒级响应的存储方案。
一、SP的ANR问题：技术剖析与实战案例
1.1 SP的ANR根源：同步提交与全量更新
SharedPreferences的ANR问题主要来源于三个致命缺陷。首先是commit的同步提交机制，直接阻塞主线程等待磁盘写入完成。在SP的commit源码中，我们看到：
public boolean commit() {
MemoryCommitResult mcr = commitToMemory();
enqueueDiskWrite(mcr, null);
try {
mcr.writtenToDiskLatch.await(); // 阻塞主线程直到写入完成
} catch (InterruptedException e) {
return false;
}
notifyListeners(mcr);
return mcr.writeToDiskResult;
}
当数据量较大时，这个await()调用会导致主线程长时间阻塞，进而触发ANR。其次是apply的异步陷阱，虽然表面上是异步操作，但在Activity生命周期关键节点（如onStop）会强制等待所有写入完成：
public void apply() {
final MemoryCommitResult mcr = commitToMemory();
final Runnable awaitCommit = new Runnable() {
@Override
public void run() {
mcr.writtenToDiskLatch.await(); // 异步等待
}
};
QueuedWork.addFinisher(awaitCommit); // 添加到队列
enqueueDiskWrite(mcr, postWriteRunnable);
}
最后是全量更新模式，SP每次修改数据时，会将所有键值重新序列化为XML并全量写入文件，导致IO频繁且耗时。
1.2 SP的内存缓存与加载阻塞
SP的缓存机制也存在严重问题。在ContextImpl类中存在一个静态的ArrayMap对象用于缓存不同packageName下的所有sp文件对象：
private static ArrayMap<String, ArrayMap 文件, > sSharedPrefsCache;
这个缓存数组在初始化和赋值，但从未对数组对象里的数据进行移除或释放操作。更严重的是，当首次加载SP时，SP的构造函数会启动一个子线程去加载磁盘文件：
private void startLoadFromDisk() {
synchronized (mLock) {
mLoaded = false;
}
new Thread("SharedPreferencesImpl-load") {
public void run() {
loadFromDisk();
}
}.start();
}
而如果主线程紧接着调用getValue，会通过awaitLoadedLocked方法阻塞主线程：
private void awaitLoadedLocked() {
if (!mLoaded) {
BlockGuard.getThreadPolicy().onReadFromDisk();
}
while (!mLoaded) {
try {
mLock.wait(); // 阻塞主线程直到加载完成
} catch (InterruptedException unused) {
}
}
if (mThrowable != null) {
throw new IllegalStateException(mThrowable);
}
}
当SP文件较大或加载线程调度延迟时，主线程会陷入长时间等待，直接导致ANR。这在实际应用中非常常见，尤其是在应用启动时加载大量配置数据的场景。
1.3 实际案例：SP导致的ANR
在微信的日常运营中，曾多次因SP问题导致应用闪退和ANR。例如，在会话列表和会话界面等有大量cell的地方，需要频繁记录用户操作计数器，但SP的全量更新机制导致每次修改都会重写整个XML文件，造成滑动卡顿和ANR。更严重的是，SP在多进程环境下支持差，容易出现数据错乱和丢失。
闲鱼团队也遇到过类似问题，他们发现ANR日志中存在主线程等待sp apply队列持久化完成、主线程对sp commit以及主线程阻塞等待sp加载数据完成的情况。其中有一个消息执行耗时155ms，挂钟耗时411ms，导致ANR。问题根源是在主线程调用较重的初始化操作，并且存在跨进程调用，阻塞了后面Receiver、Service等消息的调度执行。
二、MMKV的技术原理：内存映射与增量更新
2.1 内存映射(mmap)技术
MMKV的核心技术是内存映射(mmap)。与SP的两次数据拷贝不同，MMKV通过mmap将文件直接映射到内存，APP直接操作内存，由系统自动同步到文件，仅需一次数据拷贝。
// MMKV.cpp中mmap的实现
m_ptr = (char*) mmap(nullptr, m_size, PROT_READ | PROT_WRITE, MAP_SHARED, m_fd, 0);
mmap的优势包括：
减少数据拷贝：传统IO需要从磁盘到内核缓冲区再到用户空间，而mmap直接映射到用户空间。
提高访问速度：进程可以直接像访问内存一样操作映射区域，避免频繁的系统调用。
支持多进程共享：通过MAP_SHARED标志，多个进程可以共享同一个映射区域，实现高效的数据共享。
2.2 Protobuf序列化：更小更快的二进制格式
MMKV采用Protobuf作为底层序列化协议，相比SP的XML格式，Protobuf具有显著优势：
| 维度 | XML | Protobuf |
|---|---|---|
| 序列化速度 | 100ms/万次 | 20ms/万次 |
| 反序列化速度 | 120ms/万次 | 25ms/万次 |
| 数据体积 | 100KB | 55KB |
Protobuf的Varints可变长编码是其高效的关键。每个字节的最高位(MSB)表示是否还有后续字节，其余7位存储实际数据：
// Varints编码示例
// 编码318242
0x a2 0x b6 0x 93 0x 00
这种编码方式使得小数值只占1字节，大数值自动扩展字节数，空间利用率极高。例如，存储{“name”:“张三”,“age”:18}，SP的XML约50字节，而MMKV的Protobuf仅约20字节。
2.3 增量更新机制与文件锁
MMKV的增量更新机制是其性能提升的核心。每次修改数据时，MMKV不会重写整个文件，而是将新数据追加到文件末尾，并标记旧数据为无效：
// 增量更新流程
查找旧数据 -> 删除旧数据 -> 编码新数据 -> 追加到文件末尾
当文件空间不足时，MMKV会触发数据重整，将有效数据重新整理并释放空间：
// 数据重整策略
当文件剩余空间不足时 -> 自动剔除重复Key -> 按顺序重新写入 -> 释放旧空间
MMKV通过文件锁(flock)实现多进程数据同步，比SP的ContentProvider方案快10倍以上：
读锁（共享锁）：多个进程可同时读取，如多个页面同时读取用户配置。
写锁（排他锁）：仅允许一个进程写入，避免数据冲突。
可重入设计：通过计数器记录锁的持有次数，避免递归加锁导致死锁。
三、MMKV的集成与使用：从零开始的实战指南
3.1 依赖添加与初始化
首先，添加MMKV依赖。根据最新版本，推荐使用：
// build.gradle中添加依赖
dependencies {
implementation 'com.tencent:mmkv-static:2.0.0' // Android最新稳定版
}
在应用启动时初始化MMKV：
// Application类中初始化
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
String rootDir = MMKV.initialize(this); // 初始化MMKV
Log.d("MMKV", "MMKV root: " + rootDir); // 输出根目录路径
}
}
3.2 基本读写操作
MMKV提供了简单易用的API，与SP类似但性能更优：
// 获取默认全局实例
MMKV kv = MMKV.defaultMMKV();
// 写入数据
kv.encode("bool_key", true); // 布尔类型
kv.encode("int_key", 100); // 整数类型
kv.encode("string_key", "Hello MMKV"); // 字符串类型
// 读取数据
boolean boolValue = kv.decodeBool("bool_key", false); // 布尔类型，默认false
int intValue = kv.decodeInt("int_key", 0); // 整数类型，默认0
String string = kv.decodeString("string_key", "默认值"); // 字符串类型，默认"默认值"
// 删除数据
kv.removeValueForKey("bool_key"); // 删除单个Key
kv.removeValuesForKeys(new String[]{
"int_key", "string_key"}); // 删除多个Key
kv.clearAll(); // 清空所有数据
MMKV的所有变更立马生效，无需调用commit或apply，这是与SP最大的不同之处。
3.3 多进程模式配置
MMKV支持多进程访问，只需在创建实例时指定模式：
// 创建支持多进程的MMKV实例
MMKV multiProcessKV = MMKV.mmkvWithID("inter_processKV", MMKV.MULTI_PROCESS_MODE);
// 在鸿蒙系统中
let multiProcessKV = MMKV.getBackedUpMMKVWithID('inter_processKV', MMKV.MULTI_PROCESS_MODE, 'Tencent MMKV', backupRootDir);
MMKV的多进程模式通过文件锁实现高效数据同步，避免了SP的ContentProvider方案带来的性能瓶颈。
3.4 数据加密功能
MMKV支持AES加密，保护敏感数据：
// 创建加密MMKV实例（16位密钥）
MMKV encryptedKV = MMKV.mmkvWithID("secure_data", 0, "1234567890123456");
// 鸿蒙系统中
let encryptedKV = MMKV.getBackedUpMMKVWithID('secure_data', MMKV.MULTI_PROCESS_MODE, 'Tencent MMKV', backupRootDir, '1234567890123456');
MMKV使用AES CFB-128算法，相比常见的CBC算法更适合MMKV的append-only写入模式。加密功能在iOS和Android上都已实现。
3.5 数据迁移：SP转MMKV
MMKV提供了一键迁移SP数据的功能：
// 从SP迁移数据到MMKV
SharedPreferences oldSp = getSharedPreferences("old_data", Context.MODE_PRIVATE);
MMKV newMMKV = MMKV.mmkvWithID("new_data");
newMMKV.importFromSharedPreferences(oldSp); // 一键迁移
oldSp.edit().clear().apply(); // 清理旧数据
// 鸿蒙系统中
let oldSp = this.context.getApplicationContext().getSharedPreferences('old_data', Context.MODE_PRIVATE);
let newMMKV = MMKV.defaultMMKV();
newMMKV进口FromSharedPreferences(oldSp); // 一键迁移
oldSp.edit().clear().apply(); // 清理旧数据
迁移后的数据保留原有key命名规范，无需修改业务逻辑。
四、性能优化与最佳实践：实战经验分享
4.1 性能对比与优势
MMKV在性能上远超SharedPreferences：
| 操作 | MMKV (ms) | SP (ms) | SQLite (ms) |
|---|---|---|---|
| 写入1000次int | 12 | 119 | 101 |
| 读取1000次int | 3 | 3 | 136 |
| 写入1000次String | 7 | 187 | 29 |
| 读取1000次String | 4 | 2 | 93 |
MMKV的写入性能是SP的10倍以上，读取性能接近SP。在微信的实际应用中，通过MMKV替换SP后，ANR率从18%降至0.3%，支付多进程数据同步成功率从63%提升至99.99%。
4.2 最佳实践与代码示例
根据微信和闲鱼等大厂的实践经验，以下是MMKV的最佳使用方式：
// 全局实例复用（推荐）
// 在Application中初始化全局实例
public class GlobalApplication extends Application {
private static MMKV sDefaultMMKV;
@Override
public void onCreate() {
super.onCreate();
MMKV.initialize(this);
sDefaultMMKV = MMKV.defaultMMKV();
}
// 提供全局访问方法
public static MMKV 默认MMKV() {
return sDefaultMMKV;
}
}
// 在业务代码中直接使用全局实例
public class SettingFragment extends Fragment {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
MMKV kv = GlobalApplication.defaultMMKV();
boolean夜间模式 = kv.decodeBool("night_mode", false);
// ...
}
}
对于多进程场景，需要特别注意：
// 多进程模式配置
// 在需要多进程共享数据的场景，创建多进程模式的MMKV实例
MMKV multiProcessKV = MMKV.mmkvWithID("multi_process_data", MMKV.MULTI的过程);
4.3 鸿蒙平台上的MMKV使用
MMKV已正式支持HarmonyOS NEXT版本，集成方式略有不同：
// 在鸿蒙EntryAbility中初始化
export default class EntryAbility extends UIAbility {
onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
let appCtx = this.context.getApplicationContext();
let mmkvRootDir = MMKV.initialize(appCtx); // 初始化MMKV
console.info('mmkv rootDir: ', mmkvRootDir); // 输出根目录路径
// ...
}
}
// 数据读写操作
import { MMKV } from '@tencent/mmkv';
// 写入数据
let mmkv = MMKV.defaultMMKV();
mmkv.encodeBool('bool', true);
mmkv.encodeInt32('int32', Math.pow(2, 31) - 1);
mmkv.encodeString('string', 'Hello OpenHarmony from MMKV');
// 读取数据
console.info('bool = ', mmkv.decodeBool('bool'));
console.info('max int32 = ', mmkv.decodeInt32('int32'));
console.info('string = ', mmkv.decodeString('string'));
在鸿蒙平台上，MMKV的性能表现同样优秀，特别适合替代系统轻量级存储（Preferences）。
4.4 注意事项与常见问题
使用MMKV时需要注意以下几点：
// 内存泄漏防范
// MMKV采用LRU缓存淘汰机制，对未使用的MMKV实例自动释放内存映射
// 但为了保险起见，在不需要使用MMKV时，可以主动关闭
mmkv.close(); // 关闭MMKV实例
// 加密密钥管理
// 加密密钥必须安全存储，建议使用Android KeyStore或鸿蒙的密钥管理服务
// 避免将密钥硬编码在代码中
String cryptKey = "从安全存储获取的密钥"; // 不推荐硬编码
MMKV encryptedKV = MMKV.mmkvWithID("secure_data", 0, cryptKey);
// 文件大小限制
// MMKV采用4KB内存页动态扩展策略，当文件大小超过一定阈值时会自动扩容
// 对于超大文件存储，建议使用SQLite或其他文件存储方案
常见问题及解决方案：
数据丢失风险：MMKV通过写时复制(Copy-on-Write)机制和CRC校验+自动回滚机制，最大限度降低数据丢失风险。
内存占用过高：可以通过定期清理不使用的MMKV实例或使用LRU缓存策略来控制内存占用。
频繁删除导致碎片化：MMKV会定期触发数据重整，将有效数据重新整理并释放空间，减少碎片化。
五、企业级应用案例：MMKV在大型应用中的实战
5.1 微信的MMKV应用案例
微信是MMKV最早的应用场景。微信团队最初开发MMKV是为了处理显示异常的技术方案，需要一个大量写入的埋点功能。由于SP的性能瓶颈无法满足需求，微信团队开发了MMKV。
在微信的会话列表和会话界面等有大量cell的场景，MMKV的高效存储机制避免了SP全量更新导致的IO阻塞，极大提升了滑动性能。微信支付场景中，MMKV的多进程数据同步机制确保了不同进程间的数据一致性，将支付成功率从SP时代的63%提升至99.99%。
5.2 闲鱼的ANR治理案例
闲鱼团队在ANR治理中发现，SP是ANR的主要来源之一。他们通过监控主线程消息队列，发现了一个耗时155ms的消息执行，导致ANR。问题根源是在主线程调用较重的初始化操作，并且存在跨进程调用。
闲鱼团队通过MMKV替代SP，解决了这一问题。MMKV的异步无锁设计和增量更新机制，避免了主线程阻塞和全量更新导致的性能瓶颈。实施后，闲鱼的ANR率显著降低，用户体验得到提升。
5.3 鸿蒙应用中的MMKV使用
随着鸿蒙系统的快速发展，MMKV也适配了这一平台。在鸿蒙应用中，MMKV可以替代系统轻量级存储（Preferences），提供更高效的数据存储方案。
例如，在一个鸿蒙音乐应用中，使用MMKV存储用户播放历史和偏好设置，相比使用系统Preferences，性能提升显著，特别是在多设备协同场景下，MMKV的跨平台特性带来了极大便利。
六、总结与展望：MMKV的未来与应用前景
6.1 MMKV的核心价值与优势
MMKV通过mmap内存映射和Protobuf序列化两大技术，从根本上解决了SP的性能瓶颈。其核心优势包括：
高性能：写入性能是SP的10倍以上，读取性能接近SP。
多平台支持：支持Android、iOS、macOS、Windows和HarmonyOS NEXT等平台，提供统一API。
稳定性强：使用mmap内存映射和Protobuf序列化，减少数据丢失风险。
易用性：提供与SP类似的API，无需复杂配置即可使用。
MMKV就像”存储界的高铁”，用更高效的方式帮你运输和管理数据，告别SP带来的”堵车”（ANR）烦恼。
6.2 适用场景与局限性
MMKV适用于以下场景：
频繁读写场景，如用户配置、计数器、缓存。
多进程数据共享，如主进程与后台服务通信。
敏感数据存储，配合AES加密使用。
但MMKV也有其局限性：
不适合超大文件存储，建议使用SQLite或其他文件存储方案。
不支持复杂数据结构，更适合简单的Key-Value模式。
6.3 未来发展趋势与优化方向
随着移动应用的不断发展，MMKV也在持续优化。未来发展趋势包括：
跨平台能力增强：MMKV将更好地支持HarmonyOS、Flutter和React Native等平台，提供更统一的API。
性能进一步提升：优化内存管理和数据编码机制，提高在低端设备上的性能表现。
安全性增强：改进加密算法和密钥管理机制，提供更安全的数据存储方案。
功能扩展：增加更多高级功能，如数据版本控制、增量备份等。
对于追求性能的APP（如即时通信、游戏、高频操作工具），MMKV是替代SP的绝佳选择。通过本文的详细解析和实战指南，相信您已经掌握了MMKV的核心技术和使用方法，可以将其应用到自己的项目中，解决SP带来的ANR问题，提升应用性能和用户体验。
附录：MMKV常见问题解答
Q1：MMKV如何解决SP的ANR问题？
MMKV通过以下三大技术要点解决SP的ANR问题：
异步无锁设计：通过mmap实现内存直接写入，无需等待磁盘同步。
队列优化：取消QueuedWork机制，写入任务直接提交到独立线程池。
无加载阻塞：初始化时直接映射文件，避免SP的异步加载死锁。
Q2：MMKV的mmap会不会导致内存泄漏？
MMKV采用以下防御策略避免内存泄漏：
LRU缓存淘汰：对未使用的MMKV实例自动释放内存映射。
弱引用监控：通过WeakReference关联Context，避免Activity泄漏。
定期清理：在内存不足时，MMKV会触发trim操作，释放未使用的内存。
Q3：Protobuf相比XML有哪些优势？
Protobuf相比XML具有以下优势：
数据紧凑：二进制编码直接存储数据形式，无冗余标签。
快速解析：二进制数据可直接按字节偏移读取，无需解析语法结构。
类型安全：通过预定义的数据结构避免解析错误。
序列化速度：Protobuf序列化速度是XML的5倍以上，反序列化速度是XML的4倍以上。
数据体积：Protobuf数据体积比XML小30%-50%。
Q4：MMKV在鸿蒙系统上的性能如何？
在鸿蒙系统上，MMKV的性能表现同样优秀。根据测试数据，MMKV在HarmonyOS NEXT上的写入性能是系统轻量级存储（Preferences）的10倍以上，读取性能接近系统存储方案。MMKV的跨平台特性使其在鸿蒙应用开发中成为替代系统存储方案的理想选择。
Q5：MMKV如何保证多进程数据一致性？
MMKV通过以下机制保证多进程数据一致性：
文件锁(flock)：基于Linux系统级flock()锁，保证跨进程读写时的原子性。
Ashmem匿名内存：跨进程传输数据时，通过Android提供的Ashmem传递内存地址，避免敏感数据落地。
变更广播：内置ContentProvider实现跨进程变更通知，自动触发其他进程的缓存刷新。
代码示例：MMKV与SP的性能对比测试
6.6.1 Android平台测试代码
// 测试类
public class MMKVSPPerfTest {
private static final int TEST_COUNT = 1000;
private static final String TEST_KEY = "perf_test_key";
private static final String TEST_VALUE = "perf_test_value";
// 测试SP性能
public static void testSharedPreferences(Context context) {
SharedPreferences sp = context.getSharedPreferences("perf_test", Context.MODE_PRIVATE);
Editor editor = sp.edit();
// 写入测试
long startTime = System.currentTimeMillis();
for (int i = 0; i < TEST_COUNT; i++) {
editor.clear(); // 清空旧数据
editor.putString TEST_KEY, TEST_VALUE); // 写入新数据
editor.apply(); // 异步提交
}
long endTime = System.currentTimeMillis();
Log.d("PerfTest", "SP write time: " + (endTime - startTime) + "ms");
// 读取测试
startTime = System.currentTimeMillis();
for (int i = 0; i < TEST_COUNT; i++) {
sp.getString TEST_KEY, null); // 读取数据
}
endTime = System.currentTimeMillis();
Log.d("PerfTest", "SP read time: " + (endTime - startTime) + "ms");
}
// 测试MMKV性能
public static void testMMKV(Context context) {
MMKV kv = MMKV.defaultMMKV();
// 写入测试
long startTime = System.currentTimeMillis();
for (int i = 0; i < TEST_COUNT; i++) {
kv.removeValueForKey TEST_KEY); // 清空旧数据
kv.encode TEST_KEY, TEST_VALUE); // 写入新数据
}
long endTime = System.currentTimeMillis();
Log.d("PerfTest", "MMKV write time: " + (endTime - startTime) + "ms");
// 读取测试
startTime = System.currentTimeMillis();
for (int i = 0; i < TEST_COUNT; i++) {
kv.decodeString TEST_KEY, null); // 读取数据
}
endTime = System.currentTimeMillis();
Log.d("PerfTest", "MMKV read time: " + (endTime - startTime) + "ms");
}
}
6.6.2 鸿蒙平台测试代码
// 测试类
import { MMKV } from '@tencent/mmkv';
export default class MMKVSPPerfTest {
private static readonly TEST_COUNT = 1000;
private static readonly TEST_KEY = 'perf_test_key';
private static readonly TEST_VALUE = 'perf_test_value';
// 测试SP性能
static testSharedPreferences(context: Context) {
let sp = context.getApplicationContext().getSharedPreferences('perf_test', Context.MODE_PRIVATE);
let editor = sp.edit();
// 写入测试
let startTime = new Date().getTime();
for (let i = 0; i < TEST_COUNT; i++) {
editor.clear(); // 清空旧数据
editor.putString TEST_KEY, TEST_VALUE); // 写入新数据
editor.apply(); // 异步提交
}
let endTime = new Date().getTime();
console.info(`SP write time: ${endTime - startTime}ms`); // 输出SP写入时间
// 读取测试
startTime = new Date().getTime();
for (let i = 0; i < TEST_COUNT; i++) {
sp.getString TEST_KEY, null); // 读取数据
}
endTime = new Date().getTime();
console.info(`SP read time: ${endTime - startTime}ms`); // 输出SP读取时间
}
// 测试MMKV性能
static testMMKV(context: Context) {
let kv = MMKV.defaultMMKV();
// 写入测试
let startTime = new Date().getTime();
for (let i = 0; i < TEST_COUNT; i++) {
kv.removeValueForKey TEST_KEY); // 清空旧数据
kv.encodeString TEST_KEY, TEST_VALUE); // 写入新数据
}
let endTime = new Date().getTime();
console.info(`MMKV write time: ${endTime - startTime}ms`); // 输出MMKV写入时间
// 读取测试
startTime = new Date().getTime();
for (let i = 0; i < TEST_COUNT; i++) {
kv.decodeString TEST_KEY, null); // 读取数据
}
endTime = new Date().getTime();
console.info(`MMKV read time: ${endTime - startTime}ms`); // 输出MMKV读取时间
}
}
通过这些测试代码，您可以直观地看到MMKV在性能上的优势，特别是在写入操作上，MMKV比SP快10倍以上。
总结
本文深入解析了SharedPreferences的ANR问题根源，详细介绍了MMKV的技术原理和实现机制，提供了从零开始的完整集成指南和代码示例，并通过实际案例展示了MMKV在解决ANR问题上的卓越表现。通过MMKV的mmap内存映射、Protobuf序列化和增量更新机制，可以从根本上解决SP的性能瓶颈，实现零ANR、微秒级响应的存储方案。
对于追求性能和稳定性的移动应用，特别是需要频繁读写数据的场景，MMKV是替代SharedPreferences的理想选择。通过本文的详细指导，您可以轻松将MMKV集成到自己的项目中，解决SP带来的ANR问题，提升应用性能和用户体验。
暂无评论内容