android内存泄漏检测StrictMode和MAT工具使用

• StrictMode说明

Android 2.3提供一个称为严苛模式（StrictMode）的调试特性，Google称该特性已经使数百个Android上的Google应用程序受益。那它都做什么呢？它将报告与线程及虚拟机相关的策略违例。一旦检测到策略违例（policy violation），你将获得警告，其包含了一个栈trace显示你的应用在何处发生违例。你可以强制用警告代替崩溃（crash），也可以仅将警告计入日志，让你的应用继续执行。策略的细节尚难确定，可以期待随Android的成熟Google将增加更多策略。

目前有2种策略可用，第一个和线程相关，它主要针对主线程（或UI线程）。由于在主线程中读写磁盘和进行网络访问都不是好的做法，Google已经在磁盘和网络代码中添加了严苛模式（StrictMode）钩子（hook）。如果你对某个线程打开严苛模式（StrictMode），当那个线程进行磁盘和网络访问，你将获得警告。你可以选择警告方式。一些违例包含用户慢速调用（custom slow calls 这么翻译行吗？），磁盘读写，网络访问。你能选择将警告写入LogCat，显示一个对话框，闪下屏幕，写入DropBox日志文件，或让应用崩溃。最通常的做法是写入LogCat或让应用崩溃。

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
    .detectDiskReads()
    .detectDiskWrites()
    .detectNetwork()
    .penaltyLog()
    .build());

上面的代码是一个为线程策略设置严苛模式（StrictMode）的例子。

Builder类使得设置变得很简单，Builder函数定义所有策略都返回Builder对象，从而这些函数能像上面那样串连在一起。最后调用build()函数返回一个ThreadPolicy对象作为StrictMode对象的setThreadPolicy()函数的参数。注意到setThreadPolicy()是一个静态函数，因此不需要实例化StrictMode对象。在内部，setThreadPolicy()将对当前线程应用该策略。如果不指定检测函数，也可以用detectAll()来替代。penaltyLog()表示将警告输出到LogCat，你也可以使用其他或增加新的惩罚（penalty）函数，例如使用penaltyDeath()的话，一旦StrictMode消息被写到LogCat后应用就会崩溃。

你不需要频繁打开严苛模式（StrictMode），你可以在主活动的onCreate()函数中打开它，你也可以在Application派生类的OnCreate()函数中设置严苛模式（StrictMode）。线程中运行的任何代码都可以设置严苛模式（StrictMode），但你的确只需要设置一次，一次就够了。

类似于线程策略（ThreadPolicy），严苛模式（StrictMode）有虚拟机策略（VmPolicy）。虚拟机策略（VmPolicy）能检查内存泄漏，譬如，当关闭一个SQLite对象前的完结操作，或其他任何类似可关闭对象在关闭前的完结操作。虚拟机策略（VmPolicy）由一个类似的Builder类创建，如下面的代码所示。和线程策略（ThreadPolicy）不同的是，虚拟机策略（VmPolicy）不能通过一个对话框提供警告。

StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
    .detectLeakedSqlLiteObjects()
    .penaltyLog()
    .penaltyDeath()
    .build()); 

因为设置发生在线程中，严苛模式（StrictMode）甚至能在从一个对象到另一个对象的控制流中找到违例事件。当违例发生，你会惊奇地注意到代码正运行于主线程，而栈trace将帮助你发现它如何发生。于是你能单步调试解决问题，或是将代码移到它自己的后台线程，或是就保持原来的处理方式。这都取决与你。当然，你可能希望适时关闭严苛模式（StrictMode），当你的程序作为产品发布时，你可不希望它仅为了一个警告在你的用户手里崩溃。

有两个方法可以关闭严苛模式（StrictMode），最直接的就是移除相应代码，但这样做不利于持续开发的产品。你通常可以定义一个应用级别布尔变量来测试是否需要调用严苛模式（StrictMode）代码。在发布产品前将这个值定义为FALSE。更优雅的方式是利用调试模式（debug mode）的特点，在AndroidManifest.xml中定义这个布尔变量。< application>字段的属性之一是android:debuggable，其义自明。

if (Config.DEVELOPER_MODE && Build.VERSION.SDK_INT
                >= Build.VERSION_CODES.GINGERBREAD) {
            StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .detectCustomSlowCalls()
            .detectDiskReads()
            .detectDiskWrites()
            .detectNetwork()
            .penaltyLog()
            .build());
            StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
            .detectAll()
            .detectActivityLeaks()
//          .detectFileUriExposure()//API18支持
            .detectLeakedClosableObjects()
//          .detectLeakedRegistrationObjects()//api16支持
            .detectLeakedSqlLiteObjects()
            .penaltyLog()
            .build());
        }

这段代码是我在项目中使用的，给大家参考。

使用Eclipse调试环境，ADT自动为你设置debuggable属性，使项目更易于管理。当你在模拟器上或直接在设备上部署应用，debuggable属性为TRUE，当你导出应用建立一个产品版本，ADT将该属性置为FALSE。注意，如果你另行设置了这个属性值，ADT不会改变它。

• MAT说明

  Dalvik Debug Monitor Server (DDMS) 是 ADT插件的一部分，其中有两项功能可用于内存检查 :

· heap 查看堆的分配情况

· allocation tracker跟踪内存分配情况

DDMS 这两项功能有助于找到内存泄漏的操作行为。

Eclipse Memory Analysis Tools (MAT) 是一个分析 Java堆数据的专业工具，用它可以定位内存泄漏的原因。

工具地址 : https://www.eclipse.org/mat/

打开网页，图如：

点击图中圈中部分：

update site部分就是下载地址。

复制下来，打开eclipse，help-install new software,界面：

然后就是路径next 安装就可以了，可能耽误点时间，有点慢。安装成功之后，需要重新启动eclipse，重新启动即可。

• 工具和代码使用

以上从代码和工具两个方面进行了设置，下面就是如何利用上面的两点进行内存泄漏的检测。不过说实话，本人并没有使用的非常熟练，只是自己在做项目过程中，摸索出来了一点点谈资而已，姑且在这里和大家分享一下。后期如果在这方面有新的理解的话，后期再补充，到时再和大家分享。

本人在利用上面的代码和工具的时候，发现控制台经常输出一下信息：

也就是一个activity被创建了两个实例，但是activity应该被创建一个实例才对，这就是引起了activity没有被及时的释放，如果情况严重，必然引起内存不够app崩溃。

后来查查网上大家的说法知道，这里的instances=2是基本正常现象，就是你刚刚打开一个activity关闭之后打开该activity，之前的activity实例还没有来得及回收，所以出现了上面的strictmode的输出信息。

那么就有一个问题了，如果instances是2以上的值呢？每打开同一个activity之后，连续不断的打开，instances值不断再增加的话，那就是有问题的！说明该activity类中有对象一直持有该activity实例没有释放，所以这个时候就要检查该activity中的代码了！

以上是strictmode的控制台信息，那么如何利用MAT工具呢？

然后进入 DDMS管理界面，

如图中所示，找到设备，打开调试的app,在正在之心的线程中，找到对应的app process，图：

点击工具栏上的update heap来更新统计信息

DDMS 可以将当前的内存 Dump成一个 hprof格式的文件，MAT 读取这个文件后会给出方便阅读的信息，配合它的查找，对比功能，就可以定位内存泄漏的原因。

· 获取 hprof文件

点击工具栏上的按钮，将内存信息保存成文件。 如果是用 MAT Eclipse 插件获取的 Dump文件，则不需要经过转换，Adt会自动进行转换然后打开。

· 转换 hprof文件

DDMS Dump 出的文件要经过转换才能被 MAT识别，Android SDK提供了这个工具 hprof-conv (位于 sdk/tools下)

· ./hprof-conv xxx-a.hprof xxx-b.hprof

· 用 MAT打开转换后的 hprof文件

点击finish,出现如下界面：

点击图中的圈中的图标，出现Histogram界面，打开：

例如：

其中的objects对应该对象的数量，shallow heap对应对内存所占大小。通过使用正则表达式，找到我们需要进行判断的一个或一批对象的实例化情况，很容易找到哪些对象没有释放。

• 推荐

这里给大家一个参考网页：http://www.cnblogs.com/0616–ataozhijia/p/3954423.html 这篇文章写的很清楚详细。

文章中指出，内存泄漏的原因分析

总结出来只有一条： 存在无效的引用!

良好的模块设计以及合理使用设计模式有助于解决此问题。

这个原因深深赞同。我在项目中的问题就是利用这个原因解决的。

http://www.blogjava.net/rosen/archive/2010/05/21/321575.html

http://www.blogjava.net/rosen/archive/2010/06/13/323522.html

这两篇文章讲解的非常深入，推荐给大家。

最后给大家一些android开发的TIPS：

使用 android:largeHeap=”true”标记 (API Level >= 11)

在AndroidManifest.xml中的 Application节点中声明即可分配到更大的堆内存, android:largeHeap标记

在Android系统应用中也有广泛的应用 ,比如 Launcher, Browser这些内存大户上均有使用.

1、尽量不要长时间保持Activity的引用。

2、尝试用Application的context来代替Activity的context。因为Application是存在于程序的整个生命周期的，不像Activity一样随时有可能被销毁。

3、避免使用静态的持有Activity引用的成员变量，巧妙使用静态内部类。

4、适当运用弱引用。

5、如果确实需要保持对Activity的引用，必须确保在Activity的生命周期结束前，取消该引用。

关键的一点是，不要有无效的引用。

版权声明：本文为博主原创文章，未经博主允许不得转载。