# Application Fundamentals--Component Lifecycles（组件生命周期）

[b]Component Lifecycles--组件生命周期[/b]

Application components have a lifecycle — a beginning when Android instantiates them to respond to intents through to an end when the instances are destroyed. In between, they may sometimes be active or inactive,or, in the case of activities, visible to the user or invisible. This section discusses the lifecycles of activities, services, and broadcast receivers — including the states that they can be in during their lifetimes, the methods that notify you of transitions between states, and the effect of those states on the possibility that the process hosting them might be terminated and the instances destroyed.

Activity lifecycle--Activity组件的生命周期

An activity has essentially three states:翻译：Activity组件有三种状态

* It is active or running when it is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user's actions.【翻译：活动状态或称之为运行状态，这时候Activity实例的界面显示在当前屏幕上，此时这个Activity实例在当前task堆栈中处于栈顶位置。】
*

It is paused if it has lost focus but is still visible to the user. That is, another activity lies on top of it and that activity either is transparent or doesn't cover the full screen, so some of the paused activity can show through. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.【翻译：暂停状态，暂停状态的Activity实例失去了用户焦点，但是依然是用户可见状态,此时堆栈中已有了另一个Activity实例处于这个实例的上面，但是新的实例的用户界面还没有占据当前屏幕，暂停状态的 Activity依然持有所有自身状态信息并且与窗体管理对象依然保持关联，但是如果说系统出现内存极端不足的话，系统是可以销毁该实例的。】
*

It is stopped if it is completely obscured by another activity. It still retains all state and member information. However, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.【翻译：停止状态，停止状态的activity实例的用户界面已经完全被另外一个实例的界面所掩盖，但它依然持有所有的状态信息，不过，对于用户来说已经是不可见的了。如果说系统出现内存不足的话，系统是可以销毁该实例的。】

If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.

As an activity transitions from state to state, it is notified of the change by calls to the following protected methods（翻译：activity的状态发生变化的时候，以下方法(七个)将被系统调用：）:

void onCreate(Bundle savedInstanceState)void onStart()void onRestart()void onResume()void onPause()void onStop()void onDestroy()

All of these methods are hooks that you can override to do appropriate work when the state changes. All activities must implement onCreate() to do the initial setup when the object is first instantiated. Many will also implement onPause() to commit data changes and otherwise prepare to stop interacting with the user.

[b]Calling into the superclass[/b]

An implementation of any activity lifecycle method should always first call the superclass version. For example:【翻译：实现activity的任何生命周期方法的时候都必须首先调用父类的方法，例如：】

protected void onPause() {    super.onPause();    . . .}

Taken together, these seven methods define the entire lifecycle of an activity. There are three nested loops that you can monitor by implementing them:

* The entire lifetime of an activity happens between the first call to onCreate() through to a single final call to onDestroy(). An activity does all its initial setup of "global" state in onCreate(), and releases all remaining resources in onDestroy(). For example, if it has a thread running in the background to download data from the network, it may create that thread in onCreate() and then stop the thread in onDestroy().

*

The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop(). During this time, the user can see the activity on-screen, though it may not be in the foreground and interacting with the user. Between these two methods, you can maintain resources that are needed to show the activity to the user. For example, you can register a BroadcastReceiver in onStart() to monitor for changes that impact your UI, and unregister it in onStop() when the user can no longer see what you are displaying. The onStart() and onStop() methods can be called multiple times, as the activity alternates between being visible and hidden to the user.

*

The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time, the activity is in front of all other activities on screen and is interacting with the user. An activity can frequently transition between the resumed and paused states — for example, onPause() is called when the device goes to sleep or when a new activity is started, onResume() is called when an activity result or a new intent is delivered. Therefore, the code in these two methods should be fairly lightweight.

The following diagram illustrates these loops and the paths an activity may take between states. The colored ovals are major states the activity can be in. The square rectangles represent the callback methods you can implement to perform operations when the activity transitions between states.【翻译：下图显示了activity生命周期中的状态变换过程，带颜色的椭圆形表示activity状态，方框是发生状态变化时的回调方法。】

Note the Killable column in the table above. It 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 (onPause(), onStop(), and onDestroy()) are marked "Yes." Because onPause() is the first of the three, it's the only one that's guaranteed to be called before the process is killed — onStop() and onDestroy() may not be. Therefore, you should use onPause() to write any persistent data (such as user edits) to storage.

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 in a killable state, for example, from the time onPause() returns to the time onResume() is called. It will not again be killable until onPause() again returns.

As noted in a later section, Processes and lifecycle, an activity that's not technically "killable" by this definition might still be killed by the system — but that would happen only in extreme and dire circumstances when there is no other recourse.

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客