SharedPreference.Editor 的 apply 和 commit 方法异同

1. apply方法在 官方SDK说明 如下：

Commit your preferences changes back from this Editor to the SharedPreferences object it is editing. This atomically performs the requested modifications, replacing whatever is currently in the SharedPreferences.

Note that when two editors are modifying preferences at the same time, the last one to call apply wins.

Unlike commit(), which writes its preferences out to persistent storage synchronously, apply() commits its changes to the in-memory SharedPreferences immediately but starts an asynchronous commit to disk and you won’t be notified of any failures. If another editor on this SharedPreferences does a regular commit() while a apply() is still outstanding, the commit() will block until all async commits are completed as well as the commit itself.

As SharedPreferences instances are singletons within a process, it’s safe to replace any instance of commit() with apply() if you were already ignoring the return value.

You don’t need to worry about Android component lifecycles and their interaction with apply() writing to disk. The framework makes sure in-flight disk writes from apply() complete before switching states.

The SharedPreferences.Editor interface isn’t expected to be implemented directly. However, if you previously did implement it and are now getting errors about missing apply(), you can simply call commit() from apply().

这两个方法的区别在于：

1. apply 没有返回值而 commit 返回 boolean 表明修改是否提交成功
2. apply 是将修改数据原子提交到内存, 而后异步真正提交到硬件磁盘，后面有调用 apply 的函数的将会直接覆盖前面的内存数据，这样从一定程度上提高了很多效率
3. commit 是同步的提交到硬件磁盘，因此，在多个并发的提交 commit 的时候，他们会等待正在处理的 commit 保存到磁盘后在操作，从而降低了效率

SO 高票答案

• apply() was added in 2.3, it commits without returning a boolean indicating success or failure.
• commit() returns true if the save works, false otherwise.
• apply() was added as the Android dev team noticed that almost no one took notice of the return value, so apply is faster as it is asynchronous.