使用Android Studio检测内存泄露(LeakCanary)_Android

内存泄露,是Android开发者最头疼的事。可能一处小小的内存泄露,都可能是毁千里之堤的蚁穴。 怎么才能检测内存泄露呢?
AndroidStudio 中Memory控件台(显示器)提供了一个内存监视器。我们可以通过它方便地查看应用程序的性能和内存使用情况,从而也就可以找到需要释放对象,查找内存泄漏等。

熟悉Memory界面

打开日志控制台,有一个标签Memory ,我们可以在这个界面分析当前程序使用的内存情况。

运行要监控的程序(APP)后,打开Android Monitor控制台窗口,可以看到Memory控制台。 点击Memory控制台上Enable按钮,Memory控制台开始显示正在运行时程序的Memory使用情况。如上图中显示:

AndroidStudio Memory的功能:

  • 启动与关闭Memory监测按钮
  • 手动触发GC按钮
  • dump java heap 按钮,点击Android Studio就开始干活了,成功后会自动打开 hprof文件。
  • start(stop) allocation tracking按钮先点击一次,然后会看到Memory Recorder开始转动,然后自己开始在APP上面做相应的操作。在合适的时间再点一次,结束记录。

如何检测内存泄露

我们点击dump Java heap 这个按钮,APP会Freeze住。大概几十秒后,

dump成功后会自动打开 hprof文件。

如果我们想了解内存分配更详细的情况,可以使用Allocation Traker来查看内存到底被什么占用了。 点击Starg Allocation Tracking按钮。开始分配追踪,过一些时间后,点击Stop Allocation Tracking结束追踪的位置。停止追踪后 .alloc文件会自动打开。

当你想查看某个方法的源码时,右键选择的方法,点击Jump to source就可以了。

使用LeakCanary

LeakCanary是square公司推出的一款简单粗暴的检测内存泄漏的工具。

LeakCanary会检测应用的内存回收情况,如果发现有垃圾对象没有被回收,就会去分析当前的内存快照,也就是上边MAT用到的.hprof文件,找到对象的引用链,并显示在页面上。这款插件的好处就是,可以在手机端直接查看内存泄露的地方,可以辅助我们检测内存泄露。

使用: 

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

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

在应用的Application onCreate方法中添加LeakCanary.install(this),如下:

public class ExampleApplication extends Application {

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

应用运行起来后,LeakCanary会自动去分析当前的内存状态,如果检测到泄漏会发送到通知栏,点击通知栏就可以跳转到具体的泄漏分析页面。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索android
, 内存泄露
, studio
内存泄露工具
android leakcanary、leakcanary、leakcanary使用教程、leakcanary eclipse、leakcanary github,以便于您获取更多的相关知识。

时间: 2024-08-04 01:43:43

使用Android Studio检测内存泄露(LeakCanary)_Android的相关文章

使用新版Android Studio检测内存泄露和性能

内存泄露,是Android开发者最头疼的事.可能一处小小的内存泄露,都可能是毁于千里之堤的蚁穴. 怎么才能检测内存泄露呢?网上教程非常多,不过很多都是使用Eclipse检测的, 其实1.3版本以后的Android Studio 检测内存非常方便, 如果结合上MAT工具,LeakCanary插件,一切就变得so easy了. 熟悉Android Studio界面 工欲善其事,必先利其器.我们接下来先来熟悉下Android Studio的界面 一般分析内存泄露, 首先运行程序,打开日志控制台,有一个

android的GC内存泄露问题_Android

1. android内存泄露概念 不少人认为JAVA程序,因为有垃圾回收机制,应该没有内存泄露.其实如果我们一个程序中,已经不再使用某个对象,但是因为仍然有引用指向它,垃圾回收器就无法回收它,当然该对象占用的内存就无法被使用,这就造成了内存泄露.如果我们的java运行很久,而这种内存泄露不断的发生,最后就没内存可用了.当然java的,内存泄漏和C/C++是不一样的.如果java程序完全结束后,它所有的对象就都不可达了,系统就可以对他们进行垃圾回收,它的内存泄露仅仅限于它本身,而不会影响整个系统的

Android 和 Java 内存泄露检测工具——LeakCanary

LeakCanary Android 和 Java 内存泄露检测. "A small leak will sink a great ship." - Benjamin Franklin 千里之堤, 毁于蚁穴. -- <韩非子·喻老> demo 一个非常简单的 LeakCanary demo: https://github.com/liaohuqiu/leakcanary-demo 开始使用 在 build.gradle 中加入引用,不同的编译使用不同的引用: depende

Android 使用LeakCanary 检测内存泄露

转自:http://blog.csdn.net/sbsujjbcy/article/details/47999163 LeakCanary 是 Android 和 Java 内存泄露检测框架,该框架是Square公司的一个开源库,项目地址 leakcanary. Android 开发中你是否频频遇到内存泄露而无奈无从解决.说不定哪天你不小心写的一行代码就导致了内存泄露.可以先看看这些问题导致的内存泄露 Android开发编码规范导致的内存泄露问题,而LeakCanary 则很直白得检测出了内存泄

查找并修复Android中的内存泄露—OutOfMemoryError

[编者按]本文作者为来自南非约翰内斯堡的女程序员 Rebecca Franks,Rebecca 热衷于安卓开发,拥有4年安卓应用开发经验.有点完美主义者,喜爱美食. 本文系国内ITOM管理平台 OneAPM 编译呈现,以下为正文. Android 程序中很容易出现内存泄露问题.毫无戒心的开发者可能每天都会造成一些内存泄露,却不自知.你可能从未注意过这类错误,或者甚至都不知道它们的存在.直到你遇到下面这样的异常: java.lang.OutOfMemoryError: Failed to allo

Android开发——避免内存泄露

Android开发--避免内存泄露 本文翻译自Avoiding memory leak--Post by Romain Guy 著作权归原作者所有.转载请注明出处,由JohnTsai翻译 Android应用被分配的堆的大小限制为16MB.这对于手机来说已经很多了,但对于一些开发者想获得的来说仍旧不够.即使你没有计划使用所有的这些内存.你应该尽可能的少用以避免其他应用在运行时因为内存不足而被杀掉.Android内存中保存的应用越多,用户在应用间切换得越快.作为我工作的一部分,我在Android应用

linux中使用valgrind检测内存泄露

众所周知,c或者c++编写的程序很容易出现内存泄露问题.valgrind是一个很好的工具,可以检测程序中的内存泄露问题.什么是内存泄露 内存泄露可以分为两种: 一种是,程序中有指针指向通过malloc或者new申请的内存,但是在程序结束前,一直未收回.如果这种内存一直增加的话,可能导致内存耗尽.不过程序结束后系统会自动回收这些内存. 另一种是,通过malloc或者new申请的内存,但是程序中已经没有指针指向申请的内存.程序一直在执行,泄露的内存会越来越多,可能会耗尽程序的堆内存. 如何使用val

Android垃圾回收机制解决内存泄露问题_Android

在android编码中,会有一些简便的写法和编码习惯,会导致我们的代码有很多内存泄露的问题,在这里做一个已知错误的总结:1.编写单例的时候常出现的错误. 错误方式: public class Foo{ private static Foo foo; private Context mContext; private Foo(Context mContext){ this.mContext = mContext; } // 普通单例,非线程安全 public static Foo getInsta

Android App调试内存泄露之Cursor篇_Android

最近在工作中处理了一些内存泄露的问题,在这个过程中我尤其发现了一些基本的问题反而忽略导致内存泄露,比如静态变量,cursor关闭,线程,定时器,反注册,bitmap等等,我稍微统计并总结了一下,当然了,这些问题这么说起来比较笼统,接下来我会根据问题,把一些实例代码贴出来,一步一步分析,在具体的场景下,用行之有效的方法,找出泄露的根本原因,并给出解决方案. 现在,就从cursor关闭的问题开始把,谁都知道cursor要关闭,但是往往相反,人们却常常忘记关闭,因为真正的应用场景可能并非理想化的简单.