使用Android Studio调试内存问题

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/yutao52shi/article/details/50055669

前言

内存问题对于Android开发者是永远的痛。如果一个Android程序员说他没有遇到过OutOfMemory,那只能说他绝对不是做Android的。以往在ADT年代,都是使用eclipse的Mat(http://www.eclipse.org/mat/)插件来做内存分析。在使用了Android Studio开发后,发现AS不仅带来了不少编码上的便利,同时还带来了很多有用的工具。其中的内存分析工具就是一个经典。

正文

打开AS,在底部的Android Monitor里面就能发现这个Memory的Tab,在里面可以实时的看到内存的走势,能够在自测中发现什么地方会造成内存暴增,同时也很容易的看出GC point(内存突然下降一大截,肯定就是做了Full GC)。
这里写图片描述
看到右边有4个按钮,第一个是暂停,暂时不做任何讲解了。下面详细讲解其他三个按钮的功能。

Initial GC

这个命令会让APP执行一次Full GC。这个功能使用场景不是很多,我一般是会在Dump Heap之前执行一次,这样会减少很多无用的对象。点击之后,有时候能够明显看出内存变化
这里写图片描述

Dump Java Heap

这个功能是我用得最多,也是认为最好用的内存分析功能。因为基本能够通过它观察出哪些对象占用了巨量内存,并且能够找出它们被什么对象把持住,导致无法释放。点击Dump Java Heap后,APP会Freeze住。然后就是等待,这个时候最好别做其他事情,否则可能失败。大概几十秒后,就会进入读取hprof文件的界面了。
这里写图片描述
从途中可以基本看出来,有一个10Mac大小的Bitmap被gpuimage里面的模块把持住了(由于被混淆,所以类名是f)。通过这些信息,基本就可以解决绝大部分OOM问题了。

Start Allocation Tracking

这个功能可以记录一段区间内各个线程各个方法的内存分配情况。我用得并不多,主要用于调试在复杂系统里面短时间内存暴增造成GC频繁的Case。使用方法:先点击一次,然后会看到Memory Recorder开始转动,然后自己开始在APP上面做相应的操作。在合适的时间再点一次,结束记录。
这里写图片描述
然后APP会Freeze,过一会儿就会进入到alloc文件的打开界面了。通过分析alloc数据,我们可以知道某一个thread里面的所有的调用过的方法所分配的堆大小,通过这些数据可以让我们针对方法级别堆程序进行优化。
这里写图片描述

题外话

除了即时Dump即时查看,我们也可以用AS直接打开.hprof和.alloc文件,十分方便打开一些其他人员(比如QA)Dump出来的Heap dump。
此外,这些工具虽然在以前的DDMS里面也带了,但是个人觉得在AS里面进行了一些Improvement,界面十分简洁,关键数据一目了然。基本能够满足日常生产需求了。但是如果要做更加深入的分析,还是需要借助外部工具,AS里面带的hprof查看工具远没有MAT的数据详细,只是提供了一些关键数据。

猜你喜欢

转载自blog.csdn.net/yutao52shi/article/details/50055669