APM，全称是Application Performance Management，也就是应用性能管理，这与我们平时写的业务可能并不相关，但是却承载着App线上稳定的责任。当一款App发布到线上之后，不同的用户有不同场景，一旦App出现了问题，为了避免黑盒，找不到头绪，就需要APM出马了。对于App的性能，像CPU、流量、电量、内存、crash、ANR，这些都会是监控的点，尤其是当App发生崩溃的时候，需要回捞到当前用户的日志加以分析，找到此问题崩溃的堆栈，完成修复。否则就像是大海捞针，根本不知道哪里发生了崩溃，查找问题可能就需要找一半天。那么对于成熟的线上APM监控，我们可能使用过Bugly、火山、Leakcanary，但其中都会有缺陷，对于一些大公司一般都会考虑自研APM，监控的对象也无非上述这些指标，那么如果让我们自己做一套APM监控，该怎么出方案呢？ # 1 Leakcanary为什么不能用于线上如果有做过APM监控的伙伴，对于Leakcanary就很熟悉了，这个是一个老派的内存监控组件，但是我们在使用的时候，通常都是采用debugImplementation的方式引入，在debug环境下使用，而不是线上，这是为什么呢？这个还需要从Leakcanary的原理说起了。 ## 1.1 Leakcanary原理简单剖析对于Java的引用类型，大家应该都清楚：强软弱虚，接下来我们通过一个简单的示例，看下四种引用的特性，这里我主要是介绍一下弱引用 ```java Object object = new Object(); ReferenceQueue