1.任务栈简介
1). android任务栈又称为Task，它是一个栈结构，具有后进先出的特性，用于存放我们的Activity组件。
2). 我们每次打开一个新的Activity或者退出当前Activity都会在一个称为任务栈的结构中添加或者减少一个Activity组件，因此一个任务栈包含了一个activity的集合, android系统可以通过Task有序地管理每个activity，并决定哪个Activity与用户进行交互:只有在任务栈栈顶的activity才可以跟用户进行交互。
3). 在我们退出应用程序时，必须把所有的任务栈中所有的activity清除出栈时,任务栈才会被销毁。当然任务栈也可以移动到后台, 并且保留了每一个activity的状态. 可以有序的给用户列出它们的任务, 同时也不会丢失Activity的状态信息。
4). 需要注意的是，一个App中可能不止一个任务栈，某些特殊情况下，单独一个Actvity可以独享一个任务栈。还有一点就是一个Task中的Actvity可以来自不同的App，同一个App的Activity也可能不在一个Task中。
2.Activity的启动模式
2.1 Standard 模式
又称为标准模式，也是系统的默认模式（可以不指定），在这样模式下，每启动一个Activity都会重新创建一个Activity的新实例，并且将其加入任务栈中，谁启动了这个Activity，那么这个Activity就运行在启动它的那个Activity所在的栈中。而且完全不会去考虑这个实例是否已存在。我们通过图解来更清晰地了解Standard模式：
2.2singleTop 模式
又称栈顶复用模式，顾名思义，在这种模式下，如果有新的Activity已经存在任务栈的栈顶，那么此Activity就不会被重新创建新实例，而是复用已存在任务栈栈顶的Activity。这里重点是位于栈顶，才会被复用，如果新的Activity的实例已存在但没有位于栈顶，那么新的Activity仍然会被重建。需要注意的是，Activity的onNewIntent方法会被调用，方法原型如下：
@Override
protected void onNewIntent(Intent intent) {
super.onNewIntent(intent);
}
这种模式通常比较适用于接收到消息后显示的界面，如qq接收到消息后弹出Activity界面，如果一次来10条消息，总不能一次弹10个Activity，是吧？再比如新闻客户端收到了100个推送，你每次点一下推送他都会进入某个activiy界面（显示新闻只用一个activity，只是内容不同而已），这时也比较适合使用singleTop模式。
2.3 singleTask 模式
又称为栈内复用模式。这是一种单例模式，与singTop点类似，只不过singTop是检测栈顶元素是否有需要启动的Activity，而singTask则是检测整个栈中是否存在当前需要启动的Activity，如果存在就直接将该Activity置于栈顶，并将该Activity以上的Activity都从任务栈中移出销毁，同时也会回调onNewIntent方法。情况如下图：
从图中可以看出，当我们再次启动MainActivity时，由于MainActivity位于栈中，所以系统直接将其置于栈顶，并移除其上方的所有Activity。当然如果所需要的MainActivity不存在栈中，则会创建新的Activity并添加到栈中。singleTask 模式比较适合应用的主界面activity（频繁使用的主架构），可以用于主架构的activity，（如新闻，侧滑，应用主界面等）里面有好多fragment，一般不会被销毁，它可以跳转其它的activity 界面再回主架构界面，此时其他Activity就销毁了
2.4 singleInstance 模式
在singleInstance模式下，该Activity在整个android系统内存中有且只有一个实例，而且该实例单独尊享一个Task。换句话说，A应用需要启动的MainActivity 是singleInstance模式，当A启动后，系统会为它创建一个新的任务栈，然后A单独在这个新的任务栈中，如果此时B应用也要激活MainActivity，由于栈内复用的特性，则不会重新创建，而是两个应用共享一个Activity的实例。如下图所示：
从图中我们可以看到最终AB应用都共享一个singleInstance模式的MainActivity，也没有去重新创建。到此Activity的四种启动模式我们都介绍完了，下面我们接着来聊聊怎么使用启动模式。
3.Activity启动模式的使用方式
1.通过AndroidMenifest.xml文件为Activity指定启动模式，代码如下：
<activity android:name=".ActivityC"
android:launchMode="singleTask" />
Intent intent = new Intent();
intent.setClass(ActivityB.this,ActivityA.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);Intent Flag 启动模式
Intent.FLAG_ACTIVITY_NEW_TASK该标志位表示使用一个新的Task来启动一个Activity，相当于在清单文件中给Activity指定“singleTask”启动模式。通常我们在Service启动Activity时，由于Service中并没有Activity任务栈，所以必须使用该Flag来创建一个新的Task。
-
Intent.FLAG_ACTIVITY_SINGLE_TOP
该标志位表示使用singleTop模式来启动一个Activity，与在清单文件指定android:launchMode="singleTop"效果相同。 -
Intent.FLAG_ACTIVITY_CLEAR_TOP
该标志位表示使用singleTask模式来启动一个Activity，与在清单文件指定android：launchMode="singleTask"效果相同。 -
Intent.FLAG_ACTIVITY_NO_HISTORY
使用该模式来启动Activity，当该Activity启动其他Activity后，该Activity就被销毁了，不会保留在任务栈中。如A-B,B中以这种模式启动C，C再启动D，则任务栈只有ABD。 -
Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS
使用该标识位启动的Activity不添加到最近应用列表，也即我们从最近应用里面查看不到我们启动的这个activity。与属性android:excludeFromRecents="true"效果相同。
前面我们在分析singleTask模式时，提到过singleTask模式有些比较特殊的场景，现在我们就来了解了解它们。
特殊情景一:现在我们假设有如下两个Task栈,分别为前台任务栈和后台任务栈
从图中我们看出前台任务栈分别为AB两个Activity，后台任务栈分别为CD两个任务栈，而且其启动模式均为singleTask，此时我们先启动CD，然后再启动AB，再有B启动D，此时后台任务栈便会被切换到前台，而且这个时候整个后退列表就变成了ABCD，请注意我们这里强调的是后退列表，而非栈合并。因此当用户点击back键时，列表中的Activity会依次按DCBA顺序出栈，如下图所示：
这里我们通过两个应用ActivityTask和ActivityTask2来测试重现这个现象。因为两个是不同的应用所以启动时所在的栈也是不同。我们先启动ActivityTask2的应用，其ActivityC和ActivityD都是singleTask模式，然后再启动应用ActivityTask，此时ActivityC和ActivityD所在任务栈会被退居后台，而打开的ActivityA和ActivityB会在前台，而且都是默认模式。我们通过 adb shell dumpsys activity activities 命令查看此时栈的情况：
我们可以看到由两个栈，分别为id=222且栈名为“com.cmcm.activitytask”的任务栈其包含ActivityA和ActivityB（下面简称AB，栈名一般默认和包名相同），另外一个任务栈，id=221，栈名为“com.cmcm.activitytask2”，其包含ActivityC和ActivityD（下面检测CD）。现在我们通过ActivityB去启动ActivityD，然后按back键回退。B调用D代码如下：
import android.app.Activity;
import android.content.ComponentName;
import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
public class ActivityB extends Activity {
private Button btn;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_b);
btn= (Button) findViewById(R.id.main);
btn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Intent intent = new Intent(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_LAUNCHER);
ComponentName cn = new ComponentName("com.cmcm.activitytask2", "com.cmcm.activitytask2.ActivityD");
intent.setComponent(cn);
startActivity(intent);
}
});
}
}
我们可以看到包含CD的任务栈被提前的，虽然CD隔开了，但是我们从id和栈名可以发现他们是同一个栈，而AB所在的栈则在CD所在栈的后面，所以此时我们按back回退时，退出顺序是这样的D->C->B->A，动态图如下：
特殊情景二:
如果上面B不是请求启动D而是请求启动C，那么又会是什么情况呢？其实这个时候任务栈退出列表变成C->B->A，其实原因很简单，singleTask模式的ActivityC切换到栈顶时会导致在他之上的栈内的Activity出栈。同样我们还是使用上面的代码，把B启动D改为B启动C，那么此时B未启动C时任务栈的情况如下：
我们仍然可以看到两个任务栈，分别为id=242，栈名“com.cmcm.activitytask”的Task，包含ActivityA和ActivityB；id=241，栈名“com.cmcm.activitytask2”的Task，包含ActivityC和ActivityD。此时我们通过B启动C后栈的情况变成如下情况
因此，栈的退出列表就变成了C->B->A了.
到此我们对SingleTask模式又有了更深入的理解，但是我们发现上面的例子使用的是两个应用，所以才会有不同的任务栈，那么我们能不能在一个应用中存在多个不同的任务栈呢（暂时不考虑singleInstance 模式）？答案当然是肯定的啦，这就需要通过taskAffinity属性来设置不同的任务栈名称
4.taskAffinity属性
TaskAffinity特点如下：
- TaskAffinity 参数标识着Activity所需要的任务栈的名称，默认情况下，一个应用中所有Activity所需要的任务栈名称都为该应用的包名。
- TaskAffinity 属性一般跟singleTask模式或者跟allowTaskReparenting属性结合使用，在其他情况下没有实际意义。
TaskAffinity和singleTask启动模式结合使用
当TaskAffinity和singleTask启动模式结合使用时，当前Activity的任务栈名称将与TaskAffinity属性指定的值相同，下面我们通过代码来验证,我们同过MainActivity来启动ActivityA，其中MainActivity启动模式为默认模式，ActivityA启动模式为singleTask，而TaskAffinity属性值为android:taskAffinity="com.zejian.singleTask.affinity"
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="comzejian.myapplication">
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:supportsRtl="true"
android:theme="@style/AppTheme">
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity android:name=".ActivityA"
android:launchMode="singleTask"
android:taskAffinity="com.zejian.singleTask.affinity"
/>
</application>
</manifest>adb shell dumpsys activity activities 命令查看此时栈的情况：
我们可以清楚地看到两个任务栈，其中一个是id=249，栈名称为com.zejian.singleTask.affinity的任务栈，该栈包含了ActivityA，另外一个则是id=248，栈名为默认包名的任务栈，包含了MainActivity。到此我们也明白了，我们确实可以通过singleTask与android:taskAffinity属性相结合的方式来指定我们Activity所需要的栈名称，使相应的Activity存在于不同的栈中
当TaskAffinity和allowTaskReparenting结合使用
首先我们来聊聊allowTaskReparenting属性，它的主要作用是activity的迁移，即从一个task迁移到另一个task，这个迁移跟activity的taskAffinity有关。当allowTaskReparenting的值为“true”时，则表示Activity能从启动的Task移动到有着affinity的Task（当这个Task进入到前台时），当allowTaskReparenting的值为“false”，表示它必须呆在启动时呆在的那个Task里。如果这个特性没有被设定，元素(当然也可以作用在每次activity元素上)上的allowTaskReparenting属性的值会应用到Activity上。默认值为“false”。这样说可能还比较难理解，我们举个例子，比如现在有两个应用A和B，A启动了B的一个ActivityC，然后按Home键回到桌面，再单击B应用时，如果此时，allowTaskReparenting的值为“true”，那么这个时候并不会启动B的主Activity，而是直接显示已被应用A启动的ActivityC，我们也可以认为ActivityC从A的任务栈转移到了B的任务栈中。
我们通过代码层面来验证一下，我们创建两个应用分别为ActivityTask（简称A应用）和ActivityTask2（简称B应用），其中A包含ActivityA，B包含ActivityC，我们通过ActivityA启动B应用中的ActivityC，再回到桌面，启动B应用，此时我们观察A应用和B应用各自栈的变化（因为A,B为不同的应用所以taskAfinity属性值肯定不同，所以这里我们就没必要指定了）。
ActivityA及其清单文件代码如下：
import android.app.Activity;
import android.content.ComponentName;
import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
public class ActivityA extends Activity {
private Button btnC;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_a);
btnC= (Button) findViewById(R.id.mainC);
btnC.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Intent intent = new Intent(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_LAUNCHER);
ComponentName cn = new ComponentName("com.cmcm.activitytask2", "com.cmcm.activitytask2.ActivityC");
intent.setComponent(cn);
startActivity(intent);
}
});
}
}<activity android:name=".ActivityA">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>ActivityA及其清单文件代码如下：
package com.cmcm.activitytask;
package com.cmcm.activitytask;
import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
/**
* Created by zejian
* Time 16/7/23.
* Description:
*/
public class ActivityC extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_c);
}
}<activity android:name=".ActivityC" android:exported="true"
android:allowTaskReparenting="true">
</activity>
我们可以看到ActivityA和ActivityC同在一个栈中，接着我们回到桌面启动B应用，此时内存中的任务栈如下
我们发现ActivityC从A应用的任务栈直接移动到B应用的任务栈，这也就符合我们前面所说的现象了。
我们发现ActivityC从A应用的任务栈直接移动到B应用的任务栈，这也就符合我们前面所说的现象了。而当我们修改allowTaskReparenting为false时，再运行，然后重复上面的操作，查看内存中任务栈的变化：
A应用启动B应用的ActivityC时
回到桌面再启动B应用时:
对比发现，如果allowTaskReparenting值为false时，ActivityC并不会直接从A应用的任务栈迁移到B应用的任务栈，而是B应用直接重新创建了ActivityC的实例。到此我们对于allowTaskReparenting和taskAffinity属性的了解就已经相当深入了，不过有点需要说明的是allowTaskReparenting仅限于singleTop和standard模式，这是因为一个activity的affinity属性由它的taskAffinity属性定义（代表栈名），而一个task的affinity由它的root activity定义。所以，一个task的root activity总是拥有和它所在task相同的affinity。由于以singleTask和singleInstance启动的activity只能是一个task的root activity，因此allowTaskReparenting仅限于以standard 和singleTop启动的activity
TaskAffinity与allowTaskReparenting和singleTask结合时可能发生的应用场景
- TaskAffinity与singleTask应用场景
假如现在有这么一个需求,我们的客户端app正处于后台运行，此时我们因为某些需要，让微信调用自己客户端app的某个页面，用户完成相关操作后，我们不做任何处理，按下回退或者当前Activity.finish()，页面都会停留在自己的客户端（此时我们的app回退栈不为空），这显然不符合逻辑的，用户体验也是相当出问题的。我们要求是，回退必须回到微信客户端,而且要保证不杀死自己的app.这时候我们的处理方案就是，设置当前被调起Activity的属性为：
LaunchMode=""SingleTask" taskAffinity="com.tencent.mm"
其中com.tencent.mm是借助于工具找到的微信包名，就是把自己的Activity放到微信默认的Task栈里面，这样回退时就会遵循“Task只要有Activity一定从本Task剩余Activity回退”的原则，不会回到自己的客户端；而且也不会影响自己客户端本来的Activity和Task逻辑。
- TaskAffinity与allowTaskReparenting应用场景
清空任务栈
Android系统除了给我提供了TaskAffinity来指定任务栈名称外，还给我提供了清空任务栈的方法，在一般情况下我们只需要在<activity>标签中指明相应的属性值即可。- android:clearTaskOnLaunch
这个属性用来标记是否从task清除除根Activity之外的所有的Activity，“true”表示清除，“false”表示不清除，默认为“false”。这里有点我们必须要注意的，这个属性只对任务栈内的root Activity起作用，任务栈内其他的Activity都会被忽略。如果android:clearTaskOnLaunch属性为“true”，每次我们重新进入这个应用时，我们只会看到根Activity，任务栈中的其他Activity都会被清除出栈。
比如一个应用的Activity A,B,C，其中clearTaskOnLaunch设置为true，C为默认值，我们依次启动A,B,C，点击HOME,再在桌面点击图标。启动的是A，而B，C将都被移除当前任务栈。也就是说，当Activity的属性clearTaskOnLaunch为true时将被优先启动，其余的Activity(B、C)都被移除任务栈并销毁，除非前面A已经finish销毁，后面的已注册clearTaskOnLaunch为true的activity(B)才会生效。
特别地，如果我们的应用中引用到了其他应用的Activity，这些Activity设置了android:allowTaskReparenting属性为“true”，则它们会被重新宿主到有共同affinity的task中。
- android:finishOnTaskLaunch
finishOnTaskLaunch属性与clearTaskOnLaunch 有些类似，它们的区别是finishOnTaskLaunch是作用在自己身上(把自己移除任务栈，不影响别的Activity)，而clearTaskOnLaunch则是作用在别人身上(把别的Activity移除任务栈)，如果我们把Activity的android:finishOnTaskLaunch属性值设置为true时，离开这个Activity所依赖的任务栈后，当我们重新返回时，该Activity将会被finish掉，而且其他Activity不会受到影响。
- android:alwaysRetainTaskState
alwaysRetainTaskState实际上是给了当前Activity所在的任务栈一个“免死金牌”，如果当前Activity的android:alwaysRetainTaskState设置为true时，那么该Activity所在的任务栈将不会受到任何清理命令的影响，一直保持当前任务栈的状态。
4900
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
