内存泄露检测工具——LeakCanary

很简单:我们不是创建服务不是为了赚钱;我们赚钱是为了提供更好的服务。我们认为这才是做事的态度。

学习使用Java的同学都应该知道,Java的JVM给我们提供的垃圾回收机制是极为好用的。但是我们也很清楚,垃圾回收机制不是万能的,使用不当很容易造成内存泄露。之前我们也介绍过Java中常用的内存泄露检测工具MAT,目前Java程序最常用的内存分析工具应该是MAT(Memory Analyzer Tool),它是一个Eclipse插件,同时也有单独的RCP客户端。

不熟悉MAT的同学,或者对Java垃圾回收机制不了解的同学,可以

看我的这篇文章:http://blog.csdn.net/yzzst/article/details/26621861

今天,这里我们不说MAT,我们说一个更有用的开源工具——LeakCanary。

LeakCanary本质上就是一个基于MAT进行Android应用程序内存泄漏自动化检测的的开源工具,通过集成这个工具代码到自己的Android工程当中就能够在程序调试开发过程中通过一个漂亮的界面。

随时发现和定位内存泄漏问题,而不用每次在开发流程中都抽出专人来进行内存泄漏问题检测,极大地方便了Android应用程序的开发。

总的来说,LeakCanary有如下几个明显优点:

  1. 针对Android Activity组件完全自动化的内存泄漏检查。
  2. 可定制一些行为(dump文件和leaktrace对象的数量、自定义例外、分析结果的自定义处理等)。
  3. 集成到自己工程并使用的成本很低。(*主要)
  4. 友好的界面展示和通知。

Github地址:https://github.com/square/leakcanary

具体怎么使用?应用一下官方的翻译文档入下:


LeakCanary

Android 和 Java 内存泄露检测。

“A small leak will sink a great ship.” - Benjamin Franklin

千里之堤, 毁于蚁穴。 – 《韩非子·喻老》


开始使用

在 build.gradle 中加入引用,不同的编译使用不同的引用:

 dependencies {
   debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.3‘
   releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3‘
 }

在 Application 中:

public class ExampleApplication extends Application {

  @Override public void onCreate() {
    super.onCreate();
    LeakCanary.install(this);
}

这样,就万事俱备了! 在 debug build 中,如果检测到某个 activity 有内存泄露,LeakCanary 就是自动地显示一个通知。


如何使用

使用 RefWatcher 监控那些本该被回收的对象。

RefWatcher refWatcher = {...};

// 监控
refWatcher.watch(schrodingerCat);

LeakCanary.install() 会返回一个预定义的 RefWatcher,同时也会启用一个 ActivityRefWatcher,用于自动监控调用 Activity.onDestroy() 之后泄露的 activity。

public class ExampleApplication extends Application {

  public static RefWatcher getRefWatcher(Context context) {
    ExampleApplication application = (ExampleApplication) context.getApplicationContext();
    return application.refWatcher;
  }

  private RefWatcher refWatcher;

  @Override public void onCreate() {
    super.onCreate();
    refWatcher = LeakCanary.install(this);
  }
}

使用 RefWatcher 监控 Fragment:

public abstract class BaseFragment extends Fragment {

  @Override
  public void onDestroy() {
    super.onDestroy();
    RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
    refWatcher.watch(this);
  }
}

工作机制

  1. RefWatcher.watch() 创建一个 KeyedWeakReference 到要被监控的对象。
  2. 然后在后台线程检查引用是否被清除,如果没有,调用GC。
  3. 如果引用还是未被清除,把 heap 内存 dump 到 APP 对应的文件系统中的一个 .hprof 文件中。
  4. 在另外一个进程中的 HeapAnalyzerService 有一个 HeapAnalyzer 使用HAHA 解析这个文件。
  5. 得益于唯一的 reference key, HeapAnalyzer 找到 KeyedWeakReference,定位内存泄露。
  6. HeapAnalyzer 计算 到 GC roots 的最短强引用路径,并确定是否是泄露。如果是的话,建立导致泄露的引用链。
  7. 引用链传递到 APP 进程中的 DisplayLeakService, 并以通知的形式展示出来。

如何复制 leak trace?

在 Logcat 中,你可以看到类似这样的 leak trace:


In com.example.leakcanary:1.0:1 com.example.leakcanary.MainActivity has leaked:

* GC ROOT thread java.lang.Thread.<Java Local> (named ‘AsyncTask #1‘)
* references com.example.leakcanary.MainActivity$3.this$0 (anonymous class extends android.os.AsyncTask)
* leaks com.example.leakcanary.MainActivity instance

* Reference Key: e71f3bf5-d786-4145-8539-584afaecad1d
* Device: Genymotion generic Google Nexus 6 - 5.1.0 - API 22 - 1440x2560 vbox86p
* Android Version: 5.1 API: 22
* Durations: watch=5086ms, gc=110ms, heap dump=435ms, analysis=2086ms

你甚至可以通过分享按钮把这些东西分享出去。


SDK 导致的内存泄露

随着时间的推移,很多SDK 和厂商 ROM 中的内存泄露问题已经被尽快修复了。但是,当这样的问题发生时,一般的开发者能做的事情很有限。

LeakCanary 有一个已知问题的忽略列表,AndroidExcludedRefs.java,如果你发现了一个新的问题,请提一个 issue 并附上 leak trace, reference key, 机器型号和 SDK 版本。如果可以附带上 dump 文件的 链接那就再好不过了。

对于最新发布的 Android,这点尤其重要。你有机会在帮助在早期发现新的内存泄露,这对整个 Android 社区都有极大的益处。

开发版本的 Snapshots 包在这里: https://oss.sonatype.org/content/repositories/snapshots/


leak trace 之外

有时,leak trace 不够,你需要通过 MAT 或者 YourKit 深挖 dump 文件。

通过以下方法,你能找到问题所在:

  1. 查找所有的 com.squareup.leakcanary.KeyedWeakReference 实例。
  2. 检查 key 字段
  3. Find the KeyedWeakReference that has a key field equal to the reference key reported by LeakCanary.
  4. 找到 key 和 和 logcat 输出的 key 值一样的 KeyedWeakReference。
  5. Referent 字段对应的就是泄露的对象。
  6. 剩下的,就是动手修复了。最好是检查到 GC root 的最短强引用路径开始。

自定义

UI 样式

DisplayLeakActivity 有一个默认的图标和标签,你只要在你自己的 APP 资源中,替换以下资源就可。

res/
  drawable-hdpi/
    __leak_canary_icon.png
  drawable-mdpi/
    __leak_canary_icon.png
  drawable-xhdpi/
    __leak_canary_icon.png
  drawable-xxhdpi/
    __leak_canary_icon.png
  drawable-xxxhdpi/
    __leak_canary_icon.png
<?xml version="1.0" encoding="utf-8"?>
<resources>
  <string name="__leak_canary_display_activity_label">MyLeaks</string>
</resources>

保存 leak trace

DisplayLeakActivity saves up to 7 heap dumps & leak traces in the app directory. You can change that number by providing R.integer.__leak_canary_max_stored_leaks in your app:

在 APP 的目录中,DisplayLeakActivity 保存了 7 个 dump 文件和 leak trace。你可以在你的 APP 中,定义 R.integer.__leak_canary_max_stored_leaks 来覆盖类库的默认值。

<?xml version="1.0" encoding="utf-8"?>
<resources>
  <integer name="__leak_canary_max_stored_leaks">20</integer>
</resources>

上传 leak trace 到服务器

你可以改变处理完成的默认行为,将 leak trace 和 heap dump 上传到你的服务器以便统计分析。

创建一个 LeakUploadService, 最简单的就是继承 DisplayLeakService :

public class LeakUploadService extends DisplayLeakService {
  @Override
  protected void afterDefaultHandling(HeapDump heapDump, AnalysisResult result, String leakInfo) {
    if (!result.leakFound || result.excludedLeak) {
      return;
    }
    myServer.uploadLeakBlocking(heapDump.heapDumpFile, leakInfo);
  }
}

请确认 release 版本 使用 RefWatcher.DISABLED:

public class ExampleApplication extends Application {

  public static RefWatcher getRefWatcher(Context context) {
    ExampleApplication application = (ExampleApplication) context.getApplicationContext();
    return application.refWatcher;
  }

  private RefWatcher refWatcher;

  @Override public void onCreate() {
    super.onCreate();
    refWatcher = installLeakCanary();
  }

  protected RefWatcher installLeakCanary() {
    return RefWatcher.DISABLED;
  }
}

自定义 RefWatcher:

public class DebugExampleApplication extends ExampleApplication {
  protected RefWatcher installLeakCanary() {
    return LeakCanary.install(app, LeakUploadService.class);
  }
}

别忘了注册 service:

<?xml version="1.0" encoding="utf-8"?>
<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    >
     <application android:name="com.example.DebugExampleApplication">
           <service android:name="com.example.LeakUploadService" />
     </application>
</manifest>

demo

一个非常简单的 LeakCanary demo: https://github.com/liaohuqiu/leakcanary-demo



/*

* @author zhoushengtao(周圣韬)

* @since 2015年9月13日 下午 15:11:00

* @weixin stchou_zst

* @blog http://blog.csdn.net/yzzst

* @交流学习QQ群:341989536

* @私人QQ:445914891

/

版权声明:转载请标注:http://blog.csdn.net/yzzst 。 本文为博主原创文章,未经博主允许不得转载。

时间: 09-10

内存泄露检测工具——LeakCanary的相关文章

Android 内存泄露检测工具 LeakCanary

LeakCanary 是 Android 和 Java 内存泄露检测框架.LeakCanary 可以用更加直白的方式将内存泄露展现在我们的面前. 开始使用 在 build.gradle 中加入引用,不同的编译使用不同的引用: ? 1 2 3 4 dependencies {    debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'    releaseCompile 'com.squareup.leakcanary:leak

Android内存泄露检测工具---LeakCanary的前世今生

曾经检测内存泄露的方式 让我们来看看在没有LeakCanary之前,检测内存泄露的方式 1.Bug收集 通过Bugly.友盟这样的统计平台,统计Bug,了解OutOfMemaryError的情况. 1. 重现问题 对Bug进行筛选,归类,排除干扰项.然后为了重现问题,有时候你必须找到出现问题的机型,因为有些问题只会在特定的设备上才会出现.为了找到特定的机型,可能会想尽一切办法,去买.去借.去求人,去租,商家公司还真干过这事(14年,公司专门派了一个商务去广州找了一家租赁手机的公司,借了50台手机

Android 内存泄露检测工具 LeakCanary 的监控原理

首先回顾一下  java 的几种 reference: 从jdk 1.2 开始,引用分为 强引用,软引用.若引用 和虚引用, 其中 软引用.若引用 和虚引用 和 ReferenceQueue 关联. 在JDK 1.2以前的版本中,若一个对象不被任何变量引用,那么程序就无法再使用这个对象.也就是说,只有对象处于可触及(reachable)状态,程序才能使用它.从JDK 1.2版本开始,把对象的引用分为4种级别,从而使程序能更加灵活地控制对象的生命周期.这4种级别由高到低依次为:强引用.软引用.弱引

自己实现简易的内存泄露检测工具VLD

有一个很著名的内存泄露检测工具Visual leak detected想必大家都不陌生,但今天我们可以自己写一个简易版的.哈哈,自己动手,丰衣足食有木有!!! 它的原理就是我们重载了操作符new和delete,当用new开辟空间的时候,就讲这块空间串到我们定义的结构体MEMNode形成的链表中,(这是老师的写法,在main程序结束时,用check_vld()函数检测有没有内存泄露)但我觉得,如果我们动态开辟了一个对象,在它的析构函数里用delete释放的话,这种方法就不太可行.因为析构函数只有到

vld,Bounds Checker,memwatch,mtrace,valgrind,debug_new几种内存泄露检测工具的比较

概述 内存泄漏(memory leak)指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况,在大型的.复杂的应用程序中,内存泄漏是常见的问题.当以前分配的一片内存不再需要使用或无法访问时,但是却并没有释放它,这时就出现了内存泄漏.尽管优秀的编程实践可以确保最少的泄漏,但是根据经验,当使用大量的函数对相同的内存块进行处理时,很可能会出现内存泄漏. 内存泄露可以分为以下几类:1. 常发性内存泄漏.发生内存泄漏的代码会被多次执行到,每次被执行的时候都会导致一块内存泄漏.2. 偶发性内存泄漏.发生

vld(Visual Leak Detector) 内存泄露检测工具

初识Visual Leak Detector 灵活自由是C/C++语言的一大特色,而这也为C/C++程序员出了一个难题.当程序越来越复 杂时,内存的管理也会变得越加复杂,稍有不慎就会出现内存问题.内存泄漏是最常见的内存问题之一.内存泄漏如果不是很严重,在短时间内对程序不会有太大的 影响,这也使得内存泄漏问题有很强的隐蔽性,不容易被发现.然而不管内存泄漏多么轻微,当程序长时间运行时,其破坏力是惊人的,从性能下降到内存耗尽,甚 至会影响到其他程序的正常运行.另外内存问题的一个共同特点是,内存问题本身

Linux下C++内存泄露检测工具

下载安装:http://blog.csdn.net/wanglin754/article/details/7194145 下载地址:http://www.valgrind.org/downloads/current.html#current 安装valgrind tar jxvf valgrind-3.7.0.tar.bz2             注意这里的参数里加了j,表示有bz2属性 cd valgrind-3.7.0 ./configure make make install make

C程序内存泄露检测工具

今天给大家带来一款检测C程序内存泄露的一款实用工具--memwatch memwatch简介 MEMWATCH 由 Johan Lindh 编写,是一个开放源代码 C 语言内存错误检测工具.只要在代码中添加一个头文件并在 gcc 语句中定义了 MEMWATCH 之后,您就可以跟踪程序中的内存泄漏和错误了.MEMWATCH 支持 ANSI C,它提供结果日志记录,能检测双重释放(double-free).错误释放(erroneous free).没有释放的内存(unfreed memory).溢出

android 内存泄漏检测工具 LeakCanary 泄漏金丝雀

韩梦飞沙 yue31313 韩亚飞 han_meng_fei_sha [email protected] 内存泄漏检测工具 android 内存泄漏检测工具 ======== 内存泄漏 就是  无用的对象没有被回收,占用着内存,使得可用内存变小了. 如何检测内存泄漏, 可以使用 LeakCanary来检测内存泄漏. leak  是 泄漏的意思.. Canary 是 金丝雀 的意思. 在运行 应用的时候, 泄漏金丝雀 如果检测到内存泄漏 会显示一个通知. ======== LeakCanary捕获