? ?
可以通过调用它的finish()方法来关闭一个activity。一个activity可以通过调用另外一个activity（它用startActivityForResult() 启动的）的finishActivity()方法来关闭它。
服务可以通过调用它的stopSelf()方法来停止，或者调用 Context.stopService()。
系统也会在组件不再被使用的时候或者Android需要为活动组件声明更多内存的时候关闭它。后面的 组件的生命周期一节，将对这种可能及附属情况进行更详细的讨论。
manifest文件
当Android启动一个应用程序组件之前，它必须知道那个组件是存在的。所以，应用程序会在一个manifest文件中声明它的组件，这个文件会被打包到Android包中。这个.apk文件还将涵括应用程序的代码、文件以及其它资源。
这个manifest文件以XML作为结构格式，而且对于所有应用程序，都叫做AndroidManifest.xml。为声明一个应用程序组件，它还会做很多额外工作，比如指明应用程序所需链接到的库的名称（除了默认的Android库之外）以及声明应用程序期望获得的各种权限。
但manifest文件的主要功能仍然是向Android声明应用程序的组件。举例说明，一个activity可以如下声明：
. . .
元素的name属性指定了实现了这个activity的 Activity的子类。icon和label属性指向了包含展示给用户的此activity的图标和标签的资源文件。
其它组件也以类似的方法声明──
Intent过滤器
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激活。
对于在代码中创建并注册的广播接收器来说，intent过滤器将被直接以 IntentFilter对象实例化。其它过滤器则在manifest文件中设置。
欲获得更多intent过滤器的信息，请参阅独立章节： Intent和Intent过滤器。
Activity和任务
如前所述，一个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显示了出来。
上述的种种即是activity和任务的默认行为模式。但是有一些方法可以改变所有这一切。activity和任务的联系、任务中activity的行为方式都被启动那个activity的Intent对象中设置的一系列标记和manifest文件中那个activity中的元素的系列属性之间的交互所控制。无论是请求发出者和回应者在这里都拥有话语权。
我们刚才所说的这些关键Intent标记如下：
FLAG_ACTIVITY_NEW_TASK FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_RESET_TASK_IF_NEEDED FLAG_ACTIVITY_SINGLE_TOP
而关键的属性是：
taskAffinity launchMode
allowTaskReparenting clearTaskOnLaunch alwaysRetainTaskState finishOnTaskLaunch
接下来的一节会描述这些标记以及属性的作用，它们是如何互相影响的，以及控制它们的使用时必须考虑到的因素。
Affinity（吸引力）和新任务
默认情况下，一个应用程序中的activity相互之间会有一种Affinity──也就是说，它们首选都归属于一个任务。然而，可以在元素中把每个
activity的taskAffinity属性设置为一个独立的
affinity。于是在不同的应用程序中定义的activity可以享有同一个affinity，或者在同一个应用程序中定义的activity有着不同的affinity。affinity在两种情况下生效：当加载activity的Intent对象包含了
FLAG_ACTIVITY_NEW_TASK 标记，或者当activity的allowTaskReparenting属性设置为“true”。
FLAG_ACTIVITY_NEW_TASK标记
如前所述，在默认情况下，一个新activity被另外一个调用了startActivity()方法的activity载入了任务之中。并压入了调用者所在的堆栈。然而，如果传递给startActivity()的Intent对象包含了
FLAG_ACTIVITY_NEW_TASK标记，系统会为新activity安排另外一个任务。一般情况下，如同标记所
暗示的那样，这会是一个新任务。然而，这并不是必然的。如果已经存在了一个与新activity有着同样affinity的任务，则activity会载入那个任务之中。如果没有，则启用新任务。 allowTaskReparenting 属性
如果一个activity将allowTaskReparenting属性设置为“true”。它就可以从初始的任务中转移到与其拥有同一个affinity并转向前台的任务之中。比如说，一个旅行应用程序中包含的预报所选城市的天气情况的activity。它与这个应用程序中其它的activity拥有同样的affinity（默认的affinity）而且允许重定父级。你的另一个activity启动了天气预报，于是它就会与这个activity共处与同一任务之中。然而，当那个旅行应用程序再次回到前台的时候，这个天气预报activity就会被再次安排到原先的任务之中并显示出来。
如果在用户的角度看来，一个.apk文件中包含了多于一个的“应用程序”，你可能会想要为它们所辖的activity安排不一样的affinity。
加载模式
元素的launchMode属性可以设置四种不同的加载模式：
\standard\（默认值） \singleTop\ \singleTask\ \singleInstance\
这些模式之间的差异主要体现在四个方面：
? 哪个任务会把持对intent做出响应的activity。对“standard”和“singleTop”模式而言，是产生intent（并调用 startActivity()）的任务──除非Intent对象包含FLAG_ACTIVITY_NEW_TASK标记。而在这种情况下，如同上面Affinitie和新任务一节所述，会是另外一个任务。 相反，对“singleTask”和“singleInstance”模式而言，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的形态。