这两个方法的区别在于:
1. apply没有返回值而commit返回boolean表明修改是否提交成功
2. apply是将修改数据原子提交到内存, 而后异步真正提交到硬件磁盘, 而commit是同步的提交到硬件磁盘,因此,在多个并发的提交commit的时候,他们会等待正在处理的commit保存到磁盘后在操作,从而降低了效率。而apply只是原子的提交到内容,后面有调用apply的函数的将会直接覆盖前面的内存数据,这样从一定程度上提高了很多效率。
3. apply方法不会提示任何失败的提示。
由于在一个进程中,sharedPreference是单实例,一般不会出现并发冲突,如果对提交的结果不关心的话,建议使用apply,当然需要确保提交成功且有后续操作的话,还是需要用commit的。
转载自http://blog.csdn.net/jake9602/article/details/18414841对于这些知识是在android系统源码中的介绍,大概的意思就是为了解决线程阻塞和提高效率的问题吧。以后会写这方面的东西,对于我自己不善于写东西的,只能把我用到的和知道的觉得好的写上去,对于现成的也就直接转过来了。
大概说下对于这两个方法的认识吧,第一点对于解决现成阻塞问题,对于有经验的开发者可能不会遇到这个问题,SharedPreference一看就是个IO操作了,在android中对于听到IO,网络,保存文件,读取数据库,执行大数据循环等等关键词,应该立刻就会想到线程阻塞了,所以有经验的开发者都会开启个线程来执行这些操作,执行完之后再Handler或RunOnUIThread方法来操作主线程的东西了,再有点经验的开发者可能就会把它封住成个单独的类,并且开启个线程池来管理这些线程,以及以备以后用到,一两行代码即可实现。第二点解决提高效率问题,这就要有点经验的开发者可能才会想到的问题吧,初级的开发者可能就是为了实现功能需求,能运行,能得到要的数据就OK了,或者没有时间来优化这些,又或者他在这方面根本没有想法,等等吧,对于能想到这块的可能就会在commit和apply两个方法之间做个选择了,commit是线程阻塞的,也许你的代码中只用了一行代码commit,也许你的肉眼根本就看不到影响,(但是多了自然就会阻塞线程了),但是你用了apply方法之后自然就会为你的app提高一点性能,积少成多嘛。