Activity and Service recycling

Activity and Service recycling
In Android development, an Application runs in a process. The various components of this Application (four components) are usually run in the same process. However, it is not absolute. For example, you can set Activity_A, a component of AppA, to run in another process (ProcessB) and implement it by setting the property android: process of Activity_A. In addition, you can also implement multiple Application components to run in the same process. For example, AppA components ContentProviderA, AppB components Service, and AppC component Activity_C can be set to processTogether in an independent process. you only need to set the same Linux User ID (android: sharedUsereId ). This is about the relationship between processes and components. This information is related to the subsequent resource recovery. When the system memory is insufficient, the system will kill some processes based on the priority of the process. Processes with lower priority will be Kill first. When a process is kill, components running in the process will also be destroyed. The priority of a process is determined by the status of components running in the process. Process Priority. Type Definition: Foreground processA process that is required for what the user is currently doing. A process is considered to be in the foreground if any of the following conditions are true: It hosts an Activity that the user is interacting with (the Activity's onResume () method has been called ). it hosts a Service that's bound to the activity that the user is interacting. it hosts a Service that 'S running "in the foreground"-the service has called startForeground (). it hosts a Service that's executing one of its lifecycle callbacks (onCreate (), onStart (), or onDestroy ()). it hosts a BroadcastReceiver that's executing its onReceive () method. generally, only a few foreground processes exist at any given time. they are killed only as a last resort-if memory is so low that they cannot all conti Nue to run. generally, at that point, the device has reached a memory paging state, so killing some foreground processes is required to keep the user interface responsive. visible processA process that doesn't have any foreground components, but still can affect what the user sees on screen. A process is considered to be visible if either of the following conditions are true: It hosts an Activity That is not in the foreground, but is still visible to the user (its onPause () method has been called ). this might occur, for example, if the foreground activity started a dialog, which allows the previous activity to be seen behind it. it hosts a Service that's bound to a visible (or foreground) activity. A visible process is considered extremely important and will not be killed unless doing so is Required to keep all foreground processes running. service processA process that is running a service that has been started with the startService () method and does not fall into either of the two higher categories. although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing music in the background or downloa Ding data on the network), so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes. background processA process holding an activity that's not currently visible to the user (the activity's onStop () method has been called ). these processes have no direct impact on the user experience, and the system can kill them at any time t O reclaim memory for a foreground, visible, or service process. usually there are running background processes running, so they are kept in an LRU (least recently used) list to ensure that the process with the activity that was most recently seen by the user is the last to be killed. if an activity implements its lifecycle methods correctly, and saves its current state, killing its process will not h Ave a visible effect on the user experience, because when the user navigates back to the activity, the activity restores all of its visible state. see the Activities document for information about saving and restoring state. empty processA process that doesn't hold any active application components. the only reason to keep this kind of process alive is for caching purposes, to improve startup time The next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.] five types of processes. The information related to the actual work is as follows: 1. The Service will be destroyed; it will be destroyed like the Activity. Therefore, when the system calls the onDestroy method, it needs to save the data if you want to make the operated data persistent. 2. if you want to increase the priority of a Service and do not want its process to be killed in advance, when the system resources are insufficient, it is a method to set the process type of the Service to Forground process. In other words, call the startForground () method in the Service. (The Android system tries its best to evaluate the priority of a process to a higher priority. For example, if the components in the process have the features defined by Froground process, this Process will be evaluated as Froground Process) 3. in other aspects, the above information can guide the actual work. In terms of data persistence, since Activity and Service are destroyed, you must consider how to save the completed work if the work is not completed, that is, to save the relevant data. For the Service, the logic for saving data is added in the onDestroy method. For example, start a thread to write data to the database; or directly use the writeObject method to save the object data; or, write the data to the file system. For the Service, if you want to restore the previous operation when you start the Service again, read the previously saved data from the saved region and then continue. For Activity, the system provides multiple callback methods, such as: Assume that Activity_A runs in AppA and Activity_ B runs in AppB. 1. When Activity_A on the current screen is replaced by another Activity_ B, the system calls back the onSaveInstanceState () method that replaces the Activity. In this method, the user-implemented operation data is saved. 2. Because Activity_A is invisible, the AppA running process also has a low priority. When the system memory is insufficient, AppA is killed by the system. 3. the user starts AppA again. Because Activity_A implements the onSaveInstanceState () method, the system calls back when Activity_A is invisible, that is, the Activity_A state is saved. Then, when Activity_A is re-created, the state parameter of the onCreate method will not be empty. The system has saved the State for you when you implement the onSaveInstanceState () method. Therefore, it is better for the system to treat the Activity than to treat the Service. The system saves a state for the Activity, but the Service does not. In Service, you need to write data to a database or file system.