安卓 共享首选项。崩溃时检索到损坏的数据

Question

这更多是在某些方面征求您的意见，而不是问题。这将是有点长，所以不用担心，如果你没有耐心看完这一切。如果您不这样做，请在这里停止：)

我目前使用共享偏好来频繁存储一些值，一个接一个，我的应用程序的执行过程中。实际上，这些值每2秒更改一次，并且需要将其存储在首选项中，因此用户在关闭应用程序并重新打开后，可以从中断的位置继续进行操作。

我想到的一个问题是，如果在任何情况下都强行关闭了该应用程序，例如电池没电了，则在保存值的同时，当用户尝试从上次中断的地方恢复时，数据不会是有效的，因为它以前并未完全保存过（例如，只有5个值中的2个得以保存）。

我如何解决此问题的方法是在“两个插槽”中保存两次数据（我的意思是插槽是每个值，就像我说过的多个值一样，将存储在“ valueName_1”或“ valueName_2”中”）和正常值存储旁边，我还将在首选项内保存两个值，这些值将用于验证数据是否已完全保存。这两个值之一curSavingSpot将引用我最后保存（或在失败时进行TRIED保存）的两个插槽之一的位置，另一个将跟踪最后存储的值是否为ALL存储成功地。curSavedSuccessfully

例如：

• 最初，Shared Pref中的每个字段均为空。curSavingSpot指向1（第一个“插槽”），并且curSavedSuccessfully为false。

• 我开始将值保存到插槽1中，并在不中断的情况下完成保存，因此curSavedSuccessfully当我们成功保存所有值后，这些设置将变为真实

• 2秒后，我开始保存新值。这次是在插槽2中。但是首先，我将curSavingSpot值设置为2 AND设置curSavedSuccessfully为false。假设当我保存5个值中的3个（还剩下2个）时，设备崩溃了。当我重新启动它时，我会首先检查上一次保存会话是否成功完成，根据curSavedSuccessfully那curSavingSpot件事并没有发生，所以我查看并取相反的值，在这种情况下，我知道2尚未成功完成，因此，这意味着1具有正确的值。

你怎么看？这是这样做的好方法吗？有没有更好的方法来确保它已保存所有必需的值？

有什么建议么？这个想法有什么缺陷吗？

抱歉，很长的帖子。

Answer 1

老实说，这听起来像是您想得太多。SharedPreferences 的commit（）和apply（）方法声称是原子的，这意味着对SharedPreferences的所有更改都发生了，或者没有发生。只要不多次（在进行所有更改之后）调用commit（），就可以了。基本上，您只能提交某些首选项的方案将永远不会发生。如果您的值在单独提交时无效，则一一提交它们是没有意义的，只在它们准备好提交时才提交。

如果您要审核提交，也可以使用一个数据库（总是选择最后一个时间戳）。SQLite具有原子提交，您可以在此处阅读更多有关原子提交的含义以及为什么它永远不会只写入行的一部分的更多信息。