Android Activity的属性及启动模式相关详解
1、Activity和Task
task就好像是能包含很多activity的栈。 默认情况下，一个activity启动另外一个activity时，两个activity是放在同一个task栈中的，第二个activity压入第一个activity所在的task栈。当用户按下返回键时，第二个activity从栈中弹出，第一个activity又在当前屏幕显示。这样，从用户角度来看，这两个activity就好像是属于同一个应用程序的，即使第二个activity是属于另外一个应用程序的。当然，这是指默认情况下。 task栈包含的是activity的对象。如果一个activity有多个实例在运行，那么栈中保存的是每个实例的实体。栈中的activity不会重新排列，只有弹出和压入操作。 一个task中的所有activity都以整体的形式移动。整个task可以被移到前台或后台。打个比方，当前的task包含4个activity–当前activity下面有3个activity。当用户按下HOME键返回到程序启动器（application launcher）后，选择了一个新的应用程序（事实上是一个新的task），当前的task就被转移到后台，新的task中的根activity将被显示在屏幕上。过了一段时间，用户按返回键回到了程序启动器界面，选择了之前运行的程序（之前的task）。那个task，仍然包含着4个activity。当用户再次按下返回键时，屏幕不会显示之前留下的那个activity（之前的task的根activity），而显示当前activity从task栈中移出后栈顶的那个activity。 刚刚描述的行为是默认的activity和task的行为。有很多方法能够改变这种行为。activity和task之间的联系，以及task中的activity的行为可以通过intent中的标记以及在manifest中的
FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
FLAG_ACTIVITY_SINGLE_TOP
主要的
taskAffinity
launchMode
allowTaskReparenting
clearTaskOnLaunch
alwaysRetainTaskState
finishOnTaskLaunch
默认情况下，一个应用程序中的所有activity都有一个affinity–这让它们属于同一个task。然而，每个activity可以通过
l FLAG_ACTIVITY_NEW_TASK标记
当传递给startActivity()的Intent对象包含FLAG_ACTIVITY_NEW_TASK标记时，系统会为需要启动的activity寻找与当前activity不同的task。如果要启动的activity的affinity属性与当前所有的task的affinity属性都不相同，系统会新建一个带那个affinity属性的task，并将要启动的activity压到新建的task栈中；否则将activity压入那个affinity属性相同的栈中。
l allowTaskReparenting属性
如果一个activity的allowTaskReparenting属性为true，那么它可以从一个task（TASK1）移到另外一个有相同affinity的task（TASK2）中（TASK2带到前台时）。
如果一个.apk文件从用户角度来看包含了多个“应用程序”，你可能需要对那些activity赋不同的affinity值。
2、运行模式
activity的launchMode属性可以有四种值：
“standard” (默认)
“singleTop“
“singleTask“
“singleInstance“
这4种模式可以按4种分类来区分，以下假设位于task1中的activity1启动activity2：
| 模式\分类 |
包容activity2的task |
一个activity是否允许有多个实例 |
activity是否允许有其它activity共存于一个task |
对于新的intent，是否总是实例化activity对象 |
| standard |
如果不包含FLAG_ACTIVITY_NEW_TASK标记，则activity2放入task1，否则按前面讲述的规则为activity2选择task |
可被多次实例化，同一个task的不同的实例可位于不同的task中，每个task也可包含多个实例 |
允许 |
是的。当接收到新的intent时，总是会生成新的activity对象。 |
| singleTop |
同standard |
同standard |
允许 |
已存在的activity对象，如果位于目标task的栈顶，则该activity被重用，如果它不位于栈顶，则会实例化新的activity对象 |
| singleTask |
将activity2放到task1栈顶 |
不能有多个实例。由于该模式下activity总是位于栈顶，所以actvity在同一个设备里至多只有一个实例 |
允许。singleTask模式的activity总是位于栈底位置。目标activity实例已存在时，如果该实例刚好位于task栈顶，则接收intent，否则到来的intent将会被丢弃,但该可以响应该intent的那个activity所在的task将会被移到前台。 |
|
| singleInstance |
同singleTask |
同singleTask |
不允许与其它activity共存于一个task。如果activity1的运行在该模式下，则activity2一定与activity1位于不同的task |
对于新到的intent，如果是由新创建的activity对象来接收，则用户可以通过返回键回到之前的activity；如果是由已存在的activity来接收，则用户无法通过返回键返回到接收intent之前的状态。
3、清空栈
当用户长时间离开task（当前task被转移到后台）时，系统会清除task中栈底activity外的所有activity。这样，当用户返回到task时，只留下那个task最初始的activity了。
这是默认的情况，
l alwaysRetainTaskState属性
如果栈底activity的这个属性被设置为true，刚刚描述的情况就不会发生。task中的所有activity将被长时间保存。
l clearTaskOnLaunch属性
如果栈底activity的这个属性被设置为true，一旦用户离开task，则task栈中的activity将被清空到只剩下栈底activity。这种情况刚好与alwaysRetainTaskState相反。即使用户只是短暂地离开，task也会返回到初始状态（只剩下栈底acitivty）。
l finishOnTaskLaunch属性
这个属性与clearTaskOnLaunch相似，但它只对单独的activity操作，而不是整个task。它可以结束任何activity，包括栈底的activity。当它设置为true时，当前的activity只在当前会话期间作为task的一部分存在，当用户退出activity再返回时，它将不存在。
另外还有一种方法能将activity强行从stack中移出。如果intent对象包含FLAG_ACTIVITY_CLEAR_TOP标记，当目标task中已存在与接收该intent对象的activity类型相同的activity实例存在时，所有位于该activity对象上面的activity将被清空，这样接收该intent的activity就位于栈顶，可以响应到来的intent对象。如果目标activity的运行模式为standard，则目标activtiy也会被清空。因为当运行模式为standard时，总会创建新的activity对象来接收到来的intent对象。
FLAG_ACTIVITY_CLEAR_TOP标记常常和FLAG_ACTIVITY_NEW_TASK一起使用。用2个标记可以定位已存在的activity并让它处于可以响应intent的位置。
4、启动任务（Task）
Intent filter中有”android.intent.action.MAIN” action和”android.intent.category.LAUNCHER” category的activity将被标记为task的入口。带有这两个标记的activity将会显示在应用程序启动器（application launcher）中。
第二个比较重要的点是，用户必须能够离开task并在之后返回。因为这个原因，singleTask和singleInstance这两种运行模式只能应用于含有MAIN和LAUNCHER过滤器的activity。打个比方，如果不包含带MAIN和LAUNCHER过滤器，某个activity运行了一个singleTask模式的activity，初始化了一个新的task，当用户按下HOME键时，那个activity就被主屏幕“挡住”了，用户再也无法返回到那个activity。
类似的情况在FLAG_ACTIVITY_NEW_TASK标记上也会出现。如果这个标记会新建一个task，当用户按下HOME键时，必须有一种方式能够让用户返回到那个activity。有些东西（比如notification manager）总是要求在外部task中启动activity，在传递给startActivity的intent中总是包含FLAG_ACTIVITY_NEW_TASK标记。
对于那种不希望用户离开之后再返回activity的情况，可将finishOnTaskLaunch属性设置为true。
===============================================================================================================================
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Activity就相当于一块块的七巧板，每个应用用这一个个七巧板组合成了美丽的图画，并用代码验证了每个Activity的生命周期。
那么，每个应用又是如何将各个Activity组合起来的呢？这就是本文要讲的内容。
通常情况下，一个应用有一个Task，这个Task就是为了完成某个工作的一系列Activity的集合。而这些Activity又被组织成了堆栈的形式。
当一个Activity启动时，就会把它压入该Task的堆栈，而当用户在该Activity中按返回键，或者代码中finish掉时，就会将它从该Task的堆栈中弹出。如果我们没有特别的需求，我们的应用就会呈现出如下图所示的情形
然而，事实上我们的需求远没有我们想的那么简单。有时候，你可能希望在开启一个Activity时，重新开启一个Task；有时你可能希望将已经存在的一个Activity放到栈顶，而不是重新创建一个...
Android为了使我们能够打破默认的堆栈的先后出的模式，提供了两个方式：一种是在AndroidManifest.xml定义Activity时指定它的加载模式，另一种是在用Intent开启一个Activity时，在Intent中加入标志。如果两种方式都用了，则后者的优先级更高。
两种方式的差别在于，前者在于描述自己，向别的Acttivity等声明你们如何来加载我；而后者则是动态的，指出我要求你（要启动的Activity）如何来加载。本文的重点在于研究在AndroidManifest.xml中声明加载模式。
Android为我们定义了四种加载模式，分别是：standard、singleTop、singleTask和singleInstance。
“拿来主义”——standard模式
我们写一段代码来测试一下standard加载模式，如下
AndroidManifest.xml里Activity的设置如下：
1
2 android:launchMode="standard"
3 android:label="@string/app_name">
4
5
6
7
8
Activity1的代码如下：
9 public class Activity1 extends Activity {
10 @Override
11 public void onCreate(Bundle savedInstanceState) {
12 super.onCreate(savedInstanceState);
13 setContentView(R.layout.main);
14 }
15
16 /**当点击Activity时，启动另一个Activity1*/
17 @Override
18 public boolean onTouchEvent(MotionEvent event) {
19 Intent intent = new Intent(this, Activity1.class);
20 startActivity(intent);
21 return super.onTouchEvent(event);
22 }
23 }
然后我们启动程序，开启Activity1，然后点击Acitivity1，启动另一个Activity1，然后再点击，再点击，再点击... 之后我们点返回键。
发生了什么事情？没错，我们按返回键返回一个又一个相同的Activity1。
standard是Activity默认的加载模式，这种方式用一个词来形容的话就是“拿来主义”。使用这种模式的Activity向所有使用它的Task声明：“我这里的这种Activity多着呢，谁需要的话我就给谁”。所以当一个Task请求加载这个Activity时，该Task直接实例化该Activity，并把它放到栈顶。
因此我们的例子就出现了这样的堆栈结构（假设我们点击了4次）：
| Activity1 |
| Activity1 |
| Activity1 |
| Activity1 |
| Activity1 |
我们设想一个情形：我们要做一个图片浏览器，第一个界面是图片列表界面（假设为PictureListActivity），第二个界面是浏览该张图片（假设为PictureViewActivity）。在PictureViewActivity中可以startActivity启动浏览界面浏览上一张和下一张。
如果每一张图片的浏览启动一个PictureViewActivity（当然你可能不是采用这种方式来浏览上一张和下一张，这里只是举个例子），如果采用standard模式的话，就会出现多个PictureViewActivity在堆栈中堆叠的情形。下面介绍的singleTop便可以解决这个问题。
“拒绝堆叠”——singleTop模式
我们将上面的例子稍加改动，AndroidManifest.xml中Acitivity1的launchMode改为singleTop，Activity1的代码修改如下：
24 public class Activity1 extends Activity {
25 @Override
26 public void onCreate(Bundle savedInstanceState) {
27 super.onCreate(savedInstanceState);
28 setContentView(R.layout.main);
29 //Activity1创建时显示Toast
30 Toast.makeText(this, "onCreate called!", Toast.LENGTH_SHORT).show();
31 }
32
33 @Override
34 protected void onNewIntent(Intent intent) {
35 setTitle("I am Activity1 too, but I called onNewIntent!");
36 super.onNewIntent(intent);
37 }
38
39 //点击进入加载Activity1
40 @Override
41 public boolean onTouchEvent(MotionEvent event) {
42 Intent intent = new Intent(this, Activity1.class);
43 startActivity(intent);
44 return super.onTouchEvent(event);
45 }
46 }
同样，我们启动程序，开启Activity1，然后点击Acitivity1，启动另一个Activity1，然后再点击，再点击，再点击... 之后我们点返回键。
结果，Activity1第一次创建时，显示一个Toast提示，onCreate被调用，当再次点击时，onCreate没有被调用相反是进入了onNewIntent函数。当按返回键时，直接退出了该应用，可见，堆栈中只存在一个Acitivity1。
可见，当activity被设置为singleTop的加载模式时，如果堆栈的顶部已经存在了该Activity，那么，它便不会重新创建，而是调用onNewIntent。如果，该Activity存在，但不是在顶部，那么该Activity依然要重新创建，请读者自行验证。
因此singleTop模式的思想便是“拒绝堆叠”！
以上说的两种加载模式，Activity均可以实例化多次，而下面讲的两个加载模式就只可以实例化一次。
“独立门户”——singleTask模式
我们首先测试一下，在本应用内调用singleTask模式的Activity会出现什么情况。
我们写两个Activity（Activity1和Activity2），相互调用，其中Activity1为singleTask模式。AndroidManifest.xml如下：
47
48
49 android:launchMode="singleTask"
50 android:label="@string/app_name">
51
52
53
54
55
56
57
58
两个Activity的代码如下：
59 /**Activity1的代码*/
60 public class Activity1 extends Activity {
61 private static final String TAG = "Activity1";
62 @Override
63 public void onCreate(Bundle savedInstanceState) {
64 super.onCreate(savedInstanceState);
65 setContentView(R.layout.main);
66 Log.e(TAG, "Activity1 onCreate! HashCode=" + this.hashCode() + " TaskId=" + getTaskId());
67 }
68
69 @Override
70 protected void onNewIntent(Intent intent) {
71 Log.e(TAG, "Activity1 onNewIntent! HashCode="+ this.hashCode() + " TaskId=" + getTaskId());
72 super.onNewIntent(intent);
73 }
74
75 @Override
76 protected void onDestroy() {
77 Log.e("Activity1", "Activity1 onDestroy! HashCode="+this.hashCode()+ "TaskId="+getTaskId());
78 super.onDestroy();
79 }
80
81 /**点击进入Activity2*/
82 @Override
83 public boolean onTouchEvent(MotionEvent event) {
84 Intent intent = new Intent(this, Activity2.class);
85 startActivity(intent);
86 return super.onTouchEvent(event);
87 }
88 }
89 /**Activity2的代码*/
90 public class Activity2 extends Activity {
91 private static final String TAG = "Activity2";
92 @Override
93 protected void onCreate(Bundle savedInstanceState) {
94 super.onCreate(savedInstanceState);
95 setContentView(R.layout.main2);
96 Log.e(TAG, "Activity2 onCreated! HashCode=" + this.hashCode() + " TaskId="+getTaskId());
97 }
98
99 @Override
100 protected void onDestroy() {
101 Log.e(TAG, "Activity2 onDestroy! HashCode="+this.hashCode()+" TaskId="+getTaskId());
102 super.onDestroy();
103 }
104
105 /**点击进入Activity1*/
106 @Override
107 public boolean onTouchEvent(MotionEvent event) {
108 Intent intent = new Intent(this, Activity1.class);
109 startActivity(intent);
110 return super.onTouchEvent(event);
111 }
112 }
从代码中我们可以看出，每当两个Activity创建、销毁以及onNewIntent时，都会打印该Activity的HashCode和所在的Task id。
我们的操作步骤是这样的，打开应用程序，默认启动Activity2，点击Activity2，进入Activity1，再点击Activity1进入Activity2，再点击Activity2进入Activity1，然后按返回键，直到返回到Home。
晕了吧，好写个顺序来形象的表示下：Activity2->Activity1(singleTask)->Activity2->Activity1(singleTask)。^_^
进入Activity2，然后到Activity1，我们看Log信息为：
03-01 14:50:08.144: ERROR/Activity2(371): Activity2 onCreated! HashCode=1156067168 TaskId=7
03-01 14:50:13.923: ERROR/Activity1(371): Activity1 onCreate! HashCode=1156107384 TaskId=7
我们看到，当本应用启动singleTask的Activity（Activity1）时，Activity1并没用另外启用一个任务。而是在原来的任务中创建了它。
再从Activity1进入Activity2，然后再进入Activity1，这个过程，我们再看log信息：
03-01 14:53:50.823: ERROR/Activity2(371): Activity2 onCreated! HashCode=1156128904 TaskId=7
03-01 14:53:58.154: ERROR/Activity1(371): Activity1 onNewIntent! HashCode=1156107384 TaskId=7
03-01 14:53:58.394: ERROR/Activity2(371): Activity2 onDestroy! HashCode=1156128904 TaskId=7
从这个Log信息我们可以得到这个结论：当singleTask模式的Activity启动时，如果发现在某个Task中已经存在，那么它会先将该Activity（Activity1）上部的Activity（Activity2）销毁，然后调用它（Activity1）的onNewIntent函数。
我们下面来研究一下当singleTask的Activity被其他应用调用时的情况。
为了使Activity1能够被其他应用程序调用，我们在AndroidManifest.xml中加入action，如下：
113
114 android:launchMode="singleTask"
115 android:label="@string/app_name">
116
117
118
119
120
然后我们另外创建一个工程，创建一个Activity在初始化的时候启动Activity1，代码如下：
121 public class MyActivity extends Activity {
122 @Override
123 public void onCreate(Bundle savedInstanceState) {
124 super.onCreate(savedInstanceState);
125 setContentView(R.layout.main);
126 Log.e("MyActivity", "TaskId=" + getTaskId());
127 Intent intent = new Intent("com.winuxxan.singleTask");
128 startActivity(intent);
129 }
130 }
我们的操作方法是，MyActivity->Activity1->Activity2->Activity1，之后我们按Home键，然后再从Home重新进入MyActivity所在的应用。
首先看MyActivity->Activity1这个过程，我们查看Log信息如下：
03-01 15:04:25.784: ERROR/MyActivity(429): TaskId=9
03-01 15:04:26.244: ERROR/Activity1(401): Activity1 onCreate! HashCode=1156107632 TaskId=10
从这个Log信息我们可以看出：当某个应用调用其他应用里声明的singleTask模式的Activity时，它会重新创建一个Task，然后将该Activity实例化并压入堆栈。
接着我们看Activity1和Activity2的相互切换，log信息如下：
03-01 15:04:47.524: ERROR/Activity2(401): Activity2 onCreated! HashCode=1156128104 TaskId=10
03-01 15:04:50.674: ERROR/Activity1(401): Activity1 onNewIntent! HashCode=1156107632 TaskId=10
03-01 15:04:50.994: ERROR/Activity2(401): Activity2 onDestroy! HashCode=1156128104 TaskId=10
和我们所期望的那样，如果Activity发现已经存在时，会销毁其上的Activity，然后调用onNewIntent。
之后，我们按Home键，返回桌面，然后，再次进入该应用，我们神奇的发现，我们进入的是MyActivity界面，taskId为10的所有Activity不知了踪影！
这是因为，该应用对应的task的id为9，所以，进入后之后MyActivity在该task中，所以最后显示的是MyActivity。我的以上Activity1的代码实际上是不好的习惯，因为Activity1很可能会成为一个孤岛，所以建议，如果该Activity的类型不是LAUNCHER,最好不要设为singleTask。
那么singleTask的这些特性有什么用处？我们举一个例子，浏览器就是一个singleTask的例子，启动一个浏览器，在Android中是一个比较沉重的过程，它需要做很多初始化的工作，并且会有不小的内存开销。如果有多个应用都来请求打开网页，那么系统就不会不堪重负。因此，如果浏览器采用singleTask模式，如果有多个请求打开网页的请求，都会在一个Task中响应，这样就会避免以上的情况。
“孤独寂寞”——singleInstance模式
我们现在来研究最后一个加载模式，singgleInstance，测试很简单，我们只要在singleTask测试的例子中，将Activity1的模式改为singleInstance模式即可。
我们首先进行同一应用内部的测试。
首先Activity2->Activity1，观察log信息：
03-01 15:41:59.283: ERROR/Activity2(488): Activity2 onCreated! HashCode=1156067168 TaskId=12
03-01 15:42:04.103: ERROR/Activity1(488): Activity1 onCreate! HashCode=1156107520 TaskId=13
我们发现，当采用singleInstance模式时，启动时创建了一个新的Task，并将Activity1实例化加入到该Task中。
然后我们Activity1->Activity2->Activity1，观察log信息：
03-01 15:43:52.214: ERROR/Activity2(488): Activity2 onCreated! HashCode=1156127728 TaskId=12
03-01 15:43:56.804: ERROR/Activity1(488): Activity1 onNewIntent! HashCode=1156107520 TaskId=13
我们通过该log信息可以得出结论：singleInstance的Activity（Activity1）不允许其他的Activity（Activity2）加入到自己的Task中，它是的内心容不下另一个人，它是一个孤独寂寞的人。 当Activity1发现已经存在一个Task中包含自己的实例时，它会调用自己的onNewIntent。
然后，我们同样也测试一下，如果其它应用程序调用Activity1会出现什么样的情况：
MyActivity->Activity1, 观察log信息：
03-01 15:50:21.134: ERROR/MyActivity(556): TaskId=16
03-01 15:50:21.484: ERROR/Activity1(534): Activity1 onCreate! HashCode=1156107344 TaskId=17
不出意料，Activity1重新创建了一个Task，并将自己的实例入栈。
Activity1->Activity2->Activity1->Activity2, 我们观察log信息：
03-01 15:50:36.484: ERROR/Activity2(534): Activity2 onCreated! HashCode=1156128056 TaskId=18
03-01 15:50:46.114: ERROR/Activity1(534): Activity1 onNewIntent! HashCode=1156107344 TaskId=17
我们从该过程可以看出：如果从其它应用程序调用singleInstance模式的Activity（Activity1），从该Activity开启其他Activity（Activity2）时，会创建一个新的Task（task id为18的那个），实际上，如果包含该Activity（Activity2）的Task已经运行的话，他会在该运行的Task中重新创建。
OK，上面啰嗦了那么多，如果这部分不是很清楚的人，可能已经头昏脑胀了。那我们总结一下吧，这总该看看了吧。
“拿来主义”standard模式。哪里需要调用我我就去哪里，可以多次实例化，可以几个相同的Activity重叠。
“拒绝堆叠”singleTop模式。可以多次实例化，但是不可以多个相同的Activity重叠，当堆栈的顶部为相同的Activity时，会调用onNewIntent函数。
“独立门户”singleTask模式。同一个应用中调用该Activity时，如果该Activity没有被实例化，会在本应用程序的Task内实例化，如果已经实例化，会将Task中其上的Activity销毁后，调用onNewIntent；其它应用程序调用该Activity时，如果该Activity没有被实例化，会创建新的Task并实例化后入栈，如果已经实例化，会销毁其上的Activity，并调用onNewIntent。一句话，singleTask就是“独立门户”，在自己的Task里，并且启动时不允许其他Activity凌驾于自己之上。
“孤独寂寞”singleInstance模式。加载该Activity时如果没有实例化，他会创建新的Task后，实例化入栈，如果已经存在，直接调用onNewIntent，该Activity的Task中不允许启动其它的Activity，任何从该Activity启动的其他Activity都将被放到其他task中，先检查是否有本应用的task，没有的话就创建。
附：由于android文档中的解释不是很清楚，所以做了上述测试，结论也是根据测试得出的结论，singleTask和singInstance的任务创建还跟taskAffience有关，
=====================================================
android:allowTaskReparenting
用来标记Activity能否从启动的Task移动到有着affinity的Task（当这个Task进入到前台时）——“true”，表示能移动，“false”，表示它必须呆在启动时呆在的那个Task里。
如果这个特性没有被设定，设定到
一般来说，当Activity启动后，它就与启动它的Task关联，并且在那里耗尽它的整个生命周期。当当前的Task不再显示时，你可以使用这个特性来 强制Activity移动到有着affinity的Task中。典型用法是：把一个应用程序的Activity移到另一个应用程序的主Task中。
例如，如果e－mail中包含一个web页的链接，点击它就会启动一个Activity来显示这个页面。这个Activity是由Browser应用程序 定义的，但是，现在它作为e－mail Task的一部分。如果它重新宿主到Browser Task里，当Browser下一次进入到前台时，它就能被看见，并且，当e－mail Task再次进入前台时，就看不到它了。
Actvity的affinity是由taskAffinity特性定义的。Task的affinity是通过读取根Activity的affinity 决定。因此，根据定义，根Activity总是位于相同affinity的Task里。由于启动模式为“singleTask”和 “singleInstance”的Activity只能位于Task的底部，因此，重新宿主只能限于“standard”和“singleTop”模 式。
android:alwaysRetainTaskState
用来标记Activity所在的Task的状态是否总是由系统来保持——“true”，表示总是；“false”，表示在某种情形下允许系统恢复Task 到它的初始化状态。默认值是“false”。这个特性只针对Task的根Activity有意义；对其它Activity来说，忽略之。
一般来说，特定的情形如当用户从主画面重新选择这个Task时，系统会对这个Task进行清理（从stack中删除位于根Activity之上的所有Activivity）。典型的情况，当用户有一段时间没有访问这个Task时也会这么做，例如30分钟。
然而，当这个特性设为“true”时，用户总是能回到这个Task的最新状态，无论他们是如何启动的。这非常有用，例如，像Browser应用程序，这里有很多的状态（例如多个打开的Tab），用户不想丢失这些状态。
android:clearTaskOnLaunch
用来标记是否从Task中清除所有的Activity，除了根Activity外（每当从主画面重新启动时）——“true”，表示总是清除至它的根 Activity，“false”表示不。默认值是“false”。这个特性只对启动一个新的Task的Activity（根Activity）有意义； 对Task中其它的Activity忽略。
当这个值为“true”，每次用户重新启动这个Task时，都会进入到它的根Activity中，不管这个Task最后在做些什么，也不管用户是使用 BACK还是HOME离开的。当这个值为“false”时，可能会在一些情形下（参考alwaysRetainTaskState特性）清除Task的 Activity，但不总是。
假设，某人从主画面启动了Activity P，并从那里迁移至Activity Q。接下来用户按下HOME，然后返回Activity P。一般，用户可能见到的是Activity Q，因为它是P的Task中最后工作的内容。然而，如果P设定这个特性为“true”，当用户按下HOME并使这个Task再次进入前台时，其上的所有的 Activity(在这里是Q)都将被清除。因此，当返回到这个Task时，用户只能看到P。
如果这个特性和allowTaskReparenting都设定为“true”，那些能重新宿主的Activity会移动到共享affinity的Task中；剩下的Activity都将被抛弃，如上所述。
android:finishOnTaskLaunch
用来标记当用户再次启动它的Task（在主画面选择这个Task）时已经存在的Activity实例是否要关闭（结束）——“true”，表示应该关闭，“false”表示不关闭。默认值是“false”。
如果这个特性和allowTaskReparenting都设定为“true”，这个特性胜出。Activity的affinity忽略。这个Activity不会重新宿主，但是会销毁。
android:launchMode
用于指示Activity如何启动。这里有四种模式，与Intent对象中的Activity Flags（FLAG_ACTIVITY_*变量）共同作用，来决定Activity如何启动来处理Intent。它们是：
"standard"
"singleTop"
"singleTask"
"singleInstance"
默认模式是“standard”。
这些模式可以分成两大组别，“standard”和“singleTop”一组，“singleTask”和“singleInstance”一组。具有 “standard”和“singleTop”启动模式的Activity可以实例化很多次。这些实例可以属于任何Task并且可以位于Activity stack的任何位置。典型的情况是，它们会进入调用startActivity()的Task（除非Intent对象包含 FLAG_ACTIVITY_NEW_TASK标志，在这种情况下会选择一个不同的Task——参考taskAffinity特性）。
相反的，“singleTask”和“singleInstance”只能启动一个Task。它们总是位于Activity stack的底部。甚至，设备一次只能拥有一个Activity的实例——只有一个这样的Task。
“standard”和“singleTop”模式只在一种情况下有差别：每次有一个新的启动“standard”Activity的Intent，就会 创建一个新的实例来响应这个Intent。每个实例处理一个Intent。相似的，一个“singleTop”的Activity实例也有可能被创建来处 理新的Intent。然而，如果目标Task已经有一个存在的实例并且位于stack的顶部，那么，这个实例就会接收到这个新的Intent（调用 onNewIntent()）；不会创建新的实例。在其他情况下——例如，如果存在的“singleTop”的Activity实例在目标Task中，但 不是在stack的顶部，或者它在一个stack的顶部，但不是在目标Task中——新的实例都会被创建并压入stack中。
“singleTask”和“singleInstance”模式也只在一种情况下有差别：“singleTask”Activity允许其它 Activity成为它的Task的部分。它位于Activity stack的底部，其它Activity（必须是“standard”和“singleTop”Activity）可以启动加入到相同的Task中。 “singleInstance”Activity，换句话说，不允许其它Activity成为它的Task的部分。它是Task中的唯一 Activity。如果它启动其它的Activity，这个Activity会被放置到另一个task中——好像Intent中包含了 FLAG_ACTIVITY_NEW_TASK标志。
android:noHistory
用于标记当用户从Activity上离开并且它在屏幕上不再可见时Activity是否从Activity stack中清除并结束（调用finish()方法）——“true”，表示它应该关闭，“false”，表示不需要。默认值是“false”。
“true”值意味着Activity不会留下历史痕迹。因为它不会在Activity stack的Task中保留，因此，用户不能返回它。
android:taskAffinity
Activity为Task拥有的一个affinity。拥有相同的affinity的Activity理论上属于相同的Task（在用户的角度是相同的“应用程序”）。Task的affinity是由它的根Activity决定的。
affinity决定两件事情——Activity重新宿主的Task（参考allowTaskReparenting特性）和使用FLAG_ACTIVITY_NEW_TASK标志启动的Activity宿主的Task。
默认情况，一个应用程序中的所有Activity都拥有相同的affinity。捏可以设定这个特性来重组它们，甚至可以把不同应用程序中定义的Activity放置到相同的Task中。为了明确Activity不宿主特定的Task，设定该特性为空的字符串。
如果这个特性没有设置，Activity将从应用程序的设定那里继承下来（参考
FLAG_ACTIVITY_BROUGHT_TO_FRONT
这个标志一般不是由程序代码设置的，如在launchMode中设置singleTask模式时系统帮你设定。
FLAG_ACTIVITY_CLEAR_TOP
如果设置，并且这个Activity已经在当前的Task中运行，因此，不再是重新启动一个这个Activity的实例，而是在这个Activity上方 的所有Activity都将关闭，然后这个Intent会作为一个新的Intent投递到老的Activity（现在位于顶端）中。
例如，假设一个Task中包含这些Activity：A，B，C，D。如果D调用了startActivity()，并且包含一个指向Activity B的Intent，那么，C和D都将结束，然后B接收到这个Intent，因此，目前stack的状况是：A，B。
上例中正在运行的Activity B既可以在onNewIntent()中接收到这个新的Intent，也可以把自己关闭然后重新启动来接收这个Intent。如果它的启动模式声明为 “multiple”(默认值)，并且你没有在这个Intent中设置FLAG_ACTIVITY_SINGLE_TOP标志，那么它将关闭然后重新创 建；对于其它的启动模式，或者在这个Intent中设置FLAG_ACTIVITY_SINGLE_TOP标志，都将把这个Intent投递到当前这个实 例的onNewIntent()中。
这个启动模式还可以与FLAG_ACTIVITY_NEW_TASK结合起来使用：用于启动一个Task中的根Activity，它会把那个Task中任 何运行的实例带入前台，然后清除它直到根Activity。这非常有用，例如，当从Notification Manager处启动一个Activity。
FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET
如果设置，这将在Task的Activity stack中设置一个还原点，当Task恢复时，需要清理Activity。也就是说，下一次Task带着 FLAG_ACTIVITY_RESET_TASK_IF_NEEDED标记进入前台时（典型的操作是用户在主画面重启它），这个Activity和它之 上的都将关闭，以至于用户不能再返回到它们，但是可以回到之前的Activity。
这在你的程序有分割点的时候很有用。例如，一个e-mail应用程序可能有一个操作是查看一个附件，需要启动图片浏览Activity来显示。这个 Activity应该作为e-mail应用程序Task的一部分，因为这是用户在这个Task中触发的操作。然而，当用户离开这个Task，然后从主画面 选择e-mail app，我们可能希望回到查看的会话中，但不是查看图片附件，因为这让人困惑。通过在启动图片浏览时设定这个标志，浏览及其它启动的Activity在下 次用户返回到mail程序时都将全部清除。
FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS
如果设置，新的Activity不会在最近启动的Activity的列表中保存。
FLAG_ACTIVITY_FORWARD_RESULT
如果设置，并且这个Intent用于从一个存在的Activity启动一个新的Activity，那么，这个作为答复目标的Activity将会传到这个 新的Activity中。这种方式下，新的Activity可以调用setResult(int)，并且这个结果值将发送给那个作为答复目标的 Activity。
FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY
这个标志一般不由应用程序代码设置，如果这个Activity是从历史记录里启动的（常按HOME键），那么，系统会帮你设定。
FLAG_ACTIVITY_MULTIPLE_TASK
不要使用这个标志，除非你自己实现了应用程序启动器。与FLAG_ACTIVITY_NEW_TASK结合起来使用，可以禁用把已存的Task送入前台的 行为。当设置时，新的Task总是会启动来处理Intent，而不管这是是否已经有一个Task可以处理相同的事情。
由于默认的系统不包含图形Task管理功能，因此，你不应该使用这个标志，除非你提供给用户一种方式可以返回到已经启动的Task。
如果FLAG_ACTIVITY_NEW_TASK标志没有设置，这个标志被忽略。
FLAG_ACTIVITY_NEW_TASK
如果设置，这个Activity会成为历史stack中一个新Task的开始。一个Task（从启动它的Activity到下一个Task中的 Activity）定义了用户可以迁移的Activity原子组。Task可以移动到前台和后台；在某个特定Task中的所有Activity总是保持相 同的次序。
这个标志一般用于呈现“启动”类型的行为：它们提供用户一系列可以单独完成的事情，与启动它们的Activity完全无关。
使用这个标志，如果正在启动的Activity的Task已经在运行的话，那么，新的Activity将不会启动；代替的，当前Task会简单的移入前台。参考FLAG_ACTIVITY_MULTIPLE_TASK标志，可以禁用这一行为。
这个标志不能用于调用方对已经启动的Activity请求结果。
FLAG_ACTIVITY_NO_ANIMATION
如果在Intent中设置，并传递给Context.startActivity()的话，这个标志将阻止系统进入下一个Activity时应用 Acitivity迁移动画。这并不意味着动画将永不运行——如果另一个Activity在启动显示之前，没有指定这个标志，那么，动画将被应用。这个标 志可以很好的用于执行一连串的操作，而动画被看作是更高一级的事件的驱动。
FLAG_ACTIVITY_NO_HISTORY
如果设置，新的Activity将不再历史stack中保留。用户一离开它，这个Activity就关闭了。这也可以通过设置noHistory特性。
FLAG_ACTIVITY_NO_USER_ACTION
如果设置，作为新启动的Activity进入前台时，这个标志将在Activity暂停之前阻止从最前方的Activity回调的onUserLeaveHint()。
典型的，一个Activity可以依赖这个回调指明显式的用户动作引起的Activity移出后台。这个回调在Activity的生命周期中标记一个合适的点，并关闭一些Notification。
如果一个Activity通过非用户驱动的事件，如来电或闹钟，启动的，这个标志也应该传递给Context.startActivity，保证暂停的Activity不认为用户已经知晓其Notification。
FLAG_ACTIVITY_PREVIOUS_IS_TOP
If set and this intent is being used to launch a new activity from an existing one, the current activity will not be counted as the top activity for deciding whether the new intent should be delivered to the top instead of starting a new one. The previous activity will be used as the top, with the assumption being that the current activity will finish itself immediately.
FLAG_ACTIVITY_REORDER_TO_FRONT
如果在Intent中设置，并传递给Context.startActivity()，这个标志将引发已经运行的Activity移动到历史stack的顶端。
例如，假设一个Task由四个Activity组成：A,B,C,D。如果D调用startActivity()来启动Activity B，那么，B会移动到历史stack的顶端，现在的次序变成A,C,D,B。如果FLAG_ACTIVITY_CLEAR_TOP标志也设置的话，那么这 个标志将被忽略。
FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
If set, and this activity is either being started in a new task or bringing to the top an existing task, then it will be launched as the front door of the task. This will result in the application of any affinities needed to have that task in the proper state (either moving activities to or from it), or simply resetting that task to its initial state if needed.
FLAG_ACTIVITY_SINGLE_TOP
如果设置，当这个Activity位于历史stack的顶端运行时，不再启动一个新的。
Activity和Task
之前提到的，一个Activity可以启动另一个，即便是定义在不同应用程序中的Activity。例如，假设你想让用户显示一些地方的街景。而这里已经有一个Activity可以做到这一点，因此，你的Activity所需要做的只是在Intent对象中添加必要的信息，并传递给startActivity()。地图浏览将会显示你的地图。当用户按下BACK键，你的Activity会再次出现在屏幕上。
对于用户来说，看起来好像是地图浏览与你的Activity一样，属于相同的应用程序，即便是它定义在其它的应用程序里，并运行在那个应用程序的进程里。Android通过将这两个Activity保存在同一个Task里来体现这一用户体验。简单来说，一个Task就是用户体验上的一个“应用”。它将相关的Activity组合在一起，以stack的方式管理。stack中根Activity启动Task——典型的，它就是用户在应用程序启动栏中选择的Activity。位于stack顶端的Activity是当前正在运行的——能够聚焦用户的动作。当一个Activity启动另一个，新的Activity进入stack；它成为正在运行的Activity。之前的Activity仍保留在stack中。当用户按下BACK键，当前的Activity从stack中退出，之前的那个成为正在运行的Activity。
stack包含对象，因此，如果一个Task中有多个同一个Activity的实例时——多个地图浏览，例如——stack为每个实例拥有一个独立的入口。位于stack中的Activity不会重新调整，只是进入和退出。
一个Task就是一组Activity，不是一个类或者在manifest中定义的一个元素。因此，没有办法为Task设置独立于它的Activity的属性值。Task的值作为整体在根Activity中设置。例如，下一个章节会讨论Task的“affinity”；那个值就是从Task中的根Activity中读取的。
Task中的所有Activity作为一个单元一起移动。整个Task（整个Activity stack）可以进入前台或者退到后台。例如，假设当前Task中的stack中有4个Activity——3个位于当前Activity下方。用户按下HOME键，进入到应用程序启动栏，然后选择一个新的应用程序（实际上，一个新的Task）。当前Task退到后台，并且新Task中的根Activity会显示出来。然后，经过一段时间后，用户回到Home画面，然后再次选择前一个应用程序（前一个Task）。那个拥有4个Activity的Task会进入前台。当用户按下BACK键，屏幕不会显示用户刚刚离开的Activity（前一个Task的根Activity）。而是，这个stack中的顶端Activity移除，相同Task中的前一个Activity会显示出来。
刚才描述的行为是Activity和Task的默认行为。但有方法来完全改变它。Task之间的关联，和一个Task中的一个Activity行为，受启动Activity的Intent对象中设置的Flag和manifest文件中Activity的
核心的Intent Flag有：
FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
FLAG_ACTIVITY_SINGLE_TOP
核心的
taskAffinity
launchMode
allowTaskReparenting
clearTaskOnLaunch
alwaysRetainTaskState
finishOnTaskLaunch
接下来的章节将描述一些Flag和特性的用法，如何相互影响，以及在使用时的建议。
Affinity和新Task
默认情况下，一个应用程序中的所有Activity都有affinity——也就是说，属于同一个Task中所有Activity有一个设定。然而，每个Activity都可以在
FLAG_ACTIVITY_NEW_TASK:
之前描述的，一个Activity一般通过调用startActivity()启动并加入到Task中。它同调用者一样，进入同一个Task。然而，如果传递给startActivity()的Intent对象中包含FLAG_ACTIVITY_NEW_TASK时，系统会搜索一个新的Task来容纳新的Activity。通常，如标志的名字所示，是一个新的Task。然而，并不是必须是。如果已经存在一个Task与新Activity的affinity相同，这个Activity就会加入到那个Task中。如果不是，启动一个新的Task。
allowTaskReparenting：
如果一个Activity的allowTaskReparenting特性设置为“true”，它就能从启动的Task中移到有着相同affinity的Task（这个Task进入到前台的时候）。例如，在一个旅游的程序中定义了一个可以报告选择城市的天气情况的Activity。它和同一个应用程序的其它Activity一样，有着相同的Affinity（默认的Affinity），并且它允许重新宿主。你的Activity中的一个启动了天气预报，因此，它初始化到和你Activity相同的Task中。然而，当旅游应用程序下一次进入到前台时，天气预报那个Activity将会重新编排并在那个Task中显示。
如果从用户的角度出发，一个.apk文件包含多个“应用”的话，你可能希望为关联的Activity设置不同的affinity。
Launch Mode
这里4种不同的启动模式可以设置到
standard（默认模式）
singleTop
singleTask
singleInstance
这些模式有以下四点区别：
l 哪个Task将容纳响应Intent的Activity。对于“standard”和“singleTop”来说，是产生Intent的那个Task（并调用startActivity()）——除非Intent对象包含FLAG_ACTIVITY_NEW_TASK。在那种情况下，不同的Task将被选择，如“Affinity和新Task”中描述的那样。对比而言，“singleTask”和“singleInstance”指示Activity总是一个Task的根。它们定义一个Task；它们不会加入到另一个Task中。
l 是否有多个Activity的实例。“standard”和“singleTop”可以实例化多次。它们可以属于多个Task，一个特定的Task可以有相同Activity的多个实例。对比而言，“singleTask”和“singleInstance”只能有一个实例。因为这些Activity只能位于Task的底部，这一限制意味着在设备的某个时间，不会出现这样Task的多个实例。
l 是否可以在同一个Task中拥有其它的Activity。“singleInstance”Activity保持单身，在它的Task中它是仅有的Activity。如果它启动另一个Activity，那个Activity将会放入到不同的Task中，而不管它的启动模式——好像FLAG_ACTIVITY_NEW_TASK在Intent中一样。对于其它方面，，“singleInstance”等同于“singleTask”。其它三个模式允许多个Activity加入到这个Task中。“singleTask”Activity总是位于Task的底部，但它可以启动其它的Activity并放入到它的Task中。“standard”和“singleTop”的Activity可以出现在stack的任何地方。
l 是否一个新的实例启动来处理新的Intent。对于默认的“standard”来说，都是创建一个新的实例来响应新的Intent。每个实例处理一个Intent。对于“singleTop”来说，如果它位于目标Task的顶端，那么，已经存在的实例就可以重复使用来处理这个新的Intent。如果它不在顶端，那么它就不能重复使用。替代的，新的实例将创建来响应新的Intent，并进入到stack中。
例如，假设一个Task的Activity stack中包含根Activity A和其它Activity B，C，D，并且D位于顶端，因此，stack是A-B-C-D。有一个Intent来了，它要启动D类型的Activity。如果D有默认的“standard”启动模式，那么，一个新的实例将被启动并且stack变成A-B-C-D-D。然而，如果D的启动模式“singleTop”，已经存在的实例将去处理新来的Intent（因为它正好处在stack的顶端），并且stack依旧是A-B-C-D。
换句话说，如果来临的Intent是冲着B类型的，那么，B类型的实例将被创建启动而不管B的模式是“standard”或“singleTop”（因为B不处在stack的顶端），因此，stack将会是A-B-C-D-B。
之前提到的，设备上不会出现超过一个实例的“singleTask”或“singleInstance”Activity，因此，那个实例都将去处理所有新来的Intent。“singleInstance”Activity总是位于stack的顶端（因为它是task中唯一的Activity），因此，它总是处于能处理Intent的位置。然而，“singleTask”Activity可能有或没有其它Activity处于它的上方。如果有，它就不处于能处理Intent的位置，那么，这个Intent将被丢弃。（即使Intent被丢弃了，它的到来会引发那个Task进入到前台，在那里，它会继续保留。）
当一个存在的Activity请求去处理一个新的Intent时，Intent对象将传到该Activity的onNewIntent()的方法中。（原来启动Activity的Intent对象可以通过调用getIntent()得到。）
注意：当一个新的实例创建来处理新的Intent时，用户可以按下BACK键返回到之前的状态（前一个Activity）。但一个存在的实例来处理新的Intent时，用户不能按下BACK键返回到新Intent到来之前的状态。
清除stack
如果用户离开Task很长一段时间，系统会清除Task中的所有Activity，除根Activity外。当用户再次返回到这个Task时，和用户离开时一样，仅仅只是初始化Activity呈现。这样做的意图是，经过一些时间后，用户可能已经忘记之前正在做的事情，并且打算回到Task开始些新的时期。
这是默认情况。这里有一些Activity特性可以用于控制这一行为并且修改它：
alwaysRetainTaskState：
如果Task的根Activity的这个特性设置为“true”时，上面描述的默认行为不会发生。Task保留所有的Activity，即便是经过很长一段时间。
clearTaskOnLaunch：
如果Task的根Activity的这个特性设置为“true”时，当用户离开Task并返回时，stack会清除直到根Activity。换句话说，它是alwaysRetainTaskState的另一个极端。用户总是回到Task的初始化状态，即便是一个短暂的离开。
finishOnTaskLaunch：
这个特性和clearTaskOnLaunch相似，但它针对单个Activity，不是整个Task。它能使任何Activity消失，包括根Activity。当它设置为“true”时，这个Activity仅在当前会话期间保持为Task的部分。如果用户离开并再次返回到这个Task，它就不再显示了。
这里还有其它的方式可以强制Activity从stack中移除。如果Intent对象中包含FLAG_ACTIVITY_CLEAR_TOP标志，并且目标Task中已经有一个这个类型Activity的实例，而且这个实例应该处理这个Intent，那么，位于其上的Activity都将移除，这样，这个Activity就能在stack的顶端并响应这个Intent。如果这个Activity的启动模式设定为“standard”，它也会从stack中清除，然后新的实例启动来响应这个Intent。这是因为当启动模式设定为“standard“时，总是会创建一个新的实例来响应新的Intent。
FLAG_ACTIVITY_CLEAR_TOP经常与FLAG_ACTIVITY_NEW_TASK结合起来使用。当一起使用时，这些标志可以定位其它Task中已经存在的Activity，并且把它置于可以响应Intent的位置。
启动Task
如果一个Activity的Intent Filter的action为“android.intent.action.MAIN”、category为“android.intent.category.LAUNCHER”时，它就可以作为一个Task的入口点。有这种类型的Filter会在导致这个Activity在应用程序启动栏显示一个图标和标签，给用户提供一个方式可以启动这个Task和在任何时候可以再次回到这个Task。
第二个能力很重要：用户一定可以离开一个Task，然后可以再次回到它。基于这个原因，两个启动模式，“singleTask”和“singleInstance”应该只在有MAIN和LAUNCHER的Activity上使用。例如，假设这个Filter没有的话：一个Intent启动了一个“singleTask”Activity，初始化一个新的Task，然后用户花费了一些时间在它上面。然后，用户按下HOME键。现在，这个Task处于后台并且被HOME画面遮盖。由于它不能在应用程序启动栏显示，用户就没有办法可以返回它。
在面对FLAG_ACTIVITY_NEW_TASK时，也有相似的困难。如果这个标志导致一个Activity启动了一个新的Task，并且用户按下HOME键离开它，这里必须有方法可以再次回到它。一些机能（如Notification Manager）总是在外部的Task中启动Activity，而不是作为自己的一部分，因此，它总是把FLAG_ACTIVITY_NEW_TASK标志放入Intent，然后传递给startActivity()。如果你的Activity可能会被外部的机能（可能使用这个标志）调用，注意用户可以额外的方式可以返回到启动的Task。
如果你不想用户回到某个Activity，可以把
参考文档
Android官网启动模式