[Android performance Optimization Series] The basics of memory--android how to manage memory

If you like my blog, please follow my Weibo, please click here (http://weibo.com/kifile), thank you

Reprint please indicate the source (http://blog.csdn.net/kifile), thanks again

Original address: http://developer.android.com/training/articles/memory.html

For the next period of time, I will translate some of the official Android documents for performance improvement every day to everyone

Here is the text of this session:

################

Random access memory (RAM) is an extremely valuable resource in any software development environment, and the extremely limited physical memory is more valuable under the mobile development platform. So while Android's Dalvik virtual opportunity performs garbage collection, it doesn't mean that you can ignore the memory allocations and releases you apply.

In order for the garbage collection period to reclaim memory in your application, you need to avoid memory leaks (usually due to the fact that a global variable holds an object) and, when appropriate, release point reference objects (such as in the life cycle). For most applications, the Dalvik virtual machine's garbage collector will help you reclaim memory for objects that are no longer in scope.

This article describes how Android manages memory processes and memory allocations, and how to reduce memory usage during development. If you want to know more about the cleanup resource mechanism for Java, then you can check out some books or online documentation on resource references. If you are looking for information on how to analyze the current application memory usage, then you can refer to this article (investingating Your RAM usage).

How Android manages memory

While Android does not provide memory swap space, he uses paging and memory-mapped files to manage memory. This means that any memory you have modified, whether it is assigned a new object, or changes the memory-mapped night operation, will remain in memory so that it cannot be freed. The only way to release these memory from your app is to release the objects that are used, so that the garbage collection mechanism can reclaim him. The only exception to this is that data that has not been changed, such as code, is called by the system when the system wants to use it elsewhere.

Public memory

Android is able to hold as many resources as possible in RAM, so he allows some common memory to be used across processes. His principle is as follows:

1. Each application process is taken care of by a process called Zygote. the Zygote process starts automatically when the system starts and loads many common framework code and resources (such as Activity topics, etc.) internally. When you start a new application, the system copies the resources from the Zygote process and then runs the app code in the new process. This allows a large amount of memory resources in the framework and resources to be reused across processes.

2. most of the static data is placed into the process through memory mapping. Not only does this mean that the same data can be shared across processes, it also means that it can be called at any time when needed. For example, static data includes: Dalvik code (called directly using precompiled. Odex), application resources (called by the Guo Tong CV Resource Mapping table), and some default project resources, such as local code in. so files

3. in many places, Android will share the same dynamic RAM across processes by allocating memory areas directly. For example, Windows Surface uses public memory to sort apps and screens, and the Cursor cache uses the same memory between ContentProvider and clients

Due to the use of public memory, we need to be concerned about how much memory your application needs to use. How to properly analyze application memory usage See investingating Your RAM usage.

Allocating and releasing application memory

Here is a section on how Android allocates and frees memory:

1. The Dalvik heap of each process is limited to a virtual memory range. This means that the size of the logical heap can grow with his needs (and of course the system limits the maximum memory footprint for each application)

2. The logical size of each heap is not the same as the physical memory used by the heap. when checking the application's heap, Android accounting for a value called scale size (PPS), which will count the dirty and clean data shared with other apps, the total value of your PPS will be considered as the physical memory. For more detailed information, see investingating Your RAM Usage.

The 3.Dalvik heap does not compress the logical dimensions of the heap, which means that Android does not clean up space to reduce the heap size. Android only takes back the heap itself when there is no space left in the heap. However, this does not mean that the physical memory used by the heap can be freed. After the garbage collection, Dalvik scans the heap to find unused memory pages and frees the memory pages to kernel space through madvise. So a large amount of allocated or freed objects will reclaim the used physical memory. However, it is not very good to reclaim memory space from those small resources, because the paging that holds these small resources is likely to be used by other objects, resulting in the inability to release.

Limit application Memory

Android in order to ensure its own multitasking environment, he set a heap of hardware restrictions for each application . This limit depends on how much ram the device has. If your app has reached the upper limit of the heap and wants to allocate more memory space, it will cause oom.

Under certain conditions, you might want to know the maximum allowable heap space on the current device, say, for example, to determine the size of a cache. Then you can retrieve these system data by querying Getmemoryclass (), and he will return the memory you applied as an int type, which will be discussed below.

Switch Apps

When users switch between apps, Android uses the least recently used algorithm (LRU) to save the process in a list of foreground app components rather than in swap space. For example, when a user launches an app for the first time, the app's process is created, but when the user leaves the app, the app does not exit completely. The system will save the cache of the process so that when the user returns to the current application, the cache can be called as quickly as possible to increase the speed of entry into the program.

If your app has a cached process, and he keeps the memory he needs, it will limit the overall performance of the system even when the user is not using it. So when the system is running out of memory resources, he may be able to kill those processes that have not been used recently . So in order to keep your process as close as possible, it's best to follow the chapters below to release your resources.

If you want to learn more about how processes are cached in a non-foreground environment, and how Android determines which processes are killed, see processes and threads

[Android performance Optimization Series] The basics of memory--android how to manage memory