Use memory monitoring tool heap in Android and memory analysis tool MAT

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 (here I use the Eclipse ADT Plugin, and in the case of a real machine, like in the emulator). 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.

Memory Analyzer Tool MAT

If you do find a memory leak in our program using DDMS, how do you locate the code snippet that has the problem and finally find the problem? If you analyze the code logic from beginning to end, it will certainly drive people crazy, especially when it comes to maintaining code written by others. Here is an excellent Memory analyzer tool (MAT).

The mat is an Eclipse plug-in and also has a separate RCP client. For official, Mat introduction and detailed usage tutorials see: Www.eclipse.org/mat, not explained here. In addition, a complete tutorial is available in the Help documentation for the mat installation. Only examples of how to use them are described here. I'm using the mat's Eclipse plugin myself, which is a bit easier to use than RCP.

Using the mat for memory analysis requires several steps, including: Generate A. hprof file, open the mat and import the. hprof file, and use the Mat's view tool to analyze the memory. Detailed description below.

(i) Generate a. hprof file

There are many ways to build a. hprof file, and there are different versions of Android that are generated. Hprof are slightly different, and the version I'm using is 2.1, and the ways to generate the. prof file in each version can be found in:

Http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/heap-profiling.html;hb=HEAD.

1. Open Eclipse and switch to the DDMS perspective, confirming that the devices, heap, and logcat views are open;

2. Link the phone device to the computer and make sure to use the "USB Debug" mode link instead of the "Mass Storage" mode;

3. After the link is successful, you will see the serial number of the device in the devices view, and the part of the process that is running on the device;

4. Click to select the process for the app you want to analyze, and in the Row icon button above the devices view, select the "Update Heap" and "Dump HPROF file" two buttons;

5. This is the DDMS tool that will automatically generate the. hprof file for the currently selected process and convert it into sdcard, and if you have already installed the Mat plugin, the mat will automatically be enabled and the. hprof file will begin to be analyzed.

Note: Steps 4th and 5th are normally used if we need to have sdcard, and the current process has permission to write to SDcard (write_external_storage), otherwise. hprof files will not be generated and will be displayed in Logcat such as ERROR /DALVIKVM (8574): Hprof:can ' t open/sdcard/com.xxx.hprof-hptemp:permission denied information.

If we do not have sdcard, or if the current process does not have permission to write to SDcard (such as system_process), then we can do this:

6. In the current program, such as some code in the framework, you can use the Android.os.Debug:

public static void Dumphprofdata (String fileName) throws IOException

method to manually specify the location where the. hprof file is generated. For example:

Xxxbutton.setonclicklistener (New View.onclicklistener () {

public void OnClick (view view) {

Android.os.Debug.dumpHprofData ("/data/temp/myapp.hprof");

... ...

}

}

The intent of the code above is to start crawling memory usage information when Xxxbutton is clicked, and save it in the location we specify:/data/temp/myapp.hprof, so there is no restriction on permissions, and there is no need to use SDcard. But make sure that the/data/temp directory is present. This path can be defined by itself, but can also be written as a path in SDcard.

(ii) using the mat to import. hprof files

1. If the. hprof file is automatically generated by eclipse, it can be opened directly using the Mat plug-in (perhaps a newer ADT is supported);

2. If the eclipse auto-generated. hprof file cannot be opened directly by the mat, or is using Android.os.Debug.dumpHprofData () method to convert the. hprof file to a. hprof file that is manually generated by the Convert method:

For example, I copy the. hprof file to the/android_sdk/tools directory on the PC and enter the command Hprof-conv xxx.hprof yyy.hprof, where Xxx.hprof is the original file and Yyy.hprof is the converted file. The converted files are automatically placed in the/android_sdk/tools directory. OK, so far, the. hprof file is processed and can be used to analyze memory leaks.

3. In eclipse, click Windows->open perspective->other->memory Analyzer, or rcp with the Memory Analyzer tool. In the mat, click File->open File to browse and import the. hprof files you just converted.

(iii) Analyze memory using the MAT's view tool

After you import the. hprof file, Mat automatically parses and generates the report, clicks Dominator Tree, and groups by package, selects the right-hand button of your own definition of the group, and selects List objects->with in the pop-up menu. Incoming references. All suspicious classes are listed, right-click on an item and select Path to GC Roots-exclude weak/soft references, which will further filter out all memory-leaking classes associated with the program. As a result, you can trace to a class in your code that produces a leak.

The mat interface is as shown.

Specific analysis methods are not explained here, as there is a very detailed description of the Mat's official website and the client's help documentation.

It is important to understand the role of each view in the mat, as described in www.eclipse.org/mat/about/screenshots.php.

In summary, the fundamental idea of using mat to analyze memory for memory leaks is to find out which class object references have not been freed, to find out why they are not being released, and to easily locate which fragments in the code are logically problematic.

Original address: http://blog.csdn.net/qeqeqe236/article/details/7338608

Using memory monitoring tool heap in Android, and memory analysis tool MAT