在Android代码优化中，SharedPreferences的“ commit（）”会自动更改为“ apply（）”吗？

Question

所以，我现在正面临这个奇怪的问题。我必须在我的Android应用中使用SharedPreferences.Editor（）。commit（），但正如文档here所述，

  

由于SharedPreferences实例是流程中的单例，因此   如果您是安全的，可以用apply（）替换任何commit（）实例   已经忽略了返回值。

     

您无需担心Android组件的生命周期及其   与apply（）写入磁盘进行交互。该框架确保   在切换状态之前，完成了apply（）的运行中磁盘写操作。

如果您不使用返回值但，则基本上可以安全地将commit()替换为apply()，如前所述here ，并且在Android Studio中警告说，commit()立即写入数据，而 BUT apply()则异步进行。

所以我的问题是，我正在更改应用程序中的语言，并且我希望在用户选择语言后重新启动应用程序。但是，当用户选择语言时，当前选择的语言会放在SharedPreferences中。

现在，问题是：

每当我使用apply()而不是commit()并使用代码重新启动应用程序here来重新启动应用程序时，更改都不会写入磁盘，因为应用程序重新启动时，它不会更改当前语言，因为SharedPreference中的值不会更改，因为它不会立即写入磁盘。但是，每当我使用commit()时，更改都会被立即写入，并且在重新启动应用程序后会成功更改语言。

是，问题是

1. 为commit()和apply()编写代码的人怎么会说，如果有很大的代码，使用apply()而不是commit()是完全安全的区别在于commit()立即写入数据，但是apply()是否在后台写入数据？

2. 如果我构建了apk，那么如果我不使用返回值，那么代码优化中的commit()将被apply()替换。（我知道我可以通过构建应用的发行版，但我仍然不确定，因为当我使用apply()时，它经常出现1/10次实际上确实更改了SharedPreference中的值）

注释：

1. 我知道如何使用Apply（）仍然可以使我的应用程序正常工作，也许我必须在重新启动应用程序之前添加一些延迟？但是我不确定它是如何工作的，因为它仍然需要一些时间才能将数据实际写入磁盘，而且我目前看不到任何方法来检查SharedPreference值是否已实际更改，因此我可以更改值后，安全地重新启动。

Answer 1

问题是，使用Runtime.getRuntime().exit(0)或System.exit(0)会杀死该进程，因此以后将不执行任何计划的异步任务。

如果您不想更改重新启动代码，则应在此实例中保留commit而不是apply并禁止显示警告。

1. 可以安全地假定该语句有效，因为调用exit(0)是一种极端情况，您通常不应该这样做。
2. 没有理由假设commit将自动替换为apply。如果您想确保它，只需使用返回值即可。