​​Когда не нужно заменять HashMap на ArrayMap

Думаю, все в курсе — если попробовать использовать HashMap, студия предложит заменить тип на ArrayMap

Почему (короткий ответ) — ArrayMap оптимизирован под Android

Почему (правильный ответ) —

HashMap для каждой пары ключ-значение создаёт объект Map.Entry, который хранит ключ, значение, хэш ключа, ссылку на следующий объект

Такая сложность нужна, так как HashMap хранит данные в массиве массивов (см. "связанные посты" в комментариях)

Но даже пустой объект весит n-байт, а тут столько побочной информации

Поэтому ArrayMap реализует другой подход: он содержит два массива - один mArray для keys и objects, второй mHashes для хэша ключей
Процесс добавления новой пары:

1. в mArray кладется ключ
2. на следующую позицию в mArray кладется объект
3. вычисляется hash от ключа и кладется в mHashes

Вывод: в HashMap поиск по ключу быстрее, но ArrayMap съедает в разы меньше памяти

....

А зачем тогда SparseArray?

Бывали ли у вас ситуации, когда правильный выбор структуры давал заметный прирост к производительности или андроид-разработчику в реальности такие знания не пригождаются?