这两个方法的区别在于： 

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提高一点性能，积少成多嘛。