Go: Android Development: Using DDMS heap for memory leak debugging

No matter how careful it is, it is impossible to avoid bad code altogether, and tools are needed to help us check if there is a memory leak in the code. The DDMS in Android tools comes with a very good memory monitoring tool heap, which explains how to use the heap for memory monitoring.

Memory Monitoring Tool DDMS--Heap

Here I use the ADT plugin for Eclipse, and in the case of a real machine, it's similar in the simulator. The steps to use the heap to monitor the application process using memory are as follows:

1. After you start eclipse, switch to the DDMS perspective and confirm that the devices view, the heap view, are open;

2. Link the phone to the computer via USB, the link needs to confirm that the phone is in "USB debugging" mode, and not as "Mass Storage";

3. After the link is successful, the serial number of the mobile device and the part of the process that is running on the device will be displayed in the Devices view of DDMS.

4. Click to select the process you want to monitor, such as the system_process process;

5. Click to select the "Update Heap" icon in the top row of icons in the Devices view interface;

6. Click the "Cause GC" button in the heap view;

7. In the heap view, you will see the details of the memory usage of the currently selected process.

Description

A) Clicking on the "Cause GC" button is equivalent to requesting a GC operation from the virtual machine;

b) When the memory usage information is displayed for the first time, there is no need to continuously click on "Cause GC", the heap view interface will be refreshed periodically, and the memory usage changes can be seen during the continuous operation of the application.

c) The parameters of the memory usage information can be understood by name, and will not be mentioned here.

How do we know if our program has the possibility of a memory leak? Here's a value to note: In the middle of the heap view, there is a type called data object, which is an object of the class type that exists in our program. In the data object row, there is a column "total size", whose value is the amount of memory for all Java data Objects in the current process, in general, the size of this value determines whether there is a memory leak. It can be judged as follows:

A) continuously operate the current application, while observing the total size value of the data object;

b) The total size value will be stable in a limited range under normal circumstances, that is, because the code in the program is good, no object is not garbage collection, so that although our continuous operation will continue to generate a lot of objects, and in the process of virtual machine continuous GC, These objects are recycled, and the memory footprint will fall to a steady level;

c) Conversely, if there is a case in the code that does not release the object reference, the total size value of the data object will not come down significantly after each GC, and as the number of operations is increased, the value of total size will become larger.

Until an upper limit is reached, the process is killed.

D) The system_process process is here, for example, the total size of the data object that system_process the memory occupied by the process in my test environment will normally stabilize between 2.2~2.8, And when the value exceeds 3.55, the process is killed.

In summary, using the Ddms heap View tool makes it easy to verify that our program has the possibility of a memory leak.

Original address: http://mobile.51cto.com/aprogram-380460.htm

Also can view official website material: http://developer.android.com/tools/debugging/ddms.html

There are also the use of mat tools:

http://blog.csdn.net/feng88724/article/details/6460918

http://blog.csdn.net/zouxueping/article/details/6751884

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