在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中的数据绑定），则会很慢 - 但我不确定这在“save config”用例中扮演什么角色
• 需要稍微多一点的空间 - 我想这可以忽略不计

我知道这种方法只适用于合理的小数据（但我认为同样适用于SharedPreferences），如果仅用于“保存配置”或类似的用例，性能命中可以忽略不计写/读是稀疏的。

我在所描绘的情景中寻找/反对这种方法的论据，或者我忽略或可能出现的问题。

Answer 1

在SharedPreferences中存储小数据对象是没有害处的。 但是，您应该记住，SharedPreferences在多个进程中无法正常工作。因此，如果您计划跨进程使用它们，则应避免使用SharedPreferences。

Answer 2

所以几年后我的发现是：

• 使用基于反射的序列化时，Json序列化可能会很慢，特别是如果内容很复杂和/或很长
• 使用Proguard时，必须特别注意不要模糊序列化模型的名称。
• 迁移很难 - 这对我来说是最大的缺点。

所以这取决于用例。也许对于缓存来说这可能没问题，因为如果数据在更新后损坏就会造成性能损失，另一方面缓存应该很快（内存层可以缓解这种情况）。

如果您需要结构化数据的数据存储，请使用Google的房间等数据库或ORM。