[Android] Memory Leak debugging experience (2)

Http://rayleeya.javaeye.com/blog/755657

 

Iii. Memory monitoring tool ddms --> heap

No matter how careful you are, it is impossible to completely avoid bad code. At this time, some tools are required to help us check whether there is any place in the code that will cause memory leakage. The ddms in Android tools comes with a very good memory monitoring tool heap (here I use the ADT plug-in of eclipse, and take the real machine as an example, the situation in the simulator is similar ). 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 memory usage of the selected process is 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.

 

In short, using the heap View tool of ddms can easily confirm whether our program has the possibility of Memory leakage.

4. Memory Analysis Tool (memory analyzer tool)

If ddms does discover Memory leakage in our program, how can we locate the specific problematic code snippet and find the problem? If you analyze the code logic from start to end, it will drive people crazy, especially when maintaining the code written by others. Here is an excellent memory analysis tool-memory analyzer tool (MAT ).

MAT is an Eclipse plug-in with a separate RCP client. For more information, see www.eclipse.org/mat. In addition, there are complete tutorials in the help documentation after mat installation. Here, we will only illustrate how to use it. I use the mat Eclipse plug-in, which is easier to use than RCP.

 

Several steps are required to use mat for memory analysis, including generating the. hprof file, opening the mat and importing the. hprof file, and using the mat View tool to analyze the memory. The following is a detailed description.

(1) generate the. hprof File

Generate. there are many methods for hprof files, and they are generated in different Android versions. the hprof method is slightly different. I use version 2.1, which is generated in each version. for the prof file method, see:

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. Check that the devices, heap, and logcat views are enabled;

2. Link your phone to your computer and make sure that you use the "USB debug" mode instead of the "Mass Storage" mode;

3. After the connection is successful, the device serial number and some processes running on the device are displayed in the devices view;

4. Click the process of the application to be analyzed, and select the update heap and dump hprof file buttons in the icon button above the devices view;

5. this is where the ddms tool will automatically generate the currently selected process. hprof file, convert it, and store it in sdcard. If you have installed the mat plug-in, the mat will be automatically enabled and started. hprof file for analysis;

Note: Steps 4th and 5th can be used normally only when sdcard is available and the current process has the write permission (write_external_storage) to the sdcard. Otherwise. the hprof file will not be generated and will be displayed in logcat, such

Error/dalvikvm (8574): hprof: Can't open/sdcard/COM. XXX. hprof-hptemp: Permission denied.

.

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

6. In the current program, for example, some code in the framework, you can use:

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 ){

Android. OS. Debug. dumphprofdata ("/data/temp/MyApp. hprof ");

......

}

}

The above code is intended to capture memory usage information when xxxbutton is clicked and save it at our specified location:/data/temp/MyApp. hprof, so there is no permission restriction, and you do not need to use sdcard. Make sure that the/data/TEMP directory exists. This path can be defined by yourself, and can also be written as a path in sdcard.

 

(2) Use mat to import the. hprof File

1. If the. hprof file is automatically generated by ECLIPSE, you can use the mat plug-in to open it directly (it may be supported by a newer ADT );

2. if. the hprof file cannot be directly opened by mat, or android is used. OS. debug. manually generated by the dumphprofdata () method. hprof file, you need. to convert the hprof file, use the following method:

For example. copy the hprof file to the/android_sdk/tools directory on the PC, and enter the hprof-Conv XXX command. hprof yyy. hprof, where xxx. hprof is the original file, YYY. hprof is the converted file. The converted files are automatically stored in the/android_sdk/tools directory. OK. Till now, the. hprof file has been processed and can be used to analyze Memory leakage.

3. In eclipse, choose windows> open perspective> Other> memory analyzer, or press RCP of memory analyzer tool. In the mat, click File-> open file to browse and import the. hprof file just converted.

(3) Use Mat's View tool to analyze memory

Import. after the hprof file is created, the mat automatically parses and generates a 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.

Shows the mat interface.

 

 

The specific analysis method is not described here, because the help documents on the official website and client of Mat are very detailed.

It is important to understand the role of various views in mat, for example, introduced in www.eclipse.org/mat/about/screenshots.php.

In short, the fundamental idea of using mat to analyze the memory to find Memory leakage is to find out which class of object reference is not released, and find the reason why it is not released, in this way, you can easily locate the logic of the segments in the code.

 

So far, please do it yourself!