使用DDMS检查这个应用的heap使用情况。你可以使用下面的方法启动DDMS：

From Eclipse : click Window > Open Perspective>Other...>DDMS

在左边的面板选择进程com.founder.android.new.kyodo.activity，然后在工具条上边点击heap updates按钮。

这个时候切换到DDMS的VMHeap分页。它会显示每次gc后heap内存的一些基本数据。要看第一次gc后的数据内容，点击CauseGC按钮： 

1.生成heap dump

我们现在使用heap dump来追踪这个问题。点击DDMS工具条上面的Dump HPROF文件按钮，选择文件存储位置，然后在运行hprof-conv。

如果你使用ADT（它包含DDMS的插件）同时也在eclipse里面安装了MAT，点击“dump HPROF”按钮将会自动地做转换（用hprof-conv）同时会在eclipse里面打开转换后的hprof文件（它其实用MAT打开）。

将生成的.hprof文件导入到MAT中，选择Leak Suspects Report ，得到下图：

2.用MAT分析heap dumps

启动MAT然后加载刚才我们生成的HPROF文件。MAT是一个强大的工具，讲述它所有的特性超出了本文的范围，所以我只想演示一种你可以用来检测泄露的方法：直方图（Histogram）视图。它显示了一个可以排序的类实例的列表，内容包括：shallow heap（所有实例的内存使用总和），或者retained heap（所有类实例被分配的内存总和，里面也包括他们所有引用的对象）。

如果我们按照shallow heap排序，自从Android3.0（Honeycomb），Bitmap的像素数据被存储在byte数组里（之前是被存储在Dalvik的heap里），所以基于这个对象的大小来判断。

右击byte[]类然后选择List Objects>with incoming references。它会生成一个heap上的所有byte数组的列表，在列表里，我们可以按照Shallow Heap的使用情况来排序。选择并展开一个比较大的对象，它将展示从根到这个对象的路径--就是一条保证对象有效的链条。

MAT不会明确告诉我们这就是泄露，因为它也不知道这个东西是不是程序还需要的，只有程序员知道。在这个案例里面，缓存使用的大量的内存会影响到后面的应用程序，所以我们可以考虑限制缓存的大小。

3.使用MAT比较heap dumps

调试内存泄露时，有时候适时比较2个地方的heap状态是很有用的。这时你就需要生成2个单独的HPROF文件（不要忘了转换格式）。下面是一些关于如何在MAT里比较2个heapdumps的内容（有一点复杂）：

a) 第一个HPROF文件(usingFile>OpenHeapDump).

b) 打开Histogram view.

c) 在Navigation Historyview里(如果看不到就从Window>NavigationHistory找).右击histogram然后选择AddtoCompareBasket.

d) 打开第二个HPROF文件然后重做步骤2和3.