介绍:
在官方尚未出手之前,存储键值对等小型数据集可能普遍采用两种方式,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可能会抛出异常。 同时还有两点需要注意:
- 在transform执行完之前,在transform里改变的值并不会马上更新到DataStore,执行完才会,所以在edit()函数成功返回之前不要认为数据已经写入成功。
- 不要保存在transform中提供的MutablePreferences的引用,在transform外的对preferences操作并不会更新到DataStore,因为这很明显破坏了原设计的原子性与事务性。
总结:
总的来说还是很推荐使用DataStore,与协程的搭配,用起来也是非常的便利,至于PB协议的ProtoDataStore,可以参考官方的示例来实践,差别主要是还是集中在PB文件的处理。
作者:Lowae
链接:https://juejin.cn/post/7109395564789235720
网友评论