MMKV 多进程K-V组件 MD

时间 2019-12-08

标签 mmkv 进程组件繁體版

原文原文链接

Markdown版本笔记	个人GitHub首页	个人博客	个人微信	个人邮箱
MyAndroidBlogs	baiqiantao	baiqiantao	bqt20094	baiqiantao@sina.com

MMKV

MMKV
Android 安装教程
 Android 使用教程
 Android 进阶教程
 Android 性能对比
 MMKV 原理
 MMKV for Android 多进程设计与实现java

MMKV is an efficient, small, easy-to-use mobile key-value storage framework used in the WeChat application. It's currently available on iOS, macOS, Android and Windows.android

MMKV 是基于 mmap 内存映射的移动端通用 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。c++

基本使用

implementation 'com.tencent:mmkv:1.0.19'

MMKV 默认以动态库形式连接 libc++，会额外占用 2MB 空间（解压后）。若是你其余库没有用到libc++_shared.so，或者你担忧不一样版本的libc++_shared.so会带来潜在的问题，你可使用静态连接 libc++ 的 MMKV：git

implementation 'com.tencent:mmkv-static:1.0.19'

在 App 启动时初始化 MMKV，设定 MMKV 的根目录：github

String rootDir = MMKV.initialize(this);

MMKV 提供一个全局的实例，能够直接使用：算法

MMKV kv = MMKV.defaultMMKV();
kv.encode("bool", true); //添加、更新
boolean bValue = kv.decodeBool("bool"); //获取
kv.removeValueForKey("bool"); //删除
kv.containsKey("bool"); //判断是否存在
String[] keys = kv.allKeys(); //获取全部key的数组

若是不一样业务须要区别存储，也能够单首创建本身的实例：数组

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

支持的数据类型

支持如下 Java 语言基础类型：boolean、int、long、float、double、byte[]
支持如下 Java 类和容器：缓存

String、Set<String>
任何实现了Parcelable的类型

SharedPreferences 迁移

MMKV 提供了 importFromSharedPreferences() 函数，能够比较方便地迁移数据过来。微信

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

MMKV mmkv = MMKV.mmkvWithID("myData");
// 迁移旧数据
SharedPreferences old_man = getSharedPreferences("myData", MODE_PRIVATE);
mmkv.importFromSharedPreferences(old_man); //卧槽，把SharedPreferences整个传过去了，还不是想怎么搞都行
old_man.edit().clear().commit();

// 跟之前用法同样
SharedPreferences.Editor editor = mmkv.edit();
editor.putBoolean("bool", true);
//editor.commit(); // 无需调用 commit()

MMKV 组件如今开源了

原文：2018-09-21
MMKV--基于 mmap 的 iOS 高性能通用 key-value 组件:2018-03-14

MMKV 是基于 mmap 内存映射的移动端通用 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。从 2015 年中至今，在 iOS 微信上使用已有近 3 年，其性能和稳定性通过了时间的验证。近期已移植到 Android 平台。在腾讯内部开源半年以后，获得公司内部团队的普遍应用和一致好评。如今一并对外开源，欢迎 Star、提 Issue 和 PR。

MMKV 源起

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

MMKV 原理

内存准备：经过 mmap 内存映射文件，提供一段可供随时写入的内存块，App 只管往里面写数据，由操做系统负责将内存回写到文件，没必要担忧 crash 致使数据丢失。
数据组织：数据序列化方面咱们选用 protobuf 协议，pb 在性能和空间占用上都有不错的表现。
写入优化：考虑到主要使用场景是频繁地进行写入更新，咱们须要有增量更新的能力。咱们考虑将增量 kv 对象序列化后，append 到内存末尾。
空间增加：使用 append 实现增量更新带来了一个新的问题，就是不断 append 的话，文件大小会增加得不可控。咱们须要在性能和空间上作个折中。

更详细的设计原理参考前文《MMKV——iOS 下基于 mmap 的高性能通用 key-value 组件》。

MMKV for Android 特有功能

咱们不是简简单单地照搬 iOS 的实现，在迁移到 Android 的过程当中，深刻分析了 Android 平台现有 kv 组件的痛点，在原有功能基础上，开发了 Android 特有的功能。

多进程访问
经过与 Android 开发同窗的沟通，了解到系统自带的 SharedPreferences 对多进程的支持很差。现有基于 ContentProvider 封装的实现，虽然多进程是支持了，可是性能低下，常常致使 ANR。考虑到 mmap 共享内存本质上的多进程共享的，咱们在这个基础上，深刻挖掘了 Android 系统的能力，提供了多是业界最高效的多进程数据共享组件。具体实现原理咱们中秋节后分享，心急的同窗能够前往 GitHub 查看源码和 wiki 文档。

匿名内存
在多进程共享的基础上，考虑到某些敏感数据(例如密码)须要进程间共享，可是不方便落地存储到文件上，直接用 mmap 不合适。咱们了解到 Android 系统提供了 Ashmem 匿名共享内存的能力，发现它在进程退出后就会消失，不会落地到文件上，很是适合这个场景。咱们很愉快地提供了 Ashmem MMKV 的功能。

数据加密
不像 iOS 提供了硬件层级的加密机制，在 Android 环境里，数据加密是很是必须的。MMKV 使用了 AES CFB-128 算法来加密/解密。咱们选择 CFB 而不是常见的 CBC 算法，主要是由于 MMKV 使用 append-only 实现插入/更新操做，流式加密算法更加合适。事实上这个功能也回馈到了 iOS 版，因此如今两个系统的 MMKV 都有加密功能。

MMKV 使用

iOS 的使用在前文已经陈述，这里简单介绍一下 Android 的用法。

Android 快速上手

MMKV 已托管到 bintray(JCenter)，能够直接使用。在 App 的 build.gradle 里加上依赖：

implementation 'com.tencent:mmkv:1.0.10'

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

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    String rootDir = MMKV.initialize(this);
    Log.d("mmkv", "root: " + rootDir);
    //……
}

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

MMKV kv = MMKV.defaultMMKV();

kv.encode("bool", true);
kv.encode("int", Integer.MIN_VALUE);
kv.encode("string", "Hello from mmkv");

boolean bValue = kv.decodeBool("bool");
int iValue = kv.decodeInt("int");
String str = kv.decodeString("string");

若是不一样业务须要区别存储，也能够单首创建本身的实例：

MMKV mmkv = MMKV.mmkvWithID("MyID");
mmkv.encode("bool", true);

SharedPreferences 迁移

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

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

更详细的用法能够参看 GitHub 上的 wiki 文档。

MMKV 性能

iOS 性能对比

咱们将 MMKV 和 NSUserDefaults 进行对比，重复读写操做 1w 次。相关测试代码在 iOS/MMKVDemo/MMKVDemo/，结果见以下图表。

测试机器是 iPhone X 256 G，iOS 12 beta 2，每组操做重复 1w 次，时间单位是 ms。

可见，MMKV 在写入性能上远远超越 NSUserDefaults，在读取性能上也有相近或超越的表现。

Android 性能对比

咱们将 MMKV 和 SharedPreferences、SQLite 进行对比, 重复读写操做 1k 次。相关测试代码在 Android/MMKV/mmkvdemo/。结果以下图表。

单进程性能

测试机器是 Pixel 2 XL 64G，Android 8.1，每组操做重复 1k 次，时间单位是 ms。

可见，MMKV 在写入性能上远远超越 SharedPreferences & SQLite，在读取性能上也有相近或超越的表现。

多进程性能

测试机器是 Pixel 2 XL 64G，Android 8.1，每组操做重复 1k 次，时间单位是 ms。

可见，MMKV 不管是在写入性能仍是在读取性能，都远远超越 MultiProcessSharedPreferences & SQLite & SQLite， MMKV 在 Android 多进程 key-value 存储组件上是不二之选。

MMKV for Android 多进程设计与实现

原文：2018-09-25

原本这是此框架最核心的部分，是最须要区学习的，可是看完后只能说：一脸懵逼！

将 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 内存另外存放。

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

写指针增加

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

内存重整

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

内存增加

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

文件锁

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

递归锁
意思是若是一个进程/线程已经拥有了锁，那么后续的加锁操做不会致使卡死，而且解锁也不会致使外层的锁被解掉。对于文件锁来讲，前者是知足的，后者则否则。由于文件锁是状态锁，没有计数器，不管加了多少次锁，一个解锁操做就全解掉。只要用到子函数，就很是须要递归锁。
锁升级/降级
锁升级是指将已经持有的共享锁，升级为互斥锁，亦即将读锁升级为写锁；锁降级则是反过来。文件锁支持锁升级，可是容易死锁：假如 A、B 进程都持有了读锁，如今都想升级到写锁，就会陷入相互等待的困境，发生死锁。另外，因为文件锁不支持递归锁，也致使了锁降级没法进行，一降就降到没有锁。

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

读锁计数器	写锁计数器	加读锁	加写锁	解读锁	解写锁
0	0	加读锁	加写锁	-	-
0	1	+1	+1	-	解写锁
0	N	+1	+1	-	-1
1	0	+1	解读锁再加写锁	解读锁	-
1	1	+1	+1	-1	加读锁
1	N	+1	+1	-1	-1
N	0	+1	解读锁再加写锁	-1	-
N	1	+1	+1	-1	加读锁
N	N	+1	+1	-1	-1

须要注意的地方有两点：

加写锁时，若是当前已经持有读锁，那么先尝试加写锁，try_lock 失败说明其余进程持有了读锁，咱们须要先将本身的读锁释放掉，再进行加写锁操做，以免死锁的发生。
解写锁时，假如以前曾经持有读锁，那么咱们不能直接释放掉写锁，这样会致使读锁也解了。咱们应该加一个读锁，将锁降级。

MMKV 多进程性能

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

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

2019-5-4