Android Memory Optimizer 1 Learn how Android manages app memory

1, Dalvik & ART

Android has been using the Dalvik virtual machine as the app's running VM before 4.4, and 4.4 has introduced art as a developer alternative, with 5.0 officially being the default VM.

Let's start with a brief look at both of them:

1.1 Dalvik

If just want to understand briefly, personal feel Baidu encyclopedia on this Dalvik introduction basically meet the requirements.

If you want to go deep, you can look at the old Luo's Android Tour Dalvik related blog post, from the code level analysis of Dalvik start, operation mechanism. Worth a look.

What needs to be explained is that Dalvik uses the JIT technology, when the application launches, JIT through carries on the continuous performance analysis to optimize the program code execution, in the procedure running process, the Dalvik is unceasingly carries on the work which compiles the bytecode code to the machine code.

1.2 ART

ART is taken from Android RunTime. Android uses it to replace Dalvik, the main purpose is to improve the performance of the operation. So, art has several key improvements compared to Dalvik:

Introduction of AOT (Ahead-of-time) pre-compilation technology

During the installation of the APK, art compiles the machine code using all the bytecode of the dex2oat program. There is no need for real-time compilation during the application to run, only direct calls are required. This improves the operational efficiency of the application.

GC Efficiency

• Reduced to one time by the original two GC pauses .
• Reclaims recently allocated, short-lived objects with less GC time .
• Improve GC engineering to make concurrent GC more timely.
• Compress the GC to reduce background memory usage and memory fragmentation.

Development and commissioning

• Supports sampling analysis of memory/method execution.
• Support for more debugging techniques.
• More information is available in the crash report.

2, the memory management mode of Android

Both art and Dalvik use paging and memory-mapping (mmapping) to manage memory. This means that any allocated memory will persist, and the only way to release this memory is to release the object reference (which makes the object GC root unreachable ), so that the GC program reclaims the memory.

2.1 App memory allocation and recycling

For each app process, the heap memory is limited to a virtual memory range. and defines the logical use of the heap size, which is within the maximum system limit and varies with the usage of the application.

The logical size of the heap memory is not the same as the actual physical memory size. We will see a value called Proportional Set size (PSS) when we analyze memory using memory analysis tools such as Memories Monitor, which is the amount of physical memory that the system thinks your app occupies.

This PSS value is the actual physical memory size, which includes the amount of memory that your application process occupies, and the amount of memory that is consumed in shared memory (calculated as a proportional allocation method).

The Android VM does not compress the logical size of the heap memory, so it cannot be defragmented to free up the heap space, but the logical memory size can only be compressed by reclaiming the empty memory block at the end of the heap.

At this point, our GC comes out, and after the GC, the VM iterates through the heap to find the unused pages, returns it to the kernel via the Madvise function, and frees up the physical memory used by the logical heap.

2.2 App Memory limit

Android is a multitasking system that allows Android to set a limit on the size of the heap that each app can use to keep multitasking running.

This value is the prop value of the system setting, built-in at system compile time, and saved in System/build.prop. General domestic handset manufacturers will make changes, depending on the phone configuration and different, can be viewed by the following commands:

$ adb shell[email protected]:/ $ cat /system/build.prop

In the case of Huawei Glory 6 at hand, the heap size related prop is as follows:

dalvik.vm.heapstartsize=8mdalvik.vm.heapgrowthlimit=192mdalvik.vm.heapsize=512mdalvik.vm.heaptargetutilization=0.75dalvik.vm.heapminfree=2mdalvik.vm.heapmaxfree=8m

which

Dalvik.vm.heapstartsize

--The initial size of the heap that the system assigns to the app when it starts. As the app is used, it increases.

Dalvik.vm.heapgrowthlimit

--By default, the maximum heap value that the app can use will cause Oom to exceed this value.

Dalvik.vm.heapsize

--If the Largeheap attribute is configured in the app's manifest file, the following is the maximum value for the heap that the app can use.

<application    android:largeHeap="true">    ...</application>

Dalvik.vm.heaptargetutilization

-The current ideal heap memory utilization. After GC, the heap memory of Dalvik is adjusted to the size of the currently surviving object and/or the heap size is close to the value of this option, which is 0.75. Note that this is only a reference value.

Dalvik.vm.heapminfree

-The minimum amount of memory adjustment for a single heap.

Dalvik.vm.heapmaxfree

-The maximum number of memory adjustments for a single heap.

You can also view individual prop directly using Getprop:

$ adb shell getprop dalvik.vm.heapsize512m

2.3 Memory management mechanism when switching apps Android's process level

The Android system keeps the application process as long as possible, but in order to create a new process or run a more important process, the old process eventually needs to be purged to reclaim memory. To determine which processes are retained or terminated, each process is set to an important level based on the components that are running in the process and the state of those components. When necessary, the system first removes the least-important process, then the process with a slightly lower importance, and so on, to reclaim system resources.

According to the important degree from large to small in order to divide into 5 levels:

Foreground process

The process required for the user's current operation. A process is considered a foreground process if it meets any of the following conditions:

• Activity that the managed user is interacting with (the Onresume () method of the activity is called)
• Host a Service that binds to the Activity that the user is interacting with
• Hosting a service that is running in the foreground (services called Startforeground ())
• Managed * Service (OnCreate (), OnStart (), or OnDestroy ()) that is performing a lifecycle callback
• The host is executing its onreceive () method Broadcastreceiver

The system terminates them only if it is not sufficient to support them at the same time and continue to run as a last resort. At this point, the device tends to have reached the memory paging state, so some foreground processes need to be terminated to ensure that the user interface responds properly.

Visible process

A process that does not have any foreground components, but still affects what the user sees on the screen. A process is considered visible if it meets any of the following conditions:

• Hosts Activity that is not in the foreground, but is still visible to the user (its OnPause () method has been called). For example, this can happen if the foreground activity launches a dialog box that allows the previous activity to be displayed later.
• Hosting a Service bound to a visible (or foreground) Activity
  The visible process is considered to be an extremely important process, and the system does not terminate the process unless it must be terminated in order to maintain all foreground processes running concurrently.

Service process

Running a service that has been started with the StartService () method and is not part of the above two higher category processes. Although the service process is not directly related to what the user sees, they typically perform actions that are of interest to the user (for example, playing music in the background or downloading data from the network). Therefore, the system keeps the service process running unless the memory is insufficient to maintain all foreground and visible processes running concurrently.

Background process

Contains the current process of activity that is not visible to the user (the OnStop () method of the activity is called). These processes have no direct impact on the user experience, and the system may terminate them at any time to reclaim memory for use by foreground processes, visible processes, or service processes. There are often many background processes running, so they are saved in the LRU (least recently used) list to ensure that the last one that contains the Activity that the user recently viewed is terminated. If an activity correctly implements the life cycle method and saves its current state, terminating its process does not have a noticeable impact on the user experience, because when the user navigates back to the activity, the activity restores all of its visible state.

Empty process

Processes that do not contain any active app components. The only purpose of preserving this process is to use it as a cache to shorten the startup time required for the next component to run. To keep the overall system resources balanced between the process cache and the underlying kernel cache, the system often terminates these processes.

Switch the app's memory management

When the user switches the app, the memory used by the app that was switched to the background is not deleted, and the app process is cached in an LRU cache so that when the user switches back, the app can be launched faster, making multitasking smoother.

However, when the system is low on memory, it determines which processes are killed based on the LRU feature and the process level mentioned above (which also takes into account the size of the app's memory) to reclaim memory for performing the current task.

So, if we want to not let the system kill our app, we can optimize it from the process level, memory consumption and so on.

Conclusion

This article plus gc those things, we talked about two of theoretical knowledge, I believe you have a general understanding of the memory management of Android, the following will introduce some memory analysis tools and use, the actual to explain how to analyze memory problems.

Anly_jun
Links: Https://www.jianshu.com/p/4ad716c72c12
Source: Pinterest
Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source.

Android Memory Optimizer 1 Learn how Android manages app memory