Use of the memory analysis tool MAT and the memory analysis tool mat

Use of the memory analysis tool MAT and the memory analysis tool mat

1. troubleshooting of Memory leakage

The Dalvik Debug Monitor Server (DDMS) is part of the ADT plug-in. There are two functions available for memory check:

· Heap view heap allocation

· Allocation tracker tracks memory allocation

The two DDMS functions help you find Memory leakage operations.

Eclipse Memory Analysis Tools (MAT) is a professional tool for analyzing Java heap data. It can be used to identify the cause of Memory leakage.

Tool address: https://www.eclipse.org/mat/

1.1 observe Heap

· Run the program and enter the DDMS management interface as follows:

 

PS: Click Update statistics on the toolbar.

Click the Cause GC button on the right or the toolbar to view the current heap status, as shown below:

Focus on two items:

O Heap Size the Size of the Heap. When resources increase and the current free space of the Heap is insufficient, the system will increase the Size of the Heap. If the Size exceeds the upper limit (for example, 64 M, depending on the platform and the specific model) will be killed.

The Allocated size in the o Allocated heap, which is the actual memory occupied by the application. After resources are recycled, the data will decrease.

· Check the heap data before and after the operation to check whether memory leakage exists.
Perform repeated operations on a single operation (such as adding or deleting pages). If the heap size keeps increasing, there is a potential memory leakage.

1.2 use MAT to analyze the memory heap

DDMS can Dump the current memory into an hprof file. After the MAT reads the file, it will provide easy-to-read information and use it for searching and comparing, you can find out the cause of Memory leakage.

· Obtain the hprof File
Click the button on the toolbar to save the memory information as a file.If the Dump file is obtained using the MAT Eclipse plug-in, it does not need to be converted. The Adt will automatically convert and then open it.

· Convert the hprof File
The files dumped by DDMS must be converted before they can be recognized by MAT. The Android SDK provides the hprof-conv tool (under sdk/tools)

·./Hprof-conv xxx-a.hprof xxx-b.hprof

· Use MAT to open the converted hprof File

1.3 Histogram Query

The most commonly used function isHistogramClick Histogram under Actions to get the Histogram result:

It is listed by all instance objects of the class name. You can click the header to sort the objects. In the first row of the table, you can enter a regular expression to match the results:

Right-click an item and choose list objects-> with incoming refs from the shortcut menu to list instances of this class:

It shows the reference relationships between objects. For example, the first sub-item after expansion indicates that the HomePage (0x420ca5b0) is referenced by the mhomepagecontainer (0x420c9e40.

To quickly find out why an instance is not released, right-click the Path to GC Roots --> exclue all phantom/weak/soft etc. reference:

The result is:

We can see from the table that PreferenceManager->... -> The line HomePage references this HomePage instance. This method can be used to quickly findGC RootAn object with GC Root will not be recycled by GC.

1.4 Histogram comparison

To find memory leaks, we usually need to Compare two Dump results. Open the Navigator History panel and add the Histogram results of the two tables to Compare Basket:

After adding the file, open the Compare Basket panel. The result is as follows:

Click!Button to obtain the comparison result:

Note: The comparison result above is not conducive to finding differences. You can adjust the comparison options:

Sort the comparison results to get the intuitive comparison results:

You can also Compare the two object sets by adding the object sets in the two Dump results to Compare Basket for comparison. Find the difference and use the Histogram query method to find the GC Root and locate a specific object.

1.5 example

An example of a typical Memory Leak analysis process is as follows:

1. Use Heap to check that the current Heap size is 23.00 MB.

2. After adding a page, the heap size will change to 23.40 MB.

3. Delete the added page. The heap size is 23.40 MB.

4. Multiple operations and the results are still similar, indicating that memory leakage exists in the Add/delete pages (you should also be aware of the impact of other factors)

5. Dump the hprof file (1. hprof, 2. hprof) before and after the operation, open it with mat, and obtain the histgram result.

6. Use the HomePage field to filter the histgram results and list the object instances of the class. The object sets in the two tables are of different sizes. A HomePage exists after the operation, indicating that there is a leak.

7. Compare the two lists to find out an extra object, and use the GC Root method to find out who has hooked up the reference line and locate the end.

PS:

· In many cases, the heap increase is caused by Bitmap. The Bitmap type in Histogram is byte []. Comparing the byte [] objects in two Histogram, we can find out which bitmaps are different.

· The sorting function is used to identify differences.

2. Cause Analysis of Memory leakage

There is only one conclusion:An invalid reference exists! 
Good module design and rational use of the design pattern can help solve this problem.

3 Tips

· Use the android: largeHeap = "true" tag (API Level> = 11)
In AndroidManifest. the Application node in xml declares that it can be allocated to a larger heap memory. android: largeHeap tags are also widely used in Android applications, such as Launcher and Browser memory.

4. Reference

· DDMS official tutorials http://developer.android.com/tools/debugging/ddms.html

· MAT download http://www.eclipse.org/mat/downloads.php

· MAT use http://android-developers.blogspot.tw/2011/03/memory-analysis-for-android.html

I used android MAT to check memory leakage. I checked a lot of information. Why is there no hprof file in DDMS?

How to Use MAT for analysis is provided that the Android development and testing tools are fully installed. SDK and Eclipse:
1. Open Eclipse
2. Select Help-> Install New Software;
3. Add the site download.eclipse.org/mat/1.0/update-site/ to Work with (this address may change, but the new address can be found at www.eclipse.org/mat/downloads.php on the official website)
4. generate. hprof file: insert the SD card (many Android programs need to insert the SD card), connect the device to the PC, and select the process to be tested in DDMS of Eclipse, click the Update Heap and Dump HPROF file buttons.
The. hprof file is automatically saved on the SD card, and the. hprof file is copied to the \ android-sdk-windows \ tools directory on the PC. The file generated by DDMS cannot be opened directly in MAT and needs to be converted.
Run cmd to open the command line, cd to the directory where \ android-sdk-windows \ tools is located, and enter the command hprof-conv xxxxx. hprof yyyyy. hprof, where xxxxx. hprof is the original file, yyyyy. hprof is the converted file. The converted files are automatically stored in the android-sdk-windows \ tools directory.
OK. Till now, the. hprof file has been processed and can be used to analyze Memory leakage.
5. Open MAT:
In Eclipse, choose Windows> Open Perspective> Other> Memory Analysis.
6. Import the. hprof File
In the MAT, click File-> Open File to browse to the converted File. hprof file, and Cancel off to automatically generate the report. Click Dominator Tree, group by Package, and right-click the Package class you have defined, select List objects-> With incoming references in the pop-up menu.

All the suspicious classes are listed. Right-click an item and choose Path to GC Roots-> exclude weak/soft references, all classes related to the program with Memory leakage will be further filtered out. Based on this, we can track a class in the code that produces leakage.

Is there any convenient java memory usage analysis tool?

If you are using a Windows operating system, you may encounter the following error message: "0X? This document briefly analyzes the common causes of this error. 1. failed to check memory allocation by Application