Perfetto 内存分析用 heapprofd 抓住 Android 内存泄漏【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto凌晨的告警群弹出一条消息某购物应用线上 OOM 率在过去两小时抬升OutOfMemoryError的堆栈里夹着一段 2MB 的Bitmap分配失败。监控平台上那条 RSS 曲线更刺眼——从用户打开应用那一刻起进程驻留内存像台阶一样逐级上爬40 分钟后被lmkd一把杀掉。奇怪的是LeakCanary 在开发机上跑同样的操作什么也没抓出来。这类复现不出来、总量看着还行、却越用越肿的 Android 内存优化难题往往不是靠多打几个 log 能解决的。真正需要的是一个能把每一块未释放内存钉到具体调用栈上的工具——Perfetto 里的 heapprofd 模块正是干这个的。先把内存长在哪想清楚拿到一条异常曲线最忌讳的动作是一把梭地开全量 trace。先问一句涨的是 Native Heap 还是 Dalvik Heap用adb shell dumpsys meminfo pid看两行数字就能定调。如果 Native Heap 在涨即便你的 App 一行 C/C 都没写也正常——java.util.regex这类框架 API 底层就是 native 分配。此时选 heapprofd它 hook 住malloc/free把分配了没释放的字节归到调用栈上源码在 src/profiling/。如果涨的是 Dalvik Heap情况分两种。想看哪些对象在活着、谁牵着谁不放用 ART heap dump要求 Android 11它给你一张活对象可达性图能回溯整个堆但代价是看不到对象是在哪一行 new 出来的。想反过来盯对象创建点的分配压力用 ART 分配剖析--heaps com.android.art要求 Android 12它按调用栈聚合创建点适合查 Java 侧的 churn。图1Perfetto heapprofd 火焰图顶部是线程入口越往下越接近真正调用 malloc 的代码还有一类容易被漏掉直接mmap的大块内存。它不走 mallocheapprofd 天然看不见。这类量通常不大、出现频率低可以用linux.perf设period: 1逐次采样或走 ftrace 的 mmap 系统调用事件Android 14单独抓。别指望一个 trace 解决所有问题先把内存分类再动手能少走大量弯路。采样参数一张表定生死heapprofd 是采样式的——每分配n字节平均命中一次采样并补记n字节靠这个比例把开销压下来。默认n 4096。几个参数值得你下笔前就选好而不是事后重抓参数默认作用何时改大 / 改小-i/--interval4096采样间隔字节分配速率极高、缓冲溢出时调大到 16000查小对象泄漏时调小--shmem-size8MiB客户端到 heapprofd 的环形缓冲瞬时分配尖峰导致提前结束时调大-c0关连续快照间隔ms想画随时间爬升曲线时设 5000-d0到 Ctrl-C采集时长ms复现路径固定时设死便于前后对比--dump-at-max关按峰值而非结束时导出峰值转瞬即逝、结尾已回落时启用图2Perfetto 录制页勾选 Native heap profiling 后填写进程名可直接从浏览器抓这里有个反直觉的坑我当年栽过一次。⚠️误区只看总内存只盯 RSS 或dumpsys的总占用是危险的。总量平稳不代表没泄漏——某个对象类型持续累积只要还没触发 GC 回收总量曲线照样健康。盯未释放内存的占比和对象生命周期这两个维度比盯总量靠谱得多。⚠️误区指望它追溯过去heapprofd不是回溯式的只记录 trace 开始之后的分配。问现在为什么这么大它答不了问接下来还会不会继续涨它最在行。要抓启动阶段就得在进程还没起来时先开-n 进程名让它跟着 zygote 一起从出生跟到死亡。三个案例三种抓法参数只是入场券真正决定成败的是针对现象选对姿势。下面三个案例各自独立读完你会发现套路会自己长出来。案例一夜间模式切换后的 15MB 不释放某社交 App 切一次深色模式Native Heap 加 15MB 且再也不回。我按复现路径开-d 15000切完立刻收火焰图里AssetManager一路高下去。关键动作是在过滤器里敲关键字让火焰图聚焦到那条栈一眼看出ThemeManager用 Activity 上下文缓存了整套样式。把上下文换成ApplicationContext重跑同一条命令对比增量从 15MB 掉到 2MB。前后各抓一次、同一命令、同一时长对比才有说服力——别让感觉变好了替代数据。案例二新闻列表越滚越涨列表类问题要看随时间的形状单张快照不够。这里开连续快照-c 5000UI 里会铺出一排 slice每个 slice 是一段窗口的未释放汇总鼠标拖选连续几个还能合并统计。滚 30 条再停曲线是标准台阶——每次上滑叠一级几乎不释放。切到 Unreleased Malloc Count 而非 Size小对象泄漏立刻显形单张几 KB但 Bitmap 缓存没回收数量堆起来就是灾难。修复回收逻辑后同样 30 次操作曲线平了。图3ART 分配剖析视图按调用栈聚合 Java 对象创建点适合查 churn案例三启动阶段的隐性堆积前两个都能现场复现启动泄漏最磨人——用户冷启动那一下的分配等你连上 adb 早没了。解法是用进程名而非 PID-n com.example.app会命中之后新拉起的所有同名进程从 zygote 特化那一刻就开始采。收完拿 SQL 把调用栈一次性拉平比在火焰图里一层层翻快得多INCLUDE PERFETTO MODULE android.memory.heap_profile.summary_tree; SELECT name, mapping_name, cumulative_size FROM android_heap_profile_summary_tree ORDER BY abs(cumulative_size) DESC;这条查询按该函数出现在栈上任意位置累计未释放字节降序排完头部几行就是启动期没放回去的常驻块对着mapping_name直接翻代码。进阶与长期机制把偶发问题变成持续防线靠的是把工具接进流程。三条能立刻做的自定义分配器也要能被抓。你手写的内存池走的是自己的my_mallocheapprofd 看不见。用 Custom Allocator APIAndroid 10把每次分配/释放上报进去即可伪代码auto heap AHeapProfile_registerHeap(AHeapInfo_create(image_cache)); // my_malloc 内: AHeapProfile_reportAllocation(heap, ptr, size); // my_free 内: AHeapProfile_reportFree(heap, ptr);离线符号化与混淆还原。栈里全是地址或混淆名时对 trace 跑trace_processor做符号化Java 侧再喂 ProGuard map 还原否则你抓到的只是第 47 帧 unknown。版本差异心里有数。heapprofd 最低 Android 1032 位程序在 64 位设备上不能采ART 分配剖析要 12Android 12 上 Java 帧回溯偶发缺名13 QPR1 才修稳。低版本设备上的空 profile多半不是泄漏是目标进程根本不 eligible——user构建下只有debuggable或profileable的 App 能采。把这些落成制度CI 里固定抓启动 一次核心用户旅程两段 trace设内存预算做回归告警每个季度全量审计一次。Perfetto 的 trace_processor 支持 SQL 批量解析意味着这套流程能脱离人眼、跑成脚本——docs/ 里有完整的分析文档tools/heap_profile 是采集入口。可立即落地的四件事用dumpsys meminfo先分清 Native / Dalvik再决定用 heapprofd 还是 ART heap dump。复现路径固定的用-d定死时长、-c 5000开连续快照前后各抓一次做 diff。启动泄漏用-n 进程名冷启动采集收完用summary_tree模块一次拉平调用栈。把上面这套写进 CI配一条内存预算回归线。工具摆在你手边了命令也就这么几行。真正的问题是——你上一次看那条越爬越高的 RSS 曲线时是顺手刷过去了还是停下来抓了一帧【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考