Android重要概念3—App进程的生命周期

Process Lifecycle

The Android system attempts to keep application process around for as long as possible, but eventually will need to remove old processes when memory runs low.  As described in Activity Lifecycle, the decision about which process to remove is intimately tied to the state of the user's interaction with it.  In general, there are four states a process can be in based on the activities running in it, listed here in order of importance.  The system will kill less important processes (the last ones) before it resorts to killing more important processes (the first ones). 

1. The foreground activity (the activity at the top of the screen that the user is currently interacting with) is considered the most important. Its process will only be killed as a last resort, if it uses more memory than is available on the device.  Generally at this point the device has reached a memory paging state, so this is required in order to keep the user interface responsive.

2. A visible activity (an activity that is visible to the user but not in the foreground, such as one sitting behind a foreground dialog) is considered extremely important and will not be killed unless that is required to keep the foreground activity running.

3. A background activity (an activity that is not visible to the user and has been paused) is no longer critical, so the system may safely kill its process to reclaim memory for other foreground or visible processes.  If its process needs to be killed, when the user navigates back to the activity (making it visible on the screen again), its onCreate(Bundle) method will be called with the savedInstanceState it had previously supplied in onSaveInstanceState(Bundle) so that it can restart itself in the same state as the user last left it.

4. An empty process is one hosting no activities or other application components (such as Service or BroadcastReceiver classes).  These are killed very quickly by the system as memory becomes low.  For this reason, any background operation you do outside of an activity must be executed in the context of an activity BroadcastReceiver or Service to ensure that the system knows it needs to keep your process around.

Sometimes an Activity may need to do a long-running operation that exists independently of the activity lifecycle itself.  An example may be a camera application that allows you to upload a picture to a web site.  The upload may take a long time, and the application should allow the user to leave the application will it is executing.  To accomplish this, your Activity should start a Service in which the upload takes place.  This allows the system to properly prioritize your process (considering it to be more important than other non-visible applications) for the duration of the upload, independent of whether the original activity is paused, stopped, or finished.