在 Android 的 SharedPreferences 中将对象存储为 JSON 字符串是不是有点不好？答案

【问题标题】：Is it somehow bad practice to store Objects as JSON Strings in SharedPreferences in Android?在 Android 的 SharedPreferences 中将对象存储为 JSON 字符串是不是有点不好？
【发布时间】：2014-03-09 04:13:31
【问题描述】：

作为最近发现 NoSQL 文档存储 (namley CouchDB) 的简单之美的人，我发现自己在需要持久存储简单对象或小型数组以使用 Json 序列化程序将此数据存储为 JSON 字符串时非常诱人共享偏好。我看到的优点是：

没有增加复杂性，因为（在我的项目中）我已经为我的 REST API 提供了一个 JSON 框架，可以轻松转换 JSON/对象
我还认为：复杂性更低，因为我可以只使用 POJO 而不必手动处理键/值
与 Java 序列化或 Android 可解析相比，它或多或少是一种通用格式，即使对于人类来说也易于理解，并且易于在不同的框架中解析
使用正确的工具，可以轻松处理数据模型更改和必须迁移配置的更新情况（例如在 Jackson 中忽略未知属性并设置新的默认值）
再次使用正确的工具，可以在一行代码中完成序列化：mapper.writeValueAsString(myObject);

我看到的缺点：

如果使用舒适的序列化方式（例如 Jackson 中的数据绑定）会变慢 - 但我不确定这在“保存配置”用例中是否起任何作用
需要更多空间 - 我想这可以忽略不计

我知道这种方法仅适用于合理的小数据（但我猜这通常适用于 SharedPreferences），如果仅用于“保存配置”或类似用例，则性能损失可以忽略不计写入/读取是稀疏的。

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

【问题讨论】：

我一直在想同样的事情有一段时间了。我有一个在共享内存中存储 2 或 3 个对象并经常更新它们的应用程序，我还没有遇到任何问题。请记住，它是小数据

标签： java android json sharedpreferences

【解决方案1】：

所以几年后我的发现如下：

使用基于反射的序列化时，Json 序列化可能会很慢，尤其是在内容复杂和/或冗长的情况下
在使用 Proguard 时必须特别注意不要混淆要序列化的模型名称。
迁移很困难 - 这是我最大的缺点。

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

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

【讨论】：

【解决方案2】：

在SharedPreferences 中存储小数据对象并没有什么坏处。但是，您应该记住一件事，SharedPreferences 不能跨多个进程正常工作。因此，如果您打算跨进程使用 SharedPreferences，则应避免使用它们。

【讨论】：