SharePreferences保存数据(附带工具类),kotlin数据类

本文详细介绍了Android中SharedPreferences的使用,包括读取和写入数据的原理,编辑器的操作步骤,以及同步与异步提交的区别。同时提出了优化建议,如避免存储大量数据,减少频繁操作,合理选择操作模式,以及封装成工具类提高复用性。
摘要由CSDN通过智能技术生成

3.读取

1.在xml文件全部内加载到内存中之前,读取操作是阻塞的

2.在xml文件全部内加载到内存中之后,是直接读取内存中的数据

4.写入

1.获取一个Editor

2.putXXX的时候,只是将数据写入到内存中的一个mModified Map中

3.执行commit 或 apply操作

1.commit:

1.将mModified的数据更新到SPI的mMap中

2.当没有key发生改变, 则直接返回; 否则将mMap全部信息写入文件, 如果写入成功则删除备份文件,如果写入失败则删除mFile

3.每次commit是把全部数据更新到文件, 所以每个文件的数据量必须保证足够精简

2.apply:

1.apply跟commit的最大区别 在于apply的写入文件操作是在单线程的线程池来完成.而commit是在当前线程阻塞运行的。

2.apply方法开始的时候, 会把一个任务awaitCommit,放入一个任务队列中QueuedWork

3.单线程池会不断从QueuedWork取任务然后执行。

QueuedWork在这里存在的价值主要是用于在Stop Service, finish BroadcastReceiver过程用于 判定是否处理完所有的异步SP操作.

4.总结

1.apply因为是异步的没有返回值, commit是同步的有返回值能知道修改是否提交成功

2.多并发的提交commit时,需等待正在处理的commit数据更新到磁盘文件后才会继续往下执行,从而降低效率; 而apply只是原子更新到内存,后调用apply函数会直接覆盖前面内存数据,从一定程度上提高很多效率。 3.edit()每次都是创建新的EditorImpl对象.

5.优化

1.sp里面不要存储特别大的key/value, 有助于减少卡顿/anr

2.不要高频地使用apply和commit, 尽可能地批量提交。因为每次提交就是xml文件的全部重写

3.commit直接在主线程操作, 要注意

4.不要使用MODE_MULTI_PROCESS,多线程不应该使用SPI

5.高频写操作的key与高频读操作的key可以适当地拆分文件, 由于减少同步锁竞争

6.不要一上来就执行getSharedPreferences().edit(),因为getSharedPreferences()是在其他线程进行但是会阻塞.edit()。

7.不要连续多次edit(), 应该获取一次获取edit(),然后多次执行putxxx(), 减少内存波动。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值