Turn from Android memory mechanism analysis to understand Android heap and stack

Transfer from http://www.cnblogs.com/mythou/p/3202238.html　

Yesterday with gallery did a picture browse select the function of the boot screen, when I loaded more pictures on the problem of Oom. There have been problems before, and that was not the point. This time I intend to analyze the memory mechanism of Android.

Because I used to do VC development, so the C + + window in the memory mechanism is still relatively understanding. However, after turning to Android, has not been deliberately to deal with memory problems, because the brain has been thinking about the Java GC mechanism. But now think about, their own on the Android GC and memory management do not know, their own code in memory where the operation is not clear, the heart is not calm ah ....

After all, I used to write C + +, when and where to apply for memory, when to release memory, will not stack overflow or heap memory leaks are familiar. So, today, we're going to look at how Android stacks and stacks are different from C + +.

1. Heap and stack of Dalvik

This is just Dalvik Java part of the memory, in fact, in addition to the Dalvik part, there are native. I'll talk about this later.

The following is a description of the data types listed above, so that we can better control our own programs only if we know where the data we are applying for IS.

2. Object instance Data

is actually the property that holds the object instance, the type of the property and the type tag of the object itself, etc., but does not save the method of the instance. The method of the instance is the data instruction, which is stored in the stack, which is the class method in the table above.

After the object instance is allocated in the heap, a 4-byte heap memory address is saved in the stack to find an instance of the object. Because an instance of heap is used in a stack, especially when invoking an instance, you need to pass in a this pointer.

3. Method Internal variables

The internal variables of a class method are in two cases: the simple type is saved in the stack, the object type holds the address in the stack, and the value is saved in the heap.

4. Non-static methods and static methods

The non-static method has an implicit incoming parameter, which is passed in by the Dalvik virtual machine, which is the address pointer of the object instance in the stack. Therefore, a non-static method (the instruction code in the stack) can always find its own private data (object property values in the heap). The non-static method must also obtain the implied argument, so the non-static method must first new an object instance to obtain the address pointer in the stack before the call, otherwise the Dalvik virtual machine cannot pass the implied parameter to the non-static method.

The static method does not have an implicit parameter and therefore does not require a new object, which can be called as long as the class file is ClassLoader load into the JVM's stack. So we can call the class's method directly using the class name. Of course, at this point the static method is not accessible to object properties in the heap.

5. Static properties and Dynamic properties

　　Static properties are saved in the stack, unlike dynamic properties stored in the heap. Because all are in the stack, and the instructions and data in the stack are fixed-length, it is easy to calculate offsets so that class methods (both static and non-static) can access static properties of the class. It is also because the static property is stored in the stack, so it has a global property.

6. Summary

The Java heap is a run-time data area in which objects allocate space. These objects are established through directives such as new, NewArray, Anewarray, and Multianewarray, and they do not require program code to be explicitly released. Heap is responsible for garbage collection, the advantage of the heap is the ability to dynamically allocate memory size, the lifetime does not have to tell the compiler beforehand, because it is at runtime to allocate memory dynamically, Java garbage collector will automatically take away these no longer use data. However, the disadvantage is that the access speed is slower due to the dynamic allocation of memory at run time. The advantage of the stack is that the access speed is faster than the heap, after the register, and the stack data can be shared. However, the disadvantage is that the size and lifetime of the data in the stack must be deterministic and inflexible. 　　The stack mainly contains some basic types of variables (, int, short, long, byte, float, double, Boolean, char) and object handle. Comparing the above analysis can be seen, in fact, Java processing heap and stack the approximate principle of C + + is the same. It's just a memory-recycling mechanism that allows programmers to release memory without having to call delete voluntarily. Just like in C + +, the memory used for new applications is usually placed in the heap, and the normal temporary variables are placed in the stack. ----------------------------------------------------------------------------------------Android memory mechanism analysis 2-- Analyze app Memory usage

1. The app allocates memory size by default

In Android, program memory is divided into 2 parts: native and Dalvik,dalvik are our normal Java use memory, which is the memory we used when we analyzed the stack on the previous article. The objects we create are assigned here, and the limit for memory is Native+dalvik cannot exceed the maximum limit. Android program memory is generally limited to 16M, also some 24M (early Android system G1, is only 16M). Depending on the settings of the custom system, init.c in the Linux initialization code, you can find the default memory size. Interested friends, you can analyze the virtual machine startup related code. This piece is more in-depth, at present I also did not have the time to analyze, the back has the space to delve into a bit.

Edited by Mythou
http://www.cnblogs.com/mythou/

Gdvm.heapsizestart = 2 * 1024x768 *;   Heap initialization size is 2mgdvm.heapsizemax = * 1024x768 * 1024x768;    The largest heap is 16M

2. How the Android GC reclaims memory

An Android application's memory leak has little impact on other applications. To enable Android apps to run safely and quickly, each Android application uses a proprietary Dalvik virtual machine instance that is hatched by the zygote service process, which means that each application runs in its own process. Android allocates different memory usage caps for different types of processes, and if a memory leak occurs during a program that causes the application process to use more memory than the upper limit, it will be considered a memory leak by the system and killed, which causes only its own process to be killed. It does not affect other processes (which can cause a system restart if the system processes problems such as system_process).

When it comes to application development, you need to understand how the system's GC (garbage collection) mechanism works, and Android uses a graph as a mechanism for iterating through the recovered memory. Java considers the reference relationship as a directed edge of the graph, and has a pointing edge from the referrer to the Reference object. The thread object can serve as the starting vertex of a forward graph, which is a tree starting from the starting vertex, the objects that the root vertices can reach are valid objects, and the GC does not reclaim those objects. If an object (connected sub-graph) and this root vertex are unreachable (note that the graph is a forward graph), then we think that this (these) objects are no longer referenced and can be recycled by GC.

So for an object that we don't need to use, we can set it to null, so that when the GC runs, it's good to iterate over your object without reference and automatically reclaim the memory that the object consumes. We can't release unwanted memory as soon as C + +, but we can proactively tell the system which memory can be recycled.

3. View App Memory usage

Let's look at how the memory usage of our program runs during the development process. We can view it through one of the ADB commands:

Edited by Mythou
http://www.cnblogs.com/mythou/

//$package _name: App package name//$PID: Apply process ID, you can view adb shell Dumpsys meminfo $package _name or $pid with the PS command

I use the package name to see the gallery example of the memory usage graph, there is a lot of information, but our main concern is the use of native and Davilk. (android2.x and android4.x look at the sort of information is not the same, the content is similar, but the arrangement is different, I above is 4.0)

The android underlying kernel is Linux-based, and Linux, in contrast to window, is particularly likely to use system memory to load some cached data or to share data between processes. Linux in line with the principle of not white, will try to use the system memory, speed up our application running speed. Of course, if we expect an application that requires large memory, the system can also release a certain amount of memory usage immediately, which is the implementation of the system internal scheduling. So strictly speaking, it is difficult for us to calculate the size of a process memory under Linux. Because there is paging out to disk (page change), if you add all the memory mapped to the process, it may be larger than the actual physical size of your memory.

• Dalvik: Refers to the memory used by the Dalvik.
• Native: Is the memory used by the native heap. It should refer to the memory allocated on the heap using c\c++.
• Other: Refers to memory used in addition to Dalvik and native. But what exactly does it mean? Include at least non-heap memory allocated in c\c++, such as memory allocated on the stack. puzlle!
• Pss: It is to compute the resulting process using memory by allocating shared memory to each process that shares it, based on a certain percentage. The network is also said to be the proportion of shared library memory occupied, that is, the above mentioned process sharing issues.
• Privatedirty: It refers to the size of the memory that is unshared and cannot be paged out (can not be paged to disk). For example, the small object that Linux buffers in order to increase memory speed, even if your process ends, the memory will not be released, it just back into the buffer.
• Shareddirty: Referring to Privatedirty I think it should mean the size of the memory that is shared and cannot be paged out (can not be paged to disk). For example, the small object that Linux buffers in order to increase the allocated memory speed, even if all the processes that share it end, the memory is not released, it just goes back to the buffer.

　The above for meminfo inside the information to give the analysis, these many I refer to some articles on the Internet, so if there is no understanding in place, you are welcome to point out.

4, the program to obtain memory information

To get the relevant information through Activitymanager, here is an example code:

Edited by Mythou
http://www.cnblogs.com/mythou/

{        final Activitymanager Activitymanager = (activitymanager) getsystemservice (activity_service);        Activitymanager.memoryinfo info = new Activitymanager.memoryinfo ();       Activitymanager.getmemoryinfo (info);         LOG.I (tag, "System remaining Memory:" + (Info.availmem >>) + "K");       LOG.I (Tag, "whether the system is running in low memory:" +info.lowmemory);    LOG.I (Tag, "when the system's remaining memory is lower than" +info.threshold+ "is considered a low memory run");}

In addition, through the Debug getmemoryinfo (debug.memoryinfo memoryinfo) can get more detailed information. As detailed as the information we see in the ADB shell.

Turn from Android memory mechanism analysis to understand Android heap and stack