Android Process Discription
Anddroid Process:
When an application component starts and the application
does not have any other components running, the Android system starts a new
Linux process for the application with a single thread of execution.
The manifest entry for each type of component element—
,
,
, and
—supports an android:process
attribute
that can specify a process in which that component should run.Process lifecycle
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. rocesses with the
lowest importance are eliminated first, then those with the next lowest
importance, and so on
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:
o It hosts an Activity that the user is interacting with (the Activity's onResume() method has been called).
o It hosts a Service that's bound to the activity that the
user is interacting with.
o It hosts a Service that's running "in the
foreground"—the service has called startForeground().
o It hosts a Service that's executing one of its lifecycle
callbacks (onCreate(), onStart(), oronDestroy()).
o 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 are true:
o 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.
o 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. See the Activities document
for information about saving and restoring 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
No comments:
Post a Comment