首先是进入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。
