Android memory monitoring tool ddms-> heap.

Android memory monitoring tool ddms --> heap. Original address

To monitor the memory usage of an application process using heap, follow these steps:
1. After eclipse is started, switch to the ddms perspective and confirm that the devices view and heap view are all open;
2. Connect your phone to your computer via USB. Make sure that the phone is in "USB debugging" mode instead of "Mass Storage ";
3. After the connection is successful, the device serial number and running process information are displayed in the devices view of ddms;
4. Click the process you want to monitor, such as the system_process process;
5. Click the "Update Heap" icon in the top row of the selected devices View Interface;
6. Click "cause GC" in the heap view;
7. In the heap view, the details of the memory usage of the selected process are displayed.
Note:
A) clicking the "cause GC" button is equivalent to requesting a GC operation from the VM;
B) when the memory usage information is displayed for the first time, you do not need to constantly click "cause GC". The heap view interface will be refreshed on a regular basis, the changes in memory usage can be seen during the continuous operation of applications;
C) the parameters of the memory usage information can be known Based on the name and will not be described here.
How can we know whether our program has the possibility of Memory leakage. Here, you need to pay attention to a value: In the heap view, there is a type called data object, that is, the data object, that is, a large number of class type objects in our program. In a row of data object, there is a column named "total size", whose value is the total memory of all Java Data Objects in the current process. Generally, the size of this value determines whether memory leakage exists. You can judge this as follows:
A) constantly operate on the current application, and observe the total size value of the data object;
B) under normal circumstances, the total size value will be stable within a limited range. That is to say, because the code in the program is good, the object will not be garbage collected, therefore, although we continuously generate many objects during operations, these objects are recycled during the continuous GC of virtual machines, memory usage will reach a stable level;
C) if the Code does not release the object reference, the total size value of the data object will not be significantly reduced after each GC, as the number of operations increases, the value of total size increases,
The process is killed until the upper limit is reached.
D) The system_process process is used as an example. In my testing environment, the total size of the Data Object occupied by the system_process process will normally be 2.2 ~ 2.8, and when the value exceeds 3.55, the process will be killed.

 

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

 

 

 

Check heap usage in ddms

 

Dalvik debug monitor server (ddms) is one of the main Android debugging tools and is part of ADT Eclipse plug-in, the independent program version can also be found under tools/in the root directory of the android SDK. For more information about ddms, see use ddms.

 

We will use ddms to check the heap usage of this application. You can use the following two methods to start ddms:

• From Eclipse: ClickWindow> open perspective> other...> ddms
• Or from the command line: Runddms(Or./ddmsOn MAC/Linux) intools/Directory

 

On the left-side pane, select com. example. Android. hcgallery and Click Show heap updates in the toolbar. Switch to the VM heap page of ddms. It displays some basic data of heap memory after each GC. To view the data content after the first GC, click the cause GC button:

 

 

We can see that the current value (allocated column) is more than 8 Mb. Now, move the photo to see that the data is increasing. Because only 13 photos are in the program, the leaked memory is only that large. To some extent, this is the worst type of Memory leakage, because we cannot get outofmemoryerror to remind us that the memory has exceeded.

 

Generate heap dump

 

We now use heap dump to track this issue. Click the dump hprof file button on the ddms toolbar, select the file storage location, and then run hprof-Conv. In this example, we use an independent mat version (version 1.0.1) to download it from the mat site.

 

If you use ADT (which includes the ddms plug-in) and install mat in eclipse, click "Dump hprof" to automatically perform the conversion (using hprof-Conv) at the same time, the converted hprof file will be opened in eclipse (it is actually opened with Mat ).

 

Use mat to analyze heap dumps

Start mat and load the hprof file we just generated. MAT is a powerful tool that describes all its features beyond the scope of this article, so I just want to demonstrate a method you can use to detect leaks: histogram view. It displays a list of sortable class instances, including: shallow heap (total memory usage of all instances) or retained heap (total memory allocated to all class instances, including all the referenced objects ).

 

If we sort by shallow heap, we can see that the byte [] instance is at the top. Since android3.0 (honeycomb), the pixel data of bitmap is stored in the byte array (previously stored in the heap of Dalvik). Therefore, it is determined based on the size of this object, needless to say, it must be our leaked bitmap.

 

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

 

Select and expand a large object, which will display the path from the root to this object-is a chain that ensures the object is valid. Note that this is our bitmap cache!

 

Mat won't tell us clearly that this is a leak because it doesn't know whether the program needs this thing or not. Only the programmer knows it. In this case, the large amount of memory used by the cache will affect the subsequent applications, so we can consider limiting the cache size.

 

Use mat to compare heap dumps

 

When debugging memory leaks, it is sometimes useful to compare the heap status in two places in a timely manner. In this case, you need to generate two separate hprof files (do not forget the conversion format ). The following is some information about how to compare two heap dumps in mat (a little complicated ):

1. The first hprof file (usingFile> open heap dump).
2. Open histogram view.
3. In the navigation history view.Window> navigation history), Right-clickHistogramThen selectAdd to compare basket.
4. Open the second hprof file and redo steps 2 and 3.
5. Switch to the Compare basket view and clickCompare the results(Red in the upper-right corner of the View "! "Icon ).

Summary

This article shows how allocation tracker and heap dumps give you a perceptual knowledge of program memory usage. I also showed that eclipse memory analyzer (MAT) can help chase memory leaks in our programs. MAT is a powerful tool, and I just touched some skins. If you want to learn more, I suggest reading the following articles:

• Memory analyzer news: the official blog of the eclipse mat project.
• Markus Kohler's Java performance blog has many useful articles, including the analysis of the memory usage of Android applications with the eclipse memory analyzer and 10 useful tips for the eclipse memory analyzer.

 

 

From: http://dev.10086.cn/blog? Uid-13136-action-viewspace-itemid-9580