Andriod生命周期

Managing the Activity Lifecycle

Managing the lifecycle of your activities by implementing callback methods is crucial to developing a strong and flexible application. The lifecycle of an activity is directly affected by its association with other activities, its task and back stack.

An activity can exist in essentially three states:

Resumed

The activity is in the foreground of the screen and has user focus. (This state is also sometimes referred to as "running".)

Paused

Another activity is in the foreground and has focus, but this one is still visible. That is, another activity is visible on top of this one and that activity is partially transparent or doesn't cover the entire screen. A paused activity is completely alive (the

object is retained in memory, it maintains all state and member information, and remains attached to the window manager), but can be killed by the system in extremely low memory situations.

Stopped

The activity is completely obscured by another activity (the activity is now in the "background"). A stopped activity is also still alive (the

object is retained in memory, it maintains all state and member information, but is

notattached to the window manager). However, it is no longer visible to the user and it can be killed by the system when memory is needed elsewhere.

If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its method), or simply killing its process.  When the activity is opened again (after being finished or killed), it must be created all over.

Implementing the lifecycle callbacks

When an activity transitions into and out of the different states described above, it is notified through various callback methods. All of the callback methods are hooks that you can override to do appropriate work when the state of your activity changes. The following skeleton activity includes each of the fundamental lifecycle methods:

public class ExampleActivity extends Activity {
   @Override public void (Bundle savedInstanceState) {
   super.onCreate(savedInstanceState); // The activity is being created. } @Override protected void  {
   super.onStart(); // The activity is about to become visible. } @Override protected void  {
   super.onResume(); // The activity has become visible (it is now "resumed"). } @Override protected void  {
   super.onPause(); // Another activity is taking focus (this activity is about to be "paused"). } @Override protected void  {
   super.onStop(); // The activity is no longer visible (it is now "stopped") } @Override protected void  {
   super.onDestroy(); // The activity is about to be destroyed. } }

Note: Your implementation of these lifecycle methods must always call the superclass implementation before doing any work, as shown in the examples above.

Taken together, these methods define the entire lifecycle of an activity. By implementing these methods, you can monitor three nested loops in the activity lifecycle:

• The entire lifetime of an activity happens between the call to and the call to . Your activity should perform setup of "global" state (such as defining layout) in , and release all remaining resources in . For example, if your activity has a thread running in the background to download data from the network, it might create that thread in and then stop the thread in .

• The visible lifetime of an activity happens between the call to and the call to . During this time, the user can see the activity on-screen and interact with it. For example, is called when a new activity starts and this one is no longer visible. Between these two methods, you can maintain resources that are needed to show the activity to the user. For example, you can register a in to monitor changes that impact your UI, and unregister it in when the user can no longer see what you are displaying. The system might call and multiple times during the entire lifetime of the activity, as the activity alternates between being visible and hidden to the user.

• The foreground lifetime of an activity happens between the call to and the call to . During this time, the activity is in front of all other activities on screen and has user input focus.  An activity can frequently transition in and out of the foreground—for example, is called when the device goes to sleep or when a dialog appears. Because this state can transition often, the code in these two methods should be fairly lightweight in order to avoid slow transitions that make the user wait.

Figure 1 illustrates these loops and the paths an activity might take between states. The rectangles represent the callback methods you can implement to perform operations when the activity transitions between states.

 

Figure 1. The activity lifecycle.

The same lifecycle callback methods are listed in table 1, which describes each of the callback methods in more detail and locates each one within the activity's overall lifecycle, including whether the system can kill the activity after the callback method completes.

Table 1. A summary of the activity lifecycle's callback methods.

Method			Description	Killable after?	Next
			Called when the activity is first created.      This is where you should do all of your normal static set up —      create views, bind data to lists, and so on.  This method is passed      a Bundle object containing the activity's previous state, if that      state was captured (see ,      later).      Always followed by onStart().	No	onStart()
			Called after the activity has been stopped, just prior to it being       started again.       Always followed by onStart()	No	onStart()
			Called just before the activity becomes visible to the user.       Followed by onResume() if the activity comes       to the foreground, or onStop() if it becomes hidden.	No	onResume() or onStop()
			Called just before the activity starts       interacting with the user.  At this point the activity is at       the top of the activity stack, with user input going to it.       Always followed by onPause().	No	onPause()
			Called when the system is about to start resuming another       activity.  This method is typically used to commit unsaved changes to       persistent data, stop animations and other things that may be consuming       CPU, and so on.  It should do whatever it does very quickly, because       the next activity will not be resumed until it returns.       Followed either by onResume() if the activity       returns back to the front, or by onStop() if it becomes       invisible to the user.	Yes	onResume() or onStop()
			Called when the activity is no longer visible to the user.  This       may happen because it is being destroyed, or because another activity       (either an existing one or a new one) has been resumed and is covering it.       Followed either by onRestart() if       the activity is coming back to interact with the user, or by       onDestroy() if this activity is going away.	Yes	onRestart() or onDestroy()
			Called before the activity is destroyed.  This is the final call       that the activity will receive.  It could be called either because the       activity is finishing (someone called on it), or because the system is temporarily destroying this       instance of the activity to save space.  You can distinguish       between these two scenarios with the method.	Yes	nothing

The column labeled "Killable after?" indicates whether or not the system can kill the process hosting the activity at any time after the method returns, without executing another line of the activity's code.  Three methods are marked "yes": (, , and ). Because is the first of the three, once the activity is created, is the last method that's guaranteed to be called before the process can be killed—if the system must recover memory in an emergency, then and might not be called. Therefore, you should use to write crucial persistent data (such as user edits) to storage. However, you should be selective about what information must be retained during , because any blocking procedures in this method block the transition to the next activity and slow the user experience.

Methods that are marked "No" in the Killable column protect the process hosting the activity from being killed from the moment they are called.  Thus, an activity is killable from the time returns to the time is called. It will not again be killable until is again called and returns.

Note: An activity that's not technically "killable" by this definition in table 1 might still be killed by the system—but that would happen only in extreme circumstances when there is no other recourse. When an activity might be killed is discussed more in the document.