commit()和apply()的区别

返回值

apply()没有返回值，而commit()返回boolean表明修改是否提交成功。

操作效率

apply()是将修改数据原子提交到内存, 而后异步真正提交到硬件磁盘,。

而commit()是同步的提交到硬件磁盘。

因此，在多并发commit()的时候，会等待正在处理的commit保存到磁盘后再操作，从而降低了效率。

而apply只是原子的提交到内容，后面有调用apply的函数的将会直接覆盖前面的内存数据，从一定程度上提高了效率。

建议

如果对提交的结果不关心的话，建议使用apply()，如果需要确保提交成功且有后续操作的话，还是需要用commit()。

多进程表现

是为了回答这个问题。

一句话：在多进程中，如果要交换数据，不要使用SharedPreference，因为在不同版本表现不稳定，推荐使用ContentProvider替代。

在有的文章中，有提到在多进程中使用SharedPreference添加下面标志位就可以了。

MODE_MULTI_PROCESS

但是在官方文档中这样提到：

 This was the legacy (but undocumented) behavior in and
   before Gingerbread (Android 2.3) and this flag is implied when targetting such releases.  
   For applications targetting SDK versions greater than Android 2.3, 
   this flag must be explicitly set if desired.

@deprecated MODE_MULTI_PROCESS does not work reliably in some versions of Android, 
and furthermore does not provide any mechanism for reconciling concurrent modifications 
across processes.  Applications should not attempt to use it.  Instead, they should use an explicit 
cross-process data management approach such as ContentProvider

简单解释下，就是这个标志位在2.3之前是默认支持的，但是在2.3之后，如果需要多进程访问的情景，就需要显示的声明出来。

现在这个标志位被废弃了，因为在某些版本上表现不稳定。我们开发者不应该尝试去使用它，因为他没有提供任何并发机制，我们应该使用一种明确支持跨进程访问的机制，比如ContentProvider。

使用细节

• ContextImpl中有一个静态的ArrayMap变量sSharedPrefs，无论有多少个ContextImpl对象实例，系统都共享这一个sSharedPrefs的Map，应用启动以后首次使用SharePreference时创建，系统结束时才可能会被垃圾回收器回收，所以如果我们一个App中频繁的使用不同文件名的SharedPreferences很多时这个Map就会很大，也即会占用移动设备宝贵的内存空间。所以我们应用中应该尽可能少的使用不同文件名的SharedPreferences，取而代之的是合并他们，减小内存使用
• SharedPreferences在实例化时首先会从sdcard异步读文件，然后缓存在内存中；接下来的读操作都是内存缓存操作而不是文件操作。
• 在SharedPreferences的Editor中如果用commit()方法提交数据，其过程是先把数据更新到内存，然后在当前线程中写文件操作，提交完成返回提交状态；如果用的是apply()方法提交数据，首先也是写到内存，接着在一个新线程中异步写文件，然后没有返回值。
• 在写操作commit时有三级锁操作，效率很低，所以当我们一次有多个修改写操作时等都批量put完了再一次提交确认，这样可以提高效率。

更多参考资料

• SharedPreference.Editor的apply和commit方法区别
• Android应用Preference相关及源码浅析(SharePreferences篇)
• Android源码