跨活动/片段生命周期存储哈希图的最佳方式答案

【问题标题】：Optimal way to store hashmap across activity/fragment lifecycles跨活动/片段生命周期存储哈希图的最佳方式
【发布时间】：2016-03-25 21:05:47
【问题描述】：

我有一个HashMap<String, Integer>，我需要在恢复/重新启动、整个活动生命周期、应用重新启动等时保存它。
有以下选项：
1) 使用共享首选项并遍历所有密钥并将<key,value> 对完全存储在共享首选项中
2) 将 hashmap 转换为 JSON 并保存为共享首选项中的字符串。
3）由于hashmap是可序列化的，因此将其保存在内部存储器中。

但是什么是最好的方法性能明智？什么是标准/最佳做法？
在我看来，选项（3）似乎是选项（3），但从各种帖子中，很多人说相反。对于我对 hashmap 的特定定义，可序列化的开销是否很大？ IE。没有复杂的对象键值？

【问题讨论】：

考虑使用ArrayMap而不是HashMap，它支持库

标签： java android serialization hashmap activity-lifecycle

【解决方案1】：

选项 (3)。为什么？

1) 共享首选项使用 XML 文件存储数据。您必须读取文件并解析 XML。（读取 + 解析）

2）你必须读取文件并解析XML，然后解析JSON。（读取+解析+解析）

3）你只需读取文件并初始化hashmap。（读取）

为什么人们不使用option3？

因为他们想要与其他技术进行通信，所以可移植性将成为高级别的要求。

【讨论】：

我明白你的意思。但我的印象是人们认为序列化也很慢

【解决方案2】：

2) 是标准和最佳实践。

我会考虑 1) 不好的做法，因为它滥用 SharedPreferences。

关于性能：您必须根据您的用例对其进行基准测试。我希望 2) 最快，但根据地图大小和 JSON 转换实现，3) 可能会更快。

旁注：如果您的地图少于 1000 个条目，我不会担心性能

过早的优化是万恶之源

— 唐纳德·高德纳

【讨论】：

是的，它应该不超过 1000 个条目。为什么 1 滥用共享偏好？ JSON字符串也将存储在那里
SharedPreferences 是一个“访问和修改偏好数据的接口”，应该用于存储设置或行为标志。
当然你可以用其他方式，如果你的地图不大，这也不是问题。一般来说：将复杂数据保存在 SharedPreferences 中可能会导致性能下降，因为 SharedPreferences 保存在内存中。

【解决方案3】：

您是否考虑过将 Application 类或任何单例作为您的数据的容器以在配置更改后继续存在？

您也可以为此目的使用保留的 Fragment。

这些变体在应用运行时是最快的。

所以在重启之间保存状态你必须以一种或另一种方式使用序列化。

Google 团队声称 Parcelable 接口比经典的 Serializable 接口更快 (SO link)。

另外 JSON 考虑 GSON (SO link)。

当然，剖析器是您的最终决定裁判...

【讨论】：