DDMS中自带的Heap工具可以显示出当前堆内存的情况，分配内存、剩余的内存等信息。
首先是进入DDMS，运行应用，在DDMS的左边区域选中应用的包名，然后点击上方的update heap图标。
点击后控制台就会被触发了，但现在控制台可能没有下面的信息，因为只有在GC后控制台才会真正触发。所以可以点击Cause GC按钮，然后就可以看到下面的信息了。
说明：当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化
这些数据包括当前的数据对象个数，类对象个数，我们主要关注的是最上面的那个汇总栏（有ID的那个表格），还有下面的data object（数据对象，也就是我们的程序中大量存在的类类型的对象）。
在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下这个值的大小决定了是否会有内存泄漏。可以这样判断：
a) 不断的操作当前应用，同时注意观察data object的Total Size值；
b) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，
而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；
c) 反之，如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大，
直到到达一个上限后导致进程被Kill掉，这就是我们不希望的！
下面是一个例子，通过不断滑动照片墙来加载新的图片，从下面的动态图可以看见，当旧的图片被移出屏幕的时候引用了GC，占用的内存有明显的回落，接着开始上升（因为又加载了新的图片），但上升到一定程度便不会继续升高，这就说明这个程序不会不断的产生大量的对象，不太会出现OOM。
另外还可以使用heap dump来追踪内存信息。点击DDMS工具条上面的Dump HPROF文件按钮，选择文件存储位置（默认选择：D: oolsandroid-sdk ools）
这个由DDMS生成的文件不能直接用MAT工具打开，会提示文件格式不支持。需要转化：
（1）运行cmd，cd 到 D: oolsandroid-sdk ools目录下
（2）输入命令hprof-conv xxxxold.hprof yyyynew.hprof xxxx.hprof 为原文件，yyyy.hprof 为转化过后的文件(同样生成在D: oolsandroid-sdk ools目录下)
备注：
如果使用ADT（它包含DDMS的插件）同时也在eclipse里面安装了MAT，点击“dump HPROF”按钮将会自动地做转换（用hprof-conv），同时会在eclipse里面打开转换后的hprof文件（它其实用MAT打开）。