目录
深入学习DataStore(一),Google为什么放弃SharedPreferences
深入学习DataStore(二),使用 Preferences DataStore存储数据
深入学习DataStore(三),迁移 SharedPreferences 到 DataStore
深入学习DataStore(四),如何使用Proto DataStore数据存储
Jetpack DataStore是一种用来替换SharedPreferences新型数据存储解决方案
Jetpack DataStore是以 Kotlin协程 和Flow功能为基础提供了两种方式
- Proto DataStore 存储类的对象,通过 protocol buffers 将对象序列化存储在本地
- Preferences DataStore 以键值对的形式存储在本地和SharedPreferences类似,基于 Flow 实现的，不会阻塞主线程，并且保证类型安全
为什么Google要替换SharedPreferences
其实SharedPreferences作为一种轻量级的数据存储方式，使用起来也非常方便,以键值对的形式存储在本地，初始化 SharedPreference 的时候，会将整个文件内容加载内存中，因此会带来以下问题：
-
getXXX()获取值的形式有可能会导致主线程阻塞 - SharedPreferences不能保证类型安全, 加载的数据会一直留在内存中，浪费内存
-
apply()方法虽然是异步的，可能会发生 ANR -
apply()方法无法获取到操作成功或者失败的结果
(1)为什么getXXX()方法会导致主线程阻塞
因为getXXX()都是同步的，在主线程调用 get 方法时，同步方法内调用了 wait() 方法，会一直等待 getSharedPreferences() 方法开启的线程读取完数据才能继续往下执行，如果数据量读取的小,并没有什么影响,如果读取的文件较大会导致主线程阻塞
具体大家可以查看haredPreferences源码
frameworks/base/core/java/android/app/SharedPreferencesImpl.java
(2)SharedPreferences不能保证类型安全,并且一直会留在内存中
看一个例子
val key = "DataStore"
val sp = getSharedPreferences("文件名", Context.MODE_PRIVATE)
sp.edit { putInt(key, 0) } // 使用 Int 类型的数据覆盖相同的 key
sp.getString(key, ""); // 使用相同的 key 读取 Sting 类型的数据
使用 Int 类型的数据覆盖掉相同的 key，然后使用相同的 key 读取 Sting 类型的数就会造成ClassCastException异常
而通过 getSharedPreferences() 方法加载的数据，最后会将数据存储在静态的成员变量中。
(3)apply()方法是异步的,可能会发生ANR
异步的提交为什么会发生ANR呢,这里有一个关于这个问题的文章分析
剖析 SharedPreference apply 引起的 ANR 问题
DataStore带来了哪些改变呢?
与其说DataStore相对SharedPreference的改变,不如说是Preferences DataStore,因为Preferences DataStore主要是替换SharedPreference的,并且解决了SharedPreference所有问题
- DataStore 是基于 Flow 实现的，所以保证了在主线程的安全性
- 以事务方式处理更新数据，事务有四大特性（原子性、一致性、 隔离性、持久性）
- 没有 apply() 和 commit() 等等数据持久的方法
- 自动完成 SharedPreferences 迁移到 DataStore，保证数据一致性，不会造成数据损坏
- 可以监听到操作成功或者失败结果
目前DataStore已经发布alpha01版本
具体可以参看JetPack DataStore
