Shulou(Shulou.com)06/01 Report--

This article mainly introduces "what is the optimization of the memory management mechanism of the Linux system by Android". In the daily operation, I believe that many people have doubts about the optimization of the memory management mechanism of the Linux system by Android. The editor consulted all kinds of materials and sorted out a simple and useful method of operation. I hope it will be helpful for you to answer the doubt that "what is the optimization of the memory management mechanism of the Linux system by Android?" Next, please follow the editor to study!

Android also uses memory as much as possible, which inherits the advantages of Linux. The only difference is that Linux focuses on caching as much disk data as possible to reduce disk IO and thus improve system data access performance, while Android focuses on as many caching processes as possible to improve application startup and switching speed. The Linux system ends the process after the process activity stops, while the Android system keeps the application process in memory for as long as possible until the system needs more memory. These processes that remain in memory usually do not affect the overall running speed of the system, but will speed up the startup of these processes when the user activates them again, because there is no need to reload interface resources, which is one of the features boasted by Android. Therefore, Android does not recommend explicit "exit" applications at this time.

Then why is it slow to run large programs when there is little memory? the reason is that opening large programs when there is not much memory will trigger the system's own process scheduling policy, which is a very resource-consuming operation. Especially when a program frequently requests memory from the system. In this case, the system will not close all open processes, but selectively close, frequent scheduling will naturally slow down the system.

Process Management in Android

When it comes to memory management in Android, we have to mention process management, because process management does affect system memory. Before we look at process management, let's first look at some basic concepts.

When an application component starts and the application is not running any other components, the Android system uses a single thread of execution to start a new Linux process for the application. By default, all components of the same application run in the same process and thread (called the "main" thread). If an application component starts and the application already has a process (because other components of the application exist), the component starts and uses the same thread of execution within the process. However, you can also schedule other components in the application to run in separate processes and create additional threads for any process.

The design idea of Android application model is taken from the Mashup concept of Web 2.0. it is a component-based application design pattern. Under this model, each application is built by a series of components, which describe the function through the configuration file of the application. According to the configuration information of the components, the Android system understands the functions of each component and schedules it uniformly. This means that components from different applications can be organically combined to complete tasks together, each Android application, only a clear component boundary, but no longer a clear process boundary and application boundary. This design also allows developers to devote themselves to the development of core functions instead of spending energy to re-develop some ancillary functions. This not only improves the efficiency of application development, but also enhances the user experience (for example, the function of selecting pictures as attachments in e-mail, you can directly call the function of special image applications, without having to develop from scratch).

Separate threads are not created for each component instance. All components running in the same process are instantiated in the UI thread, and system calls to each component are dispatched by that thread. Therefore, methods that respond to system callbacks (for example, onKeyDown () or lifecycle callback methods that report user actions) always run in the UI thread of the process (each lifecycle callback method of the four components is triggered in the UI thread).

The life cycle of a process

An unusual basic feature of Android is that the life cycle of an application process is not directly controlled by the application itself. Instead, the life cycle of a process is determined by the system, which weighs the relative importance of each process to the user and the total amount of memory available to the system. For example, rather than terminating a process that hosts an Activity that is interacting with the user, the system is more likely to terminate a process that hosts an Activity that is no longer visible on the screen, otherwise the consequences would be dire. Therefore, whether or not to terminate a process depends on the state of the components running in the process. Android will limited cleanup of processes that are no longer in use to ensure minimal side effects.

As an application developer, it is important to understand how individual application components (especially Activity, Service, and BroadcastReceiver) affect the life cycle of the application process. Incorrect use of these components may cause the system to terminate the process when the application performs important work.

As a common example, BroadcastReceiver starts a thread when it receives an Intent in its onReceive () method and then returns from that function. Once returned, the system assumes that the BroadcastReceiver is no longer active, so its managed process is no longer needed (unless there are other components active in the process). In this way, it is possible for the system to terminate the process at any time to reclaim memory, which will eventually result in the termination of threads running in the process. The solution to this problem is usually to schedule a JobService from the BroadcastReceiver so that the system knows that there is still active work in the process.

To determine which processes are terminated when they run out of memory, Android places each process in an "importance hierarchy" based on the running components in the process and their status. If necessary, the system will first kill the least important process, and so on, in order to recover system resources. This is equivalent to the concept of assigning priority to a process.

Process priority

Foreground Process: foreground process (normally will not be killed)

The process required for the user's current operation. There are many components that can determine their processes as foreground processes in different ways. A process is considered a foreground process if it meets any of the following conditions:

Managed the Activity that the user is interacting with (the onResume () method of Activity has been called)

Hosts a Service that is bound to the Activity the user is interacting with

Hosts a Service (onCreate (), onStart (), or onDestroy ()) that is performing a lifecycle callback

Hosts the BroadcastReceiver whose onReceive () method is being executed

In general, there are few foreground processes at any given time. The system terminates them only if there is not enough memory to support them to continue running at the same time. At this point, the device has often reached the memory paging state, so some foreground processes need to be terminated to ensure that the user interface responds properly.

Visible Process: visible processes (normally will not be killed

There are no foreground components, but it still affects the process of what the user sees on the screen. Killing such processes can also significantly affect the user experience. A process is considered visible if it meets any of the following conditions:

Hosts an Activity that is not in the foreground but is still visible to the user (whose onPause () method has been called). For example, when you launch a dialog box-style foreground activity, you can still see the previous Activity behind it.

The runtime permissions dialog box falls into this category. Consider, what other situation causes only onPause to be triggered and not onStop to be triggered?

Hosts the foreground Service started by Service.startForeground ().

Service.startForeground (): it requires the system to treat it as a service that the user can perceive, or is basically visible to the user.

The managed system is used for the Service of a specific function that the user can perceive, such as dynamic wallpaper, input method service, and so on.

Visible processes are considered extremely important and will not be terminated unless they must be terminated in order to keep all foreground processes running at the same time. If such processes are killed, from the user's point of view, this means that the visible activity behind the current activity will be replaced by a black screen.

Service Process: service process (normally will not be killed)

A process that is running a service that has been started using the startService () method and is not part of the above two higher categories of processes. Although service processes are not directly related to what the user sees, they are usually performing operations that the user cares about (for example, uploading or downloading data on a background network). Therefore, the system keeps the service process running unless there is not enough memory to keep all foreground and visible processes running at the same time.

Service, which has been running for a long time (for example, 30 minutes or more), may be degraded so that their processes can be placed in the Cached LRU list. This helps prevent some long-running Service from consuming too much RAM due to memory leaks or other problems, resulting in the system not being able to use the cache process effectively.

Background / Cached Process: background process (which can be killed at any time)

Such processes typically hold one or more Activity that are not currently visible to the user (the onStop () method of Activity has been called). They are not currently required, so when other higher priority processes need memory, the system may terminate them at any time to reclaim memory. But if the Activity lifecycle is implemented correctly, even if the system terminates the process, the user experience will not be affected when the user returns to the application again: the associated Activity can restore the previously saved state when it is recreated in a new process.

In a functioning system, caching processes are the only ones involved in memory management: a well-run system will always have multiple caching processes (for more efficient switching applications) and periodically terminate the oldest processes as needed. Only in very serious (and undesirable) cases does the system reach a point where all caching processes have been terminated and the service process must begin to terminate.

Reference conditions for Android system to reclaim background process:

LRU algorithm: starts terminating from the bottom up and reclaims the oldest process first. The older the process, the less likely it is to be re-used by users in the near future. The older the killing process, the smaller the impact on the user experience.

Recycling benefits: the system always tends to kill a process that reclaims more memory because it provides the system with more memory gain when it is killed, thus killing fewer processes. The fewer processes killed, the less impact on the user experience. In other words, the less memory the application process consumes in the entire LRU list, the more likely it is to remain in the list and recover quickly.

Such processes are saved in a pseudo-LRU list, and the system first kills the process at the end of the list (the oldest) to ensure that the last process containing the user's most recently viewed Activity is terminated. The exact strategy for sorting this LRU list is the implementation details of the platform, but in general, the system gives priority to trying to retain more useful processes than other types of processes (such as the process that hosts the user's main application, or the process that hosts the last Activity seen by the user, and so on). There are other strategies for terminating processes: a hard limit on the number of processes allowed, a hard limit on the amount of time a process can cache continuously, and so on.

In a healthy system, only cached processes or empty processes will be terminated by the system at any time. If service processes, or higher priority visible processes and foreground processes also begin to be terminated by the system (excluding OOM caused by poor memory use of the application itself), it means that the system is running in a sub-healthy or even extremely unhealthy state, and the available memory has been tight.

Empty Process: empty process (can be killed at any time)

A process without any active components. The only purpose of keeping such a process is to use it as a cache (for more efficient use of memory rather than completely freeing it) to shorten the time it takes to start the application next time, because starting a new process also comes at a cost. Android will kill these processes at any time as needed.

The definition of foreground / background applications in memory management is different from the definition of background applications for Service restriction purposes. Since Android 8.0, in order to save system resources, optimize user experience and improve battery life, the system makes a distinction between foreground and background applications, and places some restrictions on background service. In this definition, the application is considered to be in the foreground if any of the following conditions are met:

>

Has a visible Activity (regardless of whether the Activity is started or paused).

With front desk Service.

Another foreground application has been associated with that application (either by binding to one of the Service or by using one of the content providers). For example, if another application is bound to the application's Service, then the application is in the foreground: IME wallpaper Service notifies listener voice or text Service if none of the above conditions are met, the application will be considered in the background.

How to evaluate the priority of processes in Android system

Based on the importance of the currently active components in the process, Android rates the process as the highest level it can reach. For example, if a process hosts both Service and visible Activity, it is rated as a visible process rather than a service process.

In addition, the level of one process may be raised due to the dependence of other processes on it, that is, the level of a process that serves another process is never lower than that of the process it serves. For example, if the content provider in process A provides services to clients in process B, or if the services in process An are bound to components in process B, process An is always considered at least as important as process B.

Because the process running the service is at a higher level than the process hosting the background Activity, when starting a long-running operation in Activity, it is better to start the service for that operation than to simply create a worker thread, especially when the operation is likely to be more persistent than Activity. For example, a file upload operation can be done using a service, so that even if the user exits from Activity, the upload operation can continue in the background. Using a service ensures that no matter what happens to the Activity, the operation at least has a "service process" priority. By the same token, BroadcastReceiver should also use services instead of simply putting time-consuming and tedious operations into threads.

The difference between Home key exit and return key exit

When the Home key exits, the program retains the status of the background process; while the return key exits, the program retains the state of the empty process, which is easier to be reclaimed by the system. In fact, the Home key is mainly used for inter-process switching, while the return key is the real exit program.

In theory, in either case, in the absence of any background worker thread (even if the application is in the background, the worker thread can still execute), the processes placed in the background only retain their running state, do not consume CPU resources, and therefore do not consume power. Power is consumed only when applications such as music playback software need to run Service in the background, while Service takes up CPU time. So applications without background services do not consume power or take up CPU time, and there is no need to shut down. This design itself is one of the advantages of Android, which can make the application start faster next time. However, the reality is that many applications will have some background worker threads more or less, which may be caused by the lack of experience of developers (for example, the thread is not closed or the Handler message sent by the loop does not stop), or it may be intentional for the sake of requirements, resulting in the ecological environment of the whole Android application is not clean.

At this point, the study on "what is the optimization of the memory management mechanism of the Linux system by Android" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.