这更像是对某事物的意见请求，而不是问题。 有点长，所以如果您没有耐心阅读全部内容，请不要担心。 如果您不这样做，请停在此处。）
我目前正在使用共享偏好设置经常在我的应用执行期间存储一些值逐个。实际上，每两秒钟值会发生变化，并且需要将它们存储在首选项中，以便用户在关闭应用程序并重新打开它之后，可以从他离开的地方继续。
我想到的一个问题是，如果应用程序被强行关闭，例如电池在保存值时死亡，那么当用户尝试从他中断的地方恢复时，数据将无效，因为它之前未完全保存。（例如，只有2个中的5个值可以存储）。
我怎么想克服这个问题就是将数据保存两次，在“两个插槽”中（我的意思是插槽是每个值，就像我说过有多个值，将存储在“valueName_1”中）或者“valueName_2”），并且除了正常值存储之外，我还将在首选项中保存两个值，这些值将用于验证数据是否完全保存。
这两个值curSavingSpot中的一个将引用我在最后保存的两个广告位之一中的位置（或者在以下情况下已经过TRIED保存如果最后存储的值是所有商店成功，则其他curSavedSuccessfully将跟踪。
例如：
curSavingSpot指向1（第一个“广告位”），curSavedSuccessfully为假。我开始在插槽1中保存值并完成保存而不会中断，因此curSavedSuccessfully将成为真，因为我们已成功保存所有值
2秒后，我开始保存新值。这一次是在第2个插槽中。但首先，我将curSavingSpot值设置为2并将curSavedSuccessfully设置为false。假设当我保存5个值中的3个（还有2个值）时，设备会崩溃。当我重新启动它时，我将首先检查上次保存会话是否成功完成，根据curSavedSuccessfully没有发生，所以我查看curSavingSpot并采取相反的值，在此情况我知道2还没有成功完成，所以这意味着1有正确的值。
有什么建议吗？这个想法有什么缺陷吗？
很抱歉这篇长篇文章。
答案 0 :(得分：4)
老实说，听起来就像你在思考它一样。 SharedPreferences的commit()和apply()方法声称是原子的，这意味着对SharedPreferences的所有更改都会发生，或者它们都不会发生。只要您不多次调用commit（）（在完成所有更改之后），您应该没问题。基本上，您只能提交某些首选项的情况永远不会发生。如果你的值在单独提交时是无效的，那么逐个提交它们是没有意义的，只要在它们准备好提交时就提交它们。
如果要审核提交，也可以使用数据库（并且始终只选择具有最后时间戳的提交）。 SQLite有atomic commits，你可以阅读更多关于原子提交在这里意味着什么以及为什么它永远不会只写一行的部分。
答案 1 :(得分：1)
我建议您使用“内部存储”进行某种备份。我认为它比“共享首选项”慢一点，但内部存储用于存储更大数量的数据，并且如名称所示，共享首选项是首选项（有限的信息集，不经常更改）。 / p>
所以：我会使用内部存储来每分钟左右存储应用程序的值，以及两者之间的小的增量步骤的共享首选项。有了这个，您甚至可以提供进一步的备份，而不仅仅是一步。
并且可能用户不会仅仅因为杀死正在运行的应用程序，所以我认为您的应用程序被杀死的情况相当罕见。而对于其他一切，还有onDestroy（），您可以在其中保存所有内容。
喝彩！