1, Android Process Management & memory Android is mainly used in embedded devices, and embedded devices due to some well-known conditions are limited, usually not very high configuration, especially memory is relatively limited. If we write code that has too much memory usage, it will inevitably make our device run slowly, or even crash. To enable Android apps to run safely and quickly, each Android application uses a proprietary Dalvik virtual machine instance that evolves from the zygote service process, meaning that each application runs in its own process. On the one hand, if the program in the process of running a memory leak problem, will only make their own process is killed, and will not affect other processes (if it is system_process and other system process problems, it will cause a system restart). On the other hand, Android allocates different memory usage caps for different types of processes, and if the application process uses more memory than this limit, it is considered a memory leak and is killed by the system.
At the same time, Android assigns a single Linux user to each application. Android will try to keep a running process, only in the event of insufficient memory resources, Android will try to stop some processes to free up enough resources for other new processes to use, but also to ensure that the current process users are accessing has sufficient resources to respond to the user's events in a timely manner. Android will determine the importance of the process based on the category of components running in the process and the state of the component, and Android will first stop those unimportant processes. According to the importance from high to low a total of five levels is what we often say: foreground process, visible process, service process, background process, empty process. 2, the maximum memory available for a single application Android device factory, the Java virtual machine to a single application of the maximum memory allocation is determined, beyond this value will be oom. This attribute value is defined in the/system/build.prop file.
Dalvik.vm.heapstartsize=8m
It represents the initial size of the heap allocation, which affects how much RAM is used by the entire system, and how smoothly the application will be used for the first time.
The smaller the value, the slower the system RAM consumption, but some of the larger applications are not available at first, and need to invoke the GC and heap adjustment policies, causing the application to react more slowly. The larger the value, the greater the system's RAM consumption, but the smoother the application.
DALVIK.VM.HEAPGROWTHLIMIT=64M//Single application maximum memory available
The primary counterpart is this value, which indicates that a single process memory is limited to 64m, which means that only 64m of memory is actually used while the program is running, and Oom is reported beyond. (Only for Dalvik heap, not including native heap)
The Dalvik.vm.heapsize=384m//heapsize parameter represents the maximum amount of memory available to a single process, but if there is a heapgrowthlimit parameter, the Heapgrowthlimit is the standard.
HeapSize represents an uncontrolled limit heap, which represents the maximum memory available to a single virtual machine or a single process. Android apps have a standalone virtual machine, which opens a separate virtual machine for each application (so the design will not crash the entire system in the event of a single program crash).
Note: When Heapgrowthlimit is set, a single process can have a maximum memory value of Heapgrowthlimit. In Android development, if you want to use a large heap, you need to specify ANDROID:LARGEHEAP to true in manifest so that the DVM heap can be up to heapsize.
Different devices, these values can vary. Generally, manufacturers for the configuration of equipment will be appropriate to modify the/system/build.prop file to increase this value. As device hardware performance continues to improve, from the earliest 16M restrictions (G1 phones) to later 24m,32m,64m, all follow the Android framework's minimum memory size limit for each app, refer to http://source.android.com/ Compatibility/downloads.html 3.7 knots.
View the maximum memory available to each process by code, which is the Heapgrowthlimit value:
Activitymanager Activitymanager = (activitymanager) context.getsystemservice (Context.activity_service);
int memclass = Activitymanager.getmemoryclass (),//64, in M 3, why memory leaks (memories Leak)? Android uses Android virtual machine to manage memory, programmers just apply for memory to create objects, after creation no longer need to care about how to release the object memory, everything is done by the virtual machine to help you, but the virtual machine to reclaim the object is conditional. Here is a brief description of the Java memory Management mechanism, the Java Virtual machine maintains a current object tree, when the GC occurs, the virtual opportunity from the GC Roots to scan the current object tree, found through any reference chain (reference chain) When an object cannot be accessed, the object is recycled. The noun GC Roots is the starting point for the analysis of the process, such as the JVM itself ensuring the accessibility of the object (then the JVM is GC Roots), so the GC Roots is how to keep the object reachable in memory and, once unreachable, is recycled. Typically GC roots is an object on the call stack (the calling stack) on the current thread (for example, method parameters and local variables), or either the thread itself or the System class loader (the ClassLoader) The class that is loaded and the active object that native code (local code) retains. So GC roots is a powerful tool for analyzing why objects still exist in memory. If you know what kind of object GC will be recycled, then learn what the object references contain.
There are 4 kinds of object references in Java:
Strong references: Usually we write code that is strong ref,eg:person person = new ("Sunny"), and no matter how nervous the system resources are, the objects that are strongly referenced will never be recycled, even if they are not used in the future.
Soft reference: The object is persisted as long as there is enough memory. Generally available for caching, implemented through the Java.lang.r.efsoftreference class. When the memory is very tense, it will be recycled, other times it will not be recycled, so it needs to be empty before use, thus judging the current time has been recycled.
Weak references: implemented by the WeakReference class, eg:weakreference p = new WeakReference (New person ("Rain")), and the system garbage collection must be recycled regardless of memory adequacy.
Virtual reference: cannot be used alone, mainly to track the state of the object being garbage collected. The implementation is federated using the Phantomreference class and the reference queue Referencequeue class.
We may also need to understand the shallow size, retained size concept, which simply means that the shallow size is the amount of memory that the object itself occupies, and does not contain references to other objects, that is, the sum of the object headers plus member variables (not the values of member variables). On a 32-bit system, the object header occupies 8 bytes, and int occupies 4 bytes, regardless of whether the member variable (object or array) refers to another object (instance) or is assigned null, it always consumes 4 bytes. Therefore, for a string object instance, it has three int members (34=12 bytes), one char[] member (14=4 bytes), and one object header (8 bytes), totalling 34 +14+8=24 bytes. According to this principle, for string a= "Rosen Jiang", the shallow size of instance A is also 24 bytes. Retained size is the object's own shallow size, plus the sum of the shallow size that can be accessed directly or indirectly from the object to the object. In other words, the retained size is the sum of the memory that the object can be recycled to after it has been GC. To better understand retained size, let's look at an example.
Figure 1
Assuming that the reference relationship between objects in memory can be seen as Figure 1, you can see that the GC is the starting point for reference chain. Starting with obj1, the middle blue node represents only objects that can be accessed directly or indirectly through OBJ1. Because it can be accessed through GC roots, the OBJ3 on the left is not a blue node, whereas on the right the picture is blue because it is already contained within the retained collection. So for the left, the retained size of the obj1 is the sum of the obj4 size of obj1, obj2, Shallow, and the retained size of Obj1, Obj2, Obj3, Obj4 is the sum of shallow size for the right figure.
Believe that there are these basic concepts, we should have a preliminary understanding of Java memory Management. Why is there a memory leak, the root cause is an object that will never be used, because some references are not broken, the GC conditions are not met, and are not recycled, resulting in a memory leak. For example, in the activity register a broadcast receiver, but when the page is closed to unregister, there will be a memory overflow phenomenon. If our Java runs for a long time, and this memory leak keeps happening, then there is no memory available, and eventually we see the oom error. While Android's memory leak is an application-level leak (each application in Android is run independently in a separate process, each application process is assigned a memory upper value by the virtual machine, and an oom error occurs when the memory consumption exceeds this upper limit). Process is forced to kill, kill the process memory will be reclaimed by the system, but for a development engineer, never let go of any memory leaks
Android Memory Management &memory Leak & OOM Analysis
