我在我的Android应用程序中使用共享首选项 . 我正在使用共享首选项中的 commit() 和 apply() 方法 . 当我使用AVD 2.3时它没有显示错误，但是当我在AVD 2.1中运行代码时， apply() 方法显示错误 . 那么这两者有什么区别？并且只使用 commit() 可以存储首选项值而没有任何问题吗？
commit()
apply()
apply() 在2.3中添加，它提交 without 返回一个表示成功或失败的布尔值 .
如果保存有效， commit() 将返回 true ，否则返回 false .
apply() 被添加，因为Android开发团队注意到几乎没有人注意到返回值，因此应用更快，因为它是异步的 .
http://developer.android.com/reference/android/content/SharedPreferences.Editor.html#apply()
commit() 是同步的， apply() 是异步的
apply() 是无效功能 .
如果新值已成功写入持久存储，
commit() 将返回true .
apply() 保证在切换状态之前完成，您无需担心Android组件的生命周期
如果您不使用从 commit() 返回的值并且您从主线程使用 commit() ，请使用 apply() 而不是 commit()
来自javadoc：
与commit（）同步地将其首选项写入持久存储，apply（）会立即将其更改提交到内存中的SharedPreferences，但会启动异步提交到磁盘，并且不会通知您任何失败 . 如果此SharedPreferences上的另一个编辑器执行常规commit（）而> apply（）仍然未完成，则commit（）将阻塞，直到完成所有异步提交以及提交本身
tl;dr:
commit() 写入数据 synchronously （阻塞其调用的线程） . 然后 informs 你关于操作的成功 .
apply() 安排要写入的数据 asynchronously . 它 does not inform 你关于操作的成功 .
如果使用 apply() 和 immediately read 通过任何getX方法保存，将返回 new 值！
如果您在某个时刻调用 apply() 并且它仍在执行，则对 commit() 的任何调用都将阻塞，直到所有过去的apply-calls和当前的commit-call完成为止 .
来自SharedPreferences.Editor文档的更深入信息：
与commit（）同步地将其首选项写入持久存储，apply（）会立即将其更改提交到内存中的SharedPreferences，但会启动异步提交到磁盘，并且不会通知您任何失败 . 如果此SharedPreferences上的另一个编辑器在apply（）尚未完成时执行常规commit（），则commit（）将阻塞，直到完成所有异步提交以及提交本身 . 由于SharedPreferences实例是进程中的单例，因此如果您已经忽略了返回值，则可以使用apply（）替换commit（）的任何实例 . SharedPreferences.Editor接口不应直接实现 . 但是，如果您以前执行过它并且现在收到有关缺少apply（）的错误，则只需从apply（）调用commit（）即可 .
文档对apply()和commit()之间的区别给出了很好的解释：
与commit（）同步地将其首选项写入持久存储，apply（）会立即将其更改提交到内存中的SharedPreferences，但会启动异步提交到磁盘，并且不会通知您任何失败 . 如果此SharedPreferences上的另一个编辑器在apply（）尚未完成时执行常规commit（），则commit（）将阻塞，直到完成所有异步提交以及提交本身 . 由于SharedPreferences实例是进程中的单例，因此如果您已经忽略了返回值，则可以使用apply（）替换commit（）的任何实例 .
我在使用apply（）而不是commit（）时遇到了一些问题 . 如前所述，在其他响应中，apply（）是异步的 . 我遇到的问题是，对“字符串集”首选项形成的更改永远不会写入持久性内存 .
如果您“强制拘留”程序，或者在我使用Android 4.1安装在我的设备上的ROM中，当系统由于内存需要而导致该进程被终止时，就会发生这种情况 .
如果您希望您的首选项存活，我建议使用“commit（）”而不是“apply（）” .
使用apply（） .
它立即将更改写入RAM并等待并将其写入内部存储（实际首选项文件）之后 . Commit将更改同步并直接写入文件 .
7 回答
apply()在2.3中添加，它提交 without 返回一个表示成功或失败的布尔值 .如果保存有效，
commit()将返回 true ，否则返回 false .apply()被添加，因为Android开发团队注意到几乎没有人注意到返回值，因此应用更快，因为它是异步的 .http://developer.android.com/reference/android/content/SharedPreferences.Editor.html#apply()
commit()是同步的，apply()是异步的apply()是无效功能 .如果新值已成功写入持久存储，
commit()将返回true .apply()保证在切换状态之前完成，您无需担心Android组件的生命周期如果您不使用从
commit()返回的值并且您从主线程使用commit()，请使用apply()而不是commit()来自javadoc：
tl;dr:
commit()写入数据 synchronously （阻塞其调用的线程） . 然后 informs 你关于操作的成功 .apply()安排要写入的数据 asynchronously . 它 does not inform 你关于操作的成功 .如果使用
apply()和 immediately read 通过任何getX方法保存，将返回 new 值！如果您在某个时刻调用
apply()并且它仍在执行，则对commit()的任何调用都将阻塞，直到所有过去的apply-calls和当前的commit-call完成为止 .来自SharedPreferences.Editor文档的更深入信息：
文档对apply()和commit()之间的区别给出了很好的解释：
我在使用apply（）而不是commit（）时遇到了一些问题 . 如前所述，在其他响应中，apply（）是异步的 . 我遇到的问题是，对“字符串集”首选项形成的更改永远不会写入持久性内存 .
如果您“强制拘留”程序，或者在我使用Android 4.1安装在我的设备上的ROM中，当系统由于内存需要而导致该进程被终止时，就会发生这种情况 .
如果您希望您的首选项存活，我建议使用“commit（）”而不是“apply（）” .
使用apply（） .
它立即将更改写入RAM并等待并将其写入内部存储（实际首选项文件）之后 . Commit将更改同步并直接写入文件 .