1.MMKV 原理以及使用
MMKV是基于mmap内存映射的移动端通用key-value组件，底层序列化/反序列化使用protobuf实现，性能高，稳定性强。从2015年中至今，在iOS微信上使用已有近3年，近期移植到Android平台，移动端全平台通用，并全部在Github上开源。
MMKV 原理
内存准备:
通过 mmap 内存映射文件，提供一段可供随时写入的内存块，App 只管往里面写数据，由操作系统负责将内存回写到文件，不必担心 crash 导致数据丢失。
数据组织:
数据序列化方面我们选用 protobuf 协议，pb 在性能和空间占用上都有不错的表现。考虑到我们要提供的是通用 kv 组件，key 可以限定是 string 字符串类型，value 则多种多样（int/bool/double 等）。要做到通用的话，考虑将 value 通过 protobuf 协议序列化成统一的内存块（buffer），然后就可以将这些 KV 对象序列化到内存中。
写入优化: (重点关注这里!!!)
标准 protobuf 不提供增量更新的能力，每次写入都必须全量写入。考虑到主要使用场景是频繁地进行写入更新，我们需要有增量更新的能力：将增量 kv 对象序列化后，直接 append 到内存末尾；这样同一个 key 会有新旧若干份数据，最新的数据在最后；那么只需在程序启动第一次打开 mmkv 时，不断用后读入的 value 替换之前的值，就可以保证数据是最新有效的。
空间增长: (还有这里!!!)
使用 append 实现增量更新带来了一个新的问题，就是不断 append 的话，文件大小会增长得不可控。例如同一个 key 不断更新的话，是可能耗尽几百 M 甚至上 G 空间，而事实上整个 kv 文件就这一个 key，不到 1k 空间就存得下。这明显是不可取的。我们需要在性能和空间上做个折中：以内存 pagesize 为单位申请空间，在空间用尽之前都是 append 模式；当 append 到文件末尾时，进行文件重整、key 排重，尝试序列化保存排重结果；排重后空间还是不够用的话，将文件扩大一倍，直到空间足够。
数据有效性:
考虑到文件系统、操作系统都有一定的不稳定性，我们另外增加了 crc 校验，对无效数据进行甄别。在 iOS 微信现网环境上，我们观察到有平均约 70万日次的数据校验不通过。
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 是基于 mmap 内存映射的移动端通用 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。从 2015 年中至今，在 iOS 微信上使用已有近 3 年，其性能和稳定性经过了时间的验证。近期已移植到 Android 平台。在腾讯内部开源半年之后，得到公司内部团队的广泛应用和一致好评。现在一并对外开源：https://github.com/tencent/mmkv
MMKV 源起
在微信客户端的日常运营中，时不时就会爆发特殊文字引起系统的 crash，参考文章，文章里面设计的技术方案是在关键代码前后进行计数器的加减，通过检查计数器的异常，来发现引起闪退的异常文字。在会话列表、会话界面等有大量 cell 的地方，希望新加的计时器不会影响滑动性能；另外这些计数器还要永久存储下来——因为闪退随时可能发生。这就需要一个性能非常高的通用 key-value 存储组件，我们考察了 SharedPreferences、NSUserDefaults、SQLite 等常见组件，发现都没能满足如此苛刻的性能要求。考虑到这个防 crash 方案最主要的诉求还是实时写入，而 mmap 内存映射文件刚好满足这种需求，我们尝试通过它来实现一套 key-value 组件。
==============
MMKV 使用
implementation 'com.tencent:mmkv:1.0.19' 在Application里面初始化:
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
String rootDir = MMKV.initialize(this);//就这么一句话就行
System.out.println("mmkv root: " + rootDir);
}支持的数据类型:
支持以下 Java 语言基础类型：
boolean、int、long、float、double、byte[],String、Set<String>,任何实现了Parcelable的类型,对象存储方式是，转化成json串，通过字符串存储，
使用的时候在取出来反序列化.
增:
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的写入逻辑是：当我们覆盖某个值的时候，它并不会立即删除前面的值，会保留，然后每个key，value有存储限制，当触发存储限制的时候，才会执行删除，这样即使我们频繁的覆盖，也不会引起太多的性能损耗
删:
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()));
改:
直接在存一遍就是.(执行增步骤)
查:
在增的步骤里面,已经打印可查的结果.
kv.decodeBool("bool");
kv.decodeInt("int");
.....
如果不同业务需要区别存储，也可以单独创建自己的实例：
MMKV* mmkv = MMKV.mmkvWithID("MyID");
mmkv.encode("bool", true);
SharedPreferences 迁移
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<String> set = new HashSet<String>();
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();
以上内容来自官方github：https://github.com/Tencent/MMKV/wiki/android_setup_cn
MMKV 使用
Android 快速上手
MMKV 已托管到 bintray(JCenter)，可以直接使用。在 App 的 build.gradle 里加上依赖：
MMKV 的使用非常简单，所有变更立马生效，无需调用 sync、apply。
在 App 启动时初始化 MMKV，设定 MMKV 的根目录(files/mmkv/)，例如在 MainActivity 里：
MMKV 提供一个全局的实例，可以直接使用：
如果不同业务需要区别存储，也可以单独创建自己的实例：
SharedPreferences 迁移
-
MMKV 提供了 importFromSharedPreferences() 函数，可以比较方便地迁移数据过来。
-
MMKV 还额外实现了一遍 SharedPreferences、SharedPreferences.Editor 这两个 interface，在迁移的时候只需两三行代码即可，其他 CRUD 操作代码都不用改。
更详细的用法可以参看 GitHub 上的 wiki 文档。
MMKV 性能
Android 性能对比
我们将 MMKV 和 SharedPreferences、SQLite 进行对比, 重复读写操作 1k 次。相关测试代码在 Android/MMKV/mmkvdemo/。结果如下图表。
-
单进程性能
可见，MMKV 在写入性能上远远超越 SharedPreferences & SQLite，在读取性能上也有相近或超越的表现。image（测试机器是 Pixel 2 XL 64G，Android 8.1，每组操作重复 1k 次，时间单位是 ms。）
-
多进程性能
可见，MMKV 无论是在写入性能还是在读取性能，都远远超越 MultiProcessSharedPreferences & SQLite & SQLite， MMKV 在 Android 多进程 key-value 存储组件上是不二之选。image（测试机器是 Pixel 2 XL 64G，Android 8.1，每组操作重复 1k 次，时间单位是 ms。）
点击原文直接访问 GitHub 源码。
初始化：
Application里面初始化：
MMKV.initialize(this)
//……一个全局的实例
// MMKV kv = MMKV.defaultMMKV();
MMKV mMkv = MMKV.mmkvWithID(Constant.MMKV_PREFERENCES, MMKV.SINGLE_PROCESS_MODE);
// 存储数据：
mMkv.encode("Stingid", "123456");
mMkv.encode("bool", true);
mMkv.encode("int", Integer.MIN_VALUE);
// 取数据：
String id=mMkv.decodeString("id", null);
boolean bValue = mMkv.decodeBool("bool");
int iValue = kv.decodeInt("int");
// 移除数据：
mMkv.remove("Stingid");
mMkv.remove("bool");
mMkv.remove("int");MMKV浅析
MMKV 是微信开源的一个基于 mmap 内存映射的 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。微信团队为了发现记录特殊文字引起微信 iOS 系统的 crash，在关键代码前后进行计数器的加减，通过检查计数器的异常，来发现引起闪退的异常文字，但同时因为诸多cell的复杂页面情境下希望新加的计时器不会影响性能，另外这些计数器需要永久存储下来——因为闪退随时可能发生，所以亟需高性能的通用 key-value 存储组件，而微信团队在实时写入和高性能的选择标准下，通过对比NSUserDefaults、SQLite 等常见组件，最终选择了mmap 内存映射文件，并将其封装成为了MMKV组件。下面我们来逐步进行了解
1.mmap简介
认真分析mmap：是什么 为什么 怎么用这篇文章讲的炒鸡详细，很佩服作者，本人也不想ctrl+c/v一遍， 。但在此处总结下：
mmap实现了一种使用内存映射到磁盘文件的方法，将本该属于磁盘文件的对象映射到了进程地址空间中，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动（默认并不实时）回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用read,write等系统调用函数，对文件直接通过内存映射读取从而跨过了页缓存，减少数据拷贝次数，用内存读写 取代I/O读写，提高文件读取效率。另外，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享，从而达到进程间通信和进程间共享的目的。简言之，很强大。
2.protobuf
在数据序列化方面微信团队选用了protobuf 协议，出于通用化的考虑将多样化的 value 通过 protobuf协议序列化成统一的内存块（buffer)，然后再进行相应存储。
2.1 protobuf是什么
protobuf是一种灵活高效的序列化结构机制，就像xml，但是protobuf更轻量、更快并且更简单。一旦你限定了你想要的数据结构，那么你就可以使用特殊的构建代码实现对大量数据结构的读写，并且支持多种语言哦~你甚至可以更新你的数据构建，哪怕新的数据结构与老的完全相反，这丝毫不影响已经部署完成的程序。
也就是说protobuf帮我们轻松实现了序列化和反序列化，即使变更数据结构，也不会产生太大的影响，这对于数据结构多变的实际业务场景来说简直太有必要了。
3.写入优化&空间增长
因为标准 protobuf并 不提供增量更新的能力，每次写入都必须全量写入。 查看代码我们也能看到最底层调用的方法是使用的append而非直接替换：
- (BOOL)setRawData:(NSData *)data forKey:(NSString *)key {
if (data.length <= 0 || key.length <= 0) {
return NO;
}
CScopedLock lock(m_lock);
[m_dic setObject:data forKey:key];
m_hasFullWriteBack = NO;
return [self appendData:data forKey:key];
}
但是这样就会引发两个问题：
1.很大程度上可能存在相同key但是存储了多个不同的value。 2.不断 append 的话，文件大小会增长得不可控。
针对这两个问题的处理方式是：
1.在程序启动第一次打开 mmkv 时，不断用后读入的 value 替换之前的值，就可以保证数据是最新有效的。
2.对于空间增长的问题：以内存 pagesize 为单位申请空间，在空间用尽之前都是 append 模式；当 append 到文件末尾时，进行文件重整、key 排重，尝试序列化保存排重结果；排重后空间还是不够用的话，将文件扩大一倍，直到空间足够。所以在每次append之前都会先调用- (BOOL)ensureMemorySize:(size_t)newSize；方法检查一下是否有足够空间，如果没有则按照每次2倍的大小去扩展空间：
- (BOOL)ensureMemorySize:(size_t)newSize {
...
if (newSize >= m_output->spaceLeft()) {
// try a full rewrite to make space
static const int offset = pbFixed32Size(0);
NSData *data = [MiniPBCoder encodeDataWithObject:m_dic];
size_t lenNeeded = data.length + offset + newSize;
size_t avgItemSize = lenNeeded / std::max<size_t>(1, m_dic.count);
size_t futureUsage = avgItemSize * std::max<size_t>(8, m_dic.count / 2);
// 1. no space for a full rewrite, double it
// 2. or space is not large enough for future usage, double it to avoid frequently full rewrite
if (lenNeeded >= m_size || (lenNeeded + futureUsage) >= m_size) {
size_t oldSize = m_size;
do {
m_size *= 2;
} while (lenNeeded + futureUsage >= m_size);
...
}
...
}
...
}
3.另外针对空间增长，mmkv还提供了- (void)trim;方法来提供了通过手动调用减小多余占用内存的功能，正如每次扩增时按2倍扩增，缩减时也是每次除以2：
- (void)trim {
...
auto oldSize = m_size;
while (m_size > (m_actualSize * 2)) {
m_size /= 2;
}
...
}
4.crc 校验
微信团队考虑到文件系统、操作系统都有一定的不稳定性，另外增加了 crc 校验，对无效数据进行甄别，根据微信提供的数据：在 iOS 微信现网环境上，观察到有平均约 70w 日次的数据校验不通过。
4.1 crc 校验简介
CRC即循环冗余校验码（Cyclic Redundancy Check）：是数据通信领域中最常用的一种查错校验码，其特征是信息字段和校验字段的长度可以任意选定。循环冗余检查（CRC）是一种数据传输检错功能，对数据进行多项式计算，并将得到的结果附在帧的后面，接收设备也执行类似的算法，以保证数据传输的正确性和完整性。也就是接受方和发送方约定一个用来计算的二进制数（比如x），在整个传输过程中，这个数始终保持不变。循环冗余校验码（CRC）的基本原理是：在K位信息码后再拼接R位的校验码，整个编码长度为N位，因此，这种编码也叫（N，K）码。那么发送方发送时根据约定的x计算出要补全在K位信息码后的R位校验码，然后发送，接收方接收到数据之后通过约定好的x对收到的数据进行校验，即可查验在数据传输过程中有否出错。
另外相比较NSUserDefaults还需要手动调用synchronize保存来说，MMKV为自动保存，无需手动调用同步。