Android内存泄露监控和分析应用

Install方法启动了一个内存分析的listenerService，这个Service进程独立于APP进程之外，并且创建了一份已知泄漏的问题清单，用于排除一些可被忽略的泄露引用。接着LeakCanary创建了对Activity和Fragment的生命周期监听。

ActivityRefWatcher对Application添加了一个生命周期监听器 ActivityLifecycleCallbacks，生命周期监听仅仅关注了 Activity 销毁的回调 onActivityDestroyed，在activity销毁触发时开始进行该页面的内存分析。

（2） LeakCanary内存分析

按上述流程我们可以看到，在Activity 销毁时将会调用refWatcher.watch(activity) 对它进行内存监控分析，首先会对Activity的引用和随机生成的一个UUID Key进行绑定注册。

当Activity的引用变成弱引用时，就会进入ReferenceQueue队列当中，接着触发一次系统GC，立即回收所有可回收对象，并再次确认Activity的引用是否存在于ReferenceQueue当中。

当Activity因为某些内存泄露导致强引用存在时，listenerService开始触发heapDumpFile的收集分析，heapDumpFile可以展示某一时刻java堆的使用情况，根据这个文件我们可以分析出哪些对象占用大量内存和对象引用链路，从而定位内存泄漏问题。 在heapDumpFile中查找泄露的Activity对象，然后计算从该对象到GC根节点的最短强引用路径。

然后从泄漏节点迭代到GC根节点，最终确定对象泄露的调用链。

Android原生内存检测工具

（1） Profiler工具

Android Studio内存分析工具Profiler用于捕获堆转储、强制垃圾收集和跟踪内存分配。

如果是检查内存泄漏，建议在点击“Dump Java heap”按钮之前先点击垃圾回收按钮，以防可回收的存货对象混淆分析。

使用案例分析，

new Handler().postDelayed(new Runnable() {
@Override
public void run() {
}
},1000000);

Handler引发的泄露，单击一个对象，在右侧出现Instance View窗口。 在Instance View中，会显示在Activity中的各种对象，而它下方的Reference则是显示诸多对这个存货的Activity对象的引用。大部分都是系统层面的引用，只有一个格外显眼，就是通过“this”对Activity的引用，点进去我们可以发现是MessageQueue持有了这个引用，Activity内的Handler设计如一直持有未处理的消息，将导致内存泄漏。

（2） ADB 命令分析内存

Procrank 查看系统内各个应用进程的内存占用情况

procrank |grep com.android.memorytest 查看单独指定应用进程的内存占用情况。

从以上打印可以看出，一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS

dumpsys meminfo 查看应用进程的详细内存情况

使用该命令可以很直观的观察到 Activity 的泄漏问题，是平常分析比较常用的一种方式。

寄语

本文主要从Android内存泄露的检测和使用工具方面进行分析，我们工作当中或多或少遇到各种类型的内存泄露，如try/catch/finally中网络文件等流的手动关闭、 ContendProvider、Handler、Bitmap占用、Static引用、内部匿名类引用等等，希望借助好第三方内存检测框架和Android原生开发工具，让APP应用内存得到更健康的使用，若有其它好用的内存监控方案，也欢迎一起讨论交流！

三方内存检测框架和Android原生开发工具，让APP应用内存得到更健康的使用，若有其它好用的内存监控方案，也欢迎一起讨论交流！