Использование SparseIntArray вместо HashMap <Integer, Integer> с putSeriazable

Ответ 1

1) Насколько важно использовать SparseIntArray() вместо HashMap?

Это зависит от того, как вы его используете. Но если вы не пытаетесь представить множество и/или больших "массивов", подобных этому, разница вряд ли будет значительной.

Обратите внимание, что Java SE не имеет разреженных классов массивов, и обычно это не проблема.

2) Должен ли я решить проблему сериализации SparseIntArray? (Моя первая идея заключается в создании класса-оболочки, который реализует Serializable, это правильный путь?)

См. выше и ниже. (Да, это звучит разумно... если вам нужно пойти на это.)

SparseIntArray class (исходный код) использует пару массивов int для представления ключей и значений в сопоставлении и использует двоичный поиск для поиска. Клавиши сохраняются в порядке, не "дыры", а поиск выполняется с помощью двоичного поиска. Это означает следующее:

• Использование памяти для SparseIntArray будет примерно на 10 раз меньше, чем для эквивалента HashMap. Это связано с комбинацией вещей:

  • массив хеш-таблицы содержит примерно 1 ссылку на запись (в зависимости от того, насколько полная таблица...),

  • ключи и значения должны быть "помечены" в качестве Integer объектов в HashMap и

  • для каждой записи в HashMap требуется объект node, который является довольно тяжелым весом - 4 поля в стандартной реализации.

  (Тем не менее, если вы правильно создаете объекты Integer, то служебные данные "бокса" могут быть смягчены эффектами кеша экземпляров Integer.)

  В отличие от разреженной версии требуется 2 * capacity 4 байтовых слова.

• Поиск (т.е. get) равен O(logN) по сравнению с O(1) для a HashMap.

• Случайная вставка O(N) по сравнению с O(1) для a HashMap. (Это связано с тем, что вставка должна перемещаться по средней половине существующих записей, чтобы новая запись могла быть добавлена ​​в правильное положение в массивах.)

• Последовательная вставка (то есть в порядке возрастания по порядку) O(1).

Итак, "что лучше", очевидно, зависит от того, для чего вы оптимизируете, как вы используете структуру данных и насколько она будет достигнута.

Ответ 2

Проблема с использованием HashMap<Integer, Integer> заключается в том, что каждый ключ и значение должны быть помещены в бокс. Воздействие этого может варьироваться от ничего до тяжелой нагрузки на систему из-за огромного количества выработки мусора и/или использования памяти (не говоря уже о незначительном снижении производительности при боксировании/распаковке значений). (Эти проблемы также привели к разработке нескольких сторонних коллекционных фреймворков для примитивов.)

Если вы решите, что преимущества SparseIntArray заслуживают внимания, то я думаю, что ваш подход класса-оболочки разумен. Альтернативой было бы реализовать его Parcelable, который также можно использовать для сохранения/восстановления состояния экземпляра.