Android within Storage management

Overview

In the development of Android, the main memory allocation and garbage collection, because the system for each Dalvik virtual machine allocation of memory is limited, in Google's G1, the largest allocation of heap size is only 16M, then the machine is generally 24M, is very little pitiful. This requires us to be mindful of the development process. Do not cause oom errors because of your own code problems.

Memory Management in Java

As you all know, the Android application layer is developed by Java, and Android's Davlik virtual machine is similar to the JVM, but it's based on registers. So to understand the Android memory management you have to understand the Java memory allocation and garbage collection mechanism.

In Java, the new keyword is used to allocate memory for the object, and the release of the memory is collected by the garbage collector (GC), in the process of development, the engineer does not need to explicitly manage memory. However, it is possible to unknowingly waste a lot of memory, resulting in the Java Virtual machine to spend a lot of time to garbage collection, and more serious is caused by the JVM Oom. Therefore, it is also necessary for the Java engineer to understand the Java memory allocation and garbage collection mechanism.

Memory structure

The above diagram is a structure diagram of the JVM, which consists of four main parts: the Class loader subsystem and the execution engine, the Run-time method area and the local method area, and we look at the runtime DATA area, which is what we often call JVM memory. As can be seen from the figure, the Runtimedata area is composed of 5 main parts:

M Ethod Area: The metadata of the loaded class is stored in the method area, which is a thread-shared Heap (heap): A Java Virtual machine instance exists with only one heap space, containing some object information, which is a thread-shared Java stack: Java Virtual machines operate directly on Java stacks, with frame-per-stack and stack (non-thread shared) program counters (not thread shared) Local method stacks (not thread shared)

Garbage collection of the JVM (GC)

The JVM's garbage principle is that it divides objects into young generations, older generations (tenured), persistent generations (Perm), and uses different garbage collection algorithms for objects of different lifecycle.
Younger generation (young)

The young generation is divided into three districts, one Eden area and two survivor districts. Most of the new objects generated in the program are in the Eden area, and when the Eden is full, the surviving objects will be copied to one of the survivor areas, and when the objects in this survivor area are occupied, the objects that live in this area are copied to another survivor area, When the survivor area is full, the objects copied from the first survivor and surviving at this time will be copied to the older generation.
Older generation (tenured)

The older generation is storing the objects that were copied by the younger generation, the objects that were still alive in the younger generation, and the regions were full of copies. In general, the object life cycle in the older generation is relatively long.
Persistent generation (Perm)

For storing static classes and methods, the persistence generation has no significant effect on garbage collection.

Memory leak monitoring in Android

After understanding the memory management of the JVM, let's take a look at how the memory should be monitored in Android to see if there are memory allocations and garbage collection issues in the application that can cause memory leaks.

In Android, there is a relatively good tool that can be used to monitor for leaks in memory: ddms-heap

The use of the method is relatively simple:

Select the DDMS view and open the Devices view and Heap view Click to select the process to monitor, for example: Above I chose system_process selected Devices view interface "Update Heap" icon click on Heap View "Cause GC" button (equivalent to sending a GC request to the virtual machine)

In the heap view, select the type you want to monitor, generally we will observe the change of total size of DataObject, the value of total size will be stable in a limited range, it is said that the code in the program is good, did not cause the object in the program not to be recycled. If there is a case in the code that does not release the object reference, the total size of data object does not drop significantly after each GC, and total size increases as the number of operations increases. (Note: After choosing good data object, the continuous operation of the application, so that you can see the total size change). If the totalsize is indeed increasing without falling back, there is a resource reference in the program that has not been freed. So how are we supposed to locate it?

Memory leak location in Android

Mat (Memory Analyzer tools) is our common tool for locating memory leaks, and if you use ADT and install the Mat Eclipse plug-in, you need to go to DDMS view of Devices view:

Click the "Dump HPROF File" button and then use MAT to analyze the downloaded file.

Here's a list of the problems, and click Detail to go in and list detailed, potentially problematic code:

About the use of mat can refer to: http://www.blogjava.net/rosen/archive/2010/06/13/323522.html

The brother wrote in more detail.

Summarize

Whether it is Java or Android, should understand the memory allocation and garbage collection mechanism, engineers to do write code is not bad, the key is in the problem of how to troubleshoot.