一、前言：

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

二、对比

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

1、SharedPreferences

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值来表示写入是否成功。

2、Jetpack DataStore

谷歌官方对DataStore的定位：

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

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

Preferences DataStore：仅使用键存储和访问值数据。此实现不需要预定义的架构，并且不提供类型安全性。
Proto DataStore：将数据存储为自定义数据类型的实例。此实现要求您使用协议缓冲区（protobuf - PB协议）定义架构，但它提供类型安全性。

相对于SharedPreferences的优点：

DataStore 是基于 Flow 实现的，所以保证了在主线程的安全性
以事务方式处理更新数据，事务有四大特性（原子性、一致性、隔离性、持久性）
没有 apply() 和 commit() 等数据持久的方法
自动完成 SharedPreferences 迁移到 DataStore，保证数据一致性，不会造成数据损坏
可以监听到操作成功或者失败结果

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

图片.png

3、MMKV

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