sharedpreferences 重启不保存_MMKV为什么可以替换SharedPreferences

MMKV介绍

MMKV——基于 mmap 的高性能通用 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。
https://github.com/Tencent/MMKV/blob/master/readme_cn.md

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

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

XML、JSON 更注重数据结构化，关注人类可读性和语义表达能力。
ProtoBuf 更注重数据序列化，关注效率、空间、速度，人类可读性差，语义表达能力不足(为保证极致的效率，会舍弃一部分元信息)

MMKV特点

1.高性能

可以支持实时写入

2.稳定性非常好

3.多进程访问

通过与 Android 开发同学的沟通，了解到系统自带的 SharedPreferences 对多进程的支持不好。
现有基于 ContentProvider 封装的实现，虽然多进程是支持了，但是性能低下，经常导致 ANR。
考虑到 mmap 共享内存本质上的多进程共享的，我们在这个基础上，深入挖掘了 Android 系统的能力，提供了可能是业界最高效的多进程数据共享组件。

4.匿名内存

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

5.数据加密

不像 iOS 提供了硬件层级的加密机制，在 Android 环境里，数据加密是非常必须的。
MMKV 使用了 AES CFB-128 算法来加密/解密。我们选择 CFB 而不是常见的 CBC 算法，
主要是因为 MMKV 使用 append-only 实现插入/更新操作，流式加密算法更加合适。

6.数据有效性

考虑到文件系统、操作系统都有一定的不稳定性，我们另外增加了 crc 校验，对无效数据进行甄别。

MMKV 原理

1.内存准备

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

2.数据组织

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

3.写入优化

考虑到主要使用场景是频繁地进行写入更新，我们需要有增量更新的能力。我们考虑将增量 kv 对象序列化后，append 到内存末尾。
这样同一个 key 会有新旧若干份数据，最新的数据在最后；那么只需在程序启动第一次打开 mmkv 时，不断用后读入的 value 替换之前的值，就可以保证数据是最新有效的。

4.空间增长

使用 append 实现增量更新带来了一个新的问题，就是不断 append 的话，文件大小会增长得不可控。我们需要在性能和空间上做个折中。
以内存 pagesize 为单位申请空间，在空间用尽之前都是 append 模式；当 append 到文件末尾时，进行文件重整、key 排重，尝试序列化保存排重结果；
排重后空间还是不够用的话，将文件扩大一倍，直到空间足够。

5.数据有效性

考虑到文件系统、操作系统都有一定的不稳定性，我们另外增加了 crc 校验，对无效数据进行甄别。

详细的原理请参考:https://github.com/Tencent/MMKV/wiki/design

MMKV集成

1.依赖注入

在 App 模块的 build.gradle 文件里添加:

dependencies {
    implementation 'com.tencent:mmkv-static:1.2.2'
    // replace "1.2.2" with any available version
}

Gradle 在编译工程的时候会自动从 maven 仓库下载 AAR 包。

MMKV 默认以静态库形式链接 libc++。这个库如果动态链接，会额外占用 2MB 空间(解压后)。如果你已经有其他库引入了 libc++_shared.so，并且你确保他们的库没有版本兼容问题，你可以使用动态链接 libc++ 的 MMKV，以进一步减少安装包大小：

dependencies {
    implementation 'com.tencent:mmkv:1.2.2'
    // replace "1.2.2" with any available version
}

2.初始化

// 设置初始化的根目录
String dir = getFilesDir().getAbsolutePath() + "/mmkv_2";
String rootDir = MMKV.initialize(dir);
Log.i("MMKV", "mmkv root: " + rootDir);

3.获取实例

// 获取默认的全局实例
MMKV kv = MMKV.defaultMMKV();

// 根据业务区别存储, 附带一个自己的 ID
MMKV kv = MMKV.mmkvWithID("MyID");

// 多进程同步支持
MMKV kv = MMKV.mmkvWithID("MyID", MMKV.MULTI_PROCESS_MODE);

4.具体操作

// 添加/更新数据
kv.encode(key, value);

// 获取数据
int tmp = kv.decodeInt(key);

// 删除数据
kv.removeValueForKey(key);

5.SharedPreferences迁移

private void testImportSharedPreferences() {
    MMKV mmkv = MMKV.mmkvWithID("myData");
    SharedPreferences old_man = getSharedPreferences("myData", MODE_PRIVATE);
// 迁移旧数据
    mmkv.importFromSharedPreferences(old_man);
// 清空旧数据
    old_man.edit().clear().commit();
    ......
}

详细的集成文档请参考:https://github.com/Tencent/MMKV/wiki/android_setup_cn

性能测试

以下是 MMKV、SharedPreferences 和 SQLite 同步写入 1000 条数据的测试结果

// MMKV
MMKV write int: loop[1000]: 12 ms
MMKV read int: loop[1000]: 3 ms

MMKV write String: loop[1000]: 7 ms
MMKV read String: loop[1000]: 4 ms

// SharedPreferences
SharedPreferences write int: loop[1000]: 119 ms
SharedPreferences read int: loop[1000]: 3 ms

SharedPreferences write String: loop[1000]: 187
SharedPreferences read String: loop[1000]: 2 ms

// SQLite
sqlite write int: loop[1000]: 101 ms
sqlite read int: loop[1000]: 136 ms

sqlite write String: loop[1000]: 29 ms
sqlite read String: loop[1000]: 93 ms

可以看到 MMKV 无论是对比 SP 还是 SQLite, 在性能上都有非常大的优势, 官方提供的数据测试结果如下

1.单进程性能

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

2.多进程性能

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

核心原理

Linux的内存分用户空间跟内核空间，同时页表有也分两类，用户空间页表跟内核空间页表，每个进程有一个用户空间页表，但是系统只有一个内核空间页表。
而Binder mmap的关键：更新用户空间对应的页表的同时也同步映射内核页表，让两个页表都指向同一块地址。
这样一来，数据只需要从A进程的用户空间，直接拷贝到B所对应的内核空间，而B多对应的内核空间在B进程的用户空间也有相应的映射，这样就无需从内核拷贝到用户空间了。

copy_from_user() //将数据从用户空间拷贝到内核空间
copy_to_user() //将数据从内核空间拷贝到用户空间

mmap VS 普通文件IO

1.普通文件IO

通过read/write系统调访问，先在用户空间分配一段buffer，然后，进入内核，将内容从磁盘读取到内核缓冲，最后，拷贝到用户进程空间，至少牵扯到两次数据拷贝；
同时，多个进程同时访问一个文件，每个进程都有一个副本，存在资源浪费的问题。

2.mmap

通过mmap来访问文件，mmap()将文件直接映射到用户空间，文件在mmap的时候，内存并未真正分配，
只有在第一次读取/写入的时候才会触发，这个时候，会引发缺页中断，在处理缺页中断的时候，完成内存也分配，同时也完成文件数据的拷贝。
并且，修改用户空间对应的页表，完成到物理内存到用户空间的映射，这种方式只存在一次数据拷贝，效率更高。
同时多进程间通过mmap共享文件数据的时候，仅需要一块物理内存就够了。

Android中使用mmap，可以通过RandomAccessFile与MappedByteBuffer来配合。
通过randomAccessFile.getChannel().map获取到MappedByteBuffer。然后调用ByteBuffer的put方法添加数据。

RandomAccessFile randomAccessFile = new RandomAccessFile("path","rw");
MappedByteBuffer mappedByteBuffer= randomAccessFile.getChannel().map(FileChannel.MapMode.READ_WRITE,0, randomAccessFile.length());

mappedByteBuffer.putChar('c');
mappedByteBuffer.getChar();

总结

通过上面的分析, 我们对 MMKV 有了一个整体上的把控, 其具体的表现如下所示

项目	评价	描述
正确性	优	支持多进程安全, 使用 mmap, 由操作系统保证数据回写的正确性
时间开销	优	使用 mmap 实现, 减少了用户空间数据到内核空间的拷贝
空间开销	中	使用 protocl buffer 存储数据, 同样的数据会比 xml 和 json 消耗空间小,使用的是数据追加到末尾的方式, 只有到达一定阈值之后才会触发键值合并, 不合并之前会导致同一个 key 存在多份
安全	中	使用 crc 校验, 甄别文件系统和操作系统不稳定导致的异常数据
开发成本	优	使用方式较为简单
兼容性	优	各个安卓版本都前后兼容

虽然 MMKV 一些场景下比 SP 稍慢(如: 首次实例化会进行数据的复写剔除重复数据, 比 SP 稍慢, 查询数据时存在 ProtocolBuffer 解码, 比 SP 稍慢), 但其逆天的数据写入速度、mmap Linux 内核保证数据的同步, 以及 ProtocolBuffer 编码带来的更小的本地存储空间占用等都是非常棒的闪光点。

参考文献：

https://www.jianshu.com/p/65334d245bc4

https://blog.csdn.net/gpf1320253667/article/details/91352887

https://github.com/Tencent/MMKV/releases