本文内容：
-
创建Acitivity
-
实现用户界面
-
在清单文件中声明Activity
-
使用Intent Filter
-
-
启动Activity
-
使用Intent通信
-
-
结束Activity
-
管理Activity的生命周期
-
Activity的四种状态
-
Activity的生命周期
-
实现生命周期回调
-
-
保存 Activity 状态
-
处理配置变更
-
协调Activity
-
-
任务和返回栈
-
管理任务
-
定义启动模式
-
使用清单文件
-
使用Intent标志
-
任务共用性的处理
-
清理返回栈
-
启动任务
-
Activity 是一个应用组件，用户可与其提供的屏幕进行交互，以执行拨打电话、拍摄照片、发送电子邮件或查看地图等操作。每个 Activity 都会获得一个用于绘制其用户界面的窗口。窗口通常会充满屏幕，但也可小于屏幕并浮动在其他窗口之上。
一个应用通常由多个彼此松散联系的Activity组成。一般会指定应用中的某个 Activity 为“主”Activity，即首次启动应用时呈现给用户的那个 Activity。而且每个 Activity 均可启动另一个 Activity，以便执行不同的操作。 每次新 Activity 启动时，前一个 Activity 便会停止，但系统会在堆栈（返回栈）中保留该 Activity。当新 Activity 启动时，系统会将其推送到返回栈的栈顶，并取得用户焦点。返回栈遵循基本的“后进先出”堆栈机制，因此，当用户完成当前 Activity 并按“返回”按钮时，系统会从堆栈中将其弹出（并销毁），然后恢复前一个 Activity。
当一个 Activity 因某个新 Activity 启动而停止时，系统会通过该 Activity 的生命周期回调方法通知其这一状态变化。Activity 因状态变化—系统是创建 Activity、停止 Activity、恢复 Activity 还是销毁 Activity— 而收到的回调方法可能有若干种，每一种回调都会为您提供执行与该状态变化相应的特定操作的机会。例如，停止时，您的 Activity 应释放任何大型对象，例如网络或数据库连接。 当 Activity 恢复时，您可以重新获取所需资源，并恢复执行中断的操作。这些状态转变都是 Activity 生命周期的一部分。
创建 Activity
要创建 Activity，您必须创建 Activity 的子类（或使用其现有子类）。您需要在子类中实现 Activity 在其生命周期的各种状态之间转变时系统调用的回调方法。 两个最重要的回调方法是：
onCreate()
您必须实现此方法。系统会在创建 Activity 时调用此方法。您应该在实现内初始化Activity的必需组件。最重要的是，您必须在此方法内调用 setContentView()，以定义 Activity 用户界面的布局。onPause()
系统将此方法作为用户离开 Activity 的第一个信号（但并不总是意味着 Activity 会被销毁）进行调用。 您通常应该在此方法内确认在当前用户会话结束后仍然有效的任何更改（因为用户可能不会返回）。
您还应使用几种其他生命周期回调方法，以便提供流畅的 Activity 间用户体验，以及处理导致您的 Activity 停止甚至被销毁的意外中断。
实现用户界面
Activity的用户界面是由层级式视图 —— 衍生自 View 类的对象提供的。每个视图都控制 Activity 窗口内的特定矩形空间，可对用户交互作出响应。 例如，视图可以是在用户触摸时启动某项操作的button。
您可以利用 Android 提供的许多现成视图设计和组织您的布局。“Widget”是提供button, text field, checkbox或仅仅是image等屏幕视觉（交互式）元素的视图。 “Layout”是衍生自 ViewGroup 的视图，为其子视图提供唯一布局模型，例如线性布局、网格布局或相对布局。 您还可以为 View 类和 ViewGroup 类创建子类（或使用其现有子类）来自行创建widget和layout，然后将它们应用于您的 Activity 布局。
利用视图定义布局的最常见方法是借助保存在您的应用资源内的 XML 布局文件。这样一来，您就可以将用户界面的设计与定义 Activity 行为的源代码分开维护。 您可以通过 setContentView() 将布局设置为 Activity 的 UI，从而传递布局的资源 ID。不过，您也可以在 Activity 代码中创建新 View，并通过将新 View 插入 ViewGroup 来创建视图层次，然后通过将根 ViewGroup 传递到 setContentView() 来使用该布局。
在清单文件中声明 Activity
您必须在清单文件中声明您的 Activity，这样系统才能访问它。 要声明您的 Activity，请打开您的清单文件，并将
...
您还可以在此元素中加入几个其他特性，以定义 Activity 标签、Activity 图标或风格主题等用于设置 Activity UI 风格的属性。 android:name 属性是唯一必需的属性—它指定 Activity 的类名。应用一旦发布，即不应更改此类名，否则，可能会破坏诸如应用快捷方式等一些功能。
使用 Intent Filter
当您使用 Android SDK 工具创建新应用时，系统自动为您创建的存根 Activity 包含一个 Intent 过滤器，其中声明了该 Activity 响应“主”操作且应置于“launcher”类别内。 Intent Filter的内容如下所示：
如果您打算让应用成为独立的应用，不允许其他应用激活其 Activity，则不需要定义任何其他的 Intent Filter。 正如前例所示，只应有一个 Activity 具有"main" action 和 "launcher" category，而不想提供给外部应用的 Activity 不应有任何 Intent Filter，您可以利用显式 Intent 自行启动Activity。
不过，如果您想让 Activity 对衍生自其他应用（以及您的自有应用）的隐式 Intent 作出响应，则必须为 Activity 定义其他 Intent Filter。 对于您想要作出响应的每一个 Intent 类型，您都必须加入相应的
启动Activity
您可以通过调用 startActivity()，并将其传递给描述您想启动的 Activity 的 Intent 来启动另一个 Activity。Intent 对象会指定您想启动的具体 Activity 或描述您想执行的操作类型（系统会为您选择合适的 Activity，甚至是来自其他应用的 Activity）。 Intent 对象还可能携带少量供所启动 Activity 使用的数据。
在您的自有应用内工作时，您经常只需要启动某个已知 Activity。 您可以通过使用类名创建一个显式定义您想启动的 Activity 的 Intent 对象来实现此目的。 例如，可以通过以下代码让一个 Activity 启动另一个名为 SignInActivity 的 Activity：
Intent intent = new Intent(this, SignInActivity.class);startActivity(intent);
不过，您的应用可能还需要利用您的 Activity 数据执行某项操作，例如发送电子邮件、短信或状态更新。 在这种情况下，您的应用自身可能不具有执行此类操作所需的 Activity，因此您可以改为利用设备上其他应用提供的 Activity 为您执行这些操作。 这便是 Intent 对象的真正价值所在 — 您可以创建一个 Intent 对象，对您想执行的操作进行描述，系统会从其他应用启动相应的 Activity。 如果有多个 Activity 可以处理 Intent，则用户可以选择要使用哪一个。 例如，如果您想允许用户发送电子邮件，可以创建以下 Intent：
Intent intent = new Intent(Intent.ACTION_SEND);
intent.putExtra(Intent.EXTRA_EMAIL, recipientArray);
startActivity(intent);
添加到 Intent 中的 EXTRA_EMAIL extra 是一个字符串数组，其中包含应将电子邮件发送到的电子邮件地址。 当电子邮件应用响应此 Intent 时，它会读取 extra 中提供的字符串数组，并将它们放入电子邮件撰写窗体的“收件人”字段。 在这种情况下，电子邮件应用的 Activity 启动，并且当用户完成操作时，您的 Activity 会恢复执行。
启动具有返回值的Activity
有时，您可能需要从启动的Activity获得结果。在这种情况下，请通过调用 startActivityForResult()来启动Activity。要想在随后收到后续 Activity 的结果，请实现 onActivityResult() 回调方法。 当后续 Activity 完成时，它会使用 Intent 向您的 onActivityResult() 方法返回结果。
例如，您可能希望用户选取其中一位联系人，以便您的 Activity 对该联系人中的信息执行某项操作。 您可以通过以下代码创建此类 Intent 并处理结果：
private void pickContact() {
// Create an intent to "pick" a contact, as defined by the content provider URI
Intent intent = new Intent(Intent.ACTION_PICK, Contacts.CONTENT_URI);
startActivityForResult(intent, PICK_CONTACT_REQUEST);
}
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
// If the request went well (OK) and the request was PICK_CONTACT_REQUEST
if (resultCode == Activity.RESULT_OK && requestCode == PICK_CONTACT_REQUEST) {
// Perform a query to the contact's content provider for the contact's name
Cursor cursor = getContentResolver().query(data.getData(),
new String[] {Contacts.DISPLAY_NAME}, null, null, null);
if (cursor.moveToFirst()) { // True if the cursor is not empty
int columnIndex = cursor.getColumnIndex(Contacts.DISPLAY_NAME);
String name = cursor.getString(columnIndex);
// Do something with the selected contact's name...
}
}
}
上例显示的是，您在处理 Activity 结果时应该在 onActivityResult() 方法中使用的基本逻辑。 第一个条件检查请求是否成功（如果成功，则resultCode 将为 RESULT_OK）以及此结果响应的请求是否已知 —— 在此情况下，requestCode与随 startActivityForResult() 发送的第二个参数匹配。 代码通过查询 Intent 中返回的数据（data 参数）从该处开始处理 Activity 结果。
实际情况是，ContentResolver 对一个内容者执行查询，后者返回一个 Cursor，让查询的数据能够被读取。
使用Intent通信
在 Android 中，不同的 Activity 实例可能运行在一个进程中，也可能运行在不同的进程中。因此我们需要一种特别的机制帮助我们在 Activity 之间传递消息。Android 中通过 Intent 对象来表示一条消息，一个 Intent 对象不仅包含有这个消息的目的地，还可以包含消息的内容，这好比一封 Email，其中不仅应该包含收件地址，还可以包含具体的内容。对于一个 Intent 对象，消息“目的地”是必须的，而内容则是可选项。
通过 Activity. startActivity(intent)启动另外一个 Activity 的时候，我们在 Intent 类的构造器中指定了“收件人地址”。
如果我们想要给“收件人”Activity 说点什么的话，那么可以通过下面这封“e-mail”来将我们消息传递出去：
Intent intent =new Intent(MainActivity.this,OtherActivity.class);
Bundle bundle =new Bundle();// 创建 email 内容
bundle.putBoolean("boolean_key", true);// 编写内容
bundle.putString("string_key", "string_value");
intent.putExtra("key", bundle);// 封装 email
startActivity(intent);// 启动新的 Activity
那么“收件人”该如何收信呢？在 OtherActivity类的 onCreate()或者其它任何地方使用下面的代码就可以打开这封“e-mail”阅读其中的信息：
Intent intent =getIntent();// 收取 email
Bundle bundle =intent.getBundleExtra("key");// 打开 email
bundle.getBoolean("boolean_key");// 读取内容
bundle.getString("string_key");
上面我们通过 bundle对象来传递信息，bundle维护了一个 HashMap
Intent intent =new Intent(MainActivity.this,OtherActivity.class);
intent.putExtra("boolean_key", true);
intent.putExtra("string_key", "string_value");
startActivity(intent);
接收：
Intent intent=getIntent();
intent.getBooleanExtra("boolean_key",false);
intent.getStringExtra("string_key");
结束 Activity
您可以通过调用 Activity 的 finish() 方法来结束该 Activity。您还可以通过调用 finishActivity() 结束您之前启动的另一个 Activity。
注：在大多数情况下，您不应使用这些方法显式结束 Activity。 正如下文有关 Activity 生命周期的部分所述，Android 系统会为您管理 Activity 的生命周期，因此您无需结束自己的 Activity。 调用这些方法可能对预期的用户体验产生不良影响，因此只应在您确实不想让用户返回此 Activity 实例时使用。
管理Activity的生命周期
Activity是用堆栈进行管理的。当一个新的Activity启动时，他被放置在栈顶，并成为正在运行的Activity。上一个Activity总是保持在栈下面，并且不会再在前台直到新的Activity退出。
Activity的四种状态
- actived/running：如果Activity在屏幕的前台（在堆栈的顶部），它是活动的或正在运行的。
- paused：另一个 Activity 位于屏幕前台并具有用户焦点，但此 Activity 仍可见。也就是说，另一个 Activity 显示在此 Activity 上方，并且该 Activity 部分透明或未覆盖整个屏幕。 暂停的 Activity 处于完全活动状态（Activity 对象保留在内存中，它保留了所有状态和成员信息，并与窗口管理器保持连接），但在内存极度不足的情况下，可能会被系统终止。
- stopped：该 Activity 被另一个 Activity 完全遮盖（该 Activity 目前位于“后台”）。 已停止的 Activity 同样仍是存活的（Activity 对象保留在内存中，它保留了所有状态和成员信息，但未与窗口管理器连接）。 不过，它对用户不再可见，在他处需要内存时可能会被系统终止。
- destroyed/killed：如果活动被暂停或停止，则系统可以请求结束Activity或者简单地杀死其进程来从内存中删除该Activity。当它再次显示给用户时，必须完全重新启动并恢复到其以前的状态。
Activity的生命周期
每个 Activiy 都有生命周期，在不同的阶段会回调不同的生命周期函数，Activity 的生命周期函数有如下几个：
onCreate()它会在 Activity 第一次被创建时调用，通常会在这个函数中完成 Activity 的初始化操作，如设置布局、初始化视图、绑定事件等。
onStart()这个函数会在 Activity 的 onCreate() 调用之后被调用，此时的 Activity 还处在不可见的状态，它的下一个状态就是 Activity 变得可见的时候，也就是这个函数在 Activity 可见之前被调用。
onResume()这个函数在 Activity 变得可见时被调用，执行完 onResume() 之后，Activity 就会请求 AMS 渲染它所管理的视图。此时 Activity 一定位于返回栈的栈顶，并且处于运行状态。
onPause()这个函数在系统准备去启动或者恢复一个 Activity 时调用，也就是在 Activity 即将从可见状态变为不可见时。通常会在这个函数中将一些消耗 CPU 的资源释放掉，以及保存一些关键数据。
onStop()这个函数在 Activity 完全不可见时调用。它和 onPause() 的主要区别在于， 如果新启动的 Activity 是一个对话框式的 Activity，那么 onPause() 会得到执行，而 onStop() 函数并不会执行。
onDestroy()这个函数在 Activity 被销毁之前调用，之后 Activity 的状态将变为销毁状态。
onRestart()这个函数在 Activity 由停止状态重新变为运行状态之前调用，也就是 Activity 被重新启动了。
下图说明了这些循环以及 Activity 在状态转变期间可能经过的路径。矩形表示回调方法，椭圆形表示Activity处于的状态。
实现生命周期回调
当一个 Activity 转换或退出到不同的状态时，系统会通过各种回调方法向其发出通知。 所有回调方法都可以覆盖，以便在 Activity 状态发生变化时执行相应操作。
public class ExampleActivity extends Activity {
private static final String LOG_TAG = "ExampleActivity";
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
Log.e(LOG_TAG, "onCreate");
// The activity is being created.
}
@Override
protected void onStart() {
super.onStart();
Log.e(LOG_TAG, "onStart");
// The activity is about to become visible.
}
@Override
protected void onResume() {
super.onResume();
Log.e(LOG_TAG, "onResume");
// The activity has become visible (it is now "resumed").
}
@Override
protected void onPause() {
super.onPause();
Log.e(LOG_TAG, "onPause");
// Another activity is taking focus (this activity is about to be "paused").
}
@Override
protected void onStop() {
super.onStop();
Log.e(LOG_TAG, "onStop");
// The activity is no longer visible (it is now "stopped")
}
@Override
protected void onDestroy() {
super.onDestroy();
Log.e(LOG_TAG, "onDestroy");
// The activity is about to be destroyed.
}
}
这些方法共同定义 Activity 的整个生命周期。您可以通过实现这些方法监控 Activity 生命周期中的三个嵌套循环：
Activity 的整个生命周期(entire lifetime) 发生在 onCreate() 调用与 onDestroy() 调用之间。您的 Activity 会在 onCreate() 中执行“全局”状态设置（例如定义布局），并 在 onDestroy() 中释放所有其余资源。
Activity 的可见生命周期(visible lifetime) 发生在 onStart() 调用与 onStop() 调用之间，并且Activity可以通过onRestart()方法重新运行。在这段时间，用户可以在屏幕上看到 Activity 并与其交互。当 Activity 在对用户可见和隐藏两种状态中交替变化时，系统可能会多次调用 onStart() 和 onStop()。
Activity 的前台生命周期(foreground lifetime) 发生在 onResume() 调用与 onPause() 调用之间。在这段时间，Activity 位于屏幕上的所有其他 Activity 之前，并具有用户输入焦点。 Activity 可频繁转入和转出前台 — 例如，当设备转入休眠状态或出现对话框时，系统会调用 onPause()。 由于此状态可能经常发生转变，因此这两个方法中应采用适度轻量级的代码，以避免因转变速度慢而让用户等待。
保存 Activity 状态
上文提到，当 Activity 暂停或停止时，Activity 的状态会得到保留。 确实如此，因为当 Activity 暂停或停止时，Activity 对象仍保留在内存中——所有有关其成员的信息和当前的状态仍处于存活状态。 因此，用户在 Activity 内所做的任何更改都会得到保留，这样一来，当 Activity 返回前台（当它“继续”）时，这些更改仍然存在。
不过，当系统为了恢复内存而销毁某项 Activity 时，Activity 对象也会被销毁，因此系统在继续 Activity 时根本无法让其状态保持完好，而是必须在用户返回 Activity 时重建 Activity 对象。但用户并不知道系统销毁 Activity 后又对其进行了重建，因此他们很可能认为 Activity 状态毫无变化。 在这种情况下，您可以实现另一个回调方法对有关 Activity 状态的信息进行保存，以确保有关 Activity 状态的重要信息得到保留：onSaveInstanceState()。
系统会先调用 onSaveInstanceState()，然后再使 Activity 变得易于销毁。系统会向该方法传递一个 Bundle，并在其中使用 putString() 和 putInt() 等方法以名称-值对形式保存有关 Activity 状态的信息。然后，如果系统终止您的应用进程，并且用户返回原先的 Activity，则系统会重建该 Activity，并将 Bundle 同时传递给 onCreate() 和 onRestoreInstanceState()。您可以使用上述任一方法从 Bundle 提取您保存的状态并恢复该 Activity 状态。如果没有状态信息需要恢复，则传递给您的 Bundle 是空值（如果是首次创建该 Activity，就会出现这种情况）。
注意：无法保证系统会在销毁您的 Activity 前调用 onSaveInstanceState()，因为存在不需要保存状态的情况（例如用户使用“返回”按钮离开您的 Activity 时，因为用户的行为是在显式关闭 Activity）。 如果系统调用 onSaveInstanceState()，它会在调用 onStop() 之前，并且可能会在调用 onPause() 之前进行调用。
即使您什么都不做，也不实现 onSaveInstanceState()，Activity 类的 onSaveInstanceState() 默认实现也会恢复部分 Activity 状态。具体地讲，默认实现会为布局中的每个 View 调用相应的 onSaveInstanceState() 方法，让每个视图都能提供有关自身的应保存信息。Android 框架中几乎每个小部件都会根据需要实现此方法，以便在重建 Activity 时自动保存和恢复对 UI 所做的任何可见更改。例如，EditText 控件保存用户输入的任何文本，CheckBox 控件保存复选框的选中或未选中状态。您只需为想要保存其状态的每个控件提供一个唯一的 ID（通过 android:id 属性）。如果控件没有 ID，则系统无法保存其状态。
您还可以通过将 android:saveEnabled 属性设置为 "false" 或通过调用 setSaveEnabled() 方法显式阻止布局内的视图保存其状态。您通常不应将该属性停用，但如果您想以不同方式恢复 Activity UI 的状态，就可能需要这样做。
尽管 onSaveInstanceState() 的默认实现会保存有关您的Activity UI 的有用信息，您可能仍需替换它以保存更多信息。例如，您可能需要保存在 Activity 生命周期内发生了变化的成员值（它们可能与 UI 中恢复的值有关联，但默认情况下系统不会恢复储存这些 UI 值的成员）。
由于 onSaveInstanceState() 的默认实现有助于保存 UI 的状态，因此如果您为了保存更多状态信息而替换该方法，应始终先调用 onSaveInstanceState() 的超类实现，然后再执行任何操作。 同样，如果您替换 onRestoreInstanceState() 方法，也应调用它的超类实现，以便默认实现能够恢复视图状态。
public class MainActivity extends AppCompatActivity {
// These variable are destroyed along with Activity
private int someVarA;
private String someVarB;
...
@Override
protected void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
outState.putInt("someVarA", someVarA);
outState.putString("someVarB", someVarB);
}
@Override
protected void onRestoreInstanceState(Bundle savedInstanceState) {
super.onRestoreInstanceState(savedInstanceState);
someVarA = savedInstanceState.getInt("someVarA");
someVarB = savedInstanceState.getString("someVarB");
}
}
注：由于无法保证系统会调用 onSaveInstanceState()，因此您只应利用它来记录 Activity 的瞬态（UI 的状态）— 切勿使用它来存储持久性数据，而应使用 onPause() 在用户离开 Activity 后存储持久性数据（例如应保存到数据库的数据）。
处理配置变更
有些设备配置可能会在运行时发生变化（例如屏幕方向、键盘可用性及语言）。 发生此类变化时，Android 会重建运行中的 Activity（系统调用 onDestroy()，然后立即调用 onCreate()）。此行为旨在通过利用您提供的备用资源（例如适用于不同屏幕方向和屏幕尺寸的不同布局）自动重新加载您的应用来帮助它适应新配置。
如果您对 Activity 进行了适当设计，让它能够按以上所述处理屏幕方向变化带来的重启并恢复 Activity 状态，那么在遭遇 Activity 生命周期中的其他意外事件时，您的应用将具有更强的适应性。
正如上文所述，处理此类重启的最佳方法是利用onSaveInstanceState() 和 onRestoreInstanceState()（或 onCreate()）保存并恢复 Activity 的状态。
如需了解有关运行时发生的配置变更以及应对方法的详细信息，请阅读处理运行时变更指南。
协调Activity
当一个 Activity 启动另一个 Activity 时，它们都会体验到生命周期转变。第一个 Activity 暂停并停止（但如果它在后台仍然可见，则不会停止）时，同时系统会创建另一个 Activity。 如果这些 Activity 共用保存到磁盘或其他地方的数据，必须了解的是，在创建第二个 Activity 前，第一个 Activity 不会完全停止。更确切地说，启动第二个 Activity 的过程与停止第一个 Activity 的过程存在重叠。
生命周期回调的顺序经过明确定义，当两个 Activity 位于同一进程，并且由一个 Activity 启动另一个 Activity 时，其定义尤其明确。 以下是当 Activity A 启动 Activity B 时一系列操作的发生顺序：
1.Activity A 的 onPause() 方法执行。
2.Activity B 的 onCreate()、onStart() 和 onResume() 方法依次执行。（Activity B 现在具有用户焦点。）
3.然后，如果 Activity A 在屏幕上不再可见，则其 onStop() 方法执行。
您可以利用这种可预测的生命周期回调顺序管理从一个 Activity 到另一个 Activity 的信息转变。 例如，如果您必须在第一个 Activity 停止时向数据库写入数据，以便下一个 Activity 能够读取该数据，则应在 onPause() 而不是 onStop() 执行期间向数据库写入数据。
任务和返回栈
任务是指在执行特定作业时与用户交互的一系列 Activity。 这些 Activity 按照各自的打开顺序排列在堆栈（即返回栈）中。
设备主屏幕是大多数任务的起点。当用户触摸应用启动器中的图标（或主屏幕上的快捷方式）时，该应用的任务将出现在前台。 如果应用不存在任务（应用最近未曾使用），则会创建一个新任务，并且该应用的主Activity将作为堆栈中的根 Activity 打开。
当前 Activity 启动另一个 Activity 时，该新 Activity 会被推送到堆栈顶部，成为焦点所在。 前一个 Activity 仍保留在堆栈中，但是处于停止状态。Activity 停止时，系统会保持其用户界面的当前状态。 用户按“返回”按钮时，当前 Activity 会从堆栈顶部弹出（Activity 被销毁），而前一个 Activity 恢复执行（恢复其 UI 的前一状态）。 堆栈中的 Activity 永远不会重新排列，仅推入和弹出堆栈：由当前 Activity 启动时推入堆栈；用户使用“返回”按钮退出时弹出堆栈。 因此，返回栈以“后进先出”对象结构运行。 图1通过时间线显示 Activity 之间的进度以及每个时间点的当前返回栈，直观呈现了这种行为。
如果用户继续按“返回”，堆栈中的相应 Activity 就会弹出，以显示前一个 Activity，直到用户返回主屏幕为止（或者，返回任务开始时正在运行的任意 Activity）。 当所有 Activity 均从堆栈中移除后，任务即不复存在。
任务是一个有机整体，当用户开始新任务或通过“主页”按钮转到主屏幕时，可以移动到“后台”。 尽管在后台时，该任务中的所有 Activity 全部停止，但是任务的返回栈仍旧不变，也就是说，当另一个任务发生时，该任务仅仅失去焦点而已，如图 2 中所示。然后，任务可以返回到“前台”，用户就能够回到离开时的状态。 例如，假设当前任务（任务 A）的堆栈中有三个 Activity，即当前 Activity 下方还有两个 Activity。 用户先按“主页”按钮，然后从应用启动器启动新应用。 显示主屏幕时，任务 A 进入后台。新应用启动时，系统会使用自己的 Activity 堆栈为该应用启动一个任务（任务 B）。与该应用交互之后，用户再次返回主屏幕并选择最初启动任务 A 的应用。现在，任务 A 出现在前台，其堆栈中的所有三个 Activity 保持不变，而位于堆栈顶部的 Activity 则会恢复执行。 此时，用户还可以通过转到主屏幕并选择启动该任务的应用图标（或者，通过从总览画面选择该应用的任务）切换回任务 B。这是 Android 系统中的一个多任务示例。
注：后台可以同时运行多个任务。但是，如果用户同时运行多个后台任务，则系统可能会开始销毁后台 Activity，以回收内存资源，从而导致 Activity 状态丢失。
由于返回栈中的 Activity 永远不会重新排列，因此如果应用允许用户从多个 Activity 中启动特定 Activity，则会创建该 Activity 的新实例并推入堆栈中（而不是将 Activity 的任一先前实例置于顶部）。 因此，应用中的一个 Activity 可能会多次实例化（即使 Activity 来自不同的任务），如图 3 所示。因此，如果用户使用“返回”按钮向后导航，则会按 Activity 每个实例的打开顺序显示这些实例（每个实例的 UI 状态各不相同）。 但是，如果您不希望 Activity 多次实例化，可以修改启动模式（将在后面讨论）。
Activity 和任务的默认行为总结如下：
- 当 Activity A 启动 Activity B 时，Activity A 将会停止，但系统会保留其状态（例如，滚动位置和已输入表单中的文本）。如果用户在处于 Activity B 时按“返回”按钮，则 Activity A 将恢复其状态，继续执行。
- 用户通过按“主页”按钮离开任务时，当前 Activity 将停止且其任务会进入后台。 系统将保留任务中每个 Activity 的状态。如果用户稍后通过选择开始任务的启动器图标来恢复任务，则任务将出现在前台并恢复执行堆栈顶部的 Activity。
- 如果用户按“返回”按钮，则当前 Activity 会从堆栈弹出并被销毁。 堆栈中的前一个 Activity 恢复执行。销毁 Activity 时，系统不会保留该 Activity 的状态。
- 即使来自其他任务，Activity 也可以多次实例化。
管理任务
Android 管理任务和返回栈的方式（如上所述，即：将所有连续启动的 Activity 放入同一任务和“后进先出”堆栈中）非常适用于大多数应用，而您不必担心 Activity 如何与任务关联或者如何存在于返回栈中。 但是，您可能会决定要中断这种正常行为。
也许您希望应用中的 Activity 在启动时开始新任务（而不是放置在当前任务中）；或
者，当启动 Activity 时，您希望将其现有实例上移一层（而不是在返回栈的顶部创建新实例）；或者，您希望在用户离开任务时，清除返回栈中除根 Activity 以外的所有其他 Activity。
通过使用
在这一方面，您可以使用的主要
taskAffinity
launchMode
allowTaskReparenting
clearTaskOnLaunch
alwaysRetainTaskState
finishOnTaskLaunch
您可以使用的主要 Intent 标志包括：
FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_SINGLE_TOP
在下文中，您将了解如何使用这些清单文件属性和 Intent 标志定义 Activity 与任务的关联方式，以及 Activity 在返回栈中的行为方式。
定义启动模式
启动模式允许您定义 Activity 的新实例如何与当前任务关联。 您可以通过两种方法定义不同的启动模式：
- 使用清单文件
- 使用Intent标志
如果 Activity A 启动 Activity B，则 Activity B 可以在其清单文件中定义它应该如何与当前任务关联（如果可能），并且 Activity A 还可以请求 Activity B 应该如何与当前任务关联。如果这两个 Activity 均定义 Activity B 应该如何与任务关联，则 Activity A 的请求（如 Intent 中所定义）优先级要高于 Activity B 的请求（如其清单文件中所定义）。
注：某些适用于清单文件的启动模式不可用作 Intent 标志，同样，某些可用作 Intent 标志的启动模式无法在清单文件中定义。
使用清单文件
在清单文件中声明 Activity 时，您可以使用
launchMode 属性指定有关应如何将 Activity 启动到任务中的指令。您可以分配给 launchMode 属性的启动模式共有四种：
-
"standard"（默认模式）
默认。系统在启动 Activity 的任务中创建 Activity 的新实例并向其传送 Intent。Activity 可以多次实例化，而每个实例均可属于不同的任务，并且一个任务可以拥有多个实例。
-
"singleTop"
如果当前任务的顶部已存在 Activity 的一个实例，则系统会通过调用该实例的 onNewIntent() 方法向其传送 Intent，而不是创建 Activity 的新实例。
如果一个 Activity 的实例已经存在但不位于栈顶，那么再启动这个 Activity 时，就会再创建一个新的实例。
注：为某个 Activity 创建新实例时，用户可以按“返回”按钮返回到前一个 Activity。 但是，当 Activity 的现有实例处理新 Intent 时，则在新 Intent 到达 onNewIntent() 之前，用户无法按“返回”按钮返回到 Activity 的状态。
-
"singleTask"
系统创建新任务并实例化位于新任务底部的 Activity。但是，如果该 Activity 的一个实例已存在于一个单独的任务中，则系统会通过调用现有实例的 onNewIntent() 方法向其传送 Intent，而不是创建新实例，并且销毁位于该 Activity 上面的所有 Activity，最终让该 Activity 位于栈顶。一次只能存在 Activity 的一个实例。
注意：singleTask模式的Activity不管是位于栈顶还是栈底，再次运行这个Activity时，都会destory掉它上面的Activity来保证整个栈中只有一个自己。
-
"singleInstance".
特性与 "singleTask" 相同，只是具有 singleInstance 模式的 Activity 会在一个单独的任务栈中打开，并且该任务栈中有且只有这一个实例，也就是说该实例启动的其他 Activity 会自动运行于另一个任务中。当再次启动该 Activity 实例时，会重用已存在的任务和实例。并且会调用该实例的 onNewIntent()函数，将Intent实例传递到该实例中。
无论 Activity 是在新任务中启动，还是在与启动 Activity 相同的任务中启动，用户按“返回”按钮始终会转到前一个 Activity。 但是，如果启动指定 singleTask 启动模式的 Activity，则当某后台任务中存在该 Activity 的实例时，整个任务都会转移到前台。此时，返回栈包括上移到堆栈顶部的任务中的所有 Activity。 图 4 显示了这种情况。
使用Intent标志
启动 Activity 时，您可以通过在传递给 startActivity() 的 Intent 中加入相应的标志，修改 Activity 与其任务的默认关联方式。可用于修改默认行为的标志包括：
FLAG_ACTIVITY_NEW_TASK
在新任务中启动 Activity。如果你正在启动的 Activity的已在当前任务中运行，则该任务会转到前台并恢复其最后状态，同时 Activity 会在 onNewIntent() 中收到新 Intent。
正如前文所述，这会产生与 "singleTask"launchMode 值相同的行为。
FLAG_ACTIVITY_SINGLE_TOP
如果正在启动的 Activity 是当前 Activity（位于栈顶），则现有实例会接收对 onNewIntent() 的调用，而不是创建 Activity 的新实例。
正如前文所述，这会产生与 "singleTop"launchMode 值相同的行为。
FLAG_ACTIVITY_CLEAR_TOP
如果正在启动的 Activity 已在当前任务中运行，则会销毁当前任务顶部的所有 Activity，并通过 onNewIntent() 将此 Intent 传递给 Activity 已恢复的实例（现在位于顶部），而不是启动该 Activity 的新实例。
产生这种行为的 launchMode 属性没有值。
FLAG_ACTIVITY_CLEAR_TOP 通常与 FLAG_ACTIVITY_NEW_TASK 结合使用。一起使用时，通过这些标志，可以找到其他任务中的现有 Activity，并将其放入可从中响应 Intent 的位置。
任务共用性的处理(Handling affinities)
affinity表示activity预期所处的task。默认情况下，同一个应用中的所有activity都拥有同一个affinity值。 因此，同一个应用中的所有activity默认都位于同一个task中。不过，你可以修改activity默认的affinity值。
不同应用中的activity可以共享同一个affinity值，同一个应用中的activity也可以赋予不同的task affinity值。一个应用程序默认的affinity就是应用程序的包名，所以，如果我们想定义一个不同的affinity，必须和默认的affinity不同。
我们可以通过
而affinity的使用通常有以下两种情况
1.当启动模式是是singleTask或者Intent中包含FLAG_ACTIVITY_NEW_TASK：
默认情况下，我们调用startActivity()，会实例化一个Activity，放入到与调用者相同的task。但是如果这个Activity的的启动模式是singleTask，或者启动它的Intent包含了
FLAG_ACTIVITY_NEW_TASK时，系统会进行如下的步骤：
- 判断这个Activity有没有实例已经存在了，有的话，直接传递Intent到它的onNewIntent()方法中。
- 如果不存在，系统查找是否有与这个Activity相同affinity的Task已经存在，如果存在，那么就将这个Activity启动到这个Task中。
- 如果不存在这样的Task，那么系统就会创建一个新的Task，并且将这个Activity启动这个Task中，作为根Activity。
因此，从现在看来，只是单纯的用singleTask指定Activity，是不能开辟一个新的Task的，因为我们并没有给他指定affinity。而官方文档对于singleTask的描述，都是基于我们使用了不同的affinity的前提下，只不过是省略了这个描述。所以，我们要明白，singleTask的正确用法，应该是结合affinity使用的。
2.当一个Activity设置allowTaskReparenting属性为true：
这个属性定义了一个Activity，表示是否可以从一个启动它的task，切换到与它相同affinity的task中里去（当这个task切换到前台的时候）。true表示可以移动，false表示它必须呆在启动他的task里。
通常情况下，当一个Activity启动了，那么它就会存在于启动它的task中，并且在整个生命周期中都留在这个task中。但是，我们可以通过这个属性，做出如下改变，当这个Activity当前的Task处于后台，这个时候如果有一个该Activity具有相同affinity的Task被启动到前台，那么这个Activity就可以从它之前的Task，移动到这个新的Task显示。
通常，它的作用是将app中的Activity与app的main task结合起来，举个例子，如下：
有一个e-mail程序，他需要调用浏览器程序的某个Activity（假设为Activity A）来显示一些数据，这个Activity A的该属性设置为true。现在，e-mail程序调用了这个Activity A，在用户看来，好像这个Activity A就是e-mial程序的一部分，因为这个Activity A和这个e-mail程序在同一个task中。现在将e-mail退出到后台，启动浏览器程序，因为Activity A和浏览器程序有相同的affinity，所以Activity A从e-mail程序的Task移动到浏览器程序的Task，并显示在前台。当我们下次再启动e-mail程序时，Activity A就不会存在，因为他已经移动到浏览器程序的Task里去了。
例如，假设将报告所选城市天气状况的 Activity 定义为旅行应用的一部分。 它与同一应用中的其他 Activity 具有相同的affinity值（默认应用affinity），并允许利用此属性重定父级。当您的一个 Activity 启动天气预报 Activity 时，它最初所属的任务与您的 Activity 相同。 但是，当旅行应用的任务出现在前台时，系统会将天气预报 Activity 重新分配给该任务并显示在其中。
清理返回栈
如果用户长时间离开任务，则系统会清除所有 Activity 的任务，根 Activity 除外。 当用户再次返回到任务时，仅恢复根 Activity。系统这样做的原因是，经过很长一段时间后，用户可能已经放弃之前执行的操作，返回到任务是要开始执行新的操作。
您可以使用下列几个 Activity 属性修改此行为：
alwaysRetainTaskState
如果在任务的根 Activity 中将此属性设置为 "true"，则不会发生刚才所述的默认行为。即使在很长一段时间后，任务仍将所有 Activity 保留在其堆栈中。clearTaskOnLaunch
如果在任务的根 Activity 中将此属性设置为 "true"，则每当用户离开任务然后返回时，系统都会将堆栈清除到只剩下根 Activity。 换而言之，它与 alwaysRetainTaskState 正好相反。 即使只离开任务片刻时间，用户也始终会返回到任务的初始状态。finishOnTaskLaunch
此属性类似于 clearTaskOnLaunch，但它对单个 Activity 起作用，而非整个任务。 此外，它还有可能会导致任何 Activity 停止，包括根 Activity。 设置为 "true" 时，Activity 仍是任务的一部分，但是仅限于当前会话。如果用户离开然后返回任务，则任务将不复存在。
启动任务
通过为Activity提供"android.intent.action.MAIN" 操作和 "android.intent.category.LAUNCHER" 类别的 Intent Filter，您可以将 Activity 设置为任务的入口点。 例如：
...
此类 Intent Filter会使 Activity 的图标和标签显示在应用启动器中，让用户能够启动 Activity 并在启动之后随时返回到创建的任务中。
第二个功能非常重要：用户必须能够在离开任务后，再使用此 Activity 启动器返回该任务。 因此，只有在 Activity 具有 ACTION_MAIN 和 CATEGORY_LAUNCHER de intent filter时，才应该使用将 Activity 标记为“始终启动任务”的两种启动模式，即 "singleTask" 和 "singleInstance"。例如，我们可以想像一下如果缺少intent filter会发生什么情况： Intent 启动一个 "singleTask" Activity，从而启动一个新任务，并且用户花了些时间处理该任务。然后，用户按“主页”按钮。 任务现已发送到后台，而且不可见。现在，用户无法返回到任务，因为该任务未显示在应用启动器中。
如果您并不想用户能够返回到 Activity，对于这些情况，请将