MMKV_MMKV简介

内容来自官网

MMKV——基于 mmap 的高性能通用 key-value 组件

MMKV 是基于 mmap 内存映射的 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。从 2015 年中至今，在 iOS 微信上使用已有近 3 年，其性能和稳定性经过了时间的验证。近期也已移植到 Android 平台，一并开源。

MMKV 源起

在微信客户端的日常运营中，时不时就会爆发特殊文字引起系统的 crash，参考文章，文章里面设计的技术方案是在关键代码前后进行计数器的加减，通过检查计数器的异常，来发现引起闪退的异常文字。在会话列表、会话界面等有大量 cell 的地方，希望新加的计时器不会影响滑动性能；另外这些计数器还要永久存储下来——因为闪退随时可能发生。这就需要一个性能非常高的通用 key-value 存储组件，我们考察了 SharedPreferences、NSUserDefaults、SQLite 等常见组件，发现都没能满足如此苛刻的性能要求。考虑到这个防 crash 方案最主要的诉求还是实时写入，而 mmap 内存映射文件刚好满足这种需求，我们尝试通过它来实现一套 key-value 组件。

MMKV 原理内存准备

通过 mmap 内存映射文件，提供一段可供随时写入的内存块，App 只管往里面写数据，由操作系统负责将内存回写到文件，不必担心 crash 导致数据丢失。

数据组织

数据序列化方面我们选用 protobuf 协议，pb 在性能和空间占用上都有不错的表现。

写入优化

考虑到主要使用场景是频繁地进行写入更新，我们需要有增量更新的能力。我们考虑将增量 kv 对象序列化后，append 到内存末尾。

空间增长

使用 append 实现增量更新带来了一个新的问题，就是不断 append 的话，文件大小会增长得不可控。我们需要在性能和空间上做个折中。

更详细的设计原理参考 MMKV 原理。

iOS 指南

安装引入

推荐使用 CocoaPods：打开命令行, cd 到你的项目工程目录, 输入 pod repo update 让 CocoaPods 感知最新的 MMKV 版本；

打开 Podfile, 添加 pod 'MMKV' 到你的 app target 里面；

在命令行输入 pod install；

用 Xcode 打开由 CocoaPods 自动生成的 .xcworkspace 文件；

添加头文件 #import ，就可以愉快地开始你的 MMKV 之旅了。

更多安装指引参考 iOS Setup。

快速上手

MMKV 的使用非常简单，无需任何配置，所有变更立马生效，无需调用 synchronize:

MMKV *mmkv = [MMKV defaultMMKV];

[mmkv setBool:YES forKey:@"bool"];

BOOL bValue = [mmkv getBoolForKey:@"bool"];

[mmkv setInt32:-1024 forKey:@"int32"];

int32_t iValue = [mmkv getInt32ForKey:@"int32"];

[mmkv setObject:@"hello, mmkv" forKey:@"string"];

NSString *str = [mmkv getObjectOfClass:NSString.class forKey:@"string"];

性能对比

循环写入随机的int 1w 次，我们有如下性能对比：

Android 指南

安装引入

推荐使用 Maven：

dependencies {

implementation 'com.tencent:mmkv:1.0.11'

// replace "1.0.11" with any available version

}

快速上手

MMKV 的使用非常简单，所有变更立马生效，无需调用 sync、apply。 在 App 启动时初始化 MMKV，设定 MMKV 的根目录(files/mmkv/)，例如在 MainActivity 里：

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

String rootDir = MMKV.initialize(this);

System.out.println("mmkv root: " + rootDir);

//……

}

MMKV 提供一个全局的实例，可以直接使用：

import com.tencent.mmkv.MMKV;

//……

MMKV kv = MMKV.defaultMMKV();

kv.encode("bool", true);

boolean bValue = kv.decodeBool("bool");

kv.encode("int", Integer.MIN_VALUE);

int iValue = kv.decodeInt("int");

kv.encode("string", "Hello from mmkv");

String str = kv.decodeString("string");

MMKV for Android

MMKV 是基于 mmap 内存映射的 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。从2015年中至今，在 iOS 微信上使用已有 3 年，其性能和稳定性经过了时间的验证。

使用指南

MMKV 的使用非常简单，所有变更立马生效，无需调用 sync、apply。

配置 MMKV 根目录

在 App 启动时初始化 MMKV，设定 MMKV 的根目录(files/mmkv/)，例如在 MainActivity 里：

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

String rootDir = MMKV.initialize(this);

System.out.println("mmkv root: " + rootDir);

}

CRUD 操作MMKV 提供一个全局的实例，可以直接使用：

import com.tencent.mmkv.MMKV;

...

MMKV kv = MMKV.defaultMMKV();

kv.encode("bool", true);

System.out.println("bool: " + kv.decodeBool("bool"));

kv.encode("int", Integer.MIN_VALUE);

System.out.println("int: " + kv.decodeInt("int"));

kv.encode("long", Long.MAX_VALUE);

System.out.println("long: " + kv.decodeLong("long"));

kv.encode("float", -3.14f);

System.out.println("float: " + kv.decodeFloat("float"));

kv.encode("double", Double.MIN_VALUE);

System.out.println("double: " + kv.decodeDouble("double"));

kv.encode("string", "Hello from mmkv");

System.out.println("string: " + kv.decodeString("string"));

byte[] bytes = {'m', 'm', 'k', 'v'};

kv.encode("bytes", bytes);

System.out.println("bytes: " + new String(kv.decodeBytes("bytes")));

可以看到，MMKV 在使用上还是比较简单的。删除 & 查询：

MMKV kv = MMKV.defaultMMKV();

kv.removeValueForKey("bool");

System.out.println("bool: " + kv.decodeBool("bool"));

kv.removeValuesForKeys(new String[]{"int", "long"});

System.out.println("allKeys: " + Arrays.toString(kv.allKeys()));

boolean hasBool = kv.containsKey("bool");

如果不同业务需要区别存储，也可以单独创建自己的实例：

MMKV* mmkv = MMKV.mmkvWithID("MyID");

mmkv.encode("bool", true);

如果业务需要多进程访问，那么在初始化的时候加上标志位 MMKV.MULTI_PROCESS_MODE：

MMKV* mmkv = MMKV.mmkvWithID("InterProcessKV", MMKV.MULTI_PROCESS_MODE);

mmkv.encode("bool", true);

支持的数据类型支持以下 Java 语言基础类型：boolean、int、long、float、double、byte[]

支持以下 Java 类和容器：String、Set

SharedPreferences 迁移MMKV 提供了 importFromSharedPreferences() 函数，可以比较方便地迁移数据过来。

MMKV 还额外实现了一遍 SharedPreferences、SharedPreferences.Editor 这两个 interface，在迁移的时候只需两三行代码即可，其他 CRUD 操作代码都不用改。

private void testImportSharedPreferences() {

// SharedPreferences preferences = getSharedPreferences("myData", MODE_PRIVATE);

MMKV preferences = MMKV.mmkvWithID("myData");

// 迁移旧数据

{

SharedPreferences old_man = getSharedPreferences("myData", MODE_PRIVATE);

preferences.importFromSharedPreferences(old_man);

old_man.edit().clear().commit();

}

// 跟以前用法一样

SharedPreferences.Editor editor = preferences.edit();

editor.putBoolean("bool", true);

editor.putInt("int", Integer.MIN_VALUE);

editor.putLong("long", Long.MAX_VALUE);

editor.putFloat("float", -3.14f);

editor.putString("string", "hello, imported");

HashSet set = new HashSet();

set.add("W"); set.add("e"); set.add("C"); set.add("h"); set.add("a"); set.add("t");

editor.putStringSet("string-set", set);

// 无需调用 commit()

//editor.commit();

}

MMKV for Android 多进程设计与实现

前言

将 MMKV 迁移到 Android 平台之后，很多同事反馈需要支持多进程访问——这在之前是没有考虑过的(因为 iOS 不支持多进程)，需要进行全盘的设计和仔细的实现。

IPC 选型

说到 IPC，首要的问题就是架构选型，不同的架构效果大相径庭。

CS 架构 vs 去中心化架构

Android 平台第一个想到的就是 ContentProvider：一个单独进程管理数据，数据同步不易出错，简单好用易上手。然而它的问题也很明显，就是一个字慢：启动慢，访问也慢。这个可以说是 Android 下基于 Binder 的 CS 架构组件的通用痛点。至于其他的 CS 架构，例如经典的 socket、PIPE、message queue，因为要至少 2 次的内存拷贝，就更加慢了。

MMKV 追求的是极致的访问速度，我们要尽可能地避免进程间通信，CS 架构是不可取的。再考虑到 MMKV 底层使用 mmap 实现，采用去中心化的架构是很自然的选择。我们只需要将文件 mmap 到每个访问进程的内存空间，加上合适的进程锁，再处理好数据的同步，就能够实现多进程并发访问。

挑选进程锁

然而去中心化的架构实现起来并不简单，Android 是个阉割版的 Linux，IPC 组件的支持比较残缺。例如，说到进程锁第一个想到的就是 pthread 库的 pthread_mutex，创建于共享内存的 pthread_mutex 是可以用作进程锁的，然而 Android 版的 pthread_mutex 并不保证robust，亦即对 pthread_mutex 加了锁的进程被 kill，系统不会进行清理工作，这个锁会一直存在下去，那么其他等锁的进程就会永远饿死。其他的 IPC 组件，例如信号量、条件变量，也有同样问题，Android 为了能够尽快关闭进程，真是无所不用其极。

找了一圈，能够保证 robust 的，只有已打开的文件描述符，以及基于文件描述符的文件锁和 Binder 组件的死亡通知(是的，Binder 也是依赖这个清理机制运作，打开的文件是 /dev/binder)。

我们有两个选择：文件锁，优点是天然 robust，缺点是不支持递归加锁，也不支持读写锁升级/降级，需要自行实现。

pthread_mutex，优点是 pthread 库支持递归加锁，也支持读写锁升级/降级，缺点是不 robust，需要自行清理。

关于 mutex 清理，有个可能的方案是基于 Binder 死亡通知进行清理：A、B进程相互注册对方的死亡通知，在对方死亡的时候进行清理。但有个比较棘手的场景：只有 A 进程存在，那么他的死亡通知就没人处理，留下一个永远加锁的 mutex。Binder 规定死亡通知不能本进程自行处理，必须由其他进程处理，所以这个问题不好解决。

综合各种考虑，我们先将文件锁作为一个简单的互斥锁，进行 MMKV 的多进程开发，稍后再回头解决递归锁和读写锁升级/降级的问题。

多进程实现细节

首先我们简单回顾一下 MMKV 原来的逻辑。MMKV 本质上是将文件 mmap 到内存块中，将新增的 key-value 统统 append 到内存中；到达边界后，进行重整回写以腾出空间，空间还是不够的话，就 double 内存空间；对于内存文件中可能存在的重复键值，MMKV 只选用最后写入的作为有效键值。那么其他进程为了保持数据一致，就需要处理这三种情况：写指针增长、内存重整、内存增长。但首先还得解决一个问题：怎么让其他进程感知这三种情况？

状态同步写指针的同步

我们可以在每个进程内部缓存自己的写指针，然后在写入键值的同时，还要把最新的写指针位置也写到 mmap 内存中；这样每个进程只需要对比一下缓存的指针与 mmap 内存的写指针，如果不一样，就说明其他进程进行了写操作。事实上 MMKV 原本就在文件头部保存了有效内存的大小，这个数值刚好就是写指针的内存偏移量，我们可以重用这个数值来校对写指针。

内存重整的感知

考虑使用一个单调递增的序列号，每次发生内存重整，就将序列号递增。将这个序列号也放到 mmap 内存中，每个进程内部也缓存一份，只需要对比序列号是否一致，就能够知道其他进程是否触发了内存重整。

内存增长的感知

事实上 MMKV 在内存增长之前，会先尝试通过内存重整来腾出空间，重整后还不够空间才申请新的内存。所以内存增长可以跟内存重整一样处理。至于新的内存大小，可以通过查询文件大小来获得，无需在 mmap 内存另外存放。

状态同步逻辑用伪码表达大概是这个样子：

void checkLoadData() {

if (m_sequence != mmapSequence()) {

m_sequence = mmapSequence();

if (m_size != fileSize()) {

m_size = fileSize();

// 处理内存增长

} else {

// 处理内存重整

}

} else if (m_actualSize != mmapActualSize()) {

auto lastPosition = m_actualSize;

m_actualSize = mmapActualSize();

// 处理写指针增长

} else {

// 什么也没发生

return;

}

}

写指针增长

当一个进程发现 mmap 写指针增长，就意味着其他进程写入了新键值。这些新的键值都 append 在原有写指针后面，可能跟前面的 key 重复，也可能是全新的 key，而原写指针前面的键值都是有效的。那么我们就要把这些新键值都读出来，插入或替换原有键值，并将写指针同步到最新位置。

auto lastPosition = m_actualSize;

m_actualSize = mmapActualSize();

// 处理写指针增长

auto bufferSize = m_actualSize - lastPosition;

auto buffer = Buffer(lastPosition, bufferSize);

map dictionary = decodeMap(buffer);

for (auto& itr : dictionary) {

// m_cache 还是有效的

m_cache[itr.first] = itr.second;

}

内存重整

当一个进程发现内存被重整了，就意味着原写指针前面的键值全部失效，那么最简单的做法是全部抛弃掉，从头开始重新加载一遍。

// 处理内存重整

m_actualSize = mmapActualSize();

auto buffer = Buffer(0, m_actualSize);

m_cache = decodeMap(buffer);

内存增长

正如前文所述，发生内存增长的时候，必然已经先发生了内存重整，那么原写指针前面的键值也是统统失效，处理逻辑跟内存重整一样。

文件锁

到这里我们已经完成了数据的多进程同步工作，是时候回头处理锁事了，亦即前面提到的递归锁和锁升级/降级。递归锁

意思是如果一个进程/线程已经拥有了锁，那么后续的加锁操作不会导致卡死，并且解锁也不会导致外层的锁被解掉。对于文件锁来说，前者是满足的，后者则不然。因为文件锁是状态锁，没有计数器，无论加了多少次锁，一个解锁操作就全解掉。只要用到子函数，就非常需要递归锁。

锁升级/降级

锁升级是指将已经持有的共享锁，升级为互斥锁，亦即将读锁升级为写锁；锁降级则是反过来。文件锁支持锁升级，但是容易死锁：假如 A、B 进程都持有了读锁，现在都想升级到写锁，就会陷入相互等待的困境，发生死锁。另外，由于文件锁不支持递归锁，也导致了锁降级无法进行，一降就降到没有锁。

为了解决这两个难题，需要对文件锁进行封装，增加读锁、写锁计数器。处理逻辑如下表：

需要注意的地方有两点：加写锁时，如果当前已经持有读锁，那么先尝试加写锁，try_lock 失败说明其他进程持有了读锁，我们需要先将自己的读锁释放掉，再进行加写锁操作，以避免死锁的发生。

解写锁时，假如之前曾经持有读锁，那么我们不能直接释放掉写锁，这样会导致读锁也解了。我们应该加一个读锁，将锁降级。

MMKV 多进程性能

写了个简单的测试，创建两个 Service，测试 MMKV、MultiProcessSharedPreferences、SQLite 多进程读写的性能，具体代码见 git repo。

测试环境：Pixel 2 XL 64G, Android 8.1.0，单位：ms。每组测试分别循环 1000 次；MultiProcessSharedPreferences 使用 apply() 同步数据；SQLite 打开 WAL 选项。