Android。共享首選項。崩潰情況下檢索到的損壞數據

Question

這更多的是對您的意見的要求，而不是問題。 這將是有點長，所以不用擔心，如果你沒有耐心讀一遍。 停在這裏，如果你不我目前使用共享偏好來頻繁存儲一些值，逐一，我的應用程序的執行過程中:)

。實際上，每2秒鐘這些值就會改變，並且需要將它們存儲在首選項中，以便用戶在關閉應用程序並重新打開應用程序後，可以從停止的位置繼續。

我曾經想過的一個問題是，如果有機會強制關閉應用程序，例如電池在值被保存時死亡，那麼當用戶試圖從他離開的地方恢復時，數據無效，因爲它之前沒有完全保存（例如，只有5個值中的2個被存儲）。

我想如何解決這個問題是保存數據兩次，在「兩個時隙」（我的意思是插槽是每個值，就像我說過有多個值，將存儲在「valueName_1 「或」valueName_2「），並且在正常值存儲旁邊，我還將在首選項內保存兩個值，這些值將用於驗證數據是否完全保存。 其中這兩個值curSavingSpot將參照位置在這兩個插槽在那裏我已經最後保存（或曾嘗試在情況下保存的失敗）的一個值，而其他curSavedSuccessfully將跟蹤如果LAST存儲值全部是成功存儲的。

例如：

• 最初在共享縣每個字段爲空。 curSavingSpot指向1（第一個「slot」），curSavedSuccessfully爲false。

• 我開始在插槽1中保存價值和保存完成他們不會受到任何干擾，所以curSavedSuccessfully將作爲我們已經成功保存的值

• 2秒後發虛，我開始保存新的值。這次是插槽2.但首先，我將curSavingSpot的值設置爲2和curSavedSuccessfully爲false。讓我們說，當我保存5個值中的3個（還有2個值）時，設備崩潰。當我重新啓動它時，我會首先檢查上次保存會話是否成功完成，根據curSavedSuccessfully沒有發生，所以我看curSavingSpot並採取相反的值，在這種情況下，我知道2還沒有完成所以這意味着1有正確的值。

您怎麼看？這是做這件事的好方法嗎？有沒有更好的方法確保它保存了所有必需的值？

有什麼建議嗎？這個想法有什麼缺陷嗎？

對不起，很長的文章。

Answer 1

老實說，我聽起來像是你在推翻它。 SharedPreferences的commit()和apply()聲稱是原子的，這意味着對SharedPreferences的所有更改都會發生，或者它們都不會發生。只要你不是多次調用commit（）（在完成所有更改後），你應該沒問題。基本上你只能提交一些偏好的場景永遠不會發生。如果您的值在單獨提交時無效，則逐個提交它們是沒有意義的，只需在它們都準備好提交時提交即可。

如果你想審覈你的提交，你也可以使用一個數據庫（並且總是選擇最後一個時間戳）。 SQLite有atomic commits，你可以在這裏閱讀更多關於原子提交意味着什麼，以及爲什麼它永遠不會寫入行的一部分。

Answer 2

我建議您使用「內部存儲」進行某種備份。我假設它比「共享偏好」慢一點，但是內部存儲是爲了以更大的數量存儲數據而做出的，並且正如其名稱所指出的，偏好（有限的一組信息，不會頻繁變化）的共享偏好。

因此：我會使用內部存儲來存儲應用程序的值每分鐘左右，以及共享首選項之間的小增量步驟。有了這個，你甚至可以提供進一步的備份而不僅僅是一步。

並且可能用戶不會僅僅因爲殺死他們正在運行的應用程序，所以我認爲你的應用程序被殺死的情況非常罕見。還有其他一些功能onDestroy（），您可以在其中保存所有內容。

乾杯！