The use of three memory analysis tools for Android memory optimization

Anroid Use of memory analysis tools

A Eclipse Heap analyzes memory leaks

Android Development can not avoid the memory leak problem, here is about the basic concept of memory leak: memory leaks The official explanation is that the dynamic storage allocation function dynamically open space, after use is not released, resulting in the memory unit has been occupied until the end of the program. It can also be understood that after the new object is exhausted, the object is not recycled, resulting in useless objects occupy the memory, this useless as the number of operations, the more memory occupied, until the memory overflow program, error stopped running. Memory overflow problem is more difficult to locate than the problem of direct error in the program, it is a bit too much to analyze the memory overflow problem by reading code, so we have to use the tool to analyze the memory overflow problem. This section describes how to use the Memory analysis tool MAT. the most commonly used is the DDMS tool that comes with eclipse, and after entering DDMS, the interface is as follows:

Here are the steps to use the tool first:

1. Connect the phone to the PC via USB cable, the Android debugging terminal opens the app that requires memory analysis, click the DDMS option to enter the heap display interface.

2. In the Devices interface select the app's process name, my app process name is com.example.oomtest.

3. Then click the Green button Updateheap in the upper left corner as shown to update the memory heap details of the display app, then click on the heap interface on the right, which is the usage of the app heap. Where heap size is the app's heap sizes, is variable, as to how the upper limit is set can be seen in the previous section. Allocated is the size of the heap that is currently allocated by the app, and whether a memory leak can be easily determined by looking at whether the allocated is larger, but not necessarily accurate, but for obvious memory leaks, such as loading large images and displaying them.

4. The heap interface on the right, there is a Cause GC button is used to trigger your phone's GC thread for memory recycling. Here is to mention that some people in the monitoring of the heap situation of an interface, enter an interface exit after not click Cause GC, at this time found out the interface after the allocated size increased, thought is the memory leaks. Not really, just sometimes the GC thread has not yet scanned your app, and the heap of the app is not yet recycled, so the size of the allocated is more than it was before. So after doing something, to see the heap of the app and click on the cause GC, a few more clicks are recommended.

5. The Load Heap button in step 5 is the file used to download the heap memory analysis, which is then required for the analysis tool to be used.

See here may be some netizens will ask, some code is clearly memory leaks, why allocted still show normal, that is, before and after operation, allocted size has not changed. Yes, here is also the use of DDMS to see the shortcomings of memory leaks, some hidden memory leaks, with DDMS is not visible. So the second sectionto is about the memory leak analysis through the Analyer tool, which is much more accurate and convenient for locating the problem.

two. Memory Analyer Tools Program Supect Analysis

First of all, this tool is not the eclipse comes with, so you need to download memory Analyer tools (called Mat, also can be integrated into eclipse as plug-in), I download memory Analyer tool. After installing the memory Analyer tool, proceed to the following steps:

1. Click on the Load Heap button in step 5 to download the stack analysis file, which is a file with the suffix named Hprof.

2. Since the downloaded Hprof file does not read properly in the mat, the Hprof-conv in the SDK is required to be converted before the mat can be read normally. To facilitate file conversion, and then go to the SDK to see where the Hprof-conv tool is placed, it is recommended that the Hprof file before conversion is placed in the same directory as Hprof-conv, since the conversion in CMD does not have to enter a file path that is too long. I here the absolute path of the Hprof-conv tool is D:\programfiles\eclipse\android-sdk-windows-full\platform-tools>hprof-conv, It also puts the pre-converted Hprof file in this position.

3. Open cmd, enter the directory where Hprof-conv is located, enter Hprof-conv old.hprof new.hprof and press ENTER, then D:\ProgramFiles\eclipse\ The new.hprof file generated under the Android-sdk-windows-full\platform-tools directory, which is the hprof file that the mat can read into. Note: Where Old.hprof is the file name before conversion, New.hprof is the converted file name,

4. Open the mat and import the converted Hprof file, as shown in the upper right corner:

5. After the import interface as shown, the interface of the Problemsupect is the mat to help you find out the possible memory leaks, see here you may think, this is very convenient Ah, mat help you to all possible memory leaks, and then click Problem Supect a slow look on it, in fact, many online stickers are said. Here I would like to say that it is also a method to locate some memory leaks by problem supect, such as loading large images or loading a lot of small images, but this approach is not as accurate as the eclipse heap to analyze memory leaks.

three. Mat Accurate and effective analysis method

Here's another way to analyze memory leaks in the next mat. Here you can have doubts about what kind of memory leaks are the two methods described above may not be detected, here also by the way.

(1). The context of the activity is occupied by objects with longer lifecycles (internal classes and static variables, etc.), resulting in a memory leak problem.

(2). Cursor runs out of memory leaks caused by no colse.

In addition, the following introduction will be used in some basic concepts, here First: (1) Theshallow Heap is the size of the memory occupied by the object itself, does not contain its referenced objects. The shallow size for a regular object (not an array) is determined by the number and type of its member variables, and the shallowsize of the array is determined by the array type and the length of the arrays, which are the sum of the size of the elements. (2) Retained heap is the current object size + the sum of the size of the object to which the current object can be directly or indirectly referenced. (Meaning of indirect reference: A->b->c,c is an indirect reference) and excludes objects that are referenced directly or indirectly by GC roots

Operation Steps:

(1). Step 1, click the Overview option to go to the main interface

(2). Step 2, click the Histogram option to enter the histogram interface as shown in. The Process name input box is used to enter the app's process name, allowing you to view the heap of the app.

Below with a memory leak example simple analysis, convenient for users to get started. Define a thread inner class in activity and hibernate for a long time in the threads, the test app's process name is Com.example.oomtest, the key code is as follows:

protected void onCreate (Bundlesavedinstancestate) {

// TODO auto-generated method Stub

Super. OnCreate (savedinstancestate);

Log. I (TAG,"onCreate");

Setcontentview (r.layout. Activity_second);

New testthread (). Start ();

}

Public class Testthread extends Thread {

@Override

public void run () {

Super. Run ();

Try {

Thread. Sleep (1000 * 60 *1000);

} catch (interruptedexceptione) {

e. Printstacktrace ();

           }

       }

 }

Enter the test interface and exit the interface operation once, we get the Hropf file and convert the import mat, open the Histogram interface, enter the APK process name in <Regex>, For example, this program uses com.example.oomtest, then the interface will list the heap of the app, as shown in.

You can see from the Objects column that when you exit the test interface sencondactivity, its instance exists. So it is possible to determine that sencondactivity has a memory leak, but using the two methods described earlier, it is impossible to analyze the memory leaks in the app. You may also ask here, knowing that a memory leak has occurred in sencondactivity, how do you know where the memory leak happened? This is also a simple answer, which is the advantage of analyzing memory leaks through histogram, as shown in the following steps:

followed by the following interface, which shows that the activity instance has not been recycled, which is the above-mentioned hidden strong memory leak type 1, the main reason is that the activity of the thread has occupied the activity of this caused by the memory leak, So when the activity is destroy, the activity instance cannot be recycled by GC.

When the sleep time of the thread is modified to 100, the same operation method is used to test that the Sencondactivity sub-thread is short of sleep time, when the activity is destroy,the activity's This has been released, So there is no memory leak, its heap memory condition:

As you can see from the list, Sencondactity object is 0, that is, sencondactivity does not exist, so it is very accurate to use this method for memory leak analysis. But the same program can not pinpoint where the problem is, or even detect a memory leak through the previous two methods. This chapter first introduced here, the next chapter will introduce some other hidden more powerful memory leaks, so that the major netizens to develop high-quality apps.

The use of three memory analysis tools for Android memory optimization