在Android中的SharedPreferences中將對象存儲為JSON字符串是不是一種不好的做法？

Question

作為最近發現NoSQL文檔存儲（namley CouchDB）的簡潔之美的人，我發現自己非常誘人，需要持久存儲簡單的對象或小數組以使用Json序列化程序將此數據作為JSON字符串存儲在共享首選項中。 我看到的優點是：

• 沒有增加的復雜性，因為（在我的項目中）我已經有一個可以輕松轉換JSON / Objects的REST API的JSON框架
• 我還會爭辯說：因為我可以使用POJO並且不必手動處理鍵/值，因此復雜性較低
• 與Java serilization或Androids parcable相比，它或多或少是一種易於理解的通用格式，即使對於人類也很容易解析不同的框架
• 使用正確的工具，它可以輕松處理數據模型更改和配置必須遷移的更新情況（忽略未知屬性並在Jackson中設置新的默認值）
• 再次使用正確的工具，可以在一行代碼中完成序列化： mapper.writeValueAsString(myObject);

我看到的缺點：

• 如果使用serialzition的舒適方式（例如Jackson中的Databinding），則會很慢 - 但我不確定這在“save config”用例中扮演什么角色
• 需要更多的空間 - 再次我猜這可以忽略不計

我知道這種方法只有在合理的小數據下才可行（但我認為這同樣適用於SharedPreferences），如果僅用於“保存配置”或寫入/讀取的類似用例，性能命中可忽略不計很稀疏。

我在所描繪的場景中尋找/反對這種方法的論據，或者我忽略或可能出現的問題。

Answer 1

在SharedPreferences存儲小數據對象沒有壞處。 但是，有一件事你應該記住， SharedPreferences不能在多個進程中正常工作。 因此，如果您計划跨進程使用它們，則應避免使用SharedPreferences。

Answer 2

所以幾年后我的發現是：

• 當使用基於反射的序列化時，尤其是如果內容復雜和/或長時，Json序列化可能會很慢
• 使用Proguard時，必須特別注意不要模糊序列化模型的名稱。
• 遷移很難 - 這對我來說是最大的缺點。

所以這取決於用例。 也許對於緩存來說這可能沒問題，因為如果數據在更新后損壞則只是性能損失，另一方面緩存應該很快（內存層可以減輕這種情況）。

如果您需要結構化數據的數據存儲，請使用Google的Room等數據庫或ORM。