Android Memory Monitor Tool DDMS--Heap

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.

From: http://apps.hi.baidu.com/share/detail/32190286

Check the usage of the heap in DDMS

Dalvik Debug Monitor Server (DDMS) is one of the main Android debugging Tools and is part of ADT Eclipse Plug-in, and the standalone version of the program can be found under tools/in the root directory of the Android SDK. For more information on DDMS, please refer to using DDMS.

Let's use DDMS to check the heap usage of this app. You can use the following two methods to start DDMS:

• From Eclipse:click windows > Open perspective > Other ... > DDMS
• or from the command Line:run ddms (or to ./ddms mac/linux) in the tools/ directory

Select the process com.example.android.hcgallery on the left panel and click the Show heap Updates button on the top of the toolbar. This time switch to DDMS's VM heap paging. It displays some basic data for the heap memory after each GC. To see the data content after the first GC, click the Cause GC button:

We can see now that the value (allocated column) is some more than 8MB. Now slide the photo and see the data growing. Because only 13 photos in the program inside, so leaked memory only so large. To some extent, this is the worst kind of memory leak, because we can't get outofmemoryerror to remind us that we're out of memory now.

Generate Heap Dump

We now use heap dump to track this problem. Click the Dump Hprof file button above the Ddms toolbar, select the file storage location, and then run Hprof-conv. In this example we use the standalone Mat version (version 1.0.1), which is downloaded from the mat site.

If you use ADT (which contains DDMS plugins) and also install the mat in eclipse, click "Dump HPROF" The button will automatically convert (with Hprof-conv) and open the converted Hprof file in eclipse (it actually opens with a mat).

Analyze heap dumps with mat

Start the mat and load the Hprof file we just generated. Mat is a powerful tool to tell that all of its features are beyond the scope of this article, so I just want to demonstrate a way you can detect leaks: the histogram (histogram) view. It shows a list of class instances that can be sorted, including: Shallow heap (total memory usage for all instances), or retained heap (the sum of memory allocated for all class instances, including all of their referenced objects).

If we sort by shallow heap, we can see byte[] instances at the top. Since Android3.0 (Honeycomb), bitmap's pixel data is stored in a byte array (previously stored in the heap of Dalvik), so judging by the size of this object, needless to say, it must be the bitmap we leaked out.

Right-click the byte[] class and select list Objects > with incoming references. It generates a list of all byte arrays on the heap, and in the list we can sort by the usage of the shallow heap.

Select and expand a larger object that will show the path from the root to the object--a chain that guarantees that the object is valid. Watch out, this is our bitmap cache!

Mat doesn't tell us that this is a leak, because it doesn't know if this thing is a program that needs to be made, only the programmer knows. In this case, the large amount of memory used by the cache affects the later applications, so we can consider limiting the size of the cache.

Compare heap dumps with mat

When debugging memory leaks, it is sometimes useful to compare the heap state of 2 places in a timely manner. Then you need to generate 2 separate hprof files (don't forget to convert the format). Here are some details on how to compare 2 heap dumps in mat (with a bit of complexity):

1. The first hprof file (using File > Open Heap Dump).
2. Open histogram view.
3. In Navigation history view (if you can't see it from Window > Navigation history), right-click Histogram and select Add to Compare basket.
4. Open a second hprof file and redo steps 2 and 3.
5. Switch to compare basket view, and then click Compare the Results (the red "!" in the upper right corner of the view!) icon).

Summarize

In this article, I show you how allocation tracker and heap dumps give you a perceptual understanding of the application's memory usage. I've also shown that Eclipse memory Analyzer (MAT) can help chase the leak in our program. Mat is a powerful tool, I just touch some fur, if you want to learn more, I suggest reading some of the following articles:

• Memory Analyzer News:eclipse MAT Project's official blog.
• Markus Kohler's Java Performance Blog has many useful articles, including analysing the Memory Usage of Android applications with the Eclipse Memory Analyzer and useful Tips for the Eclipse Memory Analyzer.