Use Mat to analyze Android program memory usage in Eclipse (GO)

For Android, this handheld device usually does not have too much memory, and the average user does not restart the phone for a long time, so write the program must be very careful use of memory, as far as possible to avoid the problem of memory leaks. Usually the problem of potential memory leaks in the analysis program is a very difficult job, usually by the team of senior engineers responsible, and as the program code volume increases, the difficulty will gradually increase.

Today we will present a memory analysis tool--mat (Eclipse Memory Analyzer, home page in http://www.eclipse.org/mat/) used in eclipse. It is a very rich Java heap dump file analysis tool, and easy to use, just a few mouse clicks to generate a professional analysis report. More importantly, it integrates seamlessly with DDMS to help you discover potential memory leaks in Android programs, while helping you optimize your programs and use memory more efficiently.

First, install MAT

The mat is a plugin in eclipse, so it's easy to install.

First, Install software ... To launch the Software Installation page:

Select Add ... to pop up a dialog box with the name (name) filled with mat (in fact, fill in the location), fill in the http://download.eclipse.org/mat/1.4/update-site/, and then click OK:

Next, choose the function of the MAT you want to install. Because you only need to use the mat in eclipse, you only need to select the memory Analyzer for Eclipse IDE. In particular, the Memory Analyzer (Chart) is an optional installation that is used primarily to generate related visual reports, which are often more intuitive and easier to spot.

All that's left is just a little bit of next.

Ii. several basic concepts

There are several basic concepts that you need to know to read the reports that the mat generates.

Java Memory Recycling

In Java programs, the work of garbage collection in memory space is done by the garbage collector (garbage COLLECTOR,GC). Its core idea is that the object in the heap memory space in the virtual machine is identified, and if the object is being referenced by another object, it is called a living object, whereas if the object is no longer referenced by any other object, it is a garbage object that can reclaim its occupied space for redistribution.

For Android programs, the Dalvik virtual machine itself is a Java-like virtual machine implementation, but also has the active garbage collection function.

GC Root object (GC root)

In the garbage collection mechanism, a special set of objects is called the root object, which is a set of objects that are directly referenced by the virtual machine. For example, a running thread object, an object in the system call stack, and an object loaded by the system ClassLoader. Each object in the heap space is referenced by a root object as a starting point, and only if they reference other objects, no other object can reference them. Therefore, if an object is also referenced directly or indirectly by a surviving root element, it is considered to be a surviving object and cannot be reclaimed for memory release.

Shallow size and retained size

1) Shallow size (surface size) refers to the amount of memory space occupied by the object itself, and does not contain the memory space occupied by the object to which it is referenced. The shallow size of an object depends on the type and number of instance variables for this object. The shallow size of an array object is the shallow size of the object saved in the array multiplied by the number of array elements. The shallow size of a collection object is the sum of the shallow size of all objects within the collection.

2) retained size (reserved size) refers to the sum of the shallow size of the shallow size of the object itself, which can be accessed directly or indirectly from itself, and can only be accessed by the beginning of it. This size indicates the amount of memory that the garbage collector can reclaim after releasing the object.

Here is an example that assumes that the reference relationship for an object is as follows:

The retained size of the computed object Obj1 in the first diagram contains Obj1, Obj2, and Obj4, because Obj3 and obj5 can also be referenced by the root object, so they cannot be included. In the second picture, OBJ3 can only be referenced indirectly by OBJ1, so it should be included.

Domination tree (Dominator trees)

The dominant tree is defined as if, in the object reference graph, from any object, if you want to access object Y, you must pass object x, then object x is in the dominate position of object Y.

As you can see, the concept of dominating the tree is actually associated with the previous retained size. The retained size of an object is the sum of the shallow size starting from this object and all the tree child nodes that begin with it.

Also, all root nodes must be the top node in the tree, not necessarily.

Heap dump file (heap dump)

The so-called heap dump file is a snapshot file of the memory of the Java process at a specific point in time. It contains the usage of Java objects and classes in the heap when the snapshot is triggered. Because snapshots are just a matter of moments, it is only possible to include a reference relationship between objects at that point in time, without knowing at what point in time the object was created, or by which method.

Mat is actually a generic Java heap dump file analysis tool, and through the Android DDMS, you can get the specified device on the specified process heap dump file, the combination of the two can be achieved to analyze the Android program memory usage.

Third, how to analyze

First, start the program you want to analyze and make sure it is debug (that is, declare android:debuggable= "true" in the Androidmanifest.xml file).

Then, use DDMS to collect the heap dump files on the Android device that you want to debug the program. This step is also very simple, in DDMS, select your program and click Dump HPROF file:

DDMS generating a dump file may take a little time, please be patient for a while. When the dump file is generated, Eclipse automatically calls the mat for analysis and generates the report:

In this report, we can obtain the following information:

1) Histogram: Lists the number of objects each class in the current program is instantiated from;

2) Dominator Tree: Lists the relationship between the dominant trees of each active object in the current program;

3) Topconsumer: Lists the first few objects, such as retained size, in the current program;

4) Duplicateclasses: Lists whether the current program has the same class loaded by different ClassLoader.

The difference between histogram and Dominator tree is that the angle of the analysis problem is different, histogram is to stand in the angle of the class analysis, and Dominator tree is the object instance of the station analysis, Dominator Tree makes it easier to see the reference relationships between the various objects.

With these weapons, the analysis of memory leaks becomes handy and the general process is as follows:

1) in the histogram and Dominator tree views, sort by retained heap to find the top classes and objects. These are the objects that you want to focus on later on.

2) Create a MAT analysis report every time, compare these reports, and in the histogram and Dominator tree views, find several classes and objects that are increasing in the retailed heap. Continuing to consume memory and not release it often means there is a potential memory leak problem.

3) Of course, if an object's retained size is large, it does not necessarily mean that it must be problematic, but it also requires specific analysis of the situation. Specifically, we can parse the reference path of an object to the root object to analyze why the object cannot be reclaimed successfully. If an object is not required by any program logic, but there is a case of being referenced by the root object, it is basically possible to say that there is a memory leak problem. After finding the suspected problematic class or object through the histogram or Dominator tree view, select Path to GC Roots or merge shortest Paths to GC Roots. There are a lot of filtering options, generally you can choose Exclude all Phantom/weak/soft etc.references. This excludes virtual references, weak references, and soft references, and the rest is strong references. In addition to strong references, any other type of reference can be released by the GC in the case of a Java virtual machine. If an object is never released, it must be because a strong reference exists.

4) Next you need to locate the specific code directly to see how to release the objects that should not exist. Find out why, clean up, and then compare the previous operation to see if the object continues to grow. If no longer, this potential memory leak problem has been fixed.

Use Mat to analyze Android program memory usage in Eclipse (GO)