6.11　Dump Heap

Dump Heap工具可以在DDMS工具中找到，在Android Studio的Monitor-Memory Monitor中也有这个功能。不过，Android Studio中的这个Dump Heap工具没有DDMS中的强大好用。

当待检测的程序运行起来以后，打开DDMS，点击“Update Heap”按钮，然后点击“cause GC”按钮，强迫应用进行一次GC，如图6.53所示。

图6.53　cause GC

在系统GC后，下面列表中就会显示当前内存的分配状态。从上面的列表中，开发者可以获取到如下所示的信息。

• 当前App所分配到的总Heap Size为13.122MB。
• 当前已分配的Heap Size为7.873MB，一共分配给了55207个对象。
• 当前剩余Heap Size为5.249MB。
• 当前Heap使用率为60%。

这些基本是内存使用的总览。当开发者点击下面的详细列表时，在界面的最下方会显示具体分配对象树与内存的图表，如图6.54所示。

图6.54　分配对象树

在这个详细列表中，前三列也是类似的总体概览，即free、data object、class object。同时还有它们的数量、Size，最大Size、最小Size、最多的中间Size、平均值等信息。

最需要注意的是free这一行。可以注意到，在最上面的总表中已经有了free的Size大小，那么为什么这里还有一行free呢？实际上，这里的free就是前面提到的内存碎片。当你新增一个对象的时候，只有大小能够插入这些碎片内存中的对象才能复用这些碎片内存，否则就会从真正的free空间中重新划分内存。因此这里的free（内存碎片free空间）是判断内存碎片化是否严重的一个关键指标。

那么除了这一行，剩下的最有价值的数据就是1-byte array这一行。在Android中，1-byte array就是用来存储图像数据的，如果1-byte array一行过大，就需要好好检查图像的内存管理了。

那么如何使用Dump Heap功能分析内存泄漏呢？通用的做法是使用Update Heap进行内存监听，然后操作可能发生内存泄漏App功能、界面，并点击Cause GC进行手动GC。经过多次操作后，查看data object的Total Size的大小是否有很大的变化。如果有，那么可能是发生了内存泄漏，导致内存使用不断上升。