1. SharedPreferences

SharedPreference 是一个轻量级的数据存储方式，使用起来也非常方便，以键值对的形式存储在本地，初始化 SharedPreference 的时候，会将整个文件内容加载内存中，因此会带来以下问题：

通过 getXXX() 方法获取数据，可能会导致主线程阻塞
SharedPreference 不能保证类型安全
SharedPreference 加载的数据会一直留在内存中，浪费内存
XML格式，全量写入方式，I/O效率低
apply 方法虽然是异步提交，但是仍然可能会导致 ANR
apply 方法无法获取到操作结果
不能用于跨进程

接下来我们逐个来分析一下 SharedPreferences 带来的这些问题，在文章中 SharedPreference 简称 SP。

getXXX() 方法可能会导致主线程阻塞

所有 getXXX() 方法都是同步的，在主线程调用 get 方法，必须等待 SP 加载完毕，会导致主线程阻塞，下面的代码，我相信小伙伴们并不陌生。

val sp = getSharedPreferences("ByteCode", Context.MODE_PRIVATE) // 异步加载 SP 文件内容  
sp.getString("jetpack", ""); // 等待 SP 加载完毕

调用 getSharedPreferences() 方法，最终会调用 SharedPreferencesImpl#startLoadFromDisk() 方法开启一个线程异步读取数据。

frameworks/base/core/java/android/app/SharedPreferencesImpl.java

private final Object mLock = new Object();  
private boolean mLoaded = false;  
private void startLoadFromDisk() {  
    synchronized (mLock) {  
        mLoaded = false;  
    }  
    new Thread("SharedPreferencesImpl-load") {  
        public void run() {  
            loadFromDisk();  
        }  
    }.start();  
}

正如你所看到的，开启一个线程异步读取数据，当我们正在读取一个比较大的数据，还没读取完，接着调用 getXXX() 方法。

public String getString(String key, @Nullable String defValue) {  
    synchronized (mLock) {  
        awaitLoadedLocked();  
        String v = (String)mMap.get(key);  
        return v != null ? v : defValue;  
    }  
}  
  
private void awaitLoadedLocked() {  
    ......  
    while (!mLoaded) {  
        try {  
            mLock.wait();  
        } catch (InterruptedException unused) {  
        }  
    }  
    ......  
}

在同步方法内调用了 wait() 方法，会一直等待 getSharedPreferences() 方法开启的线程读取完数据才能继续往下执行，如果读取几 KB 的数据还好，假设读取一个大的文件，势必会造成主线程阻塞。

SP 不能保证类型安全

调用 getXXX() 方法的时候，可能会出现 ClassCastException 异常，因为使用相同的 key 进行操作的时候，putXXX 方法可以使用不同类型的数据覆盖掉相同的 key。

val key = "jetpack"  
val sp = getSharedPreferences("ByteCode", Context.MODE_PRIVATE) // 异步加载 SP 文件内容  
  
sp.edit { putInt(key, 0) } // 使用 Int 类型的数据覆盖相同的 key  
sp.getString(key, ""); // 使用相同的 key 读取 Sting 类型的数据

使用 Int 类型的数据覆盖掉相同的 key，然后使用相同的 key 读取 Sting 类型的数据，编译正常，但是运行会出现以下异常。

java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String

SP 加载的数据会一直留在内存中

通过 getSharedPreferences() 方法加载的数据，最后会将数据存储在静态的成员变量中。

// 调用 getSharedPreferences 方法，最后会调用 getSharedPreferencesCacheLocked 方法  
public SharedPreferences getSharedPreferences(File file, int mode) {  
    ......  
    final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();  
    return sp;  
}  
  
// 通过静态的 ArrayMap 缓存 SP 加载的数据  
private static ArrayMap<String, ArrayMap<File, SharedPreferencesImpl>> sSharedPrefsCache;  
  
// 将数据保存在 sSharedPrefsCache 中  
private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() {  
    ......  
  
    ArrayMap<File, SharedPreferencesImpl> packagePrefs = sSharedPrefsCache.get(packageName);  
    if (packagePrefs == null) {  
        packagePrefs = new ArrayMap<>();  
        sSharedPrefsCache.put(packageName, packagePrefs);  
    }  
  
    return packagePrefs;  
}

通过静态的 ArrayMap 缓存每一个 SP 文件，而每个 SP 文件内容通过 Map 缓存键值对数据，这样数据会一直留在内存中，浪费内存。

SP 不能用于跨进程通信

我们在创建 SP 实例的时候，需要传入一个 mode，如下所示：

val sp = getSharedPreferences("ByteCode", Context.MODE_PRIVATE)

Context 内部还有一个 mode 是 MODE_MULTI_PROCESS，我们来看一下这个 mode 做了什么

public SharedPreferences getSharedPreferences(File file, int mode) {  
    if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||  
        getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {  
        // 重新读取 SP 文件内容  
        sp.startReloadIfChangedUnexpectedly();  
    }  
    return sp;  
}

在这里就做了一件事，当遇到 MODE_MULTI_PROCESS 的时候，会重新读取 SP 文件内容，并不能用 SP 来做跨进程通信。

2. Jetpack DataStore

Google 在Jetpack 中提供了一个全新的轻量级数据存储方案 DataStore，并提供有两种实现方式：

Proto DataStore：存储类的对象（typed objects ），通过 protocol buffers 将对象序列化存储在本地，protocol buffers 现在已经应用的非常广泛，无论是微信还是阿里等等大厂都在使用，我们在部分业务场景中也用到了 protocol buffers，会在后续的文章详细分析
Preferences DataStore：以键值对的形式存储在本地和 SharedPreferences 类似，但是 DataStore 是基于 Flow 实现的，不会阻塞主线程，并且保证类型安全

其中 Preferences DataStore 主要用来替换 SharedPreferences，解决了许多 SP 所带来的问题。

Preferences DataStore 的优点：

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

Preferences DataStore 的缺点：

DataStore 是基于 Flow 实现的，需要 Kotlin支持，而额外提供的 RxJava API 的核心方法目前被标注为实验性方法
不支持跨进程访问

创建 Preferences DataStore

使用由 preferencesDataStore 创建的属性委托来创建 Datastore<Preferences> 实例。在您的 Kotlin 文件顶层调用该实例一次，便可在应用的所有其余部分通过此属性访问该实例。这样可以更轻松地将 DataStore 保留为单例。此外，如果您使用的是 RxJava，请使用 RxPreferenceDataStoreBuilder。必需的 name 参数是 Preferences DataStore 的名称。

RxDataStore<Preferences> dataStore =
  new RxPreferenceDataStoreBuilder(context, /*name=*/ "settings").build();

从 Preferences DataStore 读取内容

由于 Preferences DataStore 不使用预定义的架构，因此您必须使用相应的键类型函数为需要存储在 DataStore<Preferences> 实例中的每个值定义一个键。例如，如需为 int 值定义一个键，请使用 intPreferencesKey()。然后，使用 DataStore.data 属性，通过 Flow 提供适当的存储值。

Preferences.Key<Integer> EXAMPLE_COUNTER = PreferencesKeys.int("example");

Flowable<Integer> exampleCounterFlow =  dataStore.data().map(prefs -> prefs.get(EXAMPLE_COUNTER));

将内容写入 Preferences DataStore

Preferences DataStore 提供了一个 edit() 函数，用于以事务方式更新 DataStore 中的数据。该函数的 transform 参数接受代码块，您可以在其中根据需要更新值。转换块中的所有代码均被视为单个事务。

Single<Preferences> updateResult =  dataStore.updateDataAsync(prefsIn -> {
  MutablePreferences mutablePreferences = prefsIn.toMutablePreferences();
  Integer currentInt = prefsIn.get(INTEGER_KEY);
  mutablePreferences.set(INTEGER_KEY, currentInt != null ? currentInt + 1 : 1);
  return Single.just(mutablePreferences);
});

使用 Proto DataStore 存储类型化的对象

Proto DataStore 实现使用 DataStore 和协议缓冲区将类型化的对象保留在磁盘上。

定义架构

Proto DataStore 要求在 app/src/main/proto/ 目录的 proto 文件中保存预定义的架构。此架构用于定义您在 Proto DataStore 中保存的对象的类型

syntax = "proto3";

option java_package = "com.example.application";
option java_multiple_files = true;

message Settings {
  int32 example_counter = 1;
}

创建 Proto DataStore

创建 Proto DataStore 来存储类型化对象涉及两个步骤：

定义一个实现 Serializer<T> 的类，其中 T 是 proto 文件中定义的类型。此序列化器类会告知 DataStore 如何读取和写入您的数据类型。请务必为该序列化器添加默认值，以便在尚未创建任何文件时使用。
使用由 dataStore 创建的属性委托来创建 DataStore<T> 的实例，其中 T 是在 proto 文件中定义的类型。在您的 Kotlin 文件顶层调用该实例一次，便可在应用的所有其余部分通过此属性委托访问该实例。filename 参数会告知 DataStore 使用哪个文件存储数据，而 serializer 参数会告知 DataStore 第 1 步中定义的序列化器类的名称。

private static class SettingsSerializer implements Serializer<Settings> {
  @Override
  public Settings getDefaultValue() {
    Settings.getDefaultInstance();
  }

  @Override
  public Settings readFrom(@NotNull InputStream input) {
    try {
      return Settings.parseFrom(input);
    } catch (exception: InvalidProtocolBufferException) {
      throw CorruptionException(“Cannot read proto.”, exception);
    }
  }

  @Override
  public void writeTo(Settings t, @NotNull OutputStream output) {
    t.writeTo(output);
  }
}

RxDataStore<Byte> dataStore =
    new RxDataStoreBuilder<Byte>(context, /* fileName= */ "settings.pb", new SettingsSerializer()).build();

从 Proto DataStore 读取内容

使用 DataStore.data 显示所存储对象中相应属性的 Flow。

Flowable<Integer> exampleCounterFlow =
  dataStore.data().map(settings -> settings.getExampleCounter());

将内容写入 Proto DataStore

Proto DataStore 提供了一个 updateData() 函数，用于以事务方式更新存储的对象。updateData() 为您提供数据的当前状态，作为数据类型的一个实例，并在原子读-写-修改操作中以事务方式更新数据。

Single<Settings> updateResult =
  dataStore.updateDataAsync(currentSettings ->
    Single.just(
      currentSettings.toBuilder()
        .setExampleCounter(currentSettings.getExampleCounter() + 1)
        .build()));

在同步代码中使用 DataStore

DataStore 的主要优势之一是异步 API，但可能不一定始终能将周围的代码更改为异步代码。如果您使用的现有代码库采用同步磁盘 I/O，或者您的依赖项不提供异步 API，就可能出现这种情况。

Kotlin 协程提供 runBlocking() 协程构建器，以帮助消除同步与异步代码之间的差异。您可以使用 runBlocking() 从 DataStore 同步读取数据。RxJava 在 Flowable 上提供阻塞方法。以下代码会阻塞发起调用的线程，直到 DataStore 返回数据：

Settings settings = dataStore.data().blockingFirst();

对界面线程执行同步 I/O 操作可能会导致 ANR 或界面卡顿。您可以通过从 DataStore 异步预加载数据来减少这些问题：

dataStore.data().first().subscribe();

这样，DataStore 可以异步读取数据并将其缓存在内存中。以后使用 runBlocking() 进行同步读取的速度可能会更快，或者如果初始读取已经完成，可能也可以完全避免磁盘 I/O 操作。

在多进程代码中使用 DataStore

DataStore 多进程功能目前仅在 1.1.0 Alpha 版中提供,目前不稳定版本。这里不再阐述。

3. Tencent MMKV

MMKV 是腾讯开源的基于 mmap 内存映射的 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。从 2015 年中至今在微信上使用，其性能和稳定性经过了时间的验证。

特点：

实现了 SharedPreferences 接口，可以无缝切换
通过 mmap 内存映射文件，提供一段可供随时写入的内存块，App 只管往里面写数据，由操作系统负责将内存回写到文件，不必担心 crash 导致数据丢失
数据序列化方面选用 protobuf 协议，pb 在性能和空间占用上都有不错的表现
SP是全量更新，MMKV是增量更新，有性能优势
支持多进程共享
支持类型：boolean、int、long、float、double、byte[]、String、Set、Parcelable

集成

依赖注入

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

dependencies { implementation 'com.tencent:mmkv:1.0.22'

初始化

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

获取实例

// 获取默认的全局实例 
MMKV kv = MMKV.defaultMMKV(); 
// 根据业务区别存储, 附带一个自己的 
ID MMKV kv = MMKV.mmkvWithID("MyID"); 
// 多进程同步支持 
MMKV kv = MMKV.mmkvWithID("MyID", MMKV.MULTI_PROCESS_MODE);

CURD

// 添加/更新数据 
kv.encode(key, value); 
// 获取数据 
int tmp = kv.decodeInt(key); 
// 删除数据 
kv.removeValueForKey(key);

SP 的迁移

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

原理

为什么MMKV写入速度更快

我们知道，SP是写入是基于IO操作的，为了了解IO，我们需要先了解下用户空间与内核空间
虚拟内存被操作系统划分成两块：用户空间和内核空间，用户空间是用户程序代码运行的地方，内核空间是内核代码运行的地方。为了安全，它们是隔离的，即使用户的程序崩溃了，内核也不受影响。

写文件流程:

1、调用write，告诉内核需要写入数据的开始地址与长度。

2、内核将数据拷贝到内核缓存。

3、由操作系统调用，将数据拷贝到磁盘，完成写入。

MMAP

Linux通过将一个虚拟内存区域与一个磁盘上的对象关联起来，以初始化这个虚拟内存区域的内容，这个过程称为内存映射(memory mapping)。

640 (1).png 对文件进行mmap，会在进程的虚拟内存分配地址空间，创建映射关系。实现这样的映射关系后，就可以采用指针的方式读写操作这一段内存，而系统会自动回写到对应的文件磁盘上。

MMAP优势

1、MMAP对文件的读写操作只需要从磁盘到用户主存的一次数据拷贝过程，减少了数据的拷贝次数，提高了文件读写效率。

2、MMAP使用逻辑内存对磁盘文件进行映射，操作内存就相当于操作文件，不需要开启线程，操作MMAP的速度和操作内存的速度一样快。

3、MMAP提供一段可供随时写入的内存块，App 只管往里面写数据，由操作系统如内存不足、进程退出等时候负责将内存回写到文件，不必担心 crash 导致数据丢失。

MMAP写入方式

SP的数据结构

SP是使用XML格式存储数据的，如下所示。

640 (2).png 但是这也导致SP如果要更新数据的话，只能全量更新。

MMKV数据结构

640 (3).png MMKV使用Protobuf存储数据，冗余数据更少，更省空间，同时可以方便地在末尾追加数据。不管key是否重复，直接将数据追加在前数据后。这样效率更高，更新数据只需要插入一条数据即可。

当然这样也会带来问题，如果不断增量追加内容，文件越来越大，怎么办？

当文件大小不够，这时候需要全量写入。将数据去掉重复key后，如果文件大小满足写入的数据大小，则可以直接更新全量写入，否则需要扩容。（在扩容时根据平均每个K-V大小计算未来可能需要的文件大小进行扩容，防止经常性的全量写入）

总结

1、SharedPreferences 的 Api 使用很友好，数据改变时可以进行监听。但是它在 8.0 之前可能造成ANR（8.0之后优化了），而且不能跨进程。

2、DataStore 存在 Preferences DataStore 和 Proto DataStore 这两种方式，前者适合存储键值对的数据但是效率并不如 SharedPreferences（耗时是两倍左右），后者适合存储一些自定义的数据类型，DataStore 也可以在当数据改变可以进行监听，使用 Flow 以异步一致性方式存储数据，功能强大很多，但还是不能跨进程。 Proto DataStore 在复杂数据的存储上很有优势，当本地需要一些缓存数据对象，如果使用 Proto DataStore 能够快速获取整个对象（比如首页的缓存数据），然后进行数据加载这是很有优势的。

3、 MMKV 虽然不是官方出品的，但是在性能，速率，跨进程上面秒杀官方的两个数据存储方式。

Android轻量级存储方案