mat 打开大hprof文件

mat 是分析卜尘java内存的利器，如果需要打开的 hprof 文件特别大，如何处理?修改mat配置文件 MemoryAnalyzer.ini

我打开的文件8G，所以，堆内存调整大一些，就可孙弊皮以愉快则差的使用了。

见下图

生成hprof文件，用mat进行分析

生成hprof文件可以在ddms选中进程点击窗口左上角的"dump hprof file"按钮来直接生成，也可以通过在程序加代码中来生成

代码2：

void generateHprof()

{

String packageName=getApplicationInfo().packageName

String hpFilePath="/data/data/"+packageName+"/input.hprof"

try {

//Debug.dumpHprofData("/sdcard/input.hprof")

Debug.dumpHprofData(hpFilePath)

} catch (IOException e) {

// TODO Auto-generated catch block

e.printStackTrace()

}

}

建议使用代码生成hprof，然后使用批处理hprof文件，然后用Memory Analyzer tool(mat)进行对多个hprof文件比较分析。

在mat导入.hprof文件以后，mat会自动解析并生成报告，点击Dominator Tree，并按Package分组，选择自己所定义的Package类,比较各个类在不同时期的Retained Heap,找出可疑类，然后选择该类，点右键，选中show retained Set 项,参看Retained Heap的详知陪细信息，进一步找出嫌疑项。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

一、批处理配置文件

批处理配燃蠢置文件config.bat如下：

rem the following var is for getProcessState.bat

set rawDatadir=rawData

set processName=android.process.acorecom.android.systemui

rem set processShortName=abc

set processShortName=

set outRoot=out

set statFilePrefix=stat

rem the following var is for getHprof.bat

set tools=D:\android\tools

set hpInputFileDir=/sdcard

set hpInputFile=input.hprof

set hpRoot=hpTemp

注1：rawDatadir为“ps -x”提取出来的文件的目录

注2：processName需要统计rss的进程的名字，可以同时统计多个，进程名之间用“；”进行分割。

注3：processShortName需要统计rss的进程的名字的缩写形式，如果不坐设置或设置为空，这程序会根据processName自动生成。

注4：outRoot为对进程的rss进行统计最后的生成文件的存放目录。

注5：statFilePrefix为对进程的rss进行统计最后的生成文件的前缀。

注6：tools为hprof-conv.exe所在的目录。

注7：hpInputFileDir为手机中我们生成的hprof文件所在的目录。

注8：hpInputFile为手机中我们生成的hprof文件的名字。

二，需要使用的bat库

子目录lib用于存放bat库

需要的bat库：genSerial.bat，getSubStr.bat。

关于genSerial.bat请参看《genSerial》

关于getSubStr.bat请参看《getSubStr》

三，在代码中生成Hprof文件：

在android代码，可以使用如下代码把hprof文件生成搭段蠢到sd卡上。

Debug.dumpHprofData("/sdcard/input.hprof")；

可以不用sd卡，而将hprof文件直接生成在手机上，但是只能在"/data/data/"+packageName的目录下。

实例1：

void generateHprof()

{

String packageName=getApplicationInfo().packageName

String hpFilePath="/data/data/"+packageName+"/input.hprof"

try {

//Debug.dumpHprofData("/sdcard/input.hprof")

Debug.dumpHprofData(hpFilePath)

} catch (IOException e) {

// TODO Auto-generated catch block

e.printStackTrace()

}

}

四，在电脑上通过批处理取转换Hprof 文件

如果在程序中用Debug.dumpHprofData("/sdcard/input.hprof")的方式生成了hprof文件，

那么就可以执行文件getHprof .bat来取得Hprof并转化为MemoryAnalyzer的格式。

getHprof.bat文件如下：

@echo off

call config.bat

if exist %hpInputFile% (

del %hpInputFile% /q

)

adb pull %hpInputFileDir%/%hpInputFile% .

if not exist %hpInputFile% (

echo fail to pull %hpInputFile%

exit 1

)

if not exist %hpRoot% (

md %hpRoot%

)

Setlocal enabledelayedexpansion

set path=%path%%cd%\lib

call genSerial

set serial=!genSerial~result!

set hpOutFile=%serial%.hprof

%tools%\hprof-conv.exe %hpInputFile% %hpRoot%\%hpOutFile%

echo success!

endlocal

最近在写性能优化专题相关文章，依次写了“Android电量优化全解析”、“Android性能优化全解析”、“Android渲染优化解析”、“Android计算优化解析”。文章中有提到许多碧盯性能优化的工具，但由于文章重点都是如何分析性能相关的论述，对工具的使用介绍大都是简单略过，下面简单介绍下性能优化工具-MAT（Memory Analyzer Tool）使用，介绍的顺序为：

MAT工具全称为Memory Analyzer Tool，一款详细分析Java堆内存的工具，该工具非常强大，为了使用该工具，我们需要hprof文件。但是该文件不能直接被MAT使用，需要进行一步转化，可以使用hprof-conv命令来转化，但是Android Studio可以直接转化，转化方法如下：

1.选择一个hprof文件，点击右键选择Export to standard .hprof选项。

2.填写更改后的文件名和路径。

点击OK按钮后，MAT工具所需的文件就生成了！

下面我们用MAT来打开转换后的doctorq.hprof文件：

1.打开MAT后选悔昌和择File->Open File选择我们刚才生成的doctorq.hprof文件

2.选择该文件后，MAT会有几秒种的时间解析该文件，有的hprof文件可能过大，会有更长的时间解析，解析后，展现在我们的面前的界面如下:

这是个总览界面，会大体给出一些分析后初步的结论。

该视图会首页总结出当前这个Heap dump占用了多大的内存，其中涉及的类有多少，对象有多少，类加载器，如果有没有回收的对象，会有一个连接，可以直接参看(图中的Unreachable Objects Histogram)。

比如该例子中显示了Heap dump占用了41M的内存，5400个类，96700个对象，6个类加载器， 然后还会有各种分类信息。

会列举出Retained Size值最大的几个值，你可以将鼠标放到饼图中的扇叶上，可以在右侧看出详细信息:

图中灰色区域，并不是我们需要关心的，他是除了大内存对象外的其他对象，我们需要关心的就是图中彩色区域，比如图中2.4M的对象，我们来看看该对象到底是啥

该对象是一个Bitmap对象，你如果想知道该对象到底是什么图片，可以使用图片工具gimp工具浏览该对迅扮象。

histogram视图主要是查看某个类的实例个数，比如我们在检查内存泄漏时候，要判断是否频繁创建了对象，就可以来看对象的个数来看。也可以通过排序看出占用内存大的对象:

默认是类名形式展示，你也可以选择不同的显示方式，有以下四种方式:

下面来演示一下:

该视图会以占用总内存的百分比来列举所有实例对象，注意这个地方是对象而不是类了，这个视图是用来发现大内存对象的。这些对象都可以展开查看更详细的信息，可以看到该对象内部包含的对象：

这个视图会展示一些可能的内存泄漏的点，比如上图上图显示有3个内存泄漏可疑点，我们以Problem Suspect 1为例来理解该报告，首先我们来看该可疑点详细信息:

上面信息显示ImageCahe类的一个实例0xa50819f8占用了14.19%的内存，具体值为5147200字节(5147200/1024/1024=4.9M),并存放在LinkedHashMap这个集合中，然后我们点击Details跳转到更详细的页面:

这样我们就能找到在我们的app源码中造成该泄漏可疑点的地方，很容易去定位问题。

---