Android DDMS如何使用？

By: 海市蜃楼 | In: Android开发

11九2009

DDMS 的全称是Dalvik Debug Monitor Service，它为我们提供例如：为测试设备截屏，针对特定的进程查看正在运行的线程以及堆信息、Logcat、广播状态信息、模拟电话呼叫、接收SMS、虚拟地理坐标等等。

如何启动 DDMS

DDMS 工具存放在SDK – tools/路径下，启动DDMS方法如下:

1. 直接双击ddms.bat运行；
2. 在Eclipes调试程序的过程中启动DDMS，在Eclipes中的界面如下：
   
   选择“Other”，界面如下：
   
   双击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的一些功能

Devices

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

在面板的右上角有一排很重要的按键他们分别是Debug the selected process、Update Threads、Update Heap、Stop Process和ScreenShot。

Emulator Control

通过这个面板的一些功能可以非常容易的使测试终端模拟真实手机所具备的一些交互功能，比如：接听电话，根据选项模拟各种不同网络情况，模拟接受SMS消息和发送虚拟地址坐标用于测试GPS功能等。

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

• Manual： 手动为终端发送二维经纬坐标。
• GPX： 通过GPX文件导入序列动态变化地理坐标，从而模拟行进中GPS变化的数值。
• KML： 通过KML文件导入独特的地理标识，并以动态形式根据变化的地理坐标显示在测试终端。

Threads、Heap、File Exporler

这几项，我们在其他开发工具中也经常使用，就在不此详细说明了。通过File Exporler可以查看Android模拟器中的文件，可以很方便的导入/出文件。

Locate、Console

Locate：显示输出的调试信息，详见Android下如何调试程序？；
Console：是Android模拟器输出的信息，加载程序等信息；

使用DDMS模拟发送短信，操作过程如下：

在Emulator Control\Telephony Actions 中输入以下内容

单击发送后，在Android模拟器中打开Messaging，看到下面的短信：

单击新短信，详细查看短信内容：

中文显示为乱码，在未来的开发中，我们必须要注意中文字符的问题。

总结说明

DDMS是我们开发人员最好的调试工具，它将是每个从事Android开发的人员都不可缺少的。

Using DDMS

IN THIS DOCUMENT

1. Running DDMS
2. How DDMS Interacts with a Debugger
3. Using DDMS
   1. Viewing heap usage for a process
   2. Tracking memory allocation of objects
   3. Working with an emulator or device's file system
   4. Examining thread information
   5. Starting method profiling
   6. Using the Network Traffic tool
   7. Using LogCat
   8. Emulating phone operations and location

Android ships with a debugging tool called the Dalvik Debug Monitor Server (DDMS), which provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information, incoming call and SMS spoofing, location data spoofing, and more. This page provides a modest discussion of DDMS features; it is not an exhaustive exploration of all the features and capabilities.

Running DDMS

---

DDMS is integrated into Eclipse and is also shipped in the tools/ directory of the SDK. DDMS works with both the emulator and a connected device. If both are connected and running simultaneously, DDMS defaults to the emulator.

• From Eclipse: Click Window > Open Perspective > Other... > DDMS.
• From the command line: Type ddms (or ./ddms on Mac/Linux) from the tools/directory.

How DDMS Interacts with a Debugger

---

On Android, every application runs in its own process, each of which runs in its own virtual machine (VM). Each VM exposes a unique port that a debugger can attach to.

When DDMS starts, it connects to adb. When a device is connected, a VM monitoring service is created between adb and DDMS, which notifies DDMS when a VM on the device is started or terminated. Once a VM is running, DDMS retrieves the VM's process ID (pid), via adb, and opens a connection to the VM's debugger, through the adb daemon (adbd) on the device. DDMS can now talk to the VM using a custom wire protocol.

DDMS assigns a debugging port to each VM on the device. Typically, DDMS assigns port 8600 for the first debuggable VM, the next on 8601, and so on. When a debugger connects to one of these ports, all traffic is forwarded to the debugger from the associated VM. You can only attach a single debugger to a single port, but DDMS can handle multiple, attached debuggers.

By default, DDMS also listens on another debugging port, the DDMS "base port" (8700, by default). The base port is a port forwarder, which can accept VM traffic from any debugging port and forward it to the debugger on port 8700. This allows you to attach one debugger to port 8700, and debug all the VMs on a device. The traffic that is forwarded is determined by the currently selected process in the DDMS Devices view.

The following screenshot shows a typical DDMS screen in Eclipse. If you are starting DDMS from the command line, the screen is slightly different, but much of the functionality is identical. Notice that the highlighted process,com.android.email, that is running in the emulator has the debugging port 8700 assigned to it as well as 8606. This signifies that DDMS is currently forwarding port 8606 to the static debugging port of 8700.

Figure 1. Screenshot of DDMS

If you are not using Eclipse and ADT, read Configuring your IDE to attach to the debugging port, for more information on attaching your debugger.

Tip: You can set a number of DDMS preferences in File > Preferences. Preferences are saved to$HOME/.android/ddms.cfg.

Known debugging issues with Dalvik
Debugging an application in the Dalvik VM should work the same as it does in other VMs. However, when single-stepping out of synchronized code, the "current line" cursor may jump to the last line in the method for one step.

Using DDMS

---

The following sections describe how to use DDMS and the various tabs and panes that are part of the DDMS GUI. The Eclipse version and the command line version have minor UI differences, but the same functionality. For information on running DDMS, see the previous section in this document, Running DDMS.

Viewing heap usage for a process

DDMS allows you to view how much heap memory a process is using. This information is useful in tracking heap usage at a certain point of time during the execution of your application.

To view heap usage for a process:

1. In the Devices tab, select the process that you want to see the heap information for.
2. Click the Update Heap button to enable heap information for the process.
3. In the Heap tab, click Cause GC to invoke garbage collection, which enables the collection of heap data. When the operation completes, you will see a group of object types and the memory that has been allocated for each type. You can click Cause GC again to refresh the data.
4. Click on an object type in the list to see a bar graph that shows the number of objects allocated for a particular memory size in bytes.

Tracking memory allocation of objects

DDMS provides a feature to track objects that are being allocated to memory and to see which classes and threads are allocating the objects. This allows you to track, in real time, where objects are being allocated when you perform certain actions in your application. This information is valuable for assessing memory usage that can affect application performance.

To track memory allocation of objects:

1. In the Devices tab, select the process that you want to enable allocation tracking for.
2. In the Allocation Tracker tab, click the Start Tracking button to begin allocation tracking. At this point, anything you do in your application will be tracked.
3. Click Get Allocations to see a list of objects that have been allocated since you clicked on the Start Tracking button. You can click on Get Allocations again to append to the list new objects that that have been allocated.
4. To stop tracking or to clear the data and start over, click the Stop Tracking button.
5. Click on a specific row in the list to see more detailed information such as the method and line number of the code that allocated the object.

Working with an emulator or device's file system

DDMS provides a File Explorer tab that allows you to view, copy, and delete files on the device. This feature is useful in examining files that are created by your application or if you want to transfer files to and from the device.

To work with an emulator or device's file system:

1. In the Devices tab, select the emulator that you want to view the file system for.
2. To copy a file from the device, locate the file in the File Explorer and click the Pull file button.
3. To copy a file to the device, click the Push file button on the File Explorer tab.

Examining thread information

The Threads tab in DDMS shows you the currently running threads for a selected process.

1. In the Devices tab, select the process that you want to examine the threads for.
2. Click the Update Threads button.
3. In the Threads tab, you can view the thread information for the selected process.

Starting method profiling

Method profiling is a means to track certain metrics about a method, such as number of calls, execution time, and time spent executing the method. If you want more granular control over where profiling data is collected, use thestartMethodTracing() and stopMethodTracing() methods. For more information about generating trace logs, seeProfiling and Debugging UIs.

Before you start method profiling in DDMS, be aware of the following restrictions:

• Android 2.1 and earlier devices must have an SD card present and your application must have permission to write to the SD card.
• Android 2.2 and later devices do not need an SD card. The trace log files are streamed directly to your development machine.

To start method profiling:

1. On the Devices tab, select the process that you want to enable method profiling for.
2. Click the Start Method Profiling button.
3. Interact with your application to start the methods that you want to profile.
4. Click the Stop Method Profiling button. DDMS stops profiling your application and opens Traceview with the method profiling information that was collected between the time you clicked on Start Method Profiling and Stop Method Profiling.

Using the Network Traffic tool

In Android 4.0, the DDMS (Dalvik Debug Monitor Server) includes a Detailed Network Usage tab that makes it possible to track when your application is making network requests. Using this tool, you can monitor how and when your app transfers data and optimize the underlying code appropriately. You can also distinguish between different traffic types by applying a “tag” to network sockets before use.

These tags are shown in a stack area chart in DDMS, as shown in figure 2:

Figure 2. Network Usage tab.

By monitoring the frequency of your data transfers, and the amount of data transferred during each connection, you can identify areas of your application that can be made more battery-efficient. Generally, you should look for short spikes that can be delayed, or that should cause a later transfer to be pre-empted.

To better identify the cause of transfer spikes, the TrafficStats API allows you to tag the data transfers occurring within a thread using setThreadStatsTag(), followed by manually tagging (and untagging) individual sockets using tagSocket()and untagSocket(). For example:

TrafficStats.setThreadStatsTag(0xF00D);TrafficStats.tagSocket(outputSocket);// Transfer data using socketTrafficStats.untagSocket(outputSocket);

Alternatively, the Apache HttpClient and URLConnection APIs included in the platform automatically tag sockets internally based on the active tag (as identified by getThreadStatsTag()). These APIs correctly tag/untag sockets when recycled through keep-alive pools. In the following example, setThreadStatsTag() sets the active tag to be 0xF00D. There can only be one active tag per thread. That is the value that will be returned by getThreadStatsTag() and thus used byHttpClient to tag sockets. The finally statement invokes clearThreadStatsTag() to clear the tag.

TrafficStats.setThreadStatsTag(0xF00D);    try {        // Make network request using HttpClient.execute()    } finally {        TrafficStats.clearThreadStatsTag();}

Socket tagging is supported in Android 4.0, but real-time stats will only be displayed on devices running Android 4.0.3 or higher.

Using LogCat

LogCat is integrated into DDMS, and outputs the messages that you print out using the Log class along with other system messages such as stack traces when exceptions are thrown. View the Reading and Writing Log Messages. topic for more information on how to log messages to the LogCat.

When you have set up your logging, you can use the LogCat feature of DDMS to filter certain messages with the following buttons:

• Verbose
• Debug
• Info
• Warn
• Error

You can also setup your own custom filter to specify more details such as filtering messages with the log tags or with the process id that generated the log message. The add filter, edit filter, and delete filter buttons let you manage your custom filters.

Emulating phone operations and location

The Emulator control tab lets you simulate a phone's voice and data network status. This is useful when you want to test your application's robustness in differing network environments.

Changing network state, speed, and latency

The Telephony Status section of the Emulator controls tab lets you change different aspects of the phone's networks status, speed and latency. The following options are available to you and are effective immediately after you set them:

• Voice - unregistered, home, roaming, searching, denied
• Data - unregistered, home, roaming, searching, denied
• Speed - Full, GSM, HSCSD, GPRS, EDGE, UMTS, HSDPA
• Latency - GPRS, EDGE, UMTS

Spoofing calls or SMS text messages

The Telephony Actions section of the Emulator controls tab lets you spoof calls and messages. This is useful when you want to to test your application's robustness in responding to incoming calls and messages that are sent to the phone. The following actions are available to you:

• Voice - Enter a number in the Incoming number field and click Call to send a simulated call to the emulator or phone. Click the Hang up button to terminate the call.
• SMS - Enter a number in the Incoming number field and a message in the Message: field and click the Send button to send the message.

Setting the location of the phone

If your application depends on the location of the phone, you can have DDMS send your device or AVD a mock location. This is useful if you want to test different aspects of your application's location specific features without physically moving. The following geolocation data types are available to you:

• Manual - set the location by manually specifying decimal or sexagesimal longitude and latitude values.
• GPX - GPS eXchange file
• KML - Keyhole Markup Language file

 

DDMS的使用、内存溢出的调试和模拟器的启动命令参数

2012-06-09 00:45 346人阅读 评论(0) 收藏 举报

androideclipselistvieweclipse插件system工具

目录(?)[+]

 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。

 

来自： http://apps.hi.baidu.com/share/detail/32190286

 

---

在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 the tools/ 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的内容（有一点复杂）：

1. 第一个HPROF 文件(using File > Open Heap Dump ).
2. 打开 Histogram view.
3. 在Navigation History view里 (如果看不到就从Window > Navigation History找 ), 右击histogram 然后选择Add to Compare Basket .
4. 打开第二个HPROF 文件然后重做步骤2和3.
5. 切换到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 指令參數)