企业官网建设流程全解析

1. 先把问题摆正：线上内存监控到底在监控什么

聊 KOOM 和 LeakCanary 之前，得先把"内存泄漏监控"这件事拆开看。很多人一上来就比较性能、比引用链、比报告格式，但真正决定选型的，是你能不能接受这个工具在用户手机上产生的代价。我接手过一个日活百万级的应用，OOM 率长期卡在 0.7% 上下，用户投诉集中在"用久了变卡""切后台回来就白屏重启"。排查了两周，最后定位到三个问题：某个列表页的 Adapter 持有 Activity 的匿名内部类、几个单例把 Context 存成了成员变量、以及一个第三方 SDK 在后台线程里挂了监听器没注销。这三个问题在开发机上用 LeakCanary 都能秒发现，但在线上，它们像幽灵一样活了半年多。

那次之后我才真正理解：开发期的内存泄漏检测和线上的内存泄漏监控，是两件完全不同的事。前者要的是精度和可读性，后者要的是低开销、可聚合、能持续跑。LeakCanary 把前者做到了极致，KOOM 则把重心放在了后者。这不是谁替代谁的问题，而是两个工具在设计目标上的分岔。

这篇内容适合三类人看：一是正在做线上稳定性治理、需要落地内存监控方案的 Android 开发；二是已经接了 LeakCanary 但发现线上跑不起来、想找替代方案的团队；三是对底层原理感兴趣、想知道"fork 子进程做 dump"这条路为什么能走通的同学。我会把两条链路的实现细节、开销换算、配置方法、踩坑记录都摊开讲，参数怎么算、阈值怎么定、报告怎么聚合，尽量给到能直接抄的程度。所有配置代码以常见实践为基础补全，具体方法名可能随版本略有差异，接入时以你手上那个版本的 API 为准。

1.1 内存泄漏在线上长什么样

先说清楚现象。开发期你用 LeakCanary 抓到的是一个具体的对象、一条具体的引用链、一个具体的类名。线上你面对的是海量用户，你抓不到"某一个对象"，你只能抓到"某一类泄漏在某类机型、某个版本、某个场景下的发生频次和内存占用"。这是一个从"个案"到"分布"的视角切换。

我见过不少人把 LeakCanary 直接打进 release 包，想着线上也能自动抓。结果是：包体涨了几百 KB，用户在高负载场景下频繁触发 dump，主线程卡顿投诉上来了，而抓回来的报告是一堆没法归因的散点——因为线上没有开发者本机那种可控环境，dump 出来的对象图里混杂着大量噪声，你根本分不清哪条引用链是真正的问题。

所以线上监控的第一个前提是：触发要克制，分析要异步，报告要能归类。这三个要求直接决定了后面所有的技术选型。

1.2 两个框架的定位差异，从设计目标就注定了

LeakCanary 的链路是这样的：ObjectWatcher用弱引用包裹你期望被回收的对象，关联一个ReferenceQueue，等待一段观察期（默认 5 秒）后检查引用队列，如果对象还活着，标记为 retained。当 retained 对象数量达到阈值（默认 5 个），触发一次 heap dump，交给 Shark 解析对象图，从 GC Root 做广度优先搜索，找最短强引用路径，最后生成 LeakTrace 展示出来。

注意这个链路的每一个环节：dump 在主进程做，解析在主进程做，UI 通知也在主进程做。它的定位是"开发者本机的显微镜"，前提是你坐在电脑前，看到通知会点进去看，卡一下无所谓。

KOOM 的链路完全不同：它同样有对象监听和内存水位监控，但触发 dump 之后，suspend 所有线程、fork 出一个子进程、由子进程完成 hprof dump 和解析、父进程立刻 resume。父进程的停顿只有 fork 那一瞬间（毫秒级），几百毫秒到几秒的 dump 和解析开销全部转移到了子进程。分析完生成结构化报告，回传父进程上报。

这个差异不是优化级别的差异，是架构级别的差异。它决定了 LeakCanary 在线上是"能跑但不该跑"，KOOM 是"就是为线上设计的"。

1.3 选型前先确认三条硬性约束

在具体对比之前，我建议你先给自己团队定三条线，这三条线定完，选型基本就自动出来了：

• 卡顿容忍度：你的应用能不能接受一次几百毫秒的主线程停顿？如果不能，进程内 dump 的路子直接排除。
• 内存余量：dump 之后解析对象图，峰值内存通常是当前堆占用的 2 到 3 倍。如果你的应用常驻堆在 200MB 以上，跑在 3GB 内存的低端机上，这个峰值足够触发系统杀进程。
• 数据可用性：你需要的是一份能看的报告，还是一份能进数据仓库、能做趋势对比、能按机型版本聚合的结构化数据？

我当时的答案是：卡顿零容忍、低端机必须覆盖、数据要进看板。三条线一画，LeakCanary 就只剩开发期这一个位置了。

2. 架构层面的对比：对象图分析究竟发生在哪个进程

这一章是全文最硬的部分。理解了进程边界这件事，后面所有的性能数据、兼容性问题、配置策略都顺理成章。

2.1 LeakCanary 的检测链路逐段拆解

把 LeakCanary 的一次完整检测拆成阶段，大致是这样：

第一阶段是对象观察。ObjectWatcher在 Activity destroy、Fragment 销毁等时机，把目标对象用KeyedWeakReference包起来，加一个 UUID 作为 key，同时注册到ReferenceQueue。观察期到了之后，它做一次removeWeaklyReachableObjects，把已经进入引用队列的对象清掉，剩下的就是"本该被回收但还活着"的可疑对象。

第二阶段是触发判定。可疑对象数量达到阈值，或者你手动调用，就会触发一次检测。这里有个容易忽略的细节：detectGcRoots 之前会先主动请求一次 GC，调用Runtime.getRuntime().gc()然后 sleep 一小段时间等 GC 完成。这个动作本身在主线程之外，但会带来 CPU 抖动。

第三阶段是堆转储。调用Debug.dumpHprofData(path)。这个方法是 ART 提供的，它内部会 suspend 所有线程，遍历堆把整个对象图写进文件。写入的数据量约等于当前堆大小乘以一个系数，通常在 1.2 到 1.5 之间。这一段是 STW 的，主线程完全停住。

第四阶段是对象图解析。Shark 把 hprof 读进来，建立索引，从 retained 对象反向查找到 GC Root 的最短路径。这个过程内存开销极大，因为它需要在内存里重建整个对象图的数据结构。

第五阶段是结果展示，走通知或者 UI 列表。

关键在于：第三、第四阶段都在你的应用进程里。一次检测下来，你的进程要额外扛住"hprof 文件大小 + 对象图索引结构"这两份开销。

2.2 KOOM 的 fork 子进程方案，为什么能绕开 STW

KOOM 的核心思路可以用一句话概括：让子进程去干脏活累活。

Linux 的fork有一个特性叫写时复制（Copy-On-Write）。fork 的瞬间，子进程并不真的复制父进程的内存，它只是复制了页表，父子进程共享同一份物理内存页。只有当某一方尝试写入某个页时，内核才会真正复制那一页。这意味着fork本身的耗时是非常短的，通常是毫秒级。

KOOM 的执行序列大致是：

1. 监控模块检测到触发条件（内存水位超过阈值、或者可疑对象数量达到阈值）。
2. 在 native 层 suspend 掉应用进程的所有线程。这一步需要先 hook 住线程创建，记录所有线程句柄，才能做到"全部暂停"。
3. 调用fork()派生子进程。此时子进程拥有父进程内存的一致性快照。
4. 父进程立刻resume，恢复所有线程。用户在这一刻几乎感知不到，最多是一次极轻的抖动。
5. 子进程在纯 native 环境下执行 hprof dump 和解析。这里必须强调"纯 native"：POSIX 规定，多线程进程 fork 之后，子进程只能调用 async-signal-safe 的函数，不能碰 ART 的 Java 运行时，否则会死锁。所以 KOOM 的 dump 和解析逻辑全部用 native 实现，包括对象图的遍历。
6. 子进程生成结构化报告（JSON 格式），通过管道或者共享内存回传给父进程，然后退出。

这个方案的妙处在于：父进程的停顿只等于 fork 的耗时，而不是 dump 的耗时。原来一次几百毫秒的卡顿，被压缩到了个位数毫秒。同时，解析阶段的内存开销虽然要靠 COW 承担，但因为子进程只读不写父进程的数据页，实际复制的页很少，内存放大也控制得住。

当然，代价也是有的。一是实现复杂度高，需要 native hook 和线程管理能力；二是兼容性有边界，某些定制 ROM 对 fork 的行为有干预，或者对线程 suspend 有额外限制；三是 dump 期间的堆不是完全静止的（父进程已经 resume 了，会继续产生新的对象），所以报告里会有少量"脏数据"，需要在解析时做过滤。

2.3 两种链路的代价换算，算笔明白账

拿一个具体数字来算。假设你的应用在一个中端机上常驻堆 150MB。

LeakCanary 路径：dump 产出的 hprof 文件大约 150 × 1.3 = 195MB（落盘，不占内存，但写文件本身有 IO 开销）。Shark 解析时需要把对象图结构建在内存里，这部分开销经验值在 150 到 300MB 之间。加上原有堆，进程峰值内存可能冲到 400MB 以上。而很多中低端机给单个应用的最大堆限制是 192MB 或 256MB，这个峰值一旦出现，系统就会判定内存压力过大，后台进程被杀甚至前台进程被回收。

KOOM 路径：父进程 fork 瞬间停顿，实测通常在 5 到 20 毫秒。子进程 dump 期间，因为 COW 机制，实际物理内存的增量主要来自修改过的页。dump 文件写入是流式的，不需要一次读进内存。解析过程子进程自己承担，父进程堆几乎不变。

这个对比说明一件事：LeakCanary 的开销是"乘在你的进程上"，KOOM 的开销是"挂在子进程上"。对于线上环境，这个区别是决定性的。

3. 性能开销实测与线上可承受度评估

纸面推演是一回事，真机跑起来是另一回事。这一章讲讲我实际测出来的数据和据此做的分档策略。

3.1 一次 dump 到底吃掉多少内存和 CPU

我在几个档位的设备上做过对照测试，场景统一：应用在前台，堆占用稳定在 180MB 左右，手动触发一次检测。

在中低端设备（4GB 内存、入门级芯片）上，LeakCanary 完整跑一次检测，从触发到报告生成大约需要 6 到 10 秒，期间主线程有明显的卡顿，掉帧肉眼可见。峰值内存相对基线增长约 1.8 倍。有两次测试中，应用在 dump 完成后不久被系统回收，日志里能看到低内存杀进程的记录。

在同一台设备上，KOOM 从触发到子进程吐出报告大约需要 3 到 5 秒，但父进程的停顿只有十几毫秒——用户侧的体感是"这个页面滑了一下"，不会有明显卡死。峰值内存基准几乎没有波动。

在高端设备（12GB 内存、旗舰芯片）上，两者的绝对耗时都缩短了很多，LeakCanary 大约 3 到 5 秒，KOOM 大约 1.5 到 3 秒。但差异依然存在，而且高端设备的用户在后台挂着的应用更多，对卡顿的容忍度反而更低，一旦出现明显卡顿，投诉率并不比低端机低。

这里有个很多人忽略的点：dump 的耗时和堆大小不是线性关系，而是接近线性偏指数。堆从 100MB 涨到 200MB，耗时可能翻一倍多，因为对象图的遍历和索引构建有大量随机内存访问，缓存命中率会下降。所以那些堆占用本来就偏高的应用（比如有大量图片缓存的），在进程内做 dump 的风险会比小应用高得多。

3.2 STW 之外还有哪些隐性成本

除了主线程停顿和内存放大，还有几个容易被忽略的开销：

文件 IO 压力。hprof 文件动辄几百 MB，写盘过程会占满磁盘带宽。如果此时应用正在加载图片或者写数据库，会出现明显的 IO 竞争。我遇到过一次线上投诉，用户反馈"用着用着突然卡住几秒"，最后查到的原因就是监控模块在后台 dump，同时用户在做视频缓存。

电量消耗。dump 和解析都是 CPU 密集型操作，一次完整检测的耗电量大致相当于几十秒的重度使用。如果触发策略没做好，比如每次内存涨到阈值就 dump，一天触发十几次，电池统计里这个应用的耗电排名会很难看。

GC 抖动。检测前主动请求 GC 这个动作，会让原本平稳的 GC 节奏被打乱。对于使用了分代回收的应用，一次 full GC 可能带来几十毫秒的停顿，而且会清空一些本来能复用的对象缓存，反而加剧了后续的内存分配压力。

这些成本加起来，就是为什么我一直坚持"线上不要用进程内分析"的原因。不是技术上跑不通，是代价藏在用户身上，你看不见。

3.3 按设备档位制定差异化的触发策略

既然不同设备的承受能力不一样，那策略就不能一刀切。我的做法是按内存档位分三组，各组配置不同的触发条件和采样率：

这里的阈值不是拍脑袋定的。最大堆可以用ActivityManager.getMemoryClass()拿到，比如 192MB。75% 就是 144MB。为什么低端机反而要设更低的阈值？因为低端机的堆本身就小，逼近上限时系统已经在考虑回收它了，这时候如果不主动抓一次，等 OOM 发生，数据就永远拿不到了。

采样率的作用是控制总量。假设你有 100 万日活，平均每台设备每天触发一次，按 1/2000 采样，一天能收到大约 500 份报告。这个量级足够看出趋势，又不会把服务端打爆。

提示：采样一定要做设备维度的稳定采样，不能每次随机。做法是对设备标识做哈希再取模，这样同一台设备要么一直采，要么一直不采，报告之间可以做纵向对比，能看出某个泄漏是不是在某个版本之后出现或者消失。

4. 线上监控真正需要的四项能力

架构讲完了，性能也算清楚了，这一章讲"为什么最后选了 KOOM"。答案不完全是性能，更多是它能撑起一套完整的线上监控闭环。

4.1 可配置的触发策略，是线上监控的命门

开发期你希望"只要泄漏就抓"，线上你必须做到"只在该抓的时候抓"。这两者的差别巨大。

LeakCanary 的触发逻辑是围绕"可疑对象数量"设计的，它的默认阈值是 5 个 retained 对象。这个逻辑在开发期很合理，因为你希望尽快发现泄漏。但线上这个逻辑会变成一个灾难：一个页面反复进出，每次都产生可疑对象，很容易在几分钟内就触达阈值，然后触发一次 dump。用户只是正常使用，你的监控却在后台疯狂干活。

KOOM 提供了更丰富的触发源，可以按需组合：

• 内存水位触发：基于onTrimMemory回调的等级，或者定期读取当前堆占用，超过设定比例才触发。这是最贴近"真正有问题"的信号。
• 手动触发：业务方在特定场景（比如某个已知的高风险页面退出后）主动调用。
• 周期触发：在后台按固定间隔检查一次，适合慢慢积累数据。
• 对象数量触发：类似 LeakCanary 的逻辑，但可以配置更高的阈值和更严格的冷却时间。

我实际采用的是"内存水位为主、对象数量为辅"的组合。主路径是水位触发，只有在某个页面已知会泄漏、需要重点观察时，才给这个页面单独打开对象数量触发，并且设置两小时冷却。

4.2 报告的裁剪、聚合与上报

这是 LeakCanary 和 KOOM 差距最大的地方之一。

LeakCanary 产出的是给人看的LeakTrace：一条从 GC Root 到泄漏对象的完整引用路径，中间每个节点都能展开看字段。这份报告读起来非常舒服，但它不适合机器处理。你要把它变成能聚合的数据，得自己写解析逻辑，而且不同版本的格式还在变。

KOOM 产出的是结构化的 JSON 报告，核心字段大致包括：泄漏对象的类名、对象本身占用的大小、整条引用链上每个节点的类名和字段名、GC Root 的类型（是静态变量、JNI 全局引用、还是线程栈）、以及触发时的场景信息。有了这些字段，你可以直接在服务端做聚合：

• 按泄漏对象的类名聚类，看哪几类对象是泄漏重灾区。
• 按引用链的顶层节点聚类，看是哪个单例或者哪个静态容器在持有。
• 按机型、系统版本、应用版本做交叉分析，看某个泄漏是不是集中在特定条件下。

我还在上报前做了一层裁剪。完整的 hprof 太大，不能传，但 KOOM 支持在解析时只保留引用链上涉及的对象信息，剔掉堆里其他无关的数据。裁剪之后报告通常只有几 KB 到几十 KB，走普通的数据上报通道就行。这个裁剪很关键，没有它，报告体积会成为一个新的问题。

4.3 和既有监控体系的数据衔接

一个孤立的泄漏报告价值有限，它的价值在于跟其他指标串起来。

我的做法是把泄漏报告挂到现有的事件体系上，用一个统一的事件 ID 串联。具体来说，报告里带上：当前页面的路由名、上一次页面切换的时间、触发时的堆占用、设备内存档位、是否处于低内存回调状态。这样在服务端就能做关联查询——比如"某个页面退出后 5 分钟内触发的泄漏事件"，这类查询能直接把问题定位到具体页面的生命周期逻辑上。

还有个细节：版本对比。每次发版后，我会对比新版本和上一个版本的泄漏类型分布。如果某个新出现的类名突然冲进 Top 10，基本可以确定是新代码引入的。这种基于数据的回归发现，比等用户投诉快得多。

4.4 覆盖维度：不只是 Java 堆

线上内存问题从来不只是 Java 堆。我遇到过的几次严重 OOM，一次是线程数量失控（某个 SDK 每次调用都起一个线程，跑完不退出），一次是 native 内存泄漏，Java 堆看起来完全正常，但进程总内存一直在涨。

KOOM 在这方面提供的能力更完整，除了 Java 堆泄漏监控，还有线程数量监控和 native 内存监控的模块。线程监控的逻辑是定期采样线程数量，超过阈值时把当前所有线程的堆栈 dump 出来，看看是哪类线程在堆积。这个能力在排查"线程爆炸"类问题时非常有用，因为线程爆炸的现场往往是很多个同名线程卡在同一个地方。

LeakCanary 的定位就只在 Java 堆对象上，线程和 native 这两块它不覆盖。这也是我最终倾向于 KOOM 的原因之一——一套框架能覆盖三类内存问题，运维成本低得多。

5. 落地实操：把 KOOM 接进线上监控链路

理论讲完，下面是具体怎么接。这一章的代码是基于常见实践整理的形态，方法名可能和你手上版本有出入，参照官方接入文档校正。

5.1 依赖引入与初始化时机

依赖通常分模块引入，Java 堆监控一个，线程监控一个，按需选择：

dependencies { // Java 堆泄漏监控 implementation "com.kwai.koom:koom-java-leak:2.2.4" // 线程数量监控 implementation "com.kwai.koom:koom-thread-leak:2.2.4" // native 内存监控（可选） implementation "com.kwai.koom:koom-native-leak:2.2.4" }

初始化时机的选择有讲究。太早（Application.onCreate 一开始）会影响启动耗时，太晚（首屏之后）会漏掉启动阶段的泄漏。我的做法是放在首屏渲染完成之后、第一次onTrimMemory之前的空档里，用空闲任务队列延迟执行：

class LeakMonitorInitializer : Runnable { override fun run() { val config = OOMInitConfig.Builder() .setEnableHprofDump(true) // 允许 dump .setHprofCompress(true) // 报告压缩，减小体积 .setEnableHprofAnalysis(true) // 子进程解析 .setAnalysisForegroundOnly(true) // 仅前台分析，避免后台被杀 .build() // 具体入口类名以你引入的版本为准 OOMEngine.getInstance().init(context, config) } } // 在首屏后的空闲时机投递 Looper.myQueue().addIdleHandler { executor.execute(LeakMonitorInitializer()) false }

这里有两个参数值得说。setAnalysisForegroundOnly设成 true，意味着子进程的解析只在应用处于前台时进行。为什么？因为后台进程优先级低，正在解析的时候很可能被系统回收，辛辛苦苦 dump 的东西就白费了。设成前台，虽然会让解析在用户可见时发生，但因为是在子进程里，对主进程的影响可控。

setHprofCompress影响的是报告体积和解析耗时的平衡。开启压缩后，回传的数据量小，上报成功率高；代价是子进程多花一点 CPU。线上环境我建议开启，网络传输的失败率比 CPU 多花那点时间更要命。

5.2 触发策略配置

触发策略是这套系统的"闸门"，配得松了没用，配得紧了是负担。我实际用的配置大致长这样：

object LeakTriggerPolicy { // 按设备内存档位给出水位比例 fun heapThresholdRatio(totalMemMb: Int): Float = when { totalMemMb <= 4096 -> 0.75f totalMemMb <= 6144 -> 0.80f else -> 0.85f } // 是否允许本次触发 fun shouldTrigger(context: Context, scene: String): Boolean { // 1. 采样判定：设备维度稳定采样 val bucket = abs(context.deviceIdHash()) % 2000 if (bucket != 0) return false // 2. 冷却判定：24 小时内已触发过则跳过 if (lastTriggerTime(context) > System.currentTimeMillis() - 24 * 3600_000L) { return false } // 3. 水位判定 val am = context.getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager val maxHeapMb = am.memoryClass val usedHeapMb = (Debug.getNativeHeapAllocatedSize() / 1024 / 1024).toInt() val ratio = heapThresholdRatio(totalMemoryMb(context)) if (usedHeapMb < maxHeapMb * ratio) return false // 4. 场景判定：关键支付流程中不触发 if (scene in CRITICAL_SCENES) return false return true } }

几个细节解释一下。设备维度的稳定采样用的是设备标识做哈希取模，保证同一台设备结果稳定。冷却时间设 24 小时是为了限制单设备的总触发次数，避免一个持续高内存的设备天天被抓。水位判定用memoryClass而不是系统的总内存，因为前者才是你这个应用真正能用的上限。场景判定是最后一道保险，像支付、登录这类流程，任何抖动都可能造成业务损失，一律跳过。

注意：Debug.getNativeHeapAllocatedSize()拿到的口径和实际堆占用有偏差，它统计的是 native 分配。如果你要更准确的数据，可以用Runtime.getRuntime().totalMemory() - freeMemory()拿 Java 堆用量，两者结合判断更靠谱。不同系统版本上这些 API 的口径不完全一致，建议上线前在目标机型上实测校准一次。

5.3 报告回调与上报

触发之后，框架会在子进程解析完成后回调你注册的监听器，把报告交给你。这里要做三件事：解析字段、补充上下文、投递上报。

class LeakReportHandler : LeakListener { override fun onLeak(report: HeapReport) { // 1. 提炼核心字段 val entity = LeakEntity( leakClass = report.leakObject?.className ?: "", retainSizeKb = report.leakObject?.objectSize ?: 0L, pathNodes = report.path?.map { it.className + "#" + it.fieldName }, gcRootType = report.gcRootType ?: "unknown", timestamp = System.currentTimeMillis() ) // 2. 补充业务上下文 entity.currentRoute = Router.currentPage() entity.lastRoute = Router.lastPage() entity.appVersion = BuildConfig.VERSION_NAME entity.deviceTier = DeviceTier.of() // 3. 压缩后投递到上报通道 ReportChannel.enqueue(entity, priority = Priority.LOW) } }

补充上下文这一步特别关键。没有上下文的泄漏报告，只是一堆类名。加上当前路由和上一次路由之后，你就能回答"用户是在哪个页面操作之后触发的"，这个信息直接把排查范围从整个应用缩小到一个页面。

上报优先级设成低，是因为这个数据不紧急，走普通通道即可，不要跟崩溃、ANR 这些高优先级事件抢带宽。

5.4 服务端聚合与看板

数据收上来之后，服务端的处理逻辑我建议按这个顺序做：

第一步是去重归并。报告里的引用链可能长达十几层，但真正决定归类的往往是顶层两三个节点。我用的归并键是"泄漏对象类名 + 引用链上第一个应用包内的类名"。这样同一个泄漏在不同设备上产生的报告能被归到一起。

第二步是趋势统计。按天、按版本、按机型档位统计各类泄漏的发生次数和平均占用大小。我最关注的是两个指标：新增泄漏类型的出现和某个类型占比的突增。

第三步是映射到代码。在构建阶段把类名和代码位置做个映射表打进包里，服务端解析报告时查表还原出文件和行号。这样看板上的每一条记录都能直接跳到代码，排查效率提升非常明显。

6. 常见问题与排查技巧实录

这一章把我在接入和运维过程中遇到的问题整理成速查表，后面再展开几个典型场景。

下面挑三个有代表性的展开说。

关于"解析时对象已被回收"。这是 fork 方案的固有特性，不是 bug。因为父进程在 fork 之后就 resume 了，堆在持续变化，子进程看到的快照和父进程继续产生的对象之间存在时间差。表现为报告里某些引用链节点缺失，或者大小统计偏小。我的处理方式是在解析端做一次过滤：如果引用链长度小于 3，或者根节点不是强引用类型，直接丢弃这份报告。这样能过滤掉大部分噪声，代价是牺牲一点召回率，对趋势分析影响不大。

关于 fork 的兼容性问题。这是个真实的坑。某些深度定制的系统对进程创建有额外管控，fork 会失败或者返回异常状态。我们上线初期在一个小众品牌的机型上崩溃率明显偏高，最后定位到就是这个问题。处理方式很简单粗暴：按机型维度统计子进程启动失败率，超过千分之五的机型加入黑名单，这些机型上直接关闭堆 dump 功能，只保留内存水位上报。宁可少一份数据，不能多一个崩溃。

关于采集量失控。有一次发版后，报告量突然涨了二十倍。查了半天发现是设备标识的获取逻辑变了——原来用的是稳定的硬件标识，新版本改成了一次性生成的随机串，导致每台设备每次启动都被判定成新设备，采样形同虚设，冷却也失效了。这个教训告诉我：采样和冷却的稳定性，完全依赖于那个哈希源的稳定性。上线前一定要验证这个源在小版本升级、清除数据、重装之后是否保持一致。

另外补充一个小技巧：在灰度阶段，可以给监控模块加一个"影子模式"。所谓影子模式，就是把所有判定逻辑都跑一遍，该记录的信息都记录，但到了真正要 dump 的那一步就跳过。这样能在一周内拿到真实的触发频次分布，据此调整阈值，而不会真的产生任何 dump 开销。等数据稳定了再打开真正的 dump，风险小得多。

7. 混合方案：开发期和线上期各用各的

讲到这里，结论其实很清楚：这不是一个"二选一"的问题，而是一个"分场景用对工具"的问题。

7.1 开发期 LeakCanary 依然是最好的选择

我现在的团队里，LeakCanary 一直在用，而且用得挺重。原因很简单：它在开发期的体验没有对手。

它的引用链展示是可视化的，一层层展开，能看到每个节点的字段值，甚至能看到被持有的 Bitmap 大小。这种直观性是纯 JSON 报告给不了的。新人上手也快，装着 debug 包跑一跑，通知弹出来点进去就知道哪泄漏了。

我在新项目里的做法是：debug 包默认开启完整的 LeakCanary 检测，包括对象观察和堆分析；同时在 CI 的自动化测试里跑一遍关键路径，把泄漏检测作为准入门槛。这个组合能拦住绝大部分显性的泄漏。

有一个配置值得推荐：把观察期从默认的 5 秒调长一点，比如 8 到 10 秒。原因是在慢速设备或者复杂页面上，5 秒内对象可能还没被真正回收，会产生误报。调长之后误报少了，虽然发现慢一点，但开发期不差这点时间。

7.2 线上 KOOM 的灰度节奏怎么排

线上一上来就全量开，风险太大。我一般按这个节奏推：

第一阶段只在内部员工的设备上开启，采样率 100%，观察两到三周。这阶段的目标不是找问题，是收集崩溃、耗电、卡顿等副作用数据，确认这套东西不会伤害应用本身。

第二阶段放开到 10% 用户，采样率降到 1/200，观察两周。这阶段的目标是积累泄漏类型的分布，看看头部问题都是些什么。同时重点关注低端机档位的表现，因为这个档位风险最高。

第三阶段全量，按前面说的分档采样率。这时候监控就变成一个常态化的能力了。

每一阶段的关键是准备好回滚开关。我把整个监控模块包在一个远程配置的开关后面，出问题一个配置下发就能关掉，不需要发版。这个设计在灰度阶段救过我一次——某次放开到 30% 的用户时，收到了异常的电量投诉，开关一关，半小时内就恢复正常。

7.3 两套数据的对照价值

最后说个容易被忽略的价值点：开发期和线上的数据可以互相印证。

开发期用 LeakCanary 抓到的泄漏，如果线上 KOOM 的报告里从来没出现过，那说明这个问题在实际使用中不容易触达，优先级可以降低。反过来，线上频繁出现的泄漏类型，如果开发期跑不出来，那说明它依赖特定的用户路径或者特定的设备条件，需要专门构造复现环境。

我现在的做法是每个月做一次对照：把线上 Top 10 的泄漏类型列出来，逐个在开发环境里试着复现，能复现的直接修，不能复现的加日志继续观察。这个循环跑了几轮之后，应用的 OOM 率从 0.7% 降到了 0.2% 以下，效果是很实在的。

我个人在实际操作中的体会是：工具本身没有绝对的好坏，LeakCanary 的精度和 KOOM 的线上适应性，本质上是在回答两个不同的问题。真正决定效果的，是你能不能把"发展期抓个案、线上期看分布"这条链路串起来，让每一次泄漏检测都落到具体的代码修改上。我见过太多团队接了监控之后就再也没看过报告，那还不如不接——省点电，也省点用户的耐心。