App性能体验之内存抖动篇

页面越滑越卡， Memory Profiler 里的内存曲线却总能掉下来。

没有明显泄漏，也没有 OOM ，团队很容易得出一个结论：内存没问题。

恰恰相反。

内存抖动最麻烦的地方，就是它会把垃圾及时清掉，却在清理之前不断制造卡顿、 CPU 消耗和功耗。

它不是“留住太多对象”，而是“太快地创建、太快地丢弃”。

先分清：抖动、泄漏和 OOM 不是一回事

内存泄漏关注的是：对象本该释放，却仍被引用。多次执行同一操作后，基线持续抬高，即使 GC 之后也回不去。

内存抖动关注的是：热点路径持续产生大量短命对象。堆内存快速上涨， GC 后又快速下降，曲线像密集锯齿。

OOM 则是结果。它既可能来自泄漏，也可能来自一次大对象申请、瞬时峰值或缓存失控。

判断内存抖动，可以记住一个简单模型：

抖动风险 ≈ 分配速率 × 对象体积 × 热点频率

单个对象只有几百字节并不可怕。可怕的是它出现在每一帧、每一次 Bind 、每一个滚动事件里。

现代 ART 的 GC 很多工作可以并发完成，但回收仍会占用 CPU ，也可能带来线程暂停和堆调整。当它与动画、滑动、启动竞争资源时，用户看到的就是“偶尔顿一下”。

第一类现场： UI 热路径每次都在“重新准备”

Case 1 ： onDraw 每帧创建对象

常见错误并不隐蔽：在 onDraw() 里创建 Paint 、 Path 、 Rect 、渐变、集合，甚至临时 Bitmap 。

60Hz 下，一秒可能执行 60 次；高刷屏更密。一次分配看起来很小，乘上帧率和多个 View 后，分配速率会迅速放大。

定位：录制一次稳定动画或连续滑动，在 Memory Profiler 的 Java/Kotlin Allocations 中按类和调用栈排序。如果 Paint 、 RectF 、 Path 等对象持续从绘制栈产生，证据就很直接。

最优解：把 Paint 、 Path 、 Rect 等可变对象作为成员复用；尺寸变化时再更新几何数据；静态内容提前缓存。不要缓存依赖旧尺寸或旧主题的结果，否则省下分配，却引入显示错误。

Case 2 ： RecyclerView 的 Bind 变成对象工厂

onBindViewHolder() 里格式化日期、创建 Span 、拼接富文本、生成点击监听、复制列表、构建 Shape ，都是高频分配点。

快速滑动时，同一秒可能触发几十次 Bind 。若图片请求还反复创建转换参数和临时 Drawable ， GC 往往会与列表滚动同时出现。

定位：同时观察 RV OnBindView 与分配记录，按调用栈找到由 Bind 创建的短命类型。只看某一刻的堆快照容易漏掉，因为这些对象可能已经被回收。

最优解：数据层提前生成展示模型；复用 Formatter 、 Span 配置和监听器；使用 DiffUtil 与 payload 做局部更新；图片明确目标尺寸。 Bind 的职责应该是赋值，不是现场加工。

Case 3 ： Compose 重组时反复排序、过滤和建集合

下面这些写法都可能在重组时重复分配：

定位：用 Layout Inspector 查看重组与 Skip ，再把重组区间与分配记录对齐。重组次数多不一定有问题，关键是重组是否在制造大量新对象。

最优解：昂贵计算放进 remember；派生状态用 derivedStateOf 控制无意义更新； Lazy 列表提供稳定 Key ；频繁状态尽量延迟到 Layout 或 Draw 阶段读取。模型保持不可变，但不要用错误的稳定性注解换取表面 Skip 。

UI 优化不是“完全不分配”，而是让热点路径不重复分配同一份意义。

第二类现场：一份数据在链路里复制了五遍

Case 4 ：集合链式操作与字符串拼接

Kotlin 的 map、filter、sortedBy、groupBy 很好读，但连续调用时可能创建多个中间集合、 Iterator 、 Lambda 与包装对象。

日志也经常被忽略：即使当前日志级别不输出，字符串模板和参数组装也可能已经发生。

定位：在真实数据规模下录制一次搜索、排序或刷新，查看 ArrayList 、数组、字符串及业务模型的分配调用栈。不要因为 CPU 方法耗时不高就排除它——分配成本和后续 GC 可能出现在不同位置。

最优解：先减少中间结果：能一次循环完成就不要创建三层集合；预估容量后使用 Builder ；高频数值计算考虑原生数组，避免装箱。 Sequence 不是自动加速按钮，小数据上它的迭代器和 Lambda 也有成本，必须实测。

Case 5 ：网络、 JSON 、数据库到 UI 层层转换

一份响应可能依次经历 ByteArray 、 String 、 JSON 节点、 DTO 、 Domain Model 、 UI Model ；下载或压缩时又出现多个临时 Buffer 。

对象最终都能释放，但峰值和分配速率已经翻了数倍。大列表全量解析、全量映射、全量排序叠在一起时，抖动尤其明显。

定位：按一次完整业务操作录制分配，检查同一批字段是否在不同模型中重复出现；关注 ByteArray 、 char[]、 String 、集合和 DTO 的分配大小，而不只是实例数量。

最优解：分页或分块处理大数据；避免无意义的 ByteArray ↔ String 往返；使用流式解析处理超大响应； DTO 到展示模型尽量一次完成，并移出交互关键帧。减少复制比“换一个更快的 JSON 库”更优先。

第三类现场：大对象和高频事件轮流轰炸堆

Case 6 ：图片按原图解码，再缩到控件大小

一张压缩文件只有几百 KB ，不代表解码后仍然小。 Bitmap 的内存主要由像素尺寸和像素格式决定。

列表中如果反复解码原图、裁剪、模糊、圆角，再丢弃中间 Bitmap ，就会制造大块内存峰值。缓存太小还会形成“刚解码 → 被淘汰 → 马上又解码”的震荡。

定位：检查 Bitmap 与 ByteArray 的分配大小、图片请求尺寸和缓存命中率；把滚动区间与 GC 、帧时间线对齐。只看 APK 中图片文件大小没有意义。

最优解：请求阶段就指定目标尺寸；缩略图与原图使用不同请求；稳定变换结果进入合适的内存或磁盘缓存；控制预加载窗口。缓存不是越大越好，应该根据页面工作集和低端机内存预算设定。

Case 7 ： Flow 、 RxJava 、传感器回调制造事件洪峰

搜索输入、滚动位置、动画进度、传感器数据、 WebSocket 消息，本来就可能高频到达。每个事件再经过多层 map、combine、封装对象和缓冲队列，短命对象数量会迅速膨胀。

更隐蔽的是生命周期：页面离开后收集仍在继续，既可能变成泄漏，也会继续在后台制造分配。

定位：给事件源和关键 Operator 加 Trace 标签，录制固定时长操作；检查事件产生速率、下游消费速率、缓冲队列和分配类型。先回答“每秒来了多少事件”，再看每个事件有多重。

最优解：对 UI 状态使用 distinctUntilChanged；只需要最新值的场景使用 conflate；输入搜索可以 debounce；采样展示可以 sample。但支付、埋点、消息确认等不可丢事件，不能为了降分配直接合并。收集任务必须绑定生命周期并正确取消。

最高效的对象，是根本没有被创建的对象；最高效的事件，是业务不需要处理的事件。

一套能复现、能归因的定位流程

第一步，固定操作和数据规模。

明确机型、构建类型、页面、数据量和操作时长。 Debug 与插桩本身会增加分配，最终判断要在接近 Release 的环境复核。

第二步，先看形态，再录分配。

堆曲线快速上涨又频繁回落，只能说明“值得怀疑”。使用 Android Studio Memory Profiler 的 Java/Kotlin Allocations 录制 5 ～ 15 秒关键操作，查看类、实例数、分配大小和调用栈。

第三步，把 GC 和用户卡顿对齐。

在 Perfetto 中同时观察 GC 、线程调度和 FrameTimeline 。若异常帧附近出现 GC ，再回到分配记录寻找制造垃圾的调用栈。不要看到 GC 就调用 System.gc()，那只是把回收时间强行提前。

第四步，区分短命对象和被保留对象。

操作结束后停止交互，在分析工具中观察对象是否可回收。基线持续上涨，再转向 Heap Dump 、引用链和泄漏排查；基线能回来但分配速率很高，优先处理抖动。

第五步，用四个指标验收。

优化顺序：先减频率，再减体积，最后谈复用

面对内存抖动，建议按这个顺序处理：

对象池会增加常驻内存、状态清理和并发复杂度。对便宜的小对象，池化可能比直接分配更贵。

另外，别把“优化后 PSS 没下降”当成失败。运行时和分配器可能保留已申请内存供后续复用，系统指标不会立刻归零。真正应该验证的是：同一操作是否少分配、少触发 GC 、少出现慢帧。

内存抖动治理的终点，不是把曲线画平，而是让业务操作不再靠 GC 维持流畅。

最后

内存泄漏像水龙头没关，水位一直上涨。

内存抖动更像有人不停把一桶水倒进去，再立刻舀出去。水位看似安全，人已经累得跑不动了。

下一次页面“内存没涨但就是卡”，别先盯峰值，也别急着扩大堆。

先找到谁在热点路径制造短命对象，再按频率、体积和复制链路逐层拆掉。

你们项目里最夸张的一次内存抖动，最后是图片、列表、 Compose ，还是一条无人注意的事件流？

参考资料