Unlike many traditional application platforms, Android applications have limited control over their own lifecycles. Instead, application components must listen for changes in the application state and react accordingly, taking particular care to be prepared for untimely termination
By default, each Android application runs in its own process, each of which is running a separate instance of Dalvik. Memory and process management is handled exclusively by the run time
Android aggressively manages its resources, doing whatever’s necessary to ensure a smooth and stable user experience. In practice that means that processes (and their hosted applications) will be killed, in some case without warning, to free resources for higher-priority applications.
You can force application components within the same application to run in different processes or to have multiple applications share the same process using the android:process attribute on the affected component nodes within the manifest.
Understanding An Application’S Priority And Its Process’ States
The order in which processes are killed to reclaim resources is determined by the priority of their hosted applications. An application’s priority is equal to that of its highest-priority component
If two applications have the same priority, the process that has been at that priority longest will be killed first. Process priority is also affected by interprocess dependencies; if an application has a dependency on a Service or Content Provider supplied by a second application, the secondary application has at least as high a priority as the application it supports
All Android applications continue running and in memory until the system needs resources for other applications.
Figure 3-4 shows the priority tree used to determine the order of application termination.
The following list details each of the application states shown in Figure 3-4, explaining how the state is determined by the application components of which it comprises:
- Active processes — Active (foreground) processes have application components the user is interacting with. These are the processes Android tries to keep responsive by reclaiming resources from other applications. There are generally very few of these processes, and they will be killed only as a last resort.
- Active processes include the following:
- Activities in an active state — that is, those in the foreground responding to user events.
- Broadcast Receivers executing onReceive event handlers
- Services executing onStart, onCreate, or onDestroy event handlers
- Running Services that have been fl agged to run in the foreground
- Active processes include the following:
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 be killed only under extreme circumstances to allow active processes to continue
Started Service processes — Processes hosting Services that have been started. Because these Services don’t interact directly with the user, they receive a slightly lower priority than visible Activities or foreground Services. Applications with running Services are still considered foreground processes and won’t be killed unless resources are needed for active or visible processes. When the system terminates a running Service it will attempt to restart them (unless you specify that it shouldn’t) when resources become available
Background processes — Processes hosting Activities that aren’t visible and that don’t have any running Services. There will generally be a large number of background processes that Android will kill using a last-seen-first-killed pattern in order to obtain resources for foreground processes
Empty processes — To improve overall system performance, Android will often retain an application in memory after it has reached the end of its lifetime. Android maintains this cache to improve the start-up time of applications when they’re relaunched. These processes are routinely killed, as required.