应用程序基础(Application Fundamentals)
从很多方面来看，每个Android应用程序都存在于它自己的世界之中：
* 默认情况下，每个应用程序均运行于它自己的Linux进程中。当应用程序中的任意代码开始执行时，Android启动一个进程，而当不再需要此进程而其它应用程序又需要系统资源时，则关闭这个进程。
* 每个进程都运行于自己的Java虚拟机（VM）中。所以应用程序代码实际上与其它应用程序的代码是隔绝的。
* 默认情况下，每个应用程序均被赋予一个唯一的Linux用户ID，并加以权限设置，使得应用程序的文件仅对这个用户、这个应用程序可见。当然，也有其它的方法使得这些文件同样能为别的应用程序所访问。
使两个应用程序共有同一个用户ID是可行的，这种情况下他们可以看到彼此的文件。从系统资源维护的角度来看，拥有同一个ID的应用程序也将在运行时使用同一个Linux进程，以及同一个虚拟机。
应用程序组件(Application Components)
Android的核心功能之一就是一个应用程序可以使用其它应用程序的元素（如果那个应用程序允许的话）。比如说，如果你的应用程序需要一个图片卷动列 表，而另一个应用程序已经开发了一个合用的而又允许别人使用的话，你可以直接调用那个卷动列表来完成工作，而不用自己再开发一个。你的应用程序并没有吸纳 或链接其它应用程序的代码，它只是在有需求的时候启动了其它应用程序的那个功能部分。
为达到这个目的，系统必须在一个应用程序的一部分被需要时启动这个应用程序，并将那个部分的Java对象实例化。与在其它系统上的应用程序不同，Android应用程序没有为应用准备一个单独的程序入口（比如说，没有<code>main()</code>方法）， 而是为系统依照需求实例化提供了基本的组件。共有四种组件类型：
Activities
* 一个应用程序可以只有一个activity，或者，如刚才提到的短信应用程序那样，包含很多个。每个activity的作用，以及其数目，自然取决于应用 程序及其设计。一般情况下，总有一个应用程序被标记为用户在应用程序启动的时候第一个看到的。从一个activity转向另一个的方式是靠当前的 activity启动下一个。
* 每个activity都被给予一个默认的窗口以进行绘制。一般情况下，这个窗口是满屏的，但它也可以是一个小的位于其它窗口之上的浮动窗口。一个 activity也可以使用超过一个的窗口──比如，在activity运行过程中弹出的一个供用户反应的小对话框，或是当用户选择了屏幕上特定项目后显 示的必要信息。
服务(Services)
* 一个媒体播放器播放播放列表中的曲目是一个不错的例子。播放器应用程序可能有一个或多个activity来给用户选择歌曲并进行播放。然而，音乐播放这个 任务本身不应该为任何activity所处理，因为用户期望在他们离开播放器应用程序而开始做别的事情时，音乐仍在继续播放。为达到这个目的，媒体播放器 activity应该启用一个运行于后台的服务。而系统将在这个activity不再显示于屏幕之后，仍维持音乐播放服务的运行。
* 你可以连接至（绑定）一个正在运行的服务（如果服务没有运行，则启动之）。连接之后，你可以通过那个服务暴露出来的接口与服务进行通讯。对于音乐服务来说，这个接口可以允许用户暂停、回退、停止以及重新开始播放。
广播接收器(Broadcast receivers)
* 广播接收器是一个专注于接收广播通知信息，并做出对应处理的组件。很多广播是源自于系统代码的──比如，通知时区改变、电池电量低、拍摄了一张照片或者用户改变了语言选项。应用程序也可以进行广播──比如说，通知其它应用程序一些数据下载完成并处于可用状态。
内容提供者(Content providers)
每当出现一个需要被特定组件处理的请求时，Android会确保那个组件的应用程序进程处于运行状态，或在必要的时候启动它。并确保那个相应组件的实例的存在，必要时会创建那个实例。
激活组件Activating components: intents
对于每种组件来说，激活的方法是不同的：
关闭组件(Shutting down components)
内容提供者仅在响应ContentResolver提出请求的时候激活。而一个广播接收器仅在响应广播信息的时候激活。所以，没有必要去显式的关闭这些组件。
而activity则不同，它提供了用户界面，并与用户进行会话。所以只要会话依然持续，哪怕对话过程暂时停顿，它都会一直保持激活状态。与此相似，服务也会在很长一段时间内保持运行。所以Android为关闭activity和服务提供了一系列的方法。
manifest文件(The manifest file)
当Android启动一个应用程序组件之前，它必须知道那个组件是存在的。所以，应用程序会在一个manifest文件中声明它的组件，这个文件会被打包到Android包中。这个.apk文件还将涵括应用程序的代码、文件以及其它资源。
这个manifest文件以XML作为结构格式，而且对于所有应用程序，都叫做AndroidManifest.xml。为声明一个应用程序组件，它还会 做很多额外工作，比如指明应用程序所需链接到的库的名称（除了默认的Android库之外）以及声明应用程序期望获得的各种权限。
但manifest文件的主要功能仍然是向Android声明应用程序的组件。举例说明，一个activity可以如下声明：
Intent过滤器(Intent filters)
Intent对象可以被显式的指定目标组件。如果进行了这种指定，Android会找到这个组件（依据manifest文件中的声明）并激活它。但如果 Intent没有进行显式的指定，Android就必须为它找到对于intent来说最合适的组件。这个过程是通过比较Intent对象和所有可能对象的intent过滤器完成的。组件的intent过滤器会告知Android它所能处理的intent类型。如同其它相对于组件很重要的信息一样，这些是在manifest文件中进行声明的。这里是上面实例的一个扩展，其中加入了针对activity的两个intent过滤器声明：
示例中的第一个过滤器──action “android.intent.action.MAIN”和类别“android.intent.category.LAUNCHER”的组合──是通常具有的。它标明了这个activity将在应用程序加载器中显示，就是用户在设备上看到的可供加载的应用程序列表。换句话说，这个activity是应用程序的入口，是用户选择运行这个应用程序后所见到的第一个activity。
第二个过滤器声明了这个activity能被赋予一种特定类型的数据。
组件可以拥有任意数量的intent过滤器，每个都会声明一系列不同的能力。如果它没有包含任何过滤器，它将只能被显式声明了目标组件名称的intent激活。
Activity和任务(Activities and Tasks)
如前所述，一个activity可以启动另外一个，甚至包括与它不处于同一应用程序之中的。举个例子说，假设你想让用户看到某个地方的街道地图。而已经存 在一个具有此功能的activity了，那么你的activity所需要做的工作就是把请求信息放到一个Intent对象里面，并把它传递给startActivity()。于是地图浏览器就会显示那个地图。而当用户按下BACK键的时候，你的activity又会再一次的显示在屏幕上。
对于用户来说，这看起来就像是地图浏览器是你activity所在的应用程序中的一个组成部分，其实它是在另外一个应用程序中定义，并运行在那个应用程序的进程之中的。Android将这两个activity放在同一个任务中 来维持一个完整的用户体验。简单的说，任务就是用户所体验到的“应用程序”。它是安排在一个堆栈中的一组相关的activity。堆栈中的根 activity就是启动了这整个任务的那个──一般情况下，它就是用户在应用程序加载器中所选择的。而堆栈最上方的activity则是当前运行的── 用户直接对其进行操作的。当一个activity启动另外一个的时候，新的activity就被压入堆栈，并成为当前运行的activity。而前一个 activity仍保持在堆栈之中。当用户按下BACK键的时候，当前activity出栈，而前一个恢复为当前运行的activity。
堆栈中保存的其实是对象，所以如果发生了诸如需要多个地图浏览器的情况，就会使得一个任务中出现多个同一Activity子类的实例同时存在，堆栈会为每个实例单独开辟一个入口。堆栈中的Activity永远不会重排，只会压入或弹出。
任务其实就是activity的堆栈，而不是manifest文件中的一个类或者元素。所以你无法撇开activity而为一个任务设置一个值。而事实上 整个任务使用的值是在根activity中设置的。比如说，下一节我们会谈及“任务的affinity”，从affinity中读出的值将会设置到任务的 根activity之中。
任务中的所有activity是作为一个整体进行移动的。整个的任务（即activity堆栈）可以移到前台，或退至后台。举个例子说，比如当前任务在堆 栈中存有四个activity──三个在当前activity之下。当用户按下HOME键的时候，回到了应用程序加载器，然后选择了一个新的应用程序（也 就是一个新任务）。则当前任务遁入后台，而新任务的根activity显示出来。然后，过了一小会儿，用户再次回到了应用程序加载器而又选择了前一个应用程序（上一个任务）。于是那个任务，带着它堆栈中所有的四个activity，再一次的到了前台。当用户按下BACK键的时候，屏幕不会显示出用户刚才离开的activity（上一个任务的根activity）。取而代之，当前任务的堆栈中最上面的activity被弹出，而同一任务中的上一个activity显示了出来。
我们刚才所说的这些关键Intent标记如下：
FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
FLAG_ACTIVITY_SINGLE_TOP
而关键的<activity>属性是：
taskAffinity
launchMode
allowTaskReparenting
clearTaskOnLaunch
alwaysRetainTaskState
finishOnTaskLaunch
接下来的一节会描述这些标记以及属性的作用，它们是如何互相影响的，以及控制它们的使用时必须考虑到的因素。
任务共用性和新任务Affinities and new tasks
默认情况下，一个应用程序中的activity相互之间会有一种Affinity──也就是说，它们首选都归属于一个任务。然而，可以在<code><</code>activity<code>></code><code>元素中把每个</code>activity<code>的</code>taskAffinity属 性设置为一个独立的affinity。于是在不同的应用程序中定义的activity可以享有同一个affinity，或者在同一个应用程序中定义的 activity有着不同的affinity。affinity在两种情况下生效：当加载activity的Intent对象包含了FLAG_ACTIVITY_NEW_TASK 标记，或者当activity的allowTaskReparenting属性设置为“true”。
如前所述，在默认情况下，一个新activity被另外一个调用了startActivity()方法的activity载入了任务之中。并压入了调用者所在的堆栈。然而，如果传递给startActivity()的Intent对象包含了FLAG_ACTIVITY_NEW_TASK标记，系统会为新activity安排另外一个任务。一般情况下，如同标记所暗示的那样，这会是一个新任务。然而，这并不是必然的。如果已经存在了一个与新activity有着同样affinity的任务，则activity会载入那个任务之中。如果没有，则启用新任务。
如果一个activity将allowTaskReparenting属 性设置为“true”。它就可以从初始的任务中转移到与其拥有同一个affinity并转向前台的任务之中。比如说，一个旅行应用程序中包含的预报所选城 市的天气情况的activity。它与这个应用程序中其它的activity拥有同样的affinity（默认的affinity）而且允许重定父级。你 的另一个activity启动了天气预报，于是它就会与这个activity共处与同一任务之中。然而，当那个旅行应用程序再次回到前台的时候，这个天气 预报activity就会被再次安排到原先的任务之中并显示出来。
如果在用户的角度看来，一个.apk文件中包含了多于一个的“应用程序”，你可能会想要为它们所辖的activity安排不一样的affinity。
加载模式(Launch modes)
"standard" (默认模式)
"singleTop"
"singleTask"
"singleInstance"
这些模式之间的差异主要体现在四个方面：
相反，对“<code>singleTask</code>”和“<code>singleInstance</code>”模式而言，activity总是位于任务的根部。正是它们定义了一个任务，所以它们绝不会被载入到其它任务之中。
* activity是否可以存在多个实例。一个“standard”或“singleTop”的activity可以被多次初始化。它们可以归属于多个任务，而一个任务也可以拥有同一activity的多个实例。
相反，对“singleTask”和“singleInstance”的activity被限定于只能有一个实例。因为这些activity都是任务的起源，这种限制意味着在一个设备中同一时间只允许存在一个任务的实例。
* 在实例所在的任务中是否会有别的activity。一个“singleInstance”模式的activity将会是它所在的任务中唯一的activity。如果它启动了别的activity，那个activity将会依据它自己的加载模式加载到其它的任务中去──如同在intent中设置了FLAG_ACTIVITY_NEW_TASK 标记一样的效果。在其它方面，“singleInstance”模式的效果与“singleTask”是一样的。
剩下的三种模式允许一个任务中出现多个activity。“singleTask”模式的activity将是任务的根activity，但它可以启动别的activity并将它们置入所在的任务中。“standard”和“singleTop”activity则可以在堆栈的任意位置出现。
* 是否要载入新的类实例以处理新的intent。对默认的"standard"模式来说，对于每个新intent都会创建一个新的实例以进行响应，每个实例仅处理一个intent。“singleTop”模式下，如果activity位于目的任务堆栈的最上面，则重用目前现存的activity来处理新的intent。如果它不是在堆栈顶部，则不会发生重用。而是创建一个新实例来处理新的intent并将其推入堆栈。
举例来说，假设一个任务的堆栈由根activityA和activity B、C和位于堆栈顶部的D组成，即堆栈A-B-C-D。一个针对D类型的activity的intent抵达的时候，如果D是默认的“standard”加载模式，则创建并加载一个新的类实例，于是堆栈变为A-B-C-D-D。 然而，如果D的载入模式为“singleTop”，则现有的实例会对新intent进行处理（因为它位于堆栈顶部）而堆栈保持A-B-C-D的形态。
换言之，如果新抵达的intent是针对B类型的activity，则无论B的模式是“standard”还是“singleTop” ，都会加载一个新的B的实例（因为B不位于堆栈的顶部），而堆栈的顺序变为A-B-C-D-B。
如前所述，“singleTask”或“singleInstance”模式的activity永远不会存在多于一个实例。所以实例将处理所有新的intent。一个“singleInstance”模式的activity永远保持在堆栈的顶部（因为它是那个堆栈中唯一的一个activity），所以它一直坚守在处理intent的岗位上。然而，对一个“singleTask”模式的activity来说，它上面可能有，也可能没有别的activity和它处于同一堆栈。<code>在有的情况下，它就不在能够处理</code>intent<code>的位置上，</code>则那个intent将被舍弃。（即便在intent被舍弃的情况下，它的抵达仍将使这个任务切换至前台，并一直保留）
请注意，当一个新的activity实例被创建以处理新的intent的时候，用户总可以按下BACK键来回到前面的状态（回到前一个 activity）。但当使用现存的activity来处理新intent的时候，用户是不能靠按下BACK键回到当这个新intent抵达之前的状态 的。
清理堆栈(Clearing the stack)
如果用户离开一个任务很长一段时间，系统会清理该任务中除了根activity之外的所有activity。当用户再次回到这个任务的时候，除了只剩下初 始化activity尚存之外，其余都跟用户上次离开它的时候一样。这样做的原因是：在一段时间之后，用户再次回到一个任务的时候，他们更期望放弃他们之 前的所作所为，做些新的事情。
这些属于默认行为，另外，也存在一些activity的属性用以控制并改变这些行为：
如果一个任务的根activity中此属性设置为“true”，则上述默认行为不会发生。任务将在很长的一段时间内保留它堆栈内的所有activity。
如果一个任务的根activity中此属性设置为“true”，则每当用户离开这个任务和返回它的时候，堆栈都会被清空至只留下rootactivity。换句话说，这是alwaysRetainTaskState的另一个极端。哪怕仅是过了一小会儿，用户回到任务时，也是见到它的初始状态。
这个属性与clearTaskOnLaunch属性相似，但它仅作用于单个的activity，而不是整个的task。而且它可以使任意activity都被清理，甚至根activity也不例外。当它设置为“true”的时候，此activity仅做为任务的一部分存在于当前回话中，一旦用户离开并再次回到这个任务，此activity将不复存在。
FLAG_ACTIVITY_CLEAR_TOP与FLAG_ACTIVITY_NEW_TASK经常合并使用。这时，这些标记提供了一种定位其它任务中现存的activity并将它们置于可以对intent做出响应的位置的方法。
启动任务(Starting tasks)
第二个能力相当重要：用户必须可以离开一个任务，并在一段时间后返回它。出于这个考虑，加载模式被设定为“singleTask”和“singleInstance”的activity总是会初始化一个新任务，这样的activity仅能用于指定了一个MAIN和LAUNCHER过滤器的情况之下。我们来举例说明如果没指定过滤器的情况下会发生的事情：一个intent加载了一个“singleTask”的activity，初始化了一个新任务，用户在这个任务中花费了一些时间来完成工作。然后用户按下了HOME键。于是任务被要求转至后台并被主屏幕所掩盖。因为它并没有在应用程序加载器中显示图标，这将导致用户无法再返回它。
类似的困境也可由FLAG_ACTIVITY_NEW_TASK标记引起。如果此标记使一个activity启动了一个新任务继而用户按下了HOME键离开了它，则用户必须要有一些方法再次回到这个任务。一些实体（诸如通知管理器）总是在另外的任务中启动新activity，而不是做为它们自己的一部分，所以它们总是将FLAG_ACTIVITY_NEW_TASK标记包含在intent里面并传递给startActivity()。如果你写了一个能被外部实体使用这个标记调用的activity，你必须注意要给用户留一个返回这个被外部实体启动的任务的方法。
进程和线程(Processes and Threads)
当一个应用程序开始运行它的第一个组件时，Android会为它启动一个Linux进程，并在其中执行一个单一的线程。默认情况下，应用程序所有的组件均在这个进程的这个线程中运行。
然而，你也可以安排组件在其他进程中运行，而且可以为任意进程衍生出其它线程。
进程(Processes)
组件运行所在的进程由manifest文件所控制。组件元素<code>——<</code>activity<code>></code>， <code><</code>service<code>></code>， <code><</code>receiver<code>></code>和<code><</code>provider<code>></code>——都有一个 process 属性来指定组件应当运行于哪个进程之内。这些属性可以设置为使每个组件运行于它自己的进程之内，或一些组件共享一个进程而其余的组件不这么做。它们也可以 设置为令不同应用程序的组件在一个进程中运行——使应用程序的组成部分共享同一个Linux用户ID并赋以同样的权限。<code><</code>application<code>></code>元素也有一个process属性，以设定所有组件的默认值。
在可用内存不足而又有一个正在为用户进行服务的进程需要更多内存的时候，Android有时候可能会关闭一个进程。而在这个进程中运行着的应用程序也因此被销毁。当再次出现需要它们进行处理的工作的时候，会为这些组件重新创建进程。
线程(Threads)
尽管你可以把你的应用程序限制于一个单独的进程中，有时，你仍然需要衍生出一个线程以处理后台任务。因为用户界面必须非常及时的对用户操作做出响应，所 以，控管activity的线程不应用于处理一些诸如网络下载之类的耗时操作。所有不能在瞬间完成的任务都应安排到不同的线程中去。
远程方法调用(Remote procedure calls)
Android有一个轻量级的远程方法调用（RPC）机制：即在本地调用一个方法，但在远程（其它的进程中）进行处理，然后将结果返回调用者。这将方法调用及其附属的数据以系统可以理解的方式进行分离，并将其从本地进程和本地地址空间传送至远程过程和远程地址空间，并在那里重新装配并对调用做出反应。返回 的结果将以相反的方向进行传递。Android提供了完成这些工作所需的所有的代码，以使你可以集中精力来实现RPC接口本身。
RPC接口可以只包括方法。即便没有返回值，所有方法仍以同步的方式执行（本地方法阻塞直至远程方法结束）。
一般情况下，远程过程是被一个服务所管理的（因为服务可以通知系统关于进程以及它连接到别的进程的信息）。它包含着 aidl工具产生的接口文件和实现了RPC方法的Stub的子类。而客户端只需要包括aidl工具产生的接口文件。
下面将说明服务与其客户端之间的连接是如何建立的：
* 如果服务接受了连接，Android将会调用客户端的onServiceConnected() 方法，并传递给它一个IBinder对象，它是由服务所管理的Stub的子类的代理。通过这个代理，客户端可以对远程服务进行调用。
线程安全方法(Thread-safe methods)
在一些情况下，你所实现的方法有可能会被多于一个的线程所调用，所以它们必须被写成线程安全的。
对于我们上一节所讨论的RPC机制中的可以被远程调用的方法来说，这是必须首先考虑的。如果针对一个IBinder对象中实现的方法的调用源自这个 IBinder对象所在的进程时，这个方法将会在调用者的线程中执行。然而，如果这个调用源自其它的进程，则这个方法将会在一个线程池中选出的线程中运 行，这个线程池由Android加以管理，并与IBinder存在于同一进程内；这个方法不会在进程的主线程内执行。反过来说，一个服务的 onBind() 方法应为服务进程的主线程所调用，而实现了由 onBind() 返回的对象（比如说，一个实现了RPC方法的Stub的子类）的方法将为池中的线程所调用。因为服务可以拥有多于一个的客户端，而同一时间，也会有多个池中的线程调用同一个IBinder方法。因此IBinder方法必须实现为线程安全的。
应用程序组件有其生命周期──由Android初始化它们以相应intent直到这个实例被摧毁。在此之间，它们有时是激活的有时则相反。或者，如果它是 一个activity，则是可为用户所见或者不能。这一节讨论了activity、服务以及广播接收器的生命周期，包括它们在生命周期中的状态、在状态之 间转变时通知你的方法、以及当这些进程被关闭或实例被摧毁时，这些状态产生的效果。
Activity生命周期(Activity lifecycle)
一个activity主要有三个状态：
* 当在屏幕前台时（位于当前任务堆栈的顶部），它是活跃或运行的状态。它就是相应用户操作的activity。
* 当它失去焦点但仍然对用户可见时，它处于暂停状态。即是：在它之上有另外一个activity。这个activity也许是透明的，或者未能完全遮蔽全屏，所以被暂停的activity仍对用户可见。暂停的activity仍然是存活状态（它保留着所有的状态和成员信息并连接至窗口管理器），但当系统处于极低内存的情况下，仍然可以杀死这个activity。
* 如果它完全被另一个activity覆盖是，它处于停止状态。它仍然保留所有的状态和成员信息。然而它不在为用户可见，所以它的窗口将被隐藏，如果其它地方需要内存，则系统经常会杀死这个activity。
当一个activity从这个状态转变到另一个状态时，它被以下列protected方法所通知：
void onCreate(Bundle savedInstanceState)
void onStart()
void onRestart()
void onResume()
void onPause()
void onStop()
void onDestroy()
调用父类(Calling into the superclass)
所有activity生命周期方法的实现都必须先调用其父类的版本。比如说：
总得来说，这七个方法定义了一个activity完整的生命周期。实现这些方法可以帮助你监察三个嵌套的生命周期循环：
* 一个activity 完整的生命周期 自第一次调用 onCreate()开始，直至调用onDestroy()为止。activity在onCreate()中设置所有“全局”状态以完成初始化，而在onDestroy()中释放所有系统资源。比如说，如果activity有一个线程在后台运行以从网络上下载数据，它会以 onCreate()<code>创建那个线程，而以</code> onDestroy()销毁那个线程。
* 一个activity的 可视生命周期自 onStart() 调用开始直到相应的 onStop()调用。在此期间，用户可以在屏幕上看到此activity，尽管它也许并不是位于前台或者正在与用户做交互。在这两个方法中，你可以管控用来向用户显示这个activity的资源。比如说，你可以在onStart() 中注册一个BroadcastReceiver 来监控会影响到你UI的改变，而在onStop() 中来取消注册，这时用户是无法看到你的程序显示的内容的。onStart() 和 onStop() 方法可以随着应用程序是否为用户可见而被多次调用。
* 一个activity的 前台生命周期 自 onResume() 调用起，至相应的 onPause()调用为止。在此期间，activity位于前台最上面并与用户进行交互。activity会经常在暂停和恢复之间进行状态转换──比如说当设备转入休眠状态或有新的activity启动时，将调用onPause() 方法。当activity获得结果或者接收到新的intent的时候会调用onResume() 方法。因此，在这两个方法中的代码应当是轻量级的。
下图展示了上述循环过程以及activity在这个过程之中历经的状态改变。着色的椭圆是activity可以经历的主要状态。矩形框代表了当activity在状态间发生改变的时候，你进行操作所要实现的回调方法。
下表详细描述了这些方法，并在activity的整个生命周期中定位了它们。
方法
描述
是否可被杀死(Killable?)
下一个
接下来始终遵循调用onStart()。
否
onStart()
在activity停止后，在再次启动之前被调用。
当activity正要变得为用户所见时被调用。
当activity转向前台时接下来调用onResume()，在activity变为隐藏时接下来调用onStop()。
onResume()
或
onStop()
在activity开始与用户进行交互之前被调用。此时activity位于堆栈顶部，并接受用户输入。
接下来始终遵循调用onPause()。
<code>onPause()</code>
当系统将要启动另一个activity时调用。此方法主要用来将未保存的变化进行持久化，停止类似动画这样耗费CPU的动作等。这一切动作应该在短时间内完成，因为下一个activity必须等到此方法返回后才会继续。
当activity重新回到前台时接下来调用onResume()。当activity变为用户不可见时接下来调用onStop()。
是
当activity不再为用户可见时调用此方法。这可能发生在它被销毁或者另一个activity（可能是现存的或者是新的）回到运行状态并覆盖了它。
如果activity再次回到前台跟用户交互则接下来调用onRestart()，如果关闭activity则接下来调用onDestroy()。
onRestart()
or
onDestroy()
无
请注意上表中可被杀死一列。它标示了在方法返回后，还没执行activity的其余代码的任意时间里，系统是否可以杀死包含此activity的进程。三个方法（onPause()、onStop()<code>和</code>onDestroy()）被标记为“是”。onPause()是三个中的第一个，它也是唯一一个在进程被杀死之前必然会调用的方法──onStop() 和 onDestroy() 有可能不被执行。因此你应该用 onPause() 来将所有持久性数据（比如用户的编辑结果）写入存储之中。
在可被杀死一列中标记为“否”的方法在它们被调用时将保护activity所在的进程不会被杀死。所以只有在onPause()<code>方法返回后到</code>onResume() 方法被调用时，一个activity才处于可被杀死的状态。在onPause()<code>再次被调用并返回之前，它不会被系统杀死。</code>
保存activity状态(Saving activity state)
当系统而不是用户自己出于回收内存的考虑，关闭了一个activity之后。用户会期望当他再次回到那个activity的时候，它仍保持着上次离开时的样子。
与onPause()或先前讨论的其它方法不同，onSaveInstanceState() 和 onRestoreInstanceState() 并不是生命周期方法。它们并不是总会被调用。比如说，Android会在activity易于被系统销毁之前调用 onSaveInstanceState()，但用户动作（比如按下了BACK键）造成的销毁则不调用。在这种情况下，用户没打算再次回到这个activity，所以没有保存状态的必要。
因为onSaveInstanceState()不是总被调用，所以你应该只用它来为activity保存一些临时的状态，而不能用来保存持久性数据。而是应该用onPause()来达到这个目的。
服务生命周期(Coordinating activities)
服务以两种方式使用：
这两种模式并不是完全分离的。你可以绑定至一个用 startService()启动的服务。比如说，一个后台音乐播放服务可以调用startService()并传递给它一个包含欲播放的音乐列表的Intent对象来启动。不久，当用户想要对播放器进行控制或者查看当前播放曲目的详情时，会启用一个activity，调用bindService()连接到服务来完成操作。在这种情况下，直到绑定连接关闭stopService() 才会真正停止一个服务。
与activity一样，服务也有一系列你可以实现以用于监控其状态变化的生命周期方法。但相对于activity要少一些，只有三个，而且，它们是public属性，并非protected：
void onCreate()
void onStart(Intent intent)
倚仗实现这些方法，你监控服务的两个嵌套的生命周期循环：
服务停止时没有相应的回调方法──不存在onStop()方法。
如果一个服务允许别的进程绑定，则它还会有以下额外的回调方法以供实现：
IBinder onBind(Intent intent)
boolean onUnbind(Intent intent)
void onRebind(Intent intent)
下图描绘了服务的回调方法。尽管图中对由startService 和startService方法启动的服务做了区分，但要记住，不论一个服务是怎么启动的，它都可能允许客户端的连接，所以任何服务都可以接受onBind()和onUnbind()调用。
广播接收器只有一个回调方法：
void onReceive(Context curContext, Intent broadcastMsg)
拥有一个活跃状态的广播接收器的进程被保护起来而不会被杀死。但仅拥有失活状态组件的进程则会在其它进程需要它所占有的内存的时候随时被杀掉。
这种方式引出了一个问题：如果响应一个广播信息需要很长的一段时间，我们一般会将其纳入一个衍生的线程中去完成，而不是在主线程内完成它，从而保证用户交互过程的流畅。如果onReceive()衍生了一个线程并且返回，则包涵新线程在内的整个进程都被会判为失活状态（除非进程内的其它应用程序组件仍处于活跃状态），于是它就有可能被杀掉。这个问题的解决方法是令onReceive()启动一个新服务，并用其完成任务，于是系统就会知道进程中仍然在处理着工作。
下一节中，我们会讨论更多进程易误杀的问题。
进程与生命周期(Processes and lifecycles)
Android系统会尽可能长的延续一个应用程序进程，但在内存过低的时候，仍然会不可避免需要移除旧的进程。为决定保留或移除一个进程，Android 将每个进程都放入一个“重要性层次”中，依据则是它其中运行着的组件及其状态。重要性最低的进程首先被消灭，然后是较低的，依此类推。重要性共分五层，依 据重要性列表如下：
1. 前台进程是用户操作所必须的。当满足如下任一条件时，进程被认为是处于前台的：
* 一个正在与用户交互的activity使用着它提供的一个服务。
任一时间下，仅有少数进程会处于前台，仅当内存实在无法供给它们维持同时运行时才会被杀死。一般来说，在这种情况下，设备已然处于使用虚拟内存的状态，必须要杀死一些前台进程以用户界面保持响应。
2. 可视进程没有前台组件，但仍可被用户在屏幕上所见。当满足如下任一条件时，进程被认为是可视的：
* 它包含了一个绑定至一个可视的activity的服务。
可视进程依然被视为是很重要的，非到不杀死它们便无法维持前台进程运行时，才会被杀死。
5. 空进程不包含任何活动应用程序组件。这种进程存在的唯一原因是做为缓存以改善组件再次于其中运行时的启动时间。系统经常会杀死这种进程以保持进程缓存和系统内核缓存之间的平衡。
Android会依据进程中当前活跃组件的重要程度来尽可能高的估量一个进程的级别。比如说，如果一个进程中同时有一个服务和一个可视的activity，则进程会被判定为可视进程，而不是服务进程。
此外，一个进程的级别可能会由于其它进程依赖于它而升高。一个为其它进程提供服务的进程级别永远高于使用它服务的进程。比如说，如果A进程中的内容提供者 为进程B中的客户端提供服务，或进程A中的服务为进程B中的组件所绑定，则A进程最低也会被视为与进程B拥有同样的重要性。