首页 > 代码库 > 【Android内存泄漏检测】LeakCanary使用总结

【Android内存泄漏检测】LeakCanary使用总结

一、什么是LeakCanary?

LeakCanary就是用来检测Android端内存泄漏的一个工具。能够检测Activity的泄漏

 

什么是内存泄漏?

Java 对象有时也会”长死不死“,GC 拿它没有办法,这种情况就是内存泄漏。造成这种情况的原因是:Java 对象被另一个生命周期更长对象持有,具有 可达性 ,这并不是我们想要的。

来自 <http://www.jianshu.com/p/3f1a1cc1e964>

 

内存泄漏的危害?

内存泄漏最终将导致内存溢出,也就是OOM,并且OOM发生在某一处,并不代表问题就是出在那里的,只是刚好有一块内存申请,此时内存又不够了才导致的,比较容易出现在申请比较大的内存的情况下。但是把这块申请的内存降低并不能从根本上解决问题。

 

这里有一个问题就是:内存的分配方式,分配位置,比如BitMap的分配,以及其他对象的分配?以及Activity对对象的持有,这个概念还不是很清晰。

 

github上的地址:https://github.com/square/leakcanary

 

一个原理的介绍内容在这里:

https://www.liaohuqiu.net/cn/posts/leak-canary/

https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/

 

 

二、LeakCanary的工作原理是什么?

 

这三个都有讲解,并且还有直接通过源码来进行讲解的,后面可以针对这块,针对源码专门研究一下。

http://www.jianshu.com/p/a8900eb3de12

 

http://www.jianshu.com/p/5ee6b471970e

http://www.jianshu.com/p/3f1a1cc1e964

 

 

工作原理是:

LeakCanary会开启一个Service,这个Service能够在一个Activity被OnDestory之后,检测是否真的还有这个对象,如果还有,会尝试进行二次确认,如果这个对象还是没有被释放掉,则会获取当时的内存状态,生成一个heap的状态文件,然后分析文件,计算这个对象的GC ROOT的最短强引用路径,确定是否泄漏,如果有泄漏,Leak的APP就会有一条通知栏消息出现

 

 

检测流程图如下:

 

 

 

三、如何使用

 

1、在build.gradle中引入:

 

 debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.3.1‘ // or 1.4-beta1
    releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3.1‘ // or 1.4-beta1
    testCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3.1‘ // or 1.4-beta1

 

 

或者,现在最新的1.5.1的也可以直接用:

dependencies{

compile‘com.squareup.leakcanary:leakcanary-android:1.5.1‘

}

 

 

2、同时,在Application的方法,在OnCreate中添加install

 

public class DemoApplication extends Application {
    @Override public void onCreate() {
        super.onCreate();
        LeakCanary.install(this);
    }
}

3、在添加之后,直接打出来应用的包,装上之后,会看到有一个附属应用出来,名字叫做Leaks

 

4、直接操作APP,如果发现有内存泄漏,则这个过程中会有通知栏提示,点击查看即可,可以将泄漏的信息分享,也可以将当时的heap dump的信息分享出来(但有可能这个heap dump不一定存在)

 

以检测出来的一个图为例:

 

 

LeakCanary的内存泄露提示一般会包含三个部分:

第一部分(LeakSingle类的sInstance变量)引用第二部分(LeakSingle类的mContext变量), 导致第三部分(MainActivity类的实例instance)泄露.

 

 

下方是一些更详细的原理的讲解:

1、不同的几种引用方式:强-软-弱-虚

2、LeakCanary这里,有一个原理的讲解叫做:

 

 

需要理解为什么要用WeakReference,因为GC的时候是不会对强引用的做处理,而软引用的是在内存不够用了才会被回收,而弱引用就是可以随时回收,所以需要用WeakReference对待检测的对象进行包裹引用,因为是弱引用的,因此在待检测对象调用了Destory或者Finish方法之后,被WeakReference引用的对象的生命周期结束,因为这个是弱引用,就会被GC检测到,这个时候GC会把该对象添加到ReferenceQueue中,如果GC结束该对象还是没有被加入到ReferenceQueue中,则说明可能存在内存泄漏,其实就是找到所有生命周期结束的对象,过滤掉会被回收的,剩下就是没有被回收的,然后会做二次GC,之后还是没有回收,就可以找到当时的内存状态,拿到不同对象的引用情况,得到一个hprof的文件,之后就能找到最短强引用的路径。

 

解决内存泄漏,通过以下方式:

然后我们需要解决:如何得到未被回收的对象。ReferenceQueue+WeakReference+手动调用 GC可实现这个需求。

 

  • WeakReference 创建时,传入一个 ReferenceQueue 对象。当被 WeakReference 引用的对象的生命周期结束,一旦被 GC 检查到,GC 将会把该对象添加到 ReferenceQueue 中,待ReferenceQueue处理。当 GC 过后对象一直不被加入 ReferenceQueue,它可能存在内存泄漏。

 

获得未被回收的 Object

  • 找到了未被回收的对象,如何确认是否真的内存泄漏?这里可以将问题转换为:未被回收的对象,是否被其他对象引用?找出其最短引用链。VMDebug + HAHA 完成需求。
    VM 会有堆内各个对象的引用情况,并能以hprof文件导出。HAHA 是一个由 square 开源的 Android 堆分析库,分析 hprof 文件生成Snapshot对象。Snapshot用以查询对象的最短引用链。

 

解析hprof

  • 找到最短引用链后,定位问题,排查代码将会事半功倍。

如下泳道图分析, LeakCanary 各个模块如何配合达到检测目的。

 

 

来自 <http://www.jianshu.com/p/3f1a1cc1e964>

 

 

【Android内存泄漏检测】LeakCanary使用总结