[Android Performance Optimization series] basic memory--android How to manage memory

Everyone assumes 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

The following 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. Although the Android Dalvik virtual opportunity runs garbage collection. But that doesn't mean you can be indifferent to the memory allocations and releases you apply.

In order for the garbage collection period to reclaim memory in your app. You need to avoid memory leaks (typically caused by holding an object in a global variable) and releasing point reference objects (for example, in the life cycle) when appropriate.

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.

Suppose you also want to know a lot about Java's cleanup resource mechanism. Then you can go and see some books about resource references or online documentation. Suppose you are looking for information on how to analyze the current application memory usage. Then you can take 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 whatever memory you have changed, 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 dispose of the objects used. Allows the garbage collection mechanism to be able to 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 can store as much resources in RAM as possible, so he agrees that some co-owned memory is used across processes. His principles are as follows:

1. Each application process is responsible for a process called Zygote.

The Zygote process is initiated by itself when the system is started. It also contains a lot of common framework code and resources (such as Activity topics). when launching a new application. The system replicates these resources from the Zygote process. Then execute the application code in the new process. This would allow 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. The same means that you can be called at any time when you need it. For example, the static data contains: Dalvik code (called directly using precompiled. Odex), application resources (country pass resume resource Mapping table to invoke). And some default project resources, such as the local code in the. so file

3. in very many places. Android shares the same dynamic RAM across processes by allocating memory areas directly. For example, form Surface uses public memory to sort the app and screen, and the Cursor cache uses the same memory between ContentProvider and the client

Because of the use of public memory, we need to be concerned about how much memory your application needs to use.

How to correctly 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 (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 accounts for a value called scale size (PPS), which will count both dirty and clean data shared with other apps. The total value of your PPS will be considered by the system to be the values of physical memory.

For more specific information, see investingating Your RAM Usage.

the 3.Dalvik heap does not compress the logical dimensions of the heap. This 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 of the paging of these small resources, it is very likely to be used by other objects, resulting in the inability to release.

Limit application Memory

In order to guarantee its multitasking environment, Android has set a heap hardware limit for each application . This limit depends on how much ram the device has. Assuming that your app has reached the upper limit of the heap, and you want to allocate a lot of other memory space, it can cause oom.

Under certain conditions. You may want to know the maximum amount of heap space the system has agreed on on the current device. For example, it is used to determine the size of a cache.

Then you can get to these system data by querying Getmemoryclass (). He will return your application of available memory as a value of type int, which will be discussed below.

Switch Apps

When a user switches 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 completely exit. 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.

Suppose your app has a cached process, and he keeps the memory he needs. It also limits the overall performance of the system even when the user is not using it. therefore, when the system memory resources are insufficient, he may kill those that have not been used in the recent process . So in order to keep your process as close as possible, it's best to follow the chapters below to get your resources released.

Suppose you want to know a lot about how the process is cached in a non-foreground environment. And how Android determines which process is killed, see the process and thread

Next. To see how the application manages its own memory.

[Android performance optimization] memory boost--how the app should manage memory

[Android Performance Optimization series] basic memory--android How to manage memory