Android SharedPreferences 数据丢失问题

SharedPreferences 进行的存储会导致数据丢失?

最近由于需求迭代, K-V 的存储方式加入了加解密流程, 然后上线后,发现依赖于SharedPreferences 进行缓存的页面,发生了一些不可思议的报错,仿佛SharedPreferences 没有put数据到xml中一样.一开始不太相信,后面分析了下,确实是这样.

SharedPreferences 的commit 和apply?

commit 是同步提交, apply是异步处理. 为啥有这两种区分呢,那是因为SharedPreferences 如果用commit 来存储数据,数据量针对大数据那种,很容易造成ANR,因为要数据落地才能够进行后续相应的操作的话.你可以想象一下. 而用了apply 这种异步的话, apply的原理是开多一份xml 来进行读写, 等数据真实落地后,再删之前旧的那份xml. 那问题来了,既然这个过程是异步的,有没有可能会造成数据丢失,或者数据不准确呢? 答案是,确实如此.SharedPreferences 文件的加载使用了异步线程，而且加载线程并没有设置优先级，如果这个时候读取数据就需要等待文件加载线程的结束。这就导致主线程等待低优先线程锁的问题，比如一个 100KB 的 SP 文件读取等待时间大约需要 50 ~ 100ms，并且建议大家提前用预加载启动过程用到的 SP 文件。而且重要的一点,无论是commit 还是apply ,他在读写的过程都是全量写入的.

SharedPreferences 的IO是否安全?

既然SharedPreferences 是要读写xml来进行数据存储和读取的,那么这个IO操作是否安全呢,在java里, IO操作都会带上execption 抛出相应的IO异常, 关于SharedPreferences也是一样的.如图:

image.png

所以其中的数据读取量,根据相应的流而议,文件越大,那么相应的风险也就越大啦.因此SharedPreferences 也只适合那种轻量级的数据流的读写.

SharedPreferences 在线程间的表现如何?

首先看入参:

image.png

方法是线程安全的, 但是跨线程呢? 如果你用了MODE_MULTI_PROCESS 的话,那别的线程就可以更改你的数据啦.但是如果你不用这种方式的话, 那数据就不能给到别的线程去读写,因此,这个流程,大家可以脑补一下.

那么如何处理呢?

1.不用用SharedPreferences 保存跳转入口的缓存,而应该利用Intent 去传递相应数据到Activity 或者Fragment.
2.不要存储大数据, 包括一些加解密,因为加密操作会导致string 的长度变大, 如果都是加密存储,那么内容可想而知.
3.可以区分用户级别数据和应用级别数据来进行处理,如果用户数据较大, 可以考虑一些开源库如MMKV,如果较小,需要加密处理保证安全的话,针对部分字段进行加解密即可.
4.应用尽量不要过分依赖SharedPreferences来进行相应的业务逻辑处理操作.考虑一些设计模式来避免这个过程吧.