| Markdown版本笔记 | 我的GitHub首页 | 我的博客 | 我的微信 | 我的邮箱 |
|---|---|---|---|---|
| MyAndroidBlogs | baiqiantao | baiqiantao | bqt20094 | [email protected] |
目录
MMKV
基本使用
支持的数据类型
SharedPreferences 迁移
MMKV 组件现在开源了
MMKV 源起
MMKV 原理
MMKV for Android 特有功能
MMKV 使用
Android 快速上手
SharedPreferences 迁移
MMKV 性能
iOS 性能对比
Android 性能对比
MMKV for Android 多进程设计与实现
IPC 选型
CS 架构 vs 去中心化架构
挑选进程锁
多进程实现细节
状态同步
写指针增长
内存重整
内存增长
文件锁
MMKV 多进程性能
MMKV
MMKV
Android 安装教程
Android 使用教程
Android 进阶教程
Android 性能对比
MMKV 原理
MMKV for Android 多进程设计与实现
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.
MMKV 是基于 mmap 内存映射的移动端通用 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。
基本使用
implementation 'com.tencent:mmkv:1.0.19'MMKV 默认以动态库形式链接 libc++，会额外占用 2MB 空间（解压后）。如果你其他库没有用到libc++_shared.so，或者你担心不同版本的libc++_shared.so会带来潜在的问题，你可以使用静态链接 libc++ 的 MMKV：
implementation 'com.tencent:mmkv-static:1.0.19'在 App 启动时初始化 MMKV，设定 MMKV 的根目录：
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- 任何实现了
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