Android应用的内存分析

Android内存调试

最新推荐文章于 2025-04-17 15:43:46 发布

转载最新推荐文章于 2025-04-17 15:43:46 发布 · 784 阅读

文章标签：

#android #内存 #泄露

Android 专栏收录该内容

41 篇文章

订阅专栏

本文介绍如何使用Android SDK中的工具，如DDMS和MAT，来检测和分析应用中的内存使用情况及内存泄露问题。

原文连接：点击打开链接，译文如下：

Dalvik虚拟机会进行垃圾回收，但这并不意味可以忽视内存管理，反而更应该留意内存受限的移动设备上的内存使用情况。这篇文章中，我们一起去看看Android SDK中的几个内存分析工具，这些工具可以帮你跟踪应用中的内存使用情况。

有些内存使用问题比较明显，例如：如果应用在用户每次触摸屏幕时都发生内存泄露，可能最终将触发OutOfMemoryError错误，并使应用崩溃。而有些问题则比较微妙，可能只是降低了应用（由于频繁的垃圾回收占用了较长时间）或整个系统的性能。

商业化工具

Android SDK提供了两种主要的应用程序内存使用情况分析途径：DDMS中的Allocation Tracker标签和堆转（heap dump）。Allocation Tracker用来获取给定时间里发生的各种内存分配情况，但无法给出应用程序堆的整体信息。关于Allocation Tracker的更多信息可以看文章Tracking Memory Allocations（译文连接：点击打开链接）。本文其余内容重点阐述堆转，一种更为强大的内存分析工具。

堆转是应用程序内存使用情况的快照，以名为HPROF的二进制格式存储。Dalvik虚拟机使用的格式与java HPROF工具中的相似但不完全相同。有多种方式能为正在运行的应用程序生成堆转，方式之一就是利用DDMS的Dump HPROF file按钮。如果要了解更为详细的堆转信息，可以使用android.os.Debug.dumpHprofData() 函数创建堆栈获取程序。

分析堆转，可以使用jhat或Eclipse的MAT等标准工具。但是，我们首先需要将Dalvik产生的.hprof文件转换为J2SE支持的HPROF格式，可以用Android SDK中的hprof-conv工具来实现该转换，示例：

[html] view plain copy

hprof-conv <span style="color:#3333FF;">dump</span>.hprof converted-<span style="color:#3333FF;">dump</span>.hprof

实例：调试内存泄露

Dalvik镜像中，程序员不需要显示的分配和释放内存，因此，不会像在C和C++中那样（由于内存的分配和释放没有处理好）发生内存泄露，只会在持续引用一个不再需要的对象时发生内存泄露。有时候一个单引用会使得一大批对象难以被垃圾回收（博主注：前者翻译的防止内存泄露一文中对Activity Context的引用就属此例）。

让我们以Android SDK中的HoneycombGallery（博主注：示例位于$SDK/samples/android-11/HoneycombGallery）为例，该例只是一个简单的照片画廊应用，展示了如何使用Honeycomb新增的部分API。（要编译和下载示例代码，可以看instructions）。这里我们故意在该应用中加入内存泄露代码，以便于演示如何对其进行内存泄露调试。

假设我们要修改程序，实现从网络获取显示图片。为了使其反应更灵敏，我们可能会实现一个保存最近浏览过的图片的缓存，通过对ContentFragment.java做很小的改动就可以实现。在该class文件的顶部添加一个静态变量：

[java] view plain copy

private static HashMap<String,Bitmap> sBitmapCache = new HashMap<String,Bitmap>();

这就是要加载的位图的缓存。修改 updateContentAndRecycleBitmap()方法，使其在加载前先检测缓存，加载后将图片添加到缓存。

[java] view plain copy

void updateContentAndRecycleBitmap(int category, int position) {
if (mCurrentActionMode != null) {
mCurrentActionMode.finish();
}
// Get the bitmap that needs to be drawn and update the ImageView.
// Check if the Bitmap is already in the cache
String bitmapId = "" + category + "." + position;
mBitmap = sBitmapCache.get(bitmapId);
if (mBitmap == null) {
// It's not in the cache, so load the Bitmap and add it to the cache.
// DANGER! We add items to this cache without ever removing any.
mBitmap = Directory.getCategory(category).getEntry(position)
.getBitmap(getResources());
sBitmapCache.put(bitmapId, mBitmap);
}
((ImageView) getView().findViewById(R.id.image)).setImageBitmap(mBitmap);
}

在这里，我们有意引入了内存泄露：只添加图片到缓存但从不移除。实际中，我们可能会通过一些手段来限制缓存的大小。

利用DDMS来检测堆的使用情况

DDMS（Dalvik Debug Monitor Server）是Android主要调试工具之一，也是Eclipse的ADT（Android Debug Tools）插件的一部分。在Android SDK的tools/目录下可以发现它的独立版本。更多关于DDMS的信息，请看Using DDMS。

让我们用DDMS来检测上述应用堆的使用情况，可以使用下面两种方式的其中之一来启动DDMS：

1）、通过Eclipse：单击Window > Open Perspective > Other... > DDMS

2）、通过命令行：在tools/目录下运行 ddms ( 在Mac/Linux上执行./ddms)

在Eclipse左边的窗口中选择进程com.example.android.hcgallery，并单击工具栏上的Show heap updates按钮；然后，在Eclipse右侧的窗口中切换到DDMS的VM Heap标签（博主注：不同版本的中的标签和按钮名称可能有所不同，我的Eclipse版本是Helios，工具栏上的按钮名为Update Heap，DDMS中的标签名为Heap，但无论名称是什么，功能和位置都是一样的）。每次垃圾回收后都会更新VM Heap中显示的堆内存使用情况的一些基本统计信息。如果要看首次更新的情况，单击Cause GC按钮。

可以看出程序的分配（Allocated栏）空间略微超过了8MB。现在翻动图片，并观察到该值变大了。由于这里应用中只有13张图片，内存泄露的大小是有限的。从某中意思上来说，这是一种最坏的内存泄露方式，因为，决不会有OutOfMemoryError向我们指示有内存泄露。

创建一个堆转

让我们用堆转来追踪问题。单击DDMS工具栏上的 Dump HPROF file按钮，选择保存路径，然后，执行hprof-conv命令。本例中，将使用独立版本的MAT(version 1.0.1)进行堆转分析，从MAT download site下载。

如果运行了ADT（DDMS的插件版），同时，MAT也已经在Eclipse中安装了，当单击Dump HPROF file按钮时，会自动完成转换（使用hprof-conv），并在Eclipse中打开转换后的hprof文件（使用MAT打开）。

使用MAT分析堆转

启动MAT并装载转换后的HPROF文件。MAT是一个功能强大的工具，但其特性的介绍超出了本文的范围，所以这里只演示一种侦测内存泄露的方法：直方图。直方图显示的是class列表，这些class是按实例化数进行排序的。shallow heap（所有实例使用的堆的大小总和），retained heap（所有实例使用的仍处于活动状态的堆的大小总和，包括引用的其他对象）

如果按照shallow heap的排序，可以看出：byte[]的实例高居首位。由于Android 3.0(Honeycomb)中，位图的像素数据存储在byte数组中（之前版本没有将其放入Dalvik的堆中），基于这些对象的大小，下了一个安全赌注，对于我们泄露的位图而言，将byte数组视为备用内存。

右单击byte[ ]类，选择 List Objects > with incoming references，生成一个堆中所有byte数组的列表，我们可以基于shallow heap的使用情况对其进行排序。

选择byte[ ]中大对象的其中之一，并一路追踪下去，就会看到从根到对象的整条路径——一条存放活动对象的引用链。瞧，以下就是我们的位图缓存：