1 MMKV概览
1.1 什么是MMKV
引自 github.com/Tencent/MMKV 介绍[https://github.com/Tencent/MMKV/blob/master/readme_cn.md]
MMKV——基于 mmap 的高性能通用 key-value 组件
MMKV 是基于 mmap 内存映射的 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能 高，稳定性强。从 2015 年中至今在微信上使用，其性能和稳定性经过了时间的验证。近期也已移 植到 Android / macOS / Windows 平台，一并开源。MMKV 源起
在微信客户端的日常运营中，时不时就会爆发特殊文字引起系统的 crash，文章里面设计的技术方 案是在关键代码前后进行计数器的加减，通过检查计数器的异常，来发现引起闪退的异常文字。 在会话列表、会话界面等有大量 cell 的地方，希望新加的计时器不会影响滑动性能;另外这些计 数器还要永久存储下来——因为闪退随时可能发生。这就需要一个性能非常高的通用 key-value 存 储组件，我们考察了 SharedPreferences、NSUserDefaults、SQLite 等常见组件，发现都没能满足如 此苛刻的性能要求。考虑到这个防 crash 方案最主要的诉求还是实时写入，而 mmap 内存映射文 件刚好满足这种需求，我们尝试通过它来实现一套 key-value 组件。
MMKV 原理
- 内存准备
通过 mmap 内存映射文件，提供一段可供随时写入的内存块，App 只管往里面写数据，由操 作系统负责将内存回写到文件，不必担心 crash 导致数据丢失。- 数据组织
数据序列化方面我们选用 protobuf 协议，pb 在性能和空间占用上都有不错的表现。- 写入优化
考虑到主要使用场景是频繁地进行写入更新，我们需要有增量更新的能力。我们考虑将增量 kv 对象序列化后，append 到内存末尾。- 空间增长
使用 append 实现增量更新带来了一个新的问题，就是不断 append 的话，文件大小会增长得不可 控。我们需要在性能和空间上做个折中。
1.2 SharedPreference简介
SharedPreference 是安卓系统数据持久化的一种选择，用于存储轻量级 K-V 数据。SP 的读写方式为直接 IO 读取，即通过 FileInputStream/FileOutputStream 来进行读写，数据格式为 XML ，写入方式为全量更新。
1.3 直接I/O读取与mmap
1.3.1 直接I/O
虚拟内存被操作系统划分成两块:用户空间和内核空间，用户空间是用户程序代码运行的地方，内核空 间是内核代码运行的地方。为了安全，它们是隔离的，即使用户的程序崩溃了，内核也不受影响。
直接I/O写文件流程
- 调用 write ，告诉内核需要写入数据的开始地址与长度
- 内核将数据拷贝到内核缓存
- 由操作系统调用，将数据拷贝到磁盘，完成写入
1.3.2 mmap
Linux 通过将一个虚拟内存区域与一个磁盘上的对象关联起来，以初始化这个虚拟内存区域的内容，这个过程称为内存映射 (memory mapping)。
对文件进行 mmap，会在进程的虚拟内存分配地址空间，创建映射关系。实现这样的映射关系后，就可 以采用指针的方式读写操作这一段内存，而系统会自动回写到对应的文件。
1.3.3 mmap的优势
- mmap 对文件的读写操作只需要从磁盘到用户主存的一次数据拷贝过程，减少了数据的拷贝次数， 提高了文件读写效率
- mmap 使用逻辑内存对磁盘文件进行映射，操作内存就相当于操作文件，不需要开启线程，操作 mmap 的速度和操作内存的速度一样快
- mmap 提供一段可供随时写入的内存块，App 只管往里面写数据，由操作系统如内存不足、进程退出等时候负责将内存回写到文件，不必担心 crash 导致数据丢失(见文首引文)
1.4 MMKV数据结构
使用 010editor 打开 MMKV 映射文件
-
前4个字节表示整个映射文件中数据的有效长度
Q:为什么需要有效长度?
A:因为 mmap 内存映射的时候，文件大小必须是 4096 (这个数字与操作系统位数有关)或者 其整数倍，所以并非整个文件内容都是有效数据，需要用有效数据长度来标明有效数据。
从第五个字节开始，依次为k1长--->k1值--->v1长--->v1值--->k2长--->k2值--->v2长--->v2值---> ... --->
1.5 MMKV增量修改
我们介绍了 MMKV 数据在文件中的存储结构，这种结构如何实现增量修改的呢?
原因是 MMKV 在内存中是一个 map 表结构。完成首次 mmap 映射关系的建立后，之后我再次写入一个 同名 key 的 键值对，该键值对直接存储在映射文件的末尾，并修改有效长度。当我映射关系断开后重新 建立映射关系的时候，旧的键值对先写入 map 表，新的键值对后读入，将会覆盖掉旧的键值对，也就 实现了增量修改。
1.6 protobuf编码
1.6.1 protobuf编码规则
我们以整型数据来说明
每一个字节的首位作标志位， 标志位为1 ，则表示该字节无法完整表示数据，需要更多的字节; 标志位 为0 ，则表示该字节已经是表示该数据的最后一个字节，该数据的读取到该字节为止。每一个字节的后 七位保存数据。
0x7f ?
ox7f 的10进制表示为 127 ，2 进制表示为 0111 1111 。
如果写入的数据 <= 0x7f ，那么一个字节的七个数据位足够表示这个数据，则字节首位置 0 ，后七位写入数据。
如果写入的数据 > 0x7f 那么一个字节的七个数据位不足以表示这个数据，则字节首位置1，后七位 写入数据，并将原数右移 7 位，继续执行判断。
1.6.2 protobuf编码举例
-
编码 128 ，即 1000 0000
128 <= 127 ? (或者“1000 0000 用 7 位能否完整表示?”) NO!则字节首位置 1 ，后七位写入数 据 000 0000 ，得到第一个字节 1000 0000 ，将 128 右移 7 位，得到 0000 0001;
1 <= 127 ?(或者“0000 0001 用 7 位能否完整表示?”)YES!则字节首位置 0 ，后七位写入数据 000 0001 ，得到编码的最后一个字节 0000 0001 。
128 最后的 protobuf 编码为 1000 0000 | 0000 0001 ，从原本 int 的 4 字节，压缩到了现在的 2 字节。
-
读取 128 的 protobuf 编码，即 1000 0000 | 0000 0001
从前往后读取，读到第一个字节，即 1000 0000 ，首位为 1 ，说明该字节非表示该数据的最 后一个字节，则取出数据位 000 0000 暂存;
从前往后读取，读到第二个字节，即 0000 0001 ，首位为 0 ，说明该字节是表示该数据的最 后一个字节，则取出数据位 000 0001 暂存;
要明确，先存入的是低位，即先读出的也是低位。所以 后读出的字节要拼接到先读出字节的 前面构成高位，所以读取 1000 0000 0000 0001 结果是 000 0001 000 0000 ，即 1000 0000 或 128 。
