android之 MAT、DDMS 等内存查看工具

最新推荐文章于 2023-10-30 03:00:00 发布

aaawqqq

最新推荐文章于 2023-10-30 03:00:00 发布

阅读量2w

点赞数 2

分类专栏： android 文章标签： eclipse mat android 内存优化 ddms

android 专栏收录该内容

42 篇文章 0 订阅

订阅专栏

最近学习内存管控看到一些很好的文章整合一下:

Android开发Eclipse中DDMS中Heap使用及GC_EXTERNAL_ALLOC含义

http://blog.csdn.net/dinglin_87/article/details/8011999

想要更深入的研究的朋友可以参照这些朋友的blog

http://www.blogjava.net/rosen/archive/2010/05/21/321575.html

http://www.blogjava.net/rosen/archive/2010/06/13/323522.html

使用 Eclipse Memory Analyzer 进行堆转储文件分析

http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html

官网地址: www.eclipse.org/mat/about/screenshots.php

Android官方文档 Memory Analysis for Android Applications

登陆不进去我看的其它人翻译的 (部分博客中的图片显示不出来)
http://blog.csdn.net/yexianghu/article/details/21627581 和 http://blog.csdn.net/cnnumen/article/details/7723159

以下转载自: http://blog.csdn.net/qeqeqe236/article/details/7338608

DDMS 的全称是Dalvik Debug Monitor Service，它为我们提供例如：为测试设备截屏，针对特定的进程查看正在运行的线程以及堆信息、Logcat、广播状态信息、模拟电话呼叫、接收SMS、虚拟地理坐标等等。DDMS为IDE和emultor及真正的android设备架起来了一座桥梁。开发人员可以通过DDMS看到目标机器上运行的进程/现成状态，可以android的屏幕到开发机上，可以看进程的heap信息，可以查看logcat信息，可以查看进程分配内存情况，可以像目标机发送短信以及打电话，可以像android开发发送地理位置信息。可以像GDB一样attach某一个进程调试。 SDKàtools目录下提供了ddms的完整版，直接双击ddms.bat运行即可。下面以Eclipse的DDMS perspective为例简单介绍DDMS的功能。

跟debug，java的perspective一样，安装好adt后会有一个DDMS得perspective，打开即可。

如果perspective里没有显示DDMS，刚按如下步骤执行：

点击上图中DDMS图标左边的那个图标，然后在下图中如果有DDMS，刚选择，如果没有，刚选择“其他”，然后在出现的窗口中双击“DDMS”即可。

注意：DDMS对Emulator和外接测试机有同等效用。如果系统检测到它们(VM)同时运行，那么DDMS将会默认指向 Emulator。以上2种启动后的操作有些不一样，建议分别尝试下。

DDMS 的工作原理

DDMS将搭建起IDE与测试终端(Emulator 或者connected device)的链接，它们应用各自独立的端口监听调试器的信息，DDMS可以实时监测到测试终端的连接情况。当有新的测试终端连接后，DDMS将捕捉到终端的ID,并通过adb建立调试器，从而实现发送指令到测试终端的目的。

DDMS监听第一个终端App进程的端口为8600，APP进程将分配8601，如果有更多终端或者更多APP进程将按照这个顺序依次类推。DDMS通过8700端口（“base port”）接收所有终端的指令。

打开后的窗口为：

下边通过GUI详细了解DDMS的一些功能

在GUI的左上角可以看到标签为”Devices”的面板，这里可以查看到所有与DDMS连接的终端的详细信息，以及每个终端正在运行的APP进程，每个进程最右边相对应的是与调试器链接的端口。因为Android是基于Linux内核开发的操作平台，同时也保留了Linux中特有的进程ID，它介于进程名和端口号之间。

device窗口罗列模拟器中所有的进程，右上角那一排按钮分别为：调试某个进程，更新某个进程，更新进程堆栈信息，停止某个进程，最后一个图片按钮时抓取android目前的屏幕。

当你选中某个进程，并按下调试进程按钮时，如果eclipse中有这个进程的代码，那就可以进行源代码级别的调试。有点像GDB attach。图片抓取按钮可以把当前android的显示桌面抓到你的机器上，也是非常有用。

右边那个窗口中有threads， heap ， file explorer选项卡。分别显示线程统计信息，栈信息，以及android的文件系统。

file explorer非常有用，他可以把文件上传到android手机，或者从手机下载下来，也可以进行删除操作。选中file explorer选项卡后，按下面三个按钮便可实现对android手机文件系统的上传，下载，删除操作。

emulator control也是非常重要的，通过它可以像手机发送短信，打电话，已经更新手机位置信息。

            Telephony Status: 通过选项模拟语音质量以及信号连接模式。
            Telephony Actions: 模拟电话接听和发送SMS到测试终端。
            Location Control: 模拟地理坐标或者模拟动态的路线坐标变化并显示预设的地理标识，可以通过以下3种方式：

· Manual：手动为终端发送二维经纬坐标。

· GPX：通过GPX文件导入序列动态变化地理坐标，从而模拟行进中GPS变化的数值。

· KML：通过KML文件导入独特的地理标识，并以动态形式根据变化的地理坐标显示在测试终端。

LogCat：显示输出的调试信息。

Console（控制台）：是Android模拟器输出的信息，加载程序等信息；

总结：

eclipse adt目前提供的的ddms功能只是真正ddms的一小部分，你可以直接使用tools下面的ddms来使用所有功能。其中有一个查看进程内存分配的功能比较有用。

另个要注意的是，在DDMS中模拟发送短信时，中文显示为乱码，在未来的开发中，我们必须要注意中文字符的问题

Android 内存泄漏调试

一、概述

Java编程中经常容易被忽视，但本身又十分重要的一个问题就是内存使用的问题。Android应用主要使用Java语言编写，因此这个问题也同样会在Android开发中出现。本文不对Java编程问题做探讨，而是对于在Android中，特别是应用开发中的此类问题进行整理。

由于作者接触Android时间并不是很长，因此如有叙述不当之处，欢迎指正。

二、Android(Java)中常见的容易引起内存泄漏的不良代码

Android主要应用在嵌入式设备当中，而嵌入式设备由于一些众所周知的条件限制，通常都不会有很高的配置，特别是内存是比较有限的。如果我们编写的代码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。为了能够使得Android应用程序安全且快速的运行，Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的进程被kill掉，而不会影响其他进程（如果是system_process等系统进程出问题的话，则会引起系统重启）。另一方面Android为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill掉。Android为应用进程分配的内存上限如下所示：

位置： /ANDROID_SOURCE/system/core/rootdir/init.rc 部分脚本

# Define the oom_adj values for the classes of processes that can be

# killed by the kernel. These are used in ActivityManagerService.

setprop ro.FOREGROUND_APP_ADJ 0

setprop ro.VISIBLE_APP_ADJ 1

setprop ro.SECONDARY_SERVER_ADJ 2

setprop ro.BACKUP_APP_ADJ 2

setprop ro.HOME_APP_ADJ 4

setprop ro.HIDDEN_APP_MIN_ADJ 7

setprop ro.CONTENT_PROVIDER_ADJ 14

setprop ro.EMPTY_APP_ADJ 15

# Define the memory thresholds at which the above process classes will

# be killed. These numbers are in pages (4k).

setprop ro.FOREGROUND_APP_MEM 1536

setprop ro.VISIBLE_APP_MEM 2048

setprop ro.SECONDARY_SERVER_MEM 4096

setprop ro.BACKUP_APP_MEM 4096

setprop ro.HOME_APP_MEM 4096

setprop ro.HIDDEN_APP_MEM 5120

setprop ro.CONTENT_PROVIDER_MEM 5632

setprop ro.EMPTY_APP_MEM 6144

# Write value must be consistent with the above properties.

# Note that the driver only supports 6 slots, so we have HOME_APP at the

# same memory level as services.

write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15

write /proc/sys/vm/overcommit_memory 1

write /proc/sys/vm/min_free_order_shift 4

write /sys/module/lowmemorykiller/parameters/minfree 1536,2048,4096,5120,5632,6144

# Set init its forked children's oom_adj.

write /proc/1/oom_adj -16

正因为我们的应用程序能够使用的内存有限，所以在编写代码的时候需要特别注意内存使用问题。如下是一些常见的内存使用不当的情况。

(一) 查询数据库没有关闭游标

描述：

程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。

示例代码：

Cursor cursor = getContentResolver().query(uri ...);

if (cursor.moveToNext()) {

... ...

}

修正示例代码：

Cursor cursor = null;

try {

cursor = getContentResolver().query(uri ...);

if (cursor != null && cursor.moveToNext()) {

... ...

}

} finally {

if (cursor != null) {

try {

cursor.close();

} catch (Exception e) {

//ignore this

}

(二) 构造Adapter时，没有使用缓存的 convertView

描述：

以构造ListView的BaseAdapter为例，在BaseAdapter中提高了方法：

public View getView(int position, View convertView, ViewGroup parent)

来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参 View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。

由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。ListView回收list item的view对象的过程可以查看:

android.widget.AbsListView.java --> void addScrapView(View scrap) 方法。

示例代码：

public View getView(int position, View convertView, ViewGroup parent) {

View view = new Xxx(...);

... ...

return view;

}

修正示例代码：

public View getView(int position, View convertView, ViewGroup parent) {

View view = null;

if (convertView != null) {

view = convertView;

populate(view, getItem(position));

...

} else {

view = new Xxx(...);

...

}

return view;

}

(三) Bitmap对象不在使用时调用recycle()释放内存

描述：

有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释：

/**

* Free up the memory associated with this bitmap's pixels, and mark the

* bitmap as "dead", meaning it will throw an exception if getPixels() or

* setPixels() is called, and will draw nothing. This operation cannot be

* reversed, so it should only be called if you are sure there are no

* further uses for the bitmap. This is an advanced call, and normally need

* not be called, since the normal GC process will free up this memory when

* there are no more references to this bitmap.

(四) 释放对象的引用

描述：

这种情况描述起来比较麻烦，举两个例子进行说明。

示例A：

假设有如下操作

public class DemoActivity extends Activity {

... ...

private Handler mHandler = ...

private Object obj;

public void operation() {

obj = initObj();

...

[Mark]

mHandler.post(new Runnable() {

public void run() {

useObj(obj);

}

});

}

我们有一个成员变量 obj，在operation()中我们希望能够将处理obj实例的操作post到某个线程的MessageQueue中。在以上的代码中，即便是mHandler所在的线程使用完了obj所引用的对象，但这个对象仍然不会被垃圾回收掉，因为DemoActivity.obj还保有这个对象的引用。所以如果在DemoActivity中不再使用这个对象了，可以在[Mark]的位置释放对象的引用，而代码可以修改为：

... ...

public void operation() {

obj = initObj();

...

final Object o = obj;

obj = null;

mHandler.post(new Runnable() {

public void run() {

useObj(o);

}

... ...

示例B:

假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。

但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。

总之当一个生命周期较短的对象A，被一个生命周期较长的对象B保有其引用的情况下，在A的生命周期结束时，要在B中清除掉对A的引用。

(五) 其他

Android应用程序中最典型的需要注意释放资源的情况是在Activity的生命周期中，在onPause()、onStop()、onDestroy()方法中需要适当的释放资源的情况。由于此情况很基础，在此不详细说明，具体可以查看官方文档对Activity生命周期的介绍，以明确何时应该释放哪些资源。

三、内存监测工具 DDMS --> Heap

无论怎么小心，想完全避免bad code是不可能的，此时就需要一些工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。Android tools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使用eclipse的ADT插件，并以真机为例，在模拟器中的情况类似)。用Heap监测应用进程使用内存情况的步骤如下：

1. 启动eclipse后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的；

2. 将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式，而不是作为“Mass Storage”；

3. 链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息；

4. 点击选中想要监测的进程，比如system_process进程；

5. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标；

6. 点击Heap视图中的“Cause GC”按钮；

7. 此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况［如图所示］。

说明：

a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作；

b) 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化；

c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。

如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做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掉。

d) 此处已system_process进程为例，在我的测试环境中system_process进程所占用的内存的data object的Total Size正常情况下会稳定在2.2~2.8之间，而当其值超过3.55后进程就会被kill。

总之，使用DDMS的Heap视图工具可以很方便的确认我们的程序是否存在内存泄漏的可能性。

四、内存分析工具 MAT(Memory Analyzer Tool)

如果使用DDMS确实发现了我们的程序中存在内存泄漏，那又如何定位到具体出现问题的代码片段，最终找到问题所在呢？如果从头到尾的分析代码逻辑，那肯定会把人逼疯，特别是在维护别人写的代码的时候。这里介绍一个极好的内存分析工具 -- Memory Analyzer Tool(MAT)。

MAT是一个Eclipse插件，同时也有单独的RCP客户端。官方下载地址、MAT介绍和详细的使用教程请参见：www.eclipse.org/mat，在此不进行说明了。另外在MAT安装后的帮助文档里也有完备的使用教程。在此仅举例说明其使用方法。我自己使用的是MAT的eclipse插件，使用插件要比RCP稍微方便一些。

使用MAT进行内存分析需要几个步骤，包括：生成.hprof文件、打开MAT并导入.hprof文件、使用MAT的视图工具分析内存。以下详细介绍。

(一) 生成.hprof文件

生成.hprof文件的方法有很多，而且Android的不同版本中生成.hprof的方式也稍有差别，我使用的版本的是2.1，各个版本中生成.prof文件的方法请参考：

http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/heap-profiling.html;hb=HEAD。

1. 打开eclipse并切换到DDMS透视图，同时确认Devices、Heap和logcat视图已经打开了；

2. 将手机设备链接到电脑，并确保使用“USB 调试”模式链接，而不是“Mass Storage“模式；

3. 链接成功后在Devices视图中就会看到设备的序列号，和设备中正在运行的部分进程；

4. 点击选中想要分析的应用的进程，在Devices视图上方的一行图标按钮中，同时选中“Update Heap”和“Dump HPROF file”两个按钮；

5. 这是DDMS工具将会自动生成当前选中进程的.hprof文件，并将其进行转换后存放在sdcard当中，如果你已经安装了MAT插件，那么此时MAT将会自动被启用，并开始对.hprof文件进行分析；

注意：第4步和第5步能够正常使用前提是我们需要有sdcard，并且当前进程有向sdcard中写入的权限(WRITE_EXTERNAL_STORAGE)，否则.hprof文件不会被生成，在logcat中会显示诸如

ERROR/dalvikvm(8574): hprof: can't open /sdcard/com.xxx.hprof-hptemp: Permission denied.

的信息。

如果我们没有sdcard，或者当前进程没有向sdcard写入的权限（如system_process），那我们可以这样做：

6. 在当前程序中，例如framework中某些代码中，可以使用android.os.Debug中的：

public static void dumpHprofData(String fileName) throws IOException

方法，手动的指定.hprof文件的生成位置。例如：

xxxButton.setOnClickListener(new View.OnClickListener() {

public void onClick(View view) {

android.os.Debug.dumpHprofData("/data/temp/myapp.hprof");

... ...

}

上述代码意图是希望在xxxButton被点击的时候开始抓取内存使用信息，并保存在我们指定的位置：/data/temp/myapp.hprof，这样就没有权限的限制了，而且也无须用sdcard。但要保证/data/temp目录是存在的。这个路径可以自己定义，当然也可以写成sdcard当中的某个路径。

(二) 使用MAT导入.hprof文件

1. 如果是eclipse自动生成的.hprof文件，可以使用MAT插件直接打开（可能是比较新的ADT才支持）；

2. 如果eclipse自动生成的.hprof文件不能被MAT直接打开，或者是使用android.os.Debug.dumpHprofData()方法手动生成的.hprof文件，则需要将.hprof文件进行转换，转换的方法：

例如我将.hprof文件拷贝到PC上的/ANDROID_SDK/tools目录下，并输入命令hprof-conv xxx.hprof yyy.hprof，其中xxx.hprof为原始文件，yyy.hprof为转换过后的文件。转换过后的文件自动放在/ANDROID_SDK/tools目录下。OK，到此为止，.hprof文件处理完毕，可以用来分析内存泄露情况了。

3. 在Eclipse中点击Windows->Open Perspective->Other->Memory Analyzer，或者打Memory Analyzer Tool的RCP。在MAT中点击File->Open File，浏览并导入刚刚转换而得到的.hprof文件。

(三) 使用MAT的视图工具分析内存

导入.hprof文件以后，MAT会自动解析并生成报告，点击Dominator Tree，并按Package分组，选择自己所定义的Package类点右键，在弹出菜单中选择List objects->With incoming references。这时会列出所有可疑类，右键点击某一项，并选择Path to GC Roots -> exclude weak/soft references，会进一步筛选出跟程序相关的所有有内存泄露的类。据此，可以追踪到代码中的某一个产生泄露的类。

MAT的界面如下图所示。

具体的分析方法在此不做说明了，因为在MAT的官方网站和客户端的帮助文档中有十分详尽的介绍。

了解MAT中各个视图的作用很重要，例如www.eclipse.org/mat/about/screenshots.php中介绍的。

总之使用MAT分析内存查找内存泄漏的根本思路，就是找到哪个类的对象的引用没有被释放，找到没有被释放的原因，也就可以很容易定位代码中的哪些片段的逻辑有问题了

用 Heap监测应用进程使用内存情况的步骤如下：

1. 启动eclipse后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的；
2. 将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式，而不是作为“Mass Storage”；
3. 链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息；
4. 点击选中想要监测的进程，比如system_process进程；
5. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标；
6. 点击Heap视图中的“Cause GC”按钮；
7. 此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况。
说明：
a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作；
b) 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化；
c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。
如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做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掉。
d) 此处已system_process进程为例，在我的测试环境中system_process进程所占用的内存的data object的Total Size正常情况下会稳定在2.2~2.8之间，而当其值超过3.55后进程就会被kill。

在DDMS里检查heap的使用情况

Dalvik Debug Monitor Server（DDMS）是主要的Android调试工具之一，也是ADT Eclipse plug-in 的一部分，独立的程序版本也可以在Android SDK的根目录下的tools/下面找到。关于DDMS更多的信息，请参考使用DDMS 。

我们来使用DDMS检查这个应用的heap使用情况。你可以使用下面的两种方法启动DDMS：

from Eclipse: click Window > Open Perspective > Other... > DDMS
or from the command line: run ddms (or ./ddms on Mac/Linux) in thetools/ directory

在左边的面板选择进程com.example.android.hcgallery，然后在工具条上边点击Show heap updates按钮。这个时候切换到DDMS的VM Heap分页。它会显示每次gc后heap内存的一些基本数据。要看第一次gc后的数据内容，点击Cause GC按钮：

我们可以看到现在的值（Allocated列）是有一些超过8MB。现在滑动相片，这时看到数据在增大。因为只有仅仅13个相片在程序里边，所以泄露的内存只有这么大。在某种程度上来说，这时最坏的一种内存泄露，因为我们没法得到 OutOfMemoryError来提醒我们说现在内存溢出了。

生成heap dump

我们现在使用heap dump来追踪这个问题。点击DDMS工具条上面的Dump HPROF文件按钮，选择文件存储位置，然后在运行hprof-conv。在这个例子里我们使用独立的MAT版本（版本1.0.1），从MAT站点下载。

如果你使用ADT（它包含DDMS的插件）同时也在eclipse里面安装了MAT，点击“dump HPROF”按钮将会自动地做转换（用hprof-conv）同时会在eclipse里面打开转换后的hprof文件（它其实用MAT打开）。

用MAT分析heap dumps

启动MAT然后加载刚才我们生成的HPROF文件。MAT是一个强大的工具，讲述它所有的特性超出了本文的范围，所以我只想演示一种你可以用来检测泄露的方法：直方图（Histogram）视图。它显示了一个可以排序的类实例的列表，内容包括：shallow heap（所有实例的内存使用总和），或者retained heap（所有类实例被分配的内存总和，里面也包括他们所有引用的对象）。

如果我们按照shallow heap排序，我们可以看到byte[]实例在顶端。自从Android3.0（Honeycomb），Bitmap的像素数据被存储在byte数组里（之前是被存储在Dalvik的heap里），所以基于这个对象的大小来判断，不用说它一定是我们泄露掉的bitmap。

右击byte[]类然后选择List Objects > with incoming references。它会生成一个heap上的所有byte数组的列表，在列表里，我们可以按照Shallow Heap的使用情况来排序。

选择并展开一个比较大的对象，它将展示从根到这个对象的路径--就是一条保证对象有效的链条。注意看，这个就是我们的bitmap缓存！

MAT不会明确告诉我们这就是泄露，因为它也不知道这个东西是不是程序还需要的，只有程序员知道。在这个案例里面，缓存使用的大量的内存会影响到后面的应用程序，所以我们可以考虑限制缓存的大小。

使用MAT比较heap dumps

调试内存泄露时，有时候适时比较2个地方的heap状态是很有用的。这时你就需要生成2个单独的HPROF文件（不要忘了转换格式）。下面是一些关于如何在MAT里比较2个heap dumps的内容（有一点复杂）：

第一个HPROF 文件(using File > Open Heap Dump ).
打开 Histogram view.
在Navigation History view里 (如果看不到就从Window > Navigation History找 ), 右击histogram 然后选择Add to Compare Basket .
打开第二个HPROF 文件然后重做步骤2和3.
切换到Compare Basket view, 然后点击Compare the Results (视图右上角的红色"!"图标)。

Android模擬器命令列啟動模式
在android-sdk-windows-1.1\tools執行emulator以執行模擬器
加上-skin參數，指定顯示模式為HVGA-L，則可轉為橫向
emulator - skin HVGA-L (480*320，水平顯示) emulator - skin HVGA-L (320*480，垂直顯示，模擬器預設模式) emulator - skin HVGA-L (320*240，水平顯示) emulator - skin HVGA-L (240*320，垂直顯示)
使用mksdcard指令模擬1GB的記憶卡
mksdcard 1024M sacard.img
模擬插入 SD 卡的模擬器
emulator - sdcard sdcard.img
使用 adb+push 上載檔案到SD記憶卡
adb push 001.jpg /sdcard (複製檔案到 /sdcard 目錄下) adb push pictures /sdcard (複製 picture 照片目錄到 /sdcard 目錄下) adb push mp3 /sdcard (複製 mp3 音樂目錄到 /sdcard 目錄下) adb shell (Android 模擬器啟動命令列模式) #cd /sdcard (進入 /sdcard 目錄) #ls (查看 SD 記憶卡中的檔案)
使用 adb+pull 從 SD 記憶卡下載檔案
adb pull /sdcard/001.jpg . (下載 /sdcard 目錄下的檔案) adb pull /sdcard/pictures . (下載 sdcard 目錄下的 pictures 目錄)
刪除 SD 卡裡面的檔案
adb shell #ced /sdcard #rm 001.jpg (刪除 SD 記憶卡裡的檔案) #rm -r * (刪除 SD 記憶卡裡所有檔案與目錄)
Android模擬器影片播放方法
mksdcard 4096M video.img (製作一個影像檔的 SD 記憶卡) adb push video.avi /sdcard (從電腦複製影像檔到 SD 卡中) emulator -sdcard video.img (啟動模擬器並載入 SD 卡)
下載免費的影片播放軟體，ex: Meridian Video Player (iiivpa.apk)
http://sites.google.com/site/eternalsandbox/Home/meridian-video-player
adb install iiivpa.apk (安裝Meridian Video Player)
接下來就可以用裝上去的player播放.mp4、3gp與.wmv三種檔案格式
安裝 APK 應用程式
adb install filename.apk (安裝filename.apk) adb install -r filename.apk (保留已設定資料，重新安裝filename.apk) adb -s emulator-5554 install filename.apk (指定安裝 APK 套件在 5554 的 Android 模擬器中)
移除 APK 應用程式
adb uninstall package adb uninstall -k package (移除程式時，保留資料)
此package名稱不是安裝APK套裝時的檔名或顯示在模擬器中的應用程式名稱
可以先到/data/data或data/app目錄下，查詢想移除的package名稱
adb shell ls /data/data 或 /data/app (查詢 Package 名稱) exit adb uninstall package (移除查詢到的 Package)
ADB 系統除錯與連結工具
$adb devices (顯示目前有多少個模擬器正在執行)
$adb -s <serialNumber> <command> (指定模擬器來操作) adb -s emulator-5554 install email.apk
$adb install apkfile (安裝 APK 應用程式套件) adb install email.apk $adb uninstall package (移除 APK 應用程式套件) adb uninstall com.android.email
$adb shell (進入 Android 系統指令列模式) $ls $dmesg (查看 Android Linux Kernel 運作訊息)
ls - 顯示檔案目錄
cd - 進入目錄
rm - 刪除檔案
mv - 移動檔案
mkdir - 產生目錄
rmdir - 刪除目錄

$adb push <file/dir> (複製檔案到 SD 卡) adb push mp3 /sdcard $adb pull <file/dir> . (從 Android 系統下載檔案) adb pull /data/app/com.android.email
$adb logcat (監控模擬器運作紀錄，以Ctrl + c 離開監控模式)
$adb bugreport (產生 adb 除錯報告)
$adb get-state (獲得 adb 伺服器運作狀態)
$adb start-server (啟動 adb 伺服器) $adb kill-server (關掉 adb 伺服器)
$adb forward tcp:6100 tcp:7100 (更改模擬器網路 TCP 通訊埠)
$adb shell ps -x (顯示 Android 上所有正在執行的行程)
$adb version (顯示 adb 版本)
$adb help (顯示 adb 指令參數)
Emulator 命令列啟動參數
emulator -timezone Asia/Taipei (指定時區)
emulator -no-boo-anim (省略開機小機器人動畫畫面)
emulator -scale auto (調整模擬器視窗大小) emulator - scale factor (factor: 0.1-3.0)
emulator -dpi-device 300 (更改模擬器的解析度，default為 165dpi)
emulator -skin <skinID> (更改模擬器顯示模式)
emulator -help-keys (顯示鍵盤快速鍵說明)
emulator -shell (相當於adb shell 功能)
emulator -data data.img (使 /data 目錄使用 data.img 的檔案空間) emulator -sdcard sdcard.img (使 /sdcard 目錄使用 sdcard.img 的檔案空間) emulator -cache cache.img (瀏覽器暫存檔儲存空間)
emulator -wipe-data (使模擬器恢復到原廠設定)
emulator -help (顯示 emulator 指令參數)

aaawqqq

关注

2
点赞
踩
33

收藏

觉得还不错? 一键收藏
0
评论
android之 MAT、DDMS 等内存查看工具

DDMS 的全称是Dalvik Debug Monitor Service，它为我们提供例如：为测试设备截屏，针对特定的进程查看正在运行的线程以及堆信息、Logcat、广播状态信息、模拟电话呼叫、接收SMS、虚拟地理坐标等等。DDMS为IDE和emultor及真正的android设备架起来了一座桥梁。开发人员可以通过DDMS看到目标机器上运行的进程/现成状态，可以android的屏幕到开发机上，可
复制链接

扫一扫