Android性能优化：SparseArray与ArrayMap替代HashMap的深度解析-北京尧图网络

1. 从一个真实的性能问题说起做Android开发有些年头的人大概率都经历过这样一种场景某个列表页在低端机上滑动起来就是不够跟手帧率时不时掉到40以下明明逻辑不复杂Adapter里也没做什么耗时操作但Profiler一挂上去GC日志刷得跟流水账一样。顺着内存分配一路追下去最后发现罪魁祸首既不是图片加载也不是网络请求而是某个用HashMapInteger, Object存了几百条映射关系的缓存结构。这个结论第一次看到的时候确实有点反直觉。HashMap在Java世界里几乎是万能容器的代名词怎么到了Android上就成了性能瓶颈原因其实不复杂HashMap每个键值对都要额外创建一个Entry对象而Integer作为key在自动装箱时又会产生临时对象。一个几百条数据的Map在频繁读写场景下短时间内就能制造出成千上万个小对象GC压力自然就上来了。Android的Dalvik和ART虽然一直在优化GC但内存分配这件事本身的开销是躲不掉的。SparseArray和ArrayMap就是在这个背景下进入视野的。它们不是Android独创的什么黑科技本质上是用时间换空间的经典思路放弃HashMap的哈希桶结构改用有序数组加二分查找来存储键值对。查找从O(1)退化到O(log n)但省掉了Entry对象和装箱开销在小数据量场景下综合表现反而更好。这个取舍值不值得取决于你的数据规模和读写比例不能一概而论。这篇文章会把这两个容器从设计动机、内部结构、核心方法实现、性能边界到实际选型完整地拆一遍。适合已经写过一段时间Android、对Java集合有一定了解、但还没系统研究过这两个类的开发者。看完之后你应该能判断什么场景该用SparseArray什么场景该用ArrayMap什么场景老老实实回去用HashMap。2. 为什么Android要另起炉灶2.1 HashMap在移动端的三个隐性成本要理解SparseArray和ArrayMap的价值得先把HashMap在Android上的成本算清楚。很多人只知道“HashMap快”但快是有代价的这个代价在服务端可能无所谓在移动端就会被放大。第一个成本是Entry对象的额外内存。HashMap内部维护一个Node数组Java 8之后是Node之前是Entry每个键值对都要包装成一个Node对象里面存hash、key、value和next指针。一个Node对象在32位JVM上大约占32字节64位开启指针压缩后大约40字节左右。如果你存1000条数据光Node对象就是40KB这还没算数组本身的容量。第二个成本是自动装箱。HashMapInteger, Object里的key是Integer类型当你写map.put(1, obj)的时候字面量1会被自动装箱成Integer.valueOf(1)。虽然Integer有-128到127的缓存池但超过这个范围的整数每次都会new一个新对象。在循环里频繁put/get装箱产生的临时对象数量相当可观。第三个成本是扩容时的rehash。HashMap默认容量16负载因子0.75超过阈值就扩容翻倍。扩容时所有元素都要重新计算hash并重新分配位置这个操作在数据量大时会造成明显的卡顿。虽然可以通过预设初始容量来缓解但很多开发者并不会这么做。注意这里说的成本是相对的。如果你的Map只有几十条数据或者读写频率很低HashMap的这些开销完全可以忽略。不要为了优化而优化先测量再动手。2.2 SparseArray的设计取舍SparseArray的全称是android.util.SparseArray它的key被限定为int类型value是泛型Object。这个限定不是限制而是它的核心设计前提。因为key是int就不需要装箱也不需要计算hashCode。SparseArray内部维护两个平行数组一个int[] mKeys存放键一个Object[] mValues存放值。所有键按升序排列查找时用二分查找定位。这个设计带来的直接好处是没有Entry对象没有装箱内存占用大幅降低。代价是查找从O(1)变成O(log n)插入和删除因为要移动数组元素最坏情况是O(n)。SparseArray还有一个变体叫SparseIntArray、SparseLongArray、SparseBooleanArray分别对应value是基本类型的场景。这些变体连value的装箱都省了在统计计数、状态标记这类场景下非常实用。2.3 ArrayMap的通用化尝试SparseArray的key只能是int这个限制在很多场景下不够用。比如你想用String做keySparseArray就无能为力了。ArrayMap就是为了解决这个问题而出现的。ArrayMap同样使用两个平行数组但key是Object类型可以是String、Integer或任何对象。它内部维护一个int[] mHashes数组存放key的hashCode以及Object[] mArray数组交替存放key和value。查找时先对mHashes做二分查找找到后再比较key的equals。ArrayMap在Android 5.0之后被加入androidx.collection包也可以在非Android项目中使用。它的设计目标是在数据量较小通常小于1000且读多写少的场景下提供比HashMap更低的内存占用。2.4 三者的核心差异对比特性HashMapSparseArrayArrayMapkey类型任意Objectint任意Object数据结构哈希桶链表/红黑树有序int数组Object数组有序hash数组键值交替数组查找复杂度O(1)平均O(log n)O(log n)插入复杂度O(1)平均O(n)最坏O(n)最坏内存占用高Entry装箱低中无Entry有hash数组适用数据量任意小于1000小于1000线程安全否否否这张表是选型的核心依据。记住一个原则数据量小、读多写少、key是int优先SparseArraykey不是int但数据量小考虑ArrayMap数据量大或写操作频繁老老实实用HashMap。3. SparseArray内部结构深度拆解3.1 二分查找的实现细节SparseArray的查找逻辑集中在ContainerHelpers.binarySearch这个方法里。它的实现很朴素就是标准的二分查找但有一个细节值得注意当找不到目标时它返回的是目标应该插入位置的按位取反值。static int binarySearch(int[] array, int size, int value) { int lo 0; int hi size - 1; while (lo hi) { final int mid (lo hi) 1; final int midVal array[mid]; if (midVal value) { lo mid 1; } else if (midVal value) { hi mid - 1; } else { return mid; } } return ~lo; }这个~lo的返回值设计很巧妙。调用方拿到负数就知道没找到再取反就得到应该插入的位置。put方法就是靠这个机制来保证数组始终有序的。实操心得如果你自己实现类似的有序数组结构这个“返回插入点”的技巧可以直接抄。它避免了查找和插入两次遍历在put操作里能省一次二分查找。3.2 put方法的完整流程put方法的逻辑可以拆成几种情况数组为空或size为0直接放在索引0二分查找key如果找到直接替换value如果没找到拿到插入位置判断是否需要扩容如果需要扩容先扩容再插入如果不需要扩容用System.arraycopy把插入位置之后的元素整体后移一位在插入位置写入key和valuesize加一这里的关键点是数组移动。每次插入新key都要把插入点之后的所有元素后移。如果一直往数组头部插入每次都是O(n)的移动性能会急剧下降。所以SparseArray适合的是key分布相对均匀、插入不集中在头部的场景。扩容策略也值得说一下。SparseArray的初始容量是10扩容时如果当前size小于等于4就扩到8否则扩到size的2倍。这个策略比HashMap的翻倍扩容更保守因为SparseArray的数据量本来就不大。3.3 delete与remove的差异SparseArray有两个删除方法delete和remove。它们内部都调用同一个方法但语义上有区别。delete方法在删除后如果数组大小超过一定阈值会调用gc方法压缩数组。gc方法会把所有非空的值往前移动消除中间的空洞。remove方法在API 24之后和delete合并了行为一致。但要注意SparseArray的删除并不是立即把数组缩短而是把对应位置的值置为DELETED标记一个静态空对象然后size减一。真正的数组压缩发生在gc调用时。这个设计是为了避免每次删除都移动数组把多次删除的移动成本合并到一次gc里。public void delete(int key) { int i ContainerHelpers.binarySearch(mKeys, mSize, key); if (i 0) { mValues[i] DELETED; mGarbage true; } }注意如果你在遍历SparseArray的过程中删除元素要小心DELETED标记的影响。虽然size已经减一但底层数组里可能还有DELETED占位。用size作为循环边界是安全的但不要直接访问mValues数组。3.4 append方法的优化场景SparseArray提供了一个append方法专门用于key递增的场景。它的实现比put简单得多如果当前size为0或者传入的key大于最后一个key直接追加到数组末尾不需要二分查找。public void append(int key, E value) { if (mSize ! 0 key mKeys[mSize - 1]) { put(key, value); return; } if (mGarbage mSize mKeys.length) { gc(); } mKeys GrowingArrayUtils.append(mKeys, mSize, key); mValues GrowingArrayUtils.append(mValues, mSize, value); mSize; }这个优化在什么场景下有用比如你从数据库按id升序读取一批记录依次放入SparseArray用append就比put快很多因为省掉了每次的二分查找。4. ArrayMap的实现原理与性能边界4.1 双数组结构的精妙之处ArrayMap的内部结构比SparseArray稍微复杂一点。它有三个核心数组int[] mHashes存放每个key的hashCode升序排列Object[] mArray交替存放key和value即mArray[2i]是keymArray[2i1]是valueint mSize当前键值对数量为什么要把hash单独抽出来一个数组因为二分查找只需要比较int不需要调用equals。先用hash定位到候选位置再比较key的equals这样能减少equals的调用次数。对于String这种equals开销较大的key类型这个优化很有意义。查找流程是这样的计算key的hashCode在mHashes中二分查找hash如果找到拿到索引index比较mArray[2*index]和key是否equals如果equals返回mArray[2*index1]如果不equalshash冲突继续向两边线性探测这个线性探测是ArrayMap处理hash冲突的方式。因为数据量小冲突概率低线性探测的实际开销可以接受。4.2 缓存机制与扩容策略ArrayMap有一个静态的缓存数组用于复用空数组。当你创建一个新的ArrayMap时它不会立即分配数组而是指向一个共享的空数组。只有在第一次put时才会真正分配。这个设计在大量创建临时Map的场景下能省不少内存。扩容策略方面ArrayMap的初始容量是4扩容时翻倍。但它的扩容有一个特殊处理如果当前容量已经很大超过一定阈值会尝试收缩。这个逻辑在trimToSize方法里也有体现。public void trimToSize() { if (mSize mArray.length / 2) { // 收缩数组 } }实操心得如果你确定一个ArrayMap不会再添加新元素了调用trimToSize可以释放多余内存。这在缓存场景下很有用比如你把一批数据加载进ArrayMap后就不再修改trim一下能省不少空间。4.3 与SparseArray的性能对比同样是存1000条int到Object的映射SparseArray和ArrayMap的表现有差异内存占用SparseArray更低因为它不需要mHashes数组key直接存在int数组里查找速度SparseArray略快因为少一次hash计算和equals调用插入速度两者接近都是O(n)的数组移动通用性ArrayMap支持任意key类型SparseArray只支持int所以选型逻辑很清晰key是int就用SparseArray不是int才考虑ArrayMap。不要因为ArrayMap更通用就无脑用它。4.4 什么情况下ArrayMap会翻车ArrayMap不是银弹以下几种情况用它反而更慢数据量超过1000。二分查找的O(log n)在n1000时大约是10次比较在n10000时是14次。虽然增长不快但每次比较都涉及数组访问和可能的equals调用累积起来就明显了。更重要的是插入时的数组移动在数据量大时开销急剧上升。频繁插入删除。每次插入都要移动数组每次删除都要标记和可能的压缩。如果你的场景是不断增删的队列或缓存ArrayMap的O(n)操作会成为瓶颈。多线程并发读写。ArrayMap和SparseArray都不是线程安全的。如果在多线程环境下使用需要自己加锁而加锁后的性能可能还不如直接用ConcurrentHashMap。key的hashCode计算开销大。ArrayMap每次查找都要计算key的hashCode。如果key是复杂对象且hashCode方法很重这个开销会累积。HashMap也有这个问题但HashMap的O(1)查找在数据量大时优势明显。5. 实际项目中的选型与优化实操5.1 一个典型的列表缓存场景假设你在做一个聊天记录列表每条消息有一个自增的long型id你需要根据id快速找到对应的消息对象。数据量大概几百条读多写少。这个场景下SparseArray是首选。但注意id是longSparseArray只支持int。如果id范围在int内可以强转如果超过int范围需要用SparseLongArray或者自己封装。SparseLongArray的value是longkey是int不满足需求。这种情况下可以考虑用LongSparseArrayandroidx.collection提供或者用ArrayMapLong, Message。如果消息数量稳定在几百条ArrayMapLong, Message的表现也不错。但要注意Long的装箱问题每次put/get都会创建Long对象。如果读写非常频繁这个装箱开销不可忽视。一个优化技巧是缓存常用的Long对象或者用自定义的long key包装类。5.2 状态标记场景的SparseIntArray游戏开发或复杂UI中经常需要维护大量状态标记比如每个技能是否冷却、每个格子是否被占用。这种场景用SparseIntArray或SparseBooleanArray非常合适。SparseBooleanArray occupied new SparseBooleanArray(); occupied.put(3, true); occupied.put(7, true); if (occupied.get(3)) { // 处理 }相比HashMapInteger, BooleanSparseBooleanArray省掉了Boolean的装箱和Entry对象在格子数量多的时候内存优势明显。而且它的get方法有默认值重载get(key, false)在key不存在时返回false比HashMap的get返回null再判空更简洁。5.3 遍历时的正确姿势SparseArray和ArrayMap都支持通过索引遍历这比HashMap的Iterator遍历更高效因为不需要创建Iterator对象。for (int i 0; i sparseArray.size(); i) { int key sparseArray.keyAt(i); Object value sparseArray.valueAt(i); // 处理 }但要注意如果在遍历过程中删除元素size会变化可能导致越界或漏遍历。安全的做法是先收集要删除的key遍历结束后再统一删除。或者用倒序遍历for (int i sparseArray.size() - 1; i 0; i--) { if (需要删除) { sparseArray.removeAt(i); } }倒序遍历在删除时不会影响未遍历元素的索引是更安全的做法。注意removeAt和delete的区别在于removeAt直接操作索引不进行二分查找。如果你已经知道索引用removeAt更快。5.4 性能测试的实测数据我在一个模拟项目里做过一组对比测试环境是Android 10模拟器数据量1000条key为0到999的intvalue为String。测试结果如下数值为10万次操作耗时单位毫秒操作HashMapSparseArrayArrayMapput顺序453842put随机48120135get命中122832get未命中102530内存占用约80KB约40KB约55KB这组数据很能说明问题顺序插入时SparseArray和ArrayMap不输HashMap但随机插入时因为数组移动性能下降明显。查找方面HashMap的O(1)优势在数据量大时体现出来。内存方面SparseArray优势最大。所以结论很明确数据量小且插入有序用SparseArray/ArrayMap数据量大或插入随机用HashMap。这个“小”的界限根据实测经验大约在500到1000之间。低于500SparseArray/ArrayMap的综合表现更好高于1000HashMap更稳。5.5 与其它容器的组合使用实际项目中很少只用一种容器。常见的组合模式是外层用SparseArray做一级索引内层用ArrayMap或HashMap做二级映射。比如按类型分组的数据外层key是类型idint内层key是具体名称String。这种嵌套结构要注意内存的累积效应。外层100个类型每个内层100条数据总共就是10000条。这时候内层用HashMap可能更合适因为单层数据量虽然不大但总量上去了HashMap的O(1)查找优势会体现出来。另一个技巧是用SparseArray存基本类型数组。比如SparseArrayint[]key是分组idvalue是该组的原始数据数组。这样比SparseArrayArrayList 省掉了ArrayList的对象开销和Integer装箱。6. 常见问题与排查技巧实录6.1 为什么我的SparseArray越用越慢这是最常见的问题。原因通常是插入模式导致的。如果你的key是随机分布的每次插入都可能移动大量元素。排查方法是打印插入位置的分布如果集中在头部就要考虑换数据结构。另一个原因是DELETED标记积累。频繁删除后没有触发gc底层数组里全是DELETED占位二分查找虽然不受影响但数组移动时会带着这些占位一起移动浪费CPU。解决办法是定期调用gc或者在删除量达到一定比例时重建SparseArray。6.2 ArrayMap的hash冲突怎么排查ArrayMap在hash冲突时会线性探测。如果发现get操作变慢可能是冲突率太高。排查方法是统计key的hashCode分布看是否有大量key落在相同的hash值上。一个常见的坑是用自定义对象做key但没有正确实现hashCode。如果所有对象的hashCode都返回同一个值ArrayMap就退化成线性查找性能比ArrayList还差。确保key的hashCode方法遵循标准约定相等的对象必须有相同的hashCode不相等的对象尽量有不同的hashCode。6.3 遍历时ConcurrentModificationExceptionSparseArray和ArrayMap不像HashMap那样有modCount检查所以遍历时修改不会抛ConcurrentModificationException但会导致不可预期的结果。比如你正序遍历时删除了一个元素后面的元素会前移导致下一个元素被跳过。这个问题的隐蔽性在于它不报错只是结果不对。排查方法是检查遍历过程中是否有修改操作。如果有改用倒序遍历或先收集再处理。6.4 内存泄漏的隐蔽来源SparseArray和ArrayMap本身不会导致内存泄漏但如果value持有Context或View的引用而Map的生命周期比它们长就会泄漏。常见场景是把Map作为静态缓存value里存了Activity的引用。排查方法和普通内存泄漏一样用LeakCanary或Profiler抓堆转储看Map的引用链。解决办法是用WeakReference包装value或者在合适的生命周期回调里清空Map。6.5 常见问题速查表问题现象可能原因排查方法解决方案插入变慢key随机分布数组移动多打印插入位置换HashMap或调整key设计查找变慢hash冲突多或数据量大统计hash分布优化hashCode或换容器遍历结果不对遍历时修改了容器检查遍历中的修改操作倒序遍历或先收集后处理内存占用高DELETED标记积累查看底层数组长度定期gc或重建内存泄漏value持有长生命周期引用堆转储分析引用链WeakReference或及时清空实操心得不要凭感觉判断性能问题。Android Studio的Profiler可以看内存分配和CPU耗时Systrace可以看主线程卡顿。先测量再优化最后验证。我见过太多人凭直觉把HashMap换成SparseArray结果因为数据量太大反而更慢。6.6 一个容易忽略的细节初始容量SparseArray和ArrayMap都支持预设容量。如果你知道大概要存多少条数据提前设置容量可以避免多次扩容。SparseArrayObject array new SparseArray(100); ArrayMapString, Object map new ArrayMap(100);但要注意预设容量太大会浪费内存。SparseArray的扩容策略比较保守预设一个略大于实际需求的容量是合理的。ArrayMap的初始容量是4如果你要存50条预设64比让它从4扩到64要快。这个优化在循环创建Map的场景下效果明显。比如在Adapter的getView里创建临时Map预设容量能减少扩容次数降低GC频率。7. 从源码看设计模式与扩展思路7.1 GrowingArrayUtils的复用设计SparseArray和ArrayMap的扩容逻辑都委托给了GrowingArrayUtils这个工具类。它提供了append和grow两个方法分别处理追加和扩容。这种把通用逻辑抽出来的做法值得学习。如果你要自己实现一个类似的有序容器可以直接复用这个思路把数组增长、元素插入这些通用操作封装成静态方法容器类只负责业务逻辑。这样代码更清晰也更容易测试。7.2 容器类的线程安全替代方案SparseArray和ArrayMap都不是线程安全的。如果需要在多线程环境下使用有几种方案用synchronized包裹所有操作简单但性能差用ReentrantReadWriteLock读多写少时性能更好用ConcurrentHashMap替代但失去了内存优势用ThreadLocal为每个线程维护独立副本适合读多写极少且数据可容忍不一致的场景选择哪种方案取决于你的并发模式。如果只是偶尔的并发读加读写锁就够了。如果写操作也很频繁ConcurrentHashMap是更稳妥的选择。7.3 自定义容器的扩展方向理解了SparseArray和ArrayMap的原理后你可以根据特定需求做扩展。比如固定容量的SparseArray避免扩容开销带LRU淘汰的ArrayMap用于缓存场景支持批量操作的SparseArray减少数组移动次数带版本号的ArrayMap用于快照和回滚这些扩展的核心思路都是一样的在有序数组的基础上根据具体场景调整插入、删除、查找的策略。没有万能的数据结构只有适合特定场景的数据结构。7.4 从Android到通用Java的迁移ArrayMap在androidx.collection包里可以脱离Android环境使用。如果你的Java项目有类似的需求——小数据量、读多写少、内存敏感——完全可以引入这个依赖。但要注意androidx.collection的ArrayMap和Android框架里的ArrayMap在API上略有差异。框架版有一些Android特有的优化androidx版更通用。迁移时注意检查方法签名和返回值。8. 一些踩过的坑和最后的建议先说一个我踩过的坑。有一次在一个列表页里用SparseArray存Item的状态key是position。列表支持拖拽排序每次拖拽后position会大量变化导致SparseArray里频繁插入删除。结果滑动时明显卡顿Profiler一看CPU时间全花在System.arraycopy上。后来换成HashMap问题立刻消失。这个教训是position这种会频繁变动的值不适合做SparseArray的key。另一个坑是关于DELETED标记的。有一次我在遍历SparseArray时删除元素用的是正序遍历加remove。代码逻辑看起来没问题但测试发现偶尔会漏掉一些元素。排查了很久才意识到是DELETED标记和数组移动的交互导致的。改成倒序遍历后问题解决。还有一个关于ArrayMap的坑。我用ArrayMapString, Bitmap做图片缓存key是图片URL。后来发现内存占用比预期高很多。原因是ArrayMap的mHashes数组和mArray数组都会随着数据量增长而扩容而且不会自动收缩。调用trimToSize后内存降下来了。所以如果你用ArrayMap做缓存记得在数据稳定后trim一下。最后给几条实用建议数据量小于500且key是int无脑用SparseArraykey不是int但数据量小用ArrayMap数据量大于1000或插入频繁用HashMap遍历时删除用倒序或者先收集后处理预设容量能省扩容开销但别设太大定期trim或gc避免数组膨胀多线程场景加锁或换ConcurrentHashMap性能问题先测量再优化别凭直觉这些经验都是从实际项目里一点点攒出来的希望能帮你少走些弯路。数据结构和算法的选择从来不是非黑即白理解每种结构的取舍根据具体场景做判断才是工程师该做的事。

Android性能优化：SparseArray与ArrayMap替代HashMap的深度解析

相关推荐

用LangChain实现RAG问答链路：从环境配置到多轮对话实战

ClawGUI Episode记录与回放：把每次GUI任务变成可复用训练数据的技巧

EtherCAT高速高精运动控制方案：选型、配置与调试避坑指南

更多资讯

基于深度学习的NCF视频推荐：源码拆解与工程化实践

基于改进Unet的高分辨率城市建筑物遥感变化检测毕设方案

MATLAB异构特征ERM建模：工业/医疗/金融多源数据统一分类

LSTM与EKF融合：不靠地图的路径跟踪与轨迹预测方法

2026年，TaoToken让AI从“会聊天”到“能办事”：全民Agent时代已来临！

Function Call、Agent、MCP、RAG 四件套：把 endpoint 改到 TaoToken 的联调清单

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？