Android Jetpack之DataStore指南

介绍：

在官方尚未出手之前，存储键值对等小型数据集可能普遍采用两种方式，SharedPreferences或是MMKV（如果您需要支持大型或复杂数据集、部分更新或参照完整性，请考虑使用 Room，而不是 DataStore。DataStore 非常适合简单的小型数据集，不支持部分更新或参照完整性。） MMKV这次暂时不提及，因为DatStore本身对比的也就是SharedPreferences，而且官方也是明确的建议我们迁移到DataStore。 DataStore包含了两种实现方式：

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

与SharedPreferences的对比：

首先我们来看官方的一张对比

功能	SharedPreferences	PreferencesDataStore	ProtoDataStore
异步 API	✅（仅用于通过监听器读取已更改的值）	✅（通过 Flow 以及 RxJava 2 和 3 Flowable）	✅（通过 Flow 以及 RxJava 2 和 3 Flowable）
同步 API	✅（但无法在界面线程上安全调用）	❌	❌
可在界面线程上安全调用	❌1	✅（这项工作已在后台移至 Dispatchers.IO）	✅（这项工作已在后台移至 Dispatchers.IO）
可以提示错误	❌	✅	✅
不受运行时异常影响	❌2	✅	✅
包含一个具有强一致性保证的事务性 API	❌	✅	✅
处理数据迁移	❌	✅	✅
类型安全	❌	❌	✅ 使用协议缓冲区

我们先暂时只看PreferencesDataStore和SharedPreferences 首先同步API和异步API这两点区别是没有问题的。 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值来表示写入是否成功。

详细的可以查看SharedPreferences.Editor接口提供的注释，具体的实现在SharedPreferencesImpl.EditorImpl我这里就不贴源码了。 回到DataStore，PreferencesDataStore本身是基于携程Flow来实现的，所以异步API这点没有任何问题，不过至于同步的使用方式，放到后面来说，我们先看普遍的异步使用方式。我就不一一复述了。

使用：

private const val USER_PREFERENCES_NAME = "user_preferences"

private val Context.dataStore by preferencesDataStore(
    name = USER_PREFERENCES_NAME
)

首先是通过委托拿到DataStore<Preferences>单例.

public fun preferencesDataStore(
    name: String,
    corruptionHandler: ReplaceFileCorruptionHandler<Preferences>? = null,
    produceMigrations: (Context) -> List<DataMigration<Preferences>> = { listOf() },
    scope: CoroutineScope = CoroutineScope(Dispatchers.IO + SupervisorJob())
): ReadOnlyProperty<Context, DataStore<Preferences>> {
    return PreferenceDataStoreSingletonDelegate(name, corruptionHandler, produceMigrations, scope)
}

internal class PreferenceDataStoreSingletonDelegate internal constructor(
    private val name: String,
    private val corruptionHandler: ReplaceFileCorruptionHandler<Preferences>?,
    private val produceMigrations: (Context) -> List<DataMigration<Preferences>>,
    private val scope: CoroutineScope
) : ReadOnlyProperty<Context, DataStore<Preferences>> {

    private val lock = Any()

    @GuardedBy("lock")
    @Volatile
    private var INSTANCE: DataStore<Preferences>? = null

    override fun getValue(thisRef: Context, property: KProperty<*>): DataStore<Preferences> {
        return INSTANCE ?: synchronized(lock) {
            if (INSTANCE == null) {
                val applicationContext = thisRef.applicationContext

                INSTANCE = PreferenceDataStoreFactory.create(
                    corruptionHandler = corruptionHandler,
                    migrations = produceMigrations(applicationContext),
                    scope = scope
                ) {
                    applicationContext.preferencesDataStoreFile(name)
                }
            }
            INSTANCE!!
        }
    }
}

本质上还是走的PreferenceDataStoreFactory.create()创建，是一个非常标准的双重检查锁单例。 来看一下create()函数的参数吧

• corruptionHandler: 异常处理，当反序列化错误时会走到这，可以用于读取错误是返回默认值或捕获异常。
• migrations: 用于迁移SharedPreferences到PreferenceDataStore
• scope: 协程的作用域，指定IO操作及数据转换的执行的协程作用域
• produceFile: 基于提供的Context和name创建或读取对应的文件，默认路径为this.applicationContext.filesDir + datastore/fileName

推荐做法也是通过PreferenceDataStoreFactory来创建DataStore实例并作为单例注入需要它的类中。

读取：

dataStore.data
    .catch { exception ->
        // 有异常抛出
        if (exception is IOException) {
        // 使用默认空值
            emit(emptyPreferences())
        } else {
        // 其他异常则继续抛出
            throw exception
        }
    }.map { preferences ->
        // 数据转化
    }.collect {
        // 收集数据
    }

emptyPreferences()可以参考上面提到的官方教学示例，里面会详细介绍PreferenceData的KV 可以看出dataStore返回的是一个Flow，你可以很方便的转换成你所需要的数据。

写入：

val INT_KEY = intPreferencesKey("int_key")
dataStore.edit { preferences ->
    preferences[INT_KEY] = 1
}

// 调用
public suspend fun DataStore<Preferences>.edit(
    transform: suspend (MutablePreferences) -> Unit
): Preferences {
    return this.updateData {
        // It's safe to return MutablePreferences since we freeze it in
        // PreferencesDataStore.updateData()
        it.toMutablePreferences().apply { transform(this) }
    }
}

直接调用edit函数，不过要注意的是edit可能会抛出异常。 同时还有两点需要注意：

1. 在transform执行完之前，在transform里改变的值并不会马上更新到DataStore，执行完才会，所以在edit()函数成功返回之前不要认为数据已经写入成功。
2. 不要保存在transform中提供的MutablePreferences的引用，在transform外的对preferences操作并不会更新到DataStore，因为这很明显破坏了原设计的原子性与事务性。

总结：

总的来说还是很推荐使用DataStore，与协程的搭配，用起来也是非常的便利，至于PB协议的ProtoDataStore，可以参考官方的示例来实践，差别主要是还是集中在PB文件的处理。

作者：Lowae
链接：https://juejin.cn/post/7109395564789235720