线上内存泄漏这事，最让人难受的地方从来不是"查不到"，而是你明明知道它就在那儿，却不敢在用户手机上把检测开关打开。我前后在三个项目里做过内存治理，早期都是 LeakCanary 一路用到底，后来做线上监控时才换成 KOOM，中间踩的坑足够写一篇长文。这篇就聊清楚一件事：LeakCanary 和 KOOM 到底差在哪，为什么线上监控这个场景最后会落到 KOOM 上。核心不是谁比谁强，而是两者被设计出来时解决的问题完全不同——LeakCanary 服务的是"我在开发机上把这条泄漏链找出来"，KOOM 服务的是"我在几十万台真实设备上把内存问题的分布摸清楚"。如果你正在做 Release 包的稳定性建设，或者纠结要不要把 LeakCanary 带进线上，下面这些内容应该能帮你少走几个月弯路。
1. 先把两者的定位差异摆清楚
1.1 LeakCanary 的强项是"确定性"，不是"覆盖面"
LeakCanary 的工作模型很朴素：你告诉它"帮我盯着这个对象"，它就用一个WeakReference把这个对象包起来，同时把引用注册到一个ReferenceQueue上。对象被正常回收时，弱引用会进队列，一切安好；如果一轮 GC 之后它还在队列外面，说明有人还攥着它不放——这时候就进入"疑似泄漏"状态。等到这种疑似对象攒到阈值（默认是 5 个），它才真正触发一次 heap dump，然后用 Shark 把 hprof 解析成一张引用链图，告诉你"这个 Activity 被某个静态 Map 里的 Value 挡住了"。
这套机制的价值在于结论的可信度极高。它不猜、不采样、不聚合，拿到的就是那一刻完整的堆快照，引用链一环一环都对得上。所以你在开发机上看到它报出来的泄漏，基本不需要怀疑是不是误报，直接去改代码就行。
但顺着这个逻辑往下推，代价就出来了：为了拿到这份"确定"，它必须在你的进程里做一次完整的Debug.dumpHprofData。这个调用在 Android 上是挂起所有线程的，Java 层、Native 层、GC 线程，全部停下来等文件写完。堆越大人越卡，这是物理规律，不是实现问题。
1.2 KOOM 解决的问题是"线上可观测"
KOOM 的思路完全反过来。它不追求"我看一眼就要看到底"，它追求的是在尽量不打扰用户的前提下，把内存异常的样本采回来。所以它做的事情是一整套流水线：周期性看内存水位，水位越过阈值就取一次快照，快照的过程丢到子进程去做，解析完只把"疑似泄漏的对象 + 关键引用关系"这些轻量结论传回来，最后在服务端做聚合和聚类。
这个差别听起来像是工程优化，实际上是设计目标的差别。LeakCanary 的 API 设计假设调用方是开发者，可以等几秒钟看结果；KOOM 的 API 设计假设调用方是运行在兜里的手机，用户正在刷视频，你不能让画面卡住。
我把两者的能力摆到一张表里，对比起来更直观：
| 维度 | LeakCanary | KOOM |
|---|---|---|
| 主要使用阶段 | 开发、内测、QA | Release 灰度、全量 |
| 触发方式 | 弱引用观察 + 疑似对象计数 | 内存水位阈值 + 周期性扫描 |
| dump 执行位置 | 当前进程内 | fork 出的子进程 |
| 主进程阻塞 | 秒级冻结 | fork 瞬间短暂停顿 |
| 分析产物 | 完整引用链，可视化 | 疑似对象、类名、聚合 ID |
| 单次内存放大 | 约 1.5 到 2 倍堆占用 | 主要由子进程承担 |
| 适合的设备范围 | 中高端测试机 | 从低端到高端的全量设备 |
| 对线上包体积影响 | 较大（含 Shark 解析器） | 可通过裁剪控制 |
这张表不是用来评判优劣的。LeakCanary 在它该在的位置上无可替代——你把一个泄漏样本丢进它手里，它给你的定位精度是 KOOM 给不了的。真正的问题在于：很多人把开发期工具直接搬到了线上，然后就卡在了"开了就崩、不开就瞎"的死循环里。
2. 线上环境照搬 LeakCanary 会踩到什么
2.1 一次 dump 到底有多贵
先算笔账，把"贵"这个模糊感受变成具体数字。假设一台中端机，dalvik.vm.heapmaxsize是 256MB，出问题时进程实际堆占用大约 200MB。一次Debug.dumpHprofData产生的文件大小通常是堆占用的1.0 到 1.3 倍，取中间值算 220MB。
写入速度这块，Android 上大文件顺序写大概在 60 到 120MB/s 之间波动，但 dump 不是纯顺序写——它要遍历整个堆的对象图，边遍历边序列化，实际吞吐会掉到 40MB/s 左右。220MB 除以 40MB/s，光写文件就要 5 秒以上。这 5 秒里所有线程都是停的，主线程不响应触摸，超过 5 秒就是一次标准 ANR。
我自己实测过一组数据，放在下面这张表里：
| 堆占用 | hprof 大小 | 写盘耗时 | 解析耗时 | 用户可见表现 |
|---|---|---|---|---|
| 64MB | 约 70MB | 1.2 到 1.8s | 0.8s | 明显卡顿一下 |
| 128MB | 约 140MB | 2.5 到 3.5s | 1.5s | 页面冻结，可能丢帧 |
| 256MB | 约 280MB | 5 到 7s | 3s | 大概率 ANR |
| 400MB 以上 | 400MB+ | 8s+ | 5s+ | 几乎必 ANR，低端机直接被杀 |
你要注意最右边那列——这不是"会不会卡"的问题，是"会不会被系统杀掉"的问题。低内存设备（比如 2GB RAM 的机器）在 dump 期间，进程的 RSS 会从 200MB 涨到接近 400MB（原进程数据 + 文件页缓存 dirty page），这时候系统的 low memory killer 一旦判定内存紧张，第一刀就砍在你身上。用户在后台被杀，下次打开就是冷启动，体验断崖式下跌。
2.2 线上的触发条件根本不受你控制
开发机上的内存曲线是平滑的，你跑一个固定的操作路径，堆占用从 80MB 缓慢涨到 120MB，LeakCanary 在这个区间里从容地做它的观察和判断。但线上完全不是这么回事。
真实用户的行为是没有边界的：有人会把相册里的 200 张 4K 照片一次性导入，有人会在商品详情页连续滑动半小时，有人开了十几个悬浮窗。堆占用曲线是锯齿状的，上一秒 100MB，下一秒吃进一张大图就飙到 220MB。LeakCanary 的判定逻辑遇到这种曲线会非常难受——它观察的 Activity 实例可能只是还没来得及被 GC，而不是真的泄漏。这时候它一旦误判，就要走一次完整的 dump 流程，而这次 dump 是在用户正在用的时候做的。
更麻烦的是触发频率。LeakCanary 的retainedVisibleThreshold默认是 5，意味着每观察到 5 个疑似对象就 dump 一次。开发机上你根本走不到这个阈值就发现问题了，但线上一个高频页面如果真有泄漏，几分钟内就能触发好几次。我见过最夸张的一个案例，某个页面在 10 分钟里触发了 7 次 dump，用户手机烫得能煎蛋。
2.3 包体积和分析器的隐性成本
还有一个经常被忽略的点：Shark 解析器本身是有体积的。LeakCanary 从 2.x 开始全面换成 Kotlin 实现的 Shark，相比 1.x 的 haha 已经精简很多，但整个库加上依赖打进 release 包，增量大概在几百 KB 到 1MB 之间（取决于混淆和 R8 的裁剪效果）。
对于一个日活百万级的应用，这 1MB 意味着下载转化率的实打实损失。而且这 1MB 在线上是纯负担——解析逻辑在用户手机上跑，除了耗电和占内存，对用户体验没有任何正向价值。
所以当有人问我"能不能把 LeakCanary 带进 release"，我的回答通常是：可以做技术验证，但别指望它成为线上监控的主力。它更像一把手术刀，你带它上战场，它确实锋利，但它不防水。
3. KOOM 的核心机制拆解
3.1 三段式：监控、冻结、分析
KOOM 的整个设计围绕一个核心矛盾展开：要拿到准确的堆快照，就必须 dump；要 dump 就必然冻结进程；但线上不能冻结进程。它给出的解法是把这三件事拆开，分别放到不同的执行实体里。
第一段是监控。主进程里跑一个轻量的观察者，它做的事很克制——定期看一眼当前进程的内存占用，跟设定的阈值比一比。这个动作的代价几乎为零，不碰堆、不遍历对象，就是读几个系统计数器。
第二段是冻结（也就是 dump）。这一步是整个方案的关键，KOOM 用fork()复制出一个子进程，让子进程去执行Debug.dumpHprofData。因为 fork 之后父子进程是两份独立的内存视图，子进程冻结自己的线程去写文件，父进程该干嘛干嘛。用户在子进程 dump 的那几秒里，完全感知不到异常。
第三段是分析。子进程 dump 完，接着在子进程里把 hprof 解析掉，提取出疑似泄漏的对象、它们的类名、以及关键的那几层引用关系，然后把这份轻量结果通过管道或文件回传给主进程，最后由主进程决定要不要上报。
这个拆分带来的收益是数量级的。原本 5 秒的主进程冻结，变成了 fork 瞬间的几十毫秒停顿（fork 本身要复制页表，堆越大越慢，200MB 的堆大概 30 到 80ms）。用户顶多感觉到一次极轻微的掉帧，而不会看到白屏或者 ANR 弹窗。
3.2 fork 子进程到底省了什么，又付出了什么
这里需要说清楚一个容易误解的点：fork 不是免费的。有人以为 fork 出去就万事大吉，实际上 fork 之后父子进程共享物理页（Copy-On-Write），但只要任何一方写入某个页，那个页就要被真实复制一份。dump 的过程本质上是遍历所有对象并序列化，这个动作会大量触发 COW 复制，所以物理内存的峰值仍然是会涨的，只是涨在子进程身上，而且涨得比你想的要少。
实测下来，200MB 堆的应用，fork 后子进程负责 dump，整机内存峰值大概增加60 到 120MB，而不是完整的 200MB。原因在于 hprof 的序列化是流式的，写完的内存页可以被回收，不会像进程内 dump 那样把整个对象图都保持在活跃状态。
付出的代价主要是三点。一是 fork 在部分定制 ROM 上不稳定，可能返回失败或者子进程被系统限制；二是子进程的 dump 时间会比进程内 dump 略长，因为要处理 COW 缺页；三是你必须处理子进程崩溃的场景——子进程挂了不能影响主进程，这个隔离性要靠waitpid和信号处理来保证。
注意：fork 出来的子进程里，很多 Android 框架层的 API 是不可用的（比如 Binder 调用、Looper），因为你只复制了内存状态，没复制线程。所以子进程里只能做纯计算和文件 IO，任何涉及系统服务的调用都要避免。
3.3 hprof 裁剪才是真正的成本杀手
如果只做 fork，文件该多大还是多大，220MB 的 hprof 写到磁盘上一样要命。KOOM 在这里做了一件很关键的事：裁剪。
它的思路是，线上监控根本不需要完整的堆快照。你需要的是"哪些对象不该活着却活着"以及"它们被谁引用着"，至于那些byte[]里存的图片像素、char[]里存的字符串内容，对你定位泄漏毫无帮助，纯属噪音。
所以 KOOM 在 dump 和解析的过程中做了几层过滤：
- 剥离大对象的原始数据。Bitmap 的像素缓冲区、长数组的内容体，只保留对象头和长度，不写实际字节。这一刀下去，图片密集的应用文件体积能砍掉 60% 以上。
- 只保留关键类的实例。Activity、Fragment、Dialog、Bitmap、Drawable、各种 Adapter，这些是泄漏的高发区，其余的普通 POJO 做聚合统计就行。
- 引用链只保留路径上的必要节点，不做完整图存储。
再加上解析完就删文件，整条流水线的磁盘压力比进程内 dump 小一个数量级。我见过一个堆占用 300MB 的应用，裁剪后的 hprof 只有40MB 左右，解析时间也从 5 秒压到了 1.5 秒。
3.4 触发阈值怎么定，这是个技术活
KOOM 的触发策略比 LeakCanary 保守得多，参数也更丰富。核心的几个配置项大致是这样的（不同版本的字段名会有差异，以你手上的 API 为准）：
| 参数 | 典型取值 | 含义与调优思路 |
|---|---|---|
| 监控周期 | 60s | 太短会频繁读计数器，太长会错过瞬时峰值 |
| 内存水位阈值 | maxMemory 的 80% | 定太低会误触发，定太高可能已经 OOM |
| 单进程单日上报上限 | 3 到 5 次 | 防止问题应用疯狂上报拖垮服务端 |
| 最小触发间隔 | 30 分钟 | 同一进程短时间内重复 dump 意义不大 |
| 设备内存下限 | 2GB | 低于这个值直接关闭，避免拖垮低端机 |
| 采样率 | 灰度期 100%，全量期 5% 到 10% | 全量时靠采样控制成本 |
这里重点说80% 这个水位线是怎么来的。Android 的堆增长是分代回收的，当占用接近上限时，GC 会变得更频繁但回收效果变差（因为剩下的多是长生命周期对象）。在 80% 这个位置 dump，既能保证"确实有问题"，又能避免"还没到临界点就提前惊动"。如果定到 95%，你可能刚 fork 出去，主进程就因为一次大对象分配触发了 OOM——那时候子进程还在 dump，救都来不及。
4. 把 KOOM 接进项目的实操步骤
4.1 依赖引入与初始化时机
依赖这块没有太多花活，按模块化拆开引，用不到的模块别引，包体积能省一点。核心是三个：Java 堆泄漏监控、线程泄漏监控、OOM 监控。Native 泄漏监控要不要引，看你有没有大量的 native 内存使用（比如图像处理、音视频解码），没有就先不引。
// 坐标按你实际引入的版本填写，各模块独立，按需引入 dependencies { implementation "koom-java-leak:${koomVersion}" implementation "koom-thread-leak:${koomVersion}" implementation "koom-oom-monitor:${koomVersion}" // 有 native 内存诉求再加这个 // implementation "koom-native-leak:${koomVersion}" }初始化的位置很关键。不要放在Application.onCreate的最前面，那个时机进程刚起来，很多东西还没就绪，而且会拖慢冷启动。我一般放在onCreate的末尾，或者干脆延迟到首帧渲染完成之后，用Choreographer挂一个 post 回调：
class App : Application() { override fun onCreate() { super.onCreate() // 其他初始化... deferInitMonitor() } private fun deferInitMonitor() { Choreographer.getInstance().postFrameCallback { // 首帧之后再启动，避免影响启动耗时 val config = KOOMInitConfig().apply { enableOOMTracker = true enableJavaLeakMonitor = isMainProcess() // 只在主进程开 enableThreadLeakMonitor = false // 初期先关，观察稳定后再开 setDeviceMemLowerBound(2 * 1024L) // 低于 2GB 的设备不启用 } KOOM.init(this, config) } } private fun isMainProcess(): Boolean { val name = getProcessNameByPid(Process.myPid()) return packageName == name } }注意enableJavaLeakMonitor这个开关，只在主进程开。多进程应用里如果每个进程都跑监控，fork 的次数会成倍增长，系统资源扛不住。子进程的泄漏问题用其他手段排查。
4.2 按设备档位做分级配置
这是我在实际项目里最推荐的一个做法：不要用一套参数打天下。线上设备从 2GB 的千元机到 12GB 的旗舰机混在一起，你用统一的水位线，要么低端机被拖死，要么高端机根本触发不了。
我的做法是读取ActivityManager.MemoryInfo里的totalMem，把设备分成三档：
| 设备内存 | 监控策略 | dump 阈值 | 上报频率 |
|---|---|---|---|
| 2GB 到 3GB | 只开 OOM 追踪，不做堆 dump | 不 dump | 仅上报 OOM 事件 |
| 4GB 到 6GB | 全量监控，低采样 | maxMemory 的 85% | 单日最多 2 次 |
| 8GB 以上 | 全量监控 | maxMemory 的 75% | 单日最多 5 次 |
低端机那档为什么直接关掉堆 dump？因为这类设备的可用内存本来就紧张，fork 一次子进程所需的额外内存可能就是压垮骆驼的最后一根稻草。与其冒着被系统杀掉的风险去采一个样本，不如老老实实把 OOM 的堆栈和内存分布上报回来，起码不伤害用户体验。
4.3 上报数据怎么读才有效
KOOM 上报回来的不是一份漂亮的引用链图，而是一堆结构化的字段。第一次看的时候会有点懵，我列一下最关键的几个：
- 疑似泄漏对象的类名和实例数量。比如
MainActivity出现了 3 个实例，正常情况下应该只有 1 个，那多出来的 2 个就是嫌疑对象。 - 引用链的类名前缀序列。完整链路可能有三四十层，但真正有用的是最后那几层，通常是
静态字段 -> 集合 -> 对象这样的模式。 - 该对象的 retain size。也就是这一条泄漏链一共拖住了多少内存，这个数字决定优先级——泄漏一个 200KB 的 Bitmap 和一个 20MB 的缓存池，处理顺序完全不一样。
我一般会在服务端做一个聚类：把引用链的最后三层类名拼成一个 key，相同 key 的样本聚到一起，按样本数排序。这样跑一周之后，Top 10 的泄漏点基本都能浮出来，剩下长尾的可以慢慢处理。
4.4 灰度开关和紧急降级
线上监控最怕的事情是监控本身成了故障源。所以必须在配置中心留三个开关，而且要做到毫秒级下发：
object MonitorSwitch { @Volatile var globalEnable = true // 总开关，出问题一键关停 @Volatile var dumpEnable = true // 只关 dump，保留 OOM 追踪 @Volatile var sampleRate = 0.1f // 采样率动态调整 fun shouldDump(): Boolean { if (!globalEnable || !dumpEnable) return false return Random.nextFloat() < sampleRate } }这三个开关的组合很有讲究。如果发现某个版本 dump 导致的崩溃率上升，先关dumpEnable保住基本盘，OOM 追踪还在跑，你能知道问题有没有恶化。如果情况更严重，直接关globalEnable，整个监控停摆，不影响业务。这种事我经历过两次，第一次没准备好开关，靠发版回滚，损失了一整天的数据。
5. 线上落地踩过的坑与排查思路
5.1 fork 失败与子进程异常退出
这是最高频的问题，表现是"监控开着但一直没有数据"。排查的第一步是看日志里有没有 fork 相关的错误码。
常见的失败原因有三类。一是进程数达到上限，Android 对单个应用的后台进程数有限制，如果你在 fork 的同时还有别的操作在创建进程，可能直接被拒。二是部分定制 ROM 对 fork 做了拦截，某些加固方案会 hookfork系统调用。三是内存不足导致 fork 返回 ENOMEM，虽然 COW 让 fork 看起来不占内存，但页表的复制本身是要分配内存的，堆越大页表越大。
应对方式是把 fork 的成功率作为一项监控指标上报，低于某个阈值（比如 70%）就说明这个版本在你的用户群里有兼容性问题，需要降级到其他采集手段。
5.2 低内存设备的连锁崩溃
我在一个项目上遇到过这种情况：加了 KOOM 之后，某些机型的崩溃率反而上升了 0.3 个百分点。抓回来一看，全是OutOfMemoryError，堆栈都在系统层。
原因是这类设备的可用内存本来就在临界点，fork 出来的子进程虽然共享内存，但在 dump 过程中触发了大量 COW 复制，物理内存瞬间涨了 80MB，直接触发系统的内存回收。系统回收的第一优先级就是杀掉后台进程，而你的子进程正好在被判定为"可牺牲"的行列里。
解决办法是把设备内存下限从 2GB 提到 3GB，同时对ActivityManager.MemoryInfo.lowMemory做实时判断——只要系统报告内存紧张，立刻跳过本次 dump。
5.3 误报把团队带偏方向
KOOM 的判定是推断而非证明。它看到某个 Activity 实例在水位超阈值时还活着，就把它标记为疑似泄漏，但"还活着"和"泄漏"之间还差着一次 GC。
我遇到过一个典型案例：某个列表页的 Activity 被反复标记为泄漏，团队花了两周去查，最后发现是那个页面的退出动画有 800ms 的延迟，动画期间 Activity 引用被动画控制器持有，属于完全正常的行为。KOOM 恰好在动画播放的那 800ms 里触发了 dump，就把它抓进去了。
这类误报的过滤办法是看复现率。单次出现的疑似对象先不处理，同一个类在多个不同用户的样本里反复出现（比如出现在 50 个以上独立设备的上报里），才认为是真问题。这个阈值可以根据你的日活规模调整，日活大的应用可以定高一点。
5.4 常见问题速查表
把上面这些整理成一张表，出问题时按图索骥会快很多：
| 现象 | 可能原因 | 排查手段 | 处理方式 |
|---|---|---|---|
| 监控开着但没数据 | fork 失败、开关未生效 | 查 fork 返回码、配置下发日志 | 提高设备下限，检查配置中心 |
| 崩溃率上升 | 低端机 fork 内存放大 | 按设备内存分档看崩溃分布 | 关掉低端机的 dump |
| 上报量爆炸 | 采样率过高、阈值过低 | 看单设备日均上报次数 | 降采样，提高水位阈值 |
| 疑似对象都是误报 | dump 时机撞上正常持有 | 看样本的复现率 | 提高复现阈值再决策 |
| 解析耗时过长 | hprof 未裁剪、堆太大 | 看子进程耗时埋点 | 开启裁剪，限制 dump 大小 |
| 子进程残留 | 未正确处理 waitpid | 查进程列表 | 加超时强杀逻辑 |
提示：所有跟 fork 相关的日志都要带上设备型号、内存档位、堆占用这三个字段。没有这三个字段，你在服务端根本没法判断是兼容性问题还是策略问题。
6. 两者怎么配合，而不是二选一
6.1 开发阶段让 LeakCanary 干它最擅长的事
我现在的工作流是这样：日常开发、提测、内测阶段，LeakCanary 全开，retainedVisibleThreshold调到 2 甚至 1，宁可多 dump 几次也要把问题早发现。因为这个阶段设备是测试机，卡一下无所谓，重要的是定位精度。它给出的那条完整引用链，能让你在十分钟内改完代码，而靠 KOOM 的聚合数据去反推，可能要花半天。
而且 LeakCanary 的AppWatcher可以自定义监控对象，你把手写的单例、缓存池、各种 Manager 都注册进去，它能帮你盯住那些框架层管不到的地方。这个能力 KOOM 是没打算做的。
6.2 线上阶段让 KOOM 承担采样职责
发版之后，LeakCanary 完全摘掉（通过debugImplementation保证不进 release），KOOM 接管。这个阶段的目标不是"精确定位某一条泄漏"，而是"知道大盘上内存问题的分布"——哪些页面是高发区，哪些机型问题集中，哪个版本引入的新问题最多。
这里有个细节值得说：KOOM 采回来的样本，可以拿到开发环境用 LeakCanary 复现。你在服务端看到某个类反复出现，就照着它的引用链前缀在测试机上复现那个操作路径，然后用 LeakCanary 抓一次完整的，两边一对照，效率比单用任何一个都高。
6.3 建一条从线上到本地的数据回流链路
我最后落地的一套流程是这样的：KOOM 在线上按 10% 采样跑，每天汇总一次疑似泄漏的聚类结果，按"影响设备数 × retain size"排序，Top 20 自动生成工单进研发队列。研发拿到工单后，在本地用 LeakCanary 复现，改完提交，下一个版本观察这个聚类的数据是否归零。
这条链路跑顺之后，内存问题的平均修复周期从原来的三周压到了一周左右。关键不在于工具多先进，而在于每个环节用的都是该环节最合适的工具——线上要的是覆盖面和不打扰，本地要的是精确和可复现。
再分享一个我在实际配置里的小技巧：KOOM 的水位阈值不要写死成maxMemory * 0.8，而是用近 10 次采样的滑动平均值去判断。因为单次采样很容易被瞬时大对象干扰，滑窗能把这种噪音滤掉，触发准确率能提升一大截。这个改动在代码里就是维护一个固定长度的队列，代价很小，但效果肉眼可见——我们调整之后，无效 dump 的比例从 40% 降到了 12% 左右。
最后一个体会：内存监控这件事，工具选型只占两成，剩下八成是你怎么处理数据。KOOM 给你的是原料，能不能炒出菜，取决于你有没有建好聚类、排序、复现、验证这一整套流程。工具换了一茬又一茬，流程沉淀下来才是真的资产。
