Process lifecycle and it types in Android

Hello Guys!!! Hope you all are doing well . Today I am going to discuss Android process and  resource management.  At first we have to understand the Android application process and its type.

The Android system tries to maintain an application process for as long as possible, but eventually needs to remove old processes to reclaim memory for new or more important processes.

To determine which processes to keep and which to kill, the system places each process into an “importance hierarchy” based on the components running in the process and the state of those components.

Processes with the lowest importance are eliminated first, then those with the next lowest importance, and so on, as necessary to recover system resources.

There are five levels in the importance hierarchy.  I am putting here the list presents the different types of processes in order of importance (the first process is most important and is killed last)

1. Foreground process A 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 with.
• 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 continue 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.

2. Visible process: - A 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 is 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.

3. Service process: - A 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 downloading 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.

4. Background process: - A 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 to reclaim memory for a foreground, visible, or service process. Usually there are many 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 have a visible effect on the user experience, because when the user navigates back to the activity, the activity restores all of its visible state.

5. Empty process: - A 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.

Now some working scenario of android process

1. Android ranks a process at the highest level it can, based upon the importance of the components currently active in the process. For example, if a process hosts a service and a visible activity, the process is ranked as a visible process, not a service process.
2. In addition, a process’s ranking might be increased because other processes are dependent on it—a process that is serving another process can never be ranked lower than the process it is serving. For example, if a content provider in process A is serving a client in process B, or if a service in process A is bound to a component in process B, process A is always considered at least as important as process B.
3. A process running a service is ranked higher than a process with background activities, an activity that initiates a long-running operation might do well to start a service for that operation, rather than simply create a worker thread—particularly if the operation will likely outlast the activity. For example, an activity that’s uploading a picture to a web site should start a service to perform the upload so that the upload can continue in the background even if the user leaves the activity. In that case service process has higher priority and it works regardless of its activity process. This is the same reason that broadcast receivers should employ services rather than simply put time-consuming operations in a thread.

Resource management (App Running memory uses) 
1. The Activity Stack
For each application that is running on an Android device, the run time system maintains an Activity Stack. When an application is launched, the first of the application’s activities to be started is placed onto the stack. When a second activity is started, it is placed on the top of the stack and the previous activity is pushed down. The activity at the top of the stack is referred to as the active (or running) activity. When the active activity exits, it is popped off the stack by the run-time and the activity located immediately beneath it in the stack becomes the current active activity.
 The activity at the top of the stack might, for example, simply exit because the task for which it is responsible has been completed. Alternatively, the user may have selected a “Back” button on the screen to return to the previous activity, causing the current activity to be popped off the stack by the run-time system and therefore destroyed. As  per given image

The Activity Stack is what is referred to in programming terminology as a Last-In-First-Out (LIFO) stack in that the last item to be pushed onto the stack is the first to be popped off.

Summary

Mobile devices are typically considered to be resource constrained, particularly in terms of on board memory capacity. Consequently, a prime responsibility of the Android operating system is to ensure that applications, and the operating system in general, remain responsive to the user.

Applications are hosted on Android within processes (essentially instances of the Dalvik virtual machine). Each application, in turn, is made up of components in the form of activities and Services.

The Android run-time system has the power to terminate both processes and individual activities in order to free up memory. Process state is taken into consideration by the run-time system when deciding whether a process is a suitable candidate for termination. The state of a process is, to a large extent, dependent upon the status of the activities hosted by that process.

    Thanks & Happy Coding !!!