关于Jetpack DataStore(Preferences)的八点疑问
前言
DataStore是Android上一种轻量级存储方案，依据官方教程很容易就写出简易的Demo。
本篇主要是分析关于DataStore(Preferences)使用过程中的一些问题，通过问题寻找本质，反过来能更好地指导我们合理使用DataStore。
本篇内容目录：
1. DataStore如何存取数据？
DataStore有两种存储类型：Preferences(与SharedPreferences对标) 和 Proto。
为方便行文，以下所说的DataStore指的是Preferences类型。
引入依赖
在Module级别的build.gradle里引入：
implementation("androidx.datastore:datastore-preferences:1.0.0")
使用DataStore存取数据
存数据
- 先声明DataStore对象：
val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "test")
DataStore是key-value 结构，因此在存取数据之前先定义好key的名字以及value的类型。
- 声明key的结构
val myNameKey = stringPreferencesKey("name")
val myAgeKey = intPreferencesKey("age")
想要在DataStore里存储姓名和年龄，其中姓名是String类型，年龄是Int类型。
- 存储value
suspend fun saveData() {
context.dataStore.edit {
//给不同的key赋值
it[myNameKey] = "fish"
it[myAgeKey] = 18
}
}
取数据
suspend fun queryData() {
context.dataStore.data.collect {
it.asMap().forEach {
println("${it.key.name}, ${it.value}")
}
}
}
//打印结果：
I/System.out: name, fish
I/System.out: age, 18
可以看出存取过程和SharedPreferences很相似，只是key的构造有些差异。
2. DataStore能存放哪些类型数据？
上面在构造DataStore的Key时，我们使用了两个函数：
stringPreferencesKey与intPreferencesKey，其中前缀指明了存储的value是什么类型。
实际上还有其它类型的value：
可以看出有7种类型：
Boolean、Double、Float、Int、Long、String、Set
3. DataStore存取是否耗时？
在存储数据时，我们都依赖于：
dataStore.data
而它是Flow类型：
而Flow必须要在协程里使用，因此我们使用了挂起函数(suspend)修饰存取函数。
同时我们也知道，挂起函数并不耗时。
当在主线程里分别调用DataStore的存取函数，并不会阻塞主线程。
值得注意的是：
- 存取数据的闭包的执行是在当前协程(调用saveData/queryData的协程)里执行的
- 假若当前是在主线程发起的存取动作，那么闭包将在主线程执行
总的来说：借助于协程的特性，DataFlow存取数据并不耗时。
4. DataStore Flow是如何设计的？
DataStore Flow是冷流还是热流？
先看DataStore的实现，主要依靠：SingleProcessDataStore。
在里面找到dataStore.data的定义：
//定义热流
private val downstreamFlow = MutableStateFlow(UnInitialized as State<T>)
override val data: Flow<T> = flow {
val currentDownStreamFlowState = downstreamFlow.value
if (currentDownStreamFlowState !is Data) {
actor.offer(SingleProcessDataStore.Message.Read(currentDownStreamFlowState))
}
emitAll(
//监听热流变化
downstreamFlow.dropWhile {
//满足条件则丢弃数据
if (currentDownStreamFlowState is Data<T> ||
currentDownStreamFlowState is Final<T>
) {
//不满足则继续流向map
false
} else {
//判断是否满足
it === currentDownStreamFlowState
}
}.map {
when (it) {
//根据类型，返回不同的值
is ReadException<T> -> throw it.readException
is Final<T> -> throw it.finalException
//正常的返回值
is Data<T> -> it.value
is UnInitialized -> error(
"This is a bug in DataStore. Please file a bug at: " +
"https://issuetracker.google.com/issues/new?" +
"component=907884&template=1466542"
)
}
}
)
}
可以看出：
- dataStore.data 是Flow，它是冷流
- dataStore.data 里依靠downstreamFlow(热流)持续监听数据的变化
- 因此dataStore.data 可以持续监听数据的变化，当DataStore里数据发生变化时将会回调闭包
DataStore Flow与其它Flow的差异
先看普通的flow：
suspend fun queryData2() {
val flow = flow {
emit("hello")
}
flow.collect {
println(it)
}
println("normal flow end")
}
大家猜测一下："normal flow end"会打印吗？
再看DataStore的Flow：
suspend fun queryData() {
context.dataStore.data.collect {
it.asMap().forEach {
println("${it.key.name}, ${it.value}")
}
}
println("dataStore flow end")
}
再猜一下："dataStore flow end"会打印吗？
答案是：
"normal flow end"会打印，而"dataStore flow end"永远没有机会执行
原因是DataStore Flow里依赖了热流监听数据，而热流的collect是不会退出的。
其实这也很容易想到：若是DataStore Flow的collect退出了，它就无法监听数据变化了。
5. DataStore 刷新范围？
存取影响范围
我们已经知道DataStore Flow可以监听数据的变化，假设我们一个文件里存放了很多对Key–Value，但是我们只关心其中一个或是某几个Key–Value的变化，比如现在新增一个key="score"字段：
val myScoreKey = floatPreferencesKey("score")
suspend fun queryDataV2() {
context.dataStore.data.map {
//只关心分数的变化
it[myScoreKey]
}..collect {
println("$it")
}
}
suspend fun saveData2() {
context.dataStore.edit {
//只修改分数
it[myScoreKey] = 99f
}
}
虽然文件了存放了三个字段：name、age、score，但是我们只更新了score字段，并且也仅仅监听score字段的变化。
那么问题来了：单个设置/监听某个字段会提升效率吗？
答案是：不会，因为DataStore的更新是基于单个文件的全量更新，也就是说虽然只是更改了score字段的值，写入文件的时候name/age字段值也会写入
我们换个写法来进行测试：
suspend fun saveData2() {
context.dataStore.edit {
//只修改分数
it[myNameKey] = "fish is perfect"
}
}
现在只是更改name字段，最后发现只监听了score变化的闭包也调用了。
小结：
DataStore更新和监听都是针对单个文件的全部字段
存相同的数值
还是以保存name为例：
suspend fun saveData2() {
context.dataStore.edit {
//只修改分数
it[myNameKey] = "fish is perfect"
}
}
当调用这函数两次。
问题：第二次调用的时候，还有会写文件的动作吗？
答案：不会，因为每次更新数据之前都会比对和上一次的数据是否一致，若是一致则不会再写入文件，当然也不会产生数据变化的通知
6. DataStore是线程安全的吗？
先看Demo：
suspend fun saveData2() {
context.dataStore.edit {
//只修改分数
it[myNameKey] = "fish is perfect3"
}
}
GlobalScope.launch(Dispatchers.IO) {
myDataStore.saveData2()
}
GlobalScope.launch(Dispatchers.Main) {
myDataStore.saveData2()
}
同时在子线程和主线程去更新DataStore的内容，这样合理吗？会有线程安全的问题产生吗？
答案：合理的、可行的，因为DataStore的读写是线程安全的
- 不管是读还是写，每次调用当做一次任务，若当前没有协程执行任务，则开启新协程执行任务，新协程跑在IO线程里
- 若是有任务在执行，则仅仅只是将任务加入到队列里，调用者返回；当上个任务执行完毕再执行该任务
- 因此单个DataStore读写是线程安全的。
此处的策略和线程池的实现类似，有需要的可以查看过往关于线程池设计的文章。
7. 能否创建多个DataStore实例？
我们一般会将都DataStore的操作封装起来：
class MyDataStore(val context: Context) {
val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "test")
suspend fun saveData2() {
context.dataStore.edit {
//只修改分数
it[myNameKey] = "fish is perfect3"
}
}
}
而在Activity里的onCreate()方法调用如下：
lifecycleScope.launch {
MyDataStore(this@DataStoreActivity).saveData2()
}
问题：这么写会有什么问题呢？
你可能会说，我试了没啥问题啊？进入Activity后成功写入DataStore。
那退出Activity再进入Activity试一次呢？
兴许你已经遇到Crash了：
提示不能有多个DataStore实例去操作同一个文件。
你可能又有疑问了：第一次进入Activity用的是一个DataStore实例，第二次进入Activity是另一个新的实例，第一个实例已经销毁了呀？为啥还会提示？
因为我们并不能完全确保同一时间只有一个DataStore实例在操作，若是存在不同的实例访问同一个文件，那么将会产生不可预期的脏数据。因此DataStore设计时就严格限制只能有一个实例访问同一个文件。
那么如何避免此种问题呢？很简单，只需要确保我们创建同一个文件只关联一个DataStore实例即可。
class MyDataStore(val context: Context) {
companion object {
val Context.dataStore: DataStore<Preferences> by preferencesDataStore(MyDataStore.javaClass.name)
}
}
通过静态变量确保只有一个实例。
8. DataStore 如何获取同步数据？
DataStore的核心优势在于：
使用协程挂起函数存取数据，不阻塞UI，不像SharedPreferences可能会引发ANR。
DataStore只对外暴露了Flow，调用者需要通过Flow存取数据，也就是要求调用者要拥有协程环境。
然而我们可能面临的现实环境是：
- 调用者没有协程环境(针对老的代码)
- 调用者需要同步访问DataStore数据
第1点就不说了，有些老代码是Java代码，无法使用协程/接入协程代价较大。
第2点的场景：基础数据如登录与否存储在DataStore，而其它调用方仅仅只需要1个方法判断是否已经登录。
针对第2点需要同步方法有两种思路：
- 提供一个同步方法，用于获取外界关注的状态，而内部监听Flow的变化，有变化就同步到状态里， 如此一来，对于协程和Flow的使用控制在内部，外部仅仅只需要获取内存状态即可
- 提供一个同步方法，直接获取数据
我们来看看第二种思路的实现：
val myNameKey = stringPreferencesKey("name")
fun getName():String? {
return runBlocking {
context.dataStore.data.map {
it[myNameKey]
}.first() as? String
}
}
可以看出，我们提供的getName()并不是挂起函数，外界调用会一直等到数据的返回。
此处你可能会有担忧：getName()函数阻塞了，如果主线程调用不会耗时吗？
没错，你的担忧是合理的，假若该DataStore是第一次读取，那么getName()将阻塞等待DataStore将文件加载到内存，最后才会返回。
而只要读取了一次数据，那么后续将无需再次进行I/O读取，都是内存操作，无需担忧耗时问题。
对于第一次读取耗时问题，我们可以进行预加载，比如在某个时机提前加载数据。
9. DataStore 全流程
本文基于：datastore-preferences:1.0.0
下篇将分析DataStore Proto，敬请关注。
您若喜欢，请点赞、关注、收藏，您的鼓励是我前进的动力
持续更新中，和我一起步步为营系统、深入学习Android/Kotlin
1、Android各种Context的前世今生
2、Android DecorView 必知必会
3、Window/WindowManager 不可不知之事
4、View Measure/Layout/Draw 真明白了
5、Android事件分发全套服务
6、Android invalidate/postInvalidate/requestLayout 彻底厘清
7、Android Window 如何确定大小/onMeasure()多次执行原因
8、Android事件驱动Handler-Message-Looper解析
9、Android 键盘一招搞定
10、Android 各种坐标彻底明了
11、Android Activity/Window/View 的background
12、Android Activity创建到View的显示过
13、Android IPC 系列
14、Android 存储系列
15、Java 并发系列不再疑惑
16、Java 线程池系列
17、Android Jetpack 前置基础系列
18、Android Jetpack 易学易懂系列
19、Kotlin 轻松入门系列
20、Kotlin 协程系列全面解读