SharedPreferences优化总结

SharedPreferences(后续简称SP)为我们提供了轻量级存储能力,方便了少量数据的持久化。
但是由于项目越来越庞大,SP操作使用不当会导致app卡顿,乃至ANR问题。
下面介绍一下操作SP的优化点。
SP性能优化点
SP性能变差的原因有很多。
1.原生API的限制主要有以下两方面:
     (1)IO瓶颈
     (2)锁性能差
2.对SP的不当封装也会间接造成数据读写性能差。
下面会对以上三方面进行分析。
IO瓶颈
IO瓶颈造成SP性能差是最大的原因,解决了IO瓶颈,80%的性能问题就解决了。
SP的IO瓶颈包括读取数据到内存与数据写入磁盘两部分。
1.读取数据到内存有两个场景会触发:
     (1)SP文件没有被加载到内存时,调用getSharedPreferences方法会初始化文件并读入内存。
     (2)版本低于android_Honeycomb或使用了MULTI_PROCESS标志时,每次调用getSharedPreferences方法时都会读入。
     我们可以优化的便是(2)了。每次加载数据到内存太过影响效率。
     H以下版本留存率已经很低了,基本可以忽略。
     对于MULTI_PROCESS,可以采用ContentProvider等其他方式,效率更好,而且可避免SP数据丢失的情况。
2.数据写入磁盘也有两个场景会触发:
     (1)Editor的commit方法,每次执行时同步写入磁盘。
     (2)Editor的apply方法,每次执行时在单线程池中加入写入磁盘Task,异步写入。
     commit和apply的方法区别在于同步写入和异步写入,以及是否需要返回值。
     在不需要返回值的情况下,使用apply方法可以极大的提高性能。
     同时,多个写入操作可以合并为一个commit/apply,将多个写入操作合并后也能提高IO性能。
锁性能差
SP的get操作,会锁定SharedPreferences对象,互斥其他操作。
SP的put操作,getEditor及commitToMemory会锁定SharedPreferences对象,put操作会锁定Editor对象,写入磁盘更会锁定一个写入锁。
由于锁的缘故,SP操作并发时,耗时会徒增。减少锁耗时,是另一个优化点。
由于读写操作的锁均是针对SP实例对象的,将数据拆分到不同的sp文件中,便是减少锁耗时的直接方案。
降低单文件访问频率,多文件均摊访问,以减少锁耗时。
用开发机进行了简单的性能测试(写入均使用apply,若使用commit则多线程耗时更高):
读写同一文件,10个线程每个读写10次数据:
耗时80-130ms
读写10个文件,每个文件由1个线程读写10次数据:
耗时30-70ms
对SP操作的不当封装
由于我们项目采用了插件化,所以对SP的操作涉及到了跨进程访问。
我们采用ContentProvider方案支持跨进程访问,并对所有SP操作均套上了ContentProvider进行访问。
随着项目越来越庞大,通过ContentProvider访问造成的耗时性能也成了问题。
对ContentProvider操作SP测试,耗时是直接操作SP的4倍左右。
所以,最近项目中进行了SP的处理,对于不需要跨进程的SP操作去掉了ContentProvider,尽可能减少无谓耗时。
SP优化的建议
1.尽量不要直接调用SharedPreferences进行读写操作。
若直接调用getSharedPreferences(fileName,mode).edit().putString(key,value),则对数据的操作直接耦合了fileName和key,后续想调整file和key会比较困难。
可以考虑封装一下,譬如:
public void saveUserId(){
     getSharedPreferences(fileName,mode).edit().putString(“user_id”,value);
}
这样做可以直接对数据访问,而与fileName与key解耦,后续拆分与调整时会很方便。
2.将SP作为耗时操作对待,尽量减少无谓的调用。
譬如以下代码,SP读一次即可:
if(sp.getUserId()>0){
     int id=sp.getUserId();
     …
}

亲测mode_multi_process会到导致数据丢失的问题,具体会表现为随机问题,如果不是看官方文档的描述是很难跟踪到问题的具体的原因的。

github上有个开源项目tray,是SF在多进程间共享数据的替代方案:github.com/grandcentrix

0 条评论
发表一条评论