LeakCanary应用与二次开发

内存泄漏检测利器——LeakCanary简介

LeakCanary是由Square公司开源的一款安卓平台内存泄露检测工具，Square公司是一个开源大户，旗下优秀、流行的框架有OkHttp,Retrofit ,Picasso等等,其中OkHttp还被Google采用在安卓系统上，也就是说在版本稍高点的安卓系统上实现网络通信调用SDK里内置的网络框架——HttpUrlconnect，底层走的其实是OkHttp的代码。那么回到正题，LeakCanary的用法也是很简单，在github上也说明的很清楚：在gradle添加如下，在Application初始化，然后结果效果图如下图所示

内存泄漏简介

          内存泄漏简洁的方式理解就是本该被回收的内存被强引用了导致无法被GC所回收，虽说JVM会根据GCRoot可达性算法来判断哪些对象是无效的，但是如果开发者逻辑代码出问题，导致本该回收的对象被强引用了，那么就会被误判有还是有效的对象，这些对象一直占用着内存则认为内存泄漏，常见场景有handler引用activity，Activity destroy未结束线程，静态变量或者单例引用了Activity或者Fragment，总的来说就是生命周期长的对象引用了短生命周期对象。内存泄漏会造成卡顿或者严重的则会造成内存溢出崩溃。那么LeakCanary是怎么检测内存泄漏的呢？

LeakCanary工作流程

         首先注册了ActivityLifecycleCallbacks,并在回调里调用了RefWatcher的watch方法并传入destroy Activity

 RefWatcher

       ReftWatcher的watch方法是leakcancay检测内存泄露的入口点。在对象生命周期即将结束的时候调用。

watchExecutor: 执行内存泄露检测的executor
debuggerControl ：用于查询是否正在调试中，调试中不会执行内存泄露检测
queue ： 用于判断弱引用所持有的对象是否已被GC。
gcTrigger： 用于在判断内存泄露之前，再给一次GC的机会
heapDumper: 用于在产生内存泄露时执行dump 内存heap
heapdumpListener: 用于分析前面产生的dump文件，找到内存泄露的原因
excludedRefs: 用于排除某些系统bug导致的内存泄露
retainedKeys:持有那些待检测以及产生内存泄露的引用的key

 二次确认保证内存泄露准确性

 

HAHA

         监测到内存泄露后，首先做的就是dump出当前的heap，默认的AndroidHeapDumper调用的是

                                                                    Debug.dumpHprofData(filePath);     

        导出当前内存的hprof分析文件，一般我们在DeviceMonitor中也可以dump出hprof文件，然后将其从dalvik格式转成标准jvm格式，然后使用MAT进行分析。 那么LeakCanary是如何分析内存泄露的呢？     LeakCanary分析采用了HAHA库，这个库也是square公司开源的内存快照分析库，其实它这个库也是在MAT源码上面进行二次开发，删减了一些不必要的功能，并且做到了直接分析出对象GCRoot的引用链。

LeakCanary应用

开发阶段：Android开发过程中实时开启内存泄露检测，可在开发过程中检测出问题并及时修复，这也是LeakCanary的常规操作；

测试阶段：开发过程中未能覆盖到的场景，在提测的时候通过我们的集成了LeakCanary深度性能测试系统进行测试，可在测试阶段找到应用内存泄漏Bug。此处需要二次开发成本；

内存快照自动分析工具：在分析内存快照文件时，可以用MAT分析，但由于MAT分析的繁琐，并且需要人工操作，所以这里利用LeakCanary的分析原理做成自动分析工具，自动分析出内存泄漏对象，Bitmap对象。此处需要二次开发成本。

二次开发我们做了什么

LeakCanary深度性能测试：     

        有些数据，比如内存相关信息，必须得在当前进程中才能获取，所以LeakCanary的工作环境必须为当前进程，当然，源码集成我们这里不说，这里所说的是在没源码的情况下，所谓深度性能测试则是突破安卓平台沙盒限制，让自己代码逻辑注入到目标进程执行，即是共进程，从而获取到目标应用进程的数据，那么共进程有哪些实现方式？

1、Xposed方案，此方案可实现共进程，并且可以对大部分应用有效，但是缺点也是明显的，就是手机需要Root

2、逆向注入代码，当然此方案也是可行，并且可以对所有应用有效，不需要Root，但成本有点大，需要填的坑有点多

3、通过instrument，此方案也可行，因为其对签名的要求，所以只能对自家应用有效，不需要Root

       综上，建议采取方案3，即是把LeakCanary集成到测试应用，在保证测试应用和被测应用签名相同的情况下，即可实现共进程监控内存泄漏。值得一提的是，测试应用是依赖宿主，即被测应用，所以测试应用只能有逻辑代码，不能有资源、MainFest，所以得去除LeakCanary的四大组件。

内存快照自动分析工具：      

      通过二次开发LeakCanary实现了内存快照自动分析，可自动分析出泄漏的Activity、Fragment和Bitmap的引用链，不再需要转换hprof文件和通过MAT人工来找。工具已开源到Github

https://github.com/qq542391099/HprofAnalysis