Memory Management in Android

Start with some questions about Android:
1. After exiting all the activities, the application is still running in the background. Why can't I really exit the application?
2. It seems that the thread can also complete the service function. Why cannot it replace the service with a thread?

To answer the first question, we should start with the memory management mechanism of Android.
Android memory management is somewhat unusual. Like Java or. net, Android has its own runtime status and Virtual Machine (Dalvik) to manage program memory. However, unlike other frameworks (such as Java, the process of the program starts when the program is opened, and the process ends when the program exits), android also manages the lifecycle of the process. Android will stop or kill low-priority processes to ensure that high-priority processes work normally. In other words, the cleanup of processes is decided by Android. It will kill low-priority processes when the system encounters performance bottlenecks to ensure that the system and high-priority processes can run normally, rather than simply exiting the program, the process of the program also ends. In Android, if the system has enough available memory, the application process will not be destroyed. The effect is that you are re-running the application quickly.
 
Every Android application runs in an independent process and Virtual Machine instance, all application processes are centrally managed by the Android Runtime Environment (stop or kill a process as needed ).
 
We mentioned the concept of process priority. The priority of the Android process is mainly divided into: active process or Foreground process (Foreground), visible process, started Service process (Service), background process, empty process. The foreground process has the highest priority and the blank process has the lowest priority. A detailed explanation of the priority of all processes is provided at the end of this article.
 
Now let's answer the second question: why the background thread started in the application cannot replace the Service.
After an application changes to invisible (for example, all activities exit), it changes from visible process to background process. If the system does not have enough memory to run processes with higher priority, background processes may be destroyed. The threads started in the application are actually derived from the application process. If the application process is destroyed, all its derived threads are also destroyed. We can see from the previous introduction about process priority that the priority of a service process is higher than that of a background process. In fact, Service processes are considered as front-end processes with a high priority. Service processes will not be destroyed unless there is no memory available for front-end processes or visible processes that interact with users.
 
Once our application becomes a background process, when the memory is in a hurry, our application process may be destroyed to release the memory to a process with a higher priority, the derived thread is also destroyed. So it is possible that a background thread that you want to start in the application for a long time disappears inexplicably. However, the Service has a high priority, which generally does not happen.
 
Of course, Service also has other functions, such as inter-process communication, some encapsulated functions, and lifecycle management. That's another topic.
 
Appendix: Process Priority description:
 
Active Processes Active (foreground) processes are those hosting applications with components currently interacting with the user. these are the processes Android is trying to keep responsive by reclaiming resources. there are generally very few of these processes, and they will be killed only as a last resort.

Active processes include:

Activities in an "active" state; that is, they are in the foreground and responding to user events. You will have e Activity states in greater detail later in this chapter.
Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
Services that are executing an onStart, onCreate, or onDestroy event handler.
Visible Processes Visible, but inactive processes are those hosting "visible" Activities. as the name suggests, visible Activities are visible, but they aren't in the foreground or responding to user events. this happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity ). there are generally very few visible processes, and they'll only be killed in extreme circumstances to allow active processes to continue.

Started Service Processes hosting Services that have been started. services support ongoing processing that shoshould continue without a visible interface. because Services don't interact directly with the user, they receive a slightly lower priority than visible Activities. they are still considered to be foreground processes and won't be killed unless resources are needed for active or visible processes.

Background Processes hosting Activities that aren't visible and that don't have any Services that have been started are considered background processes. there will generally be a large number of background processes that Android will kill using a last-seen-first-killed pat-tern to obtain resources for foreground processes.

Empty Processes To improve overall system performance, Android often retains applications in memory after they have reached the end of their lifetimes. android maintains this cache to improve the start-up time of applications when they're-launched. these processes are rou-tinely killed as required.

The author "braised cabbage soup, taste it by yourself ."