Android键值对存储方案最优解？

Android开发中对于轻量的键值对存储需求，通常我们会考虑采用SharedPreferences或是MMKV，今天和大家分享关于谷歌官方推荐用于替换sp的解决方案DataStore。

下面我们依次看一下三个方案

apply()来完成异步操作：会立即更改内存中的 SharedPreferences 对象，但会将更新异步写入磁盘。而且apply()还有个问题就是，虽然他本身是异步的来完成IO操作，但是在SharedPreferencesImpl.EditorImpl.apply()中会添加到QueuedWork中，当Service或者Activity启动或停止时，具体可见ActivityThread中handleServiceArgs，handleStopService，handlePauseActivity，handleStopActivity均会执行QueuedWork.waitToFinish()等待数据写入的完成，因为要保证数据不会丢失，但是我们也知道，onPause() 是不适合执行耗时操作的，因为当你期待另一个Activity的时候，会先onPause当前Activity，这很明显，假如你写入了较多内容，然后立马启动了另一个Activity，结果在onPause()被阻塞，就很容易导致ANR。
commit()来实现同步操作，但应避免从主线程调用它，因为它可能会阻塞UI线程，这点没什么好说的，而且会返回Boolean值来表示写入是否成功。

谷歌官方对DataStore的定位：

以异步、一致的事务方式存储数据，克服了 SharedPreferences 的一些缺点

DataStore 基于 Kotlin 协程和流程构建而成，DataStore包含了两种实现方式：

相对于SharedPreferences的优点：

Google 分析的 SharedPreferences 和 DataStore 的区别的一张图：

内存准备通过 mmap 内存映射文件，提供一段可供随时写入的内存块，App 只管往里面写数据，由操作系统负责将内存回写到文件，不必担心 crash 导致数据丢失。
数据组织数据序列化方面我们选用 protobuf 协议，pb 在性能和空间占用上都有不错的表现。
写入优化考虑到主要使用场景是频繁地进行写入更新，我们需要有增量更新的能力。我们考虑将增量 kv 对象序列化后，append 到内存末尾。
空间增长使用 append 实现增量更新带来了一个新的问题，就是不断 append 的话，文件大小会增长得不可控。我们需要在性能和空间上做个折中。

性能对比：