FastKV：一个真的很快的KV存储组件，kotlin协程池

• 读取相对较慢

SP在加载的时候已经将value反序列化存在HashMap中了，读取的时候索引到之后就能直接引用了。

而MMKV每次读取时都需要重新解码，除了时间上的消耗之外，还需要每次都创建新的对象。

不过这不是大问题，相对SP没有差很多。

• 需要引入so, 增加包体积

引入MMKV需要增加的体积还是不少的，且不说jar包和aidl文件，光是一个arm64-v8a的so就有四百多K。

虽然说现在APP体积都不小，但毕竟增加体积对打包、分发和安装时间都多少有些影响。

• 文件只增不减

MMKV的扩容策略还是比较激进的，而且扩容之后不会主动trim size。

比方说，假如有一个大value，让其扩容至1M，后面删除该value，哪怕有效内容只剩几K，文件大小还是保持在1M。

• 可能会丢失数据

前面的问题总的来说都不是什么“要紧”的问题，但是这个丢失数据确实是硬伤。

MMKV官方有这么一段表述：

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

这个表述对一半不对一半。

如果数据完成写入到内存块，如果系统不崩溃，即使进程崩溃，系统也会将buffer刷入磁盘；

但是如果在刷入磁盘之前发生系统崩溃或者断电等，数据就丢失了，不过这种情况发生的概率不大；

另一种情况是数据写一半的时候进程崩溃或者被杀死，然后系统会将已写入的部分刷入磁盘，再次打开时文件可能就不完整了。

例如，MMKV在剩余空间不足时会回收无效的空间，如果这期间进程中断，数据可能会不完整。 MMKV官方的说明可以佐证：

CRC校验失败之后，MMKV有两种应对策略：直接丢弃所有数据，或者尝试读取数据（用