Java 使用SparseIntArray代替HashMap<；整数，整数>；可串行化

当我在Android中使用带有

Integer

键和数据值的

HashMap

时，我在Eclipse中得到以下消息：

Use new SparseIntArray(...) for better performance

现在的问题是

SparseIntArray（）

没有实现

Serializable

接口，并且不能与

onrestoreinnstancestate（）

中的

getSerializable（）

和

putSerializable（）

一起使用

使用

SparseIntArray（）

而不是

HashMap

有多重要

我是否应该麻烦地使

SparseIntArray

可序列化？（我的第一个想法是创建一个实现可序列化的包装器类，这是正确的方法吗？）

1） 使用

SparseIntArray

而不是

HashMap

有多重要

这取决于你如何使用它。但是，除非您试图像这样表示许多和/或大型“数组”，否则差异不大

请注意，JavaSE没有任何稀疏数组类，这通常不是一个问题

2） 我是否应该麻烦地使

SparseIntArray

可序列化？（我的第一个想法是创建一个实现可序列化的包装器类，这是正确的方法吗？）

见上文和下文

实现包装器听起来很合理。。。如果你需要找麻烦的话。另一种方法可能是声明

SparseIntArray

的可序列化子类。建议声明自定义的

readObject

和

writeObject

方法

---

SparseIntArray

类（）使用一对

int

数组来表示映射中的键和值，并使用二进制搜索进行查找。键保持有序，没有“孔”，并使用二进制搜索执行查找。这意味着：

• SparseIntArray

  的内存使用量大约比等效的

  HashMap

  要少10倍。这是由多种因素共同作用的结果：
  • 哈希表数组每个条目大约包含1个引用（取决于表的填充程度…）

  • 键和值必须作为

    HashMap

    中的

    Integer

    对象“装箱”，并且

  • HashMap

    中的每个条目都需要一个“node”对象，该对象相当重，在标准实现中有4个字段

  （但是，如果以正确的方式创建

  Integer

  对象，“装箱”开销可以通过

  Integer

  类实例缓存的效果来减轻。）
  相比之下，稀疏版本需要

  2*容量

  4字节字

• 与

  哈希映射的
  O（1）
  相比，查找（即
  get
  ）是
  O（logN）
  

• 与

  HashMap

  的

  O（1）

  相比，随机插入是

  O（N）

  。（这是因为插入必须平均移动现有项的一半，以便在数组中的正确位置添加新项。）

• 顺序插入（即按键顺序升序）是

  O（1）

---

因此，“哪一个是最好的”显然取决于您优化的目的、数据结构的使用方式以及数据结构的规模。

使用HashMap的问题在于每个键和值都需要装箱。这可能会对系统造成影响，从零到大量的垃圾生成和/或内存使用（更不用说装箱/拆箱值的轻微性能损失），都会给系统带来沉重的负载。（这些担忧也推动了几家第三方公司的发展。）

如果您认为

SparseIntArray

的好处值得拥有，那么我认为您的包装类方法是合理的。另一种方法是使其实现

Parcelable

，这也可以用于保存/恢复实例状态