经历过几个大型项目的开发,在使用SharedPreferences
(下面简称Sp
)的时候踩了许多坑。下面将自己的一些经验总结一下。
不合理用法(个人认为)
- 存放大量的数据。(例如:存放接口数据,达到了MB级别)
- 当应用中有许多需要保存在
Sp
中的数据时,整个应用使用同一个Sp
。 Sp
的key使用时定义。Sp
commit方法使用时机不合理。- 同批次的key-value多次提交。
Sp
读取数据时,会将整个xml放入内存中,当发生上面1和2的情况时就会影响读取速度,严重时造成卡顿,甚至是ANR,用户体验很差。
Sp
的key定义也需要规范起来,不能使用的时候直接“xxx”这种情况,一旦复制粘贴keyName的时候多个空格或者少个字母你就准备怀疑人生吧,非常难发现(本人亲身经历过)。
Sp
的提交分为commit
和apply
两种。这两个方法的区别在于:
apply
没有返回值而commit
返回boolean
表明修改是否提交成功apply
是将修改数据元素提交到内存,而后异步真正提交到硬件磁盘,而commit
是同步提交到硬件磁盘,因此,在多个并发提交commit
的时候,他们会等待正在处理的commit
保存到磁盘后再操作,从而降低了效率。而apply
只是先提交到内存,后面有调用apply
的函数的将会直接覆盖前面的内存数据,这样从一定程度上提高了很多效率。apply
方法不会提示任何失败的提示。由于在一个进程中,Sp
是单实例,一般不会出现并发冲突,如果对提交的结果不关心的话,建议使用apply
,当然需要确保提交成功且有后续操作的话,还是需要用commit的。
封装
针对上面提出的一些问题,我这里整理了一些使用规范以及简单的封装。封装的核心目的:为了方便维护,对每个Sp
中保存的key-value能快速了解使用。
举个列子:假如项目中,需要将用户的一些信息(name,age,sex,phone,isMarried)保存在Sp
中。
创建Sp
key的描述类
建议新建一个包,专门存放Sp
相关的内容。在新建的包下新建一个SpKeyUser
类如下:
|
|
这里之所用一个类来描述Sp
的key,是为了更清晰地展现这个其保存的所有key,看了上面的注释我相信好处就不用我再一一赘述了。
创建Sp
的帮助类
这个类主要作为各个Sp
的生产工厂使用,并进一步提供简化的提交,获取值的方法。
|
|
大家可以根据业务需求对这个帮助类进行改造。
展望
优化永无止境!后面计划将Sp
的提交等操作通过注解方式来实现。
当然如果大家有相关优化的建议,欢迎留言反馈。