Preferences Library适配DataStore的使用方案与坑点咨询

两者是否需要并行/二选一 #

• 本质上androidx.preference（即你提到的Preferences Library）是设置页UI组件库，和底层存储实现完全解耦，默认接入SharedPreferences只是开箱即用的默认行为，本身不强制绑定某一种存储方案。
• 技术上并行使用两套存储（一部分配置存DataStore、一部分配置通过SharedPreferences给Preferences Library用）完全可行，但强烈不推荐：这种模式会拆分配置存储源，极易出现UI显示的配置值与应用实际读取的配置值不一致的问题，后续维护成本极高。
• 正确的选型逻辑是完全二选一：既然你已经按官方推荐迁移到DataStore，就不需要在设置页链路中再引入SharedPreferences作为中间层，通过自定义PreferenceDataStore实现把所有存储请求直接转发到DataStore即可，整个设置页链路可以完全跑在DataStore上，无需额外维护SharedPreferences实例。

基于DataStore实现PreferenceDataStore的常见坑点 #

• 同步语义不匹配导致的主线程阻塞/死锁
  PreferenceDataStore的所有读、写接口都是同步阻塞设计，但DataStore是基于Flow的纯异步API，没有内置的同步读取方法。如果直接用runBlocking包装DataStore的读取操作响应同步接口：一方面在主线程触发磁盘IO会违反StrictMode规则，甚至引发ANR；另一方面当DataStore的编辑锁被其他协程持有时，同步等待很容易触发线程死锁。
• 数据变更监听链路断裂
  原生SharedPreferences实现的PreferenceDataStore会在数据变更时自动通知Preference组件刷新UI，如果自定义实现只做了数据转发、没有把DataStore Flow推送的变更事件回传给Preference的注册表，会出现其他位置修改配置后，设置页UI仍显示旧值的同步问题。
• 类型边界不一致引发的崩溃
  SharedPreferences允许存储null类型的字符串、可空的数值类配置，但Preferences DataStore的Key定义不支持null值写入，适配时如果不针对null值做兜底处理，读写过程中会直接触发空指针异常。
• 批量操作的性能损耗
  SharedPreferences原生支持批量事务提交，但Preferences Library在执行“恢复默认设置”这类批量操作时，会逐条调用自定义存储实现的put方法。如果每条put都单独触发一次DataStore的edit操作，会产生不必要的频繁磁盘IO，甚至在批量写入未完成时，被其他读取方拿到半更新的脏配置值。
• 跨进程能力不匹配
  DataStore本身不支持跨进程读写，如果你的应用配置需要跨进程同步，哪怕完成了PreferenceDataStore的适配，也无法满足原SharedPreferences的跨进程场景需求，这种情况下不建议强行替换底层存储。

内容的提问来源于stack exchange，提问作者fafcrumb