一. 多任务和task、启动模式
android 手机在早期，下方通常会内置三个实体的触摸按键，分别是：桌面、菜单、返回。大概在android 5.0 之后，android开始流行系统内置虚拟按键，其中的菜单被替换成了多任务，一旦我们按下多任务按键，一个个的任务快照就以流的形式展现在屏幕之上。
随着google对多任务更好地支持，越来越多的厂商将正面的实体按键，替换成了虚拟按键，也将菜单按键删除，替换成了多任务视图按钮，显然多任务在之后的android版本中是非常重要的一个概念。
甚至由于虚拟按键的出现，一些特定型号的手机在下方可能会形成奇怪的五层下巴：
我们将这一个个的任务叫做task，多任务视图中，会显示各个task顶层activity的快照（之所以是快照，是因为activity不一定是存活的，有可能它只是一张图片。）task中，以回退栈的形式堆叠activity。
每个task，对应一个名称，如果我们不去设置，那么就是我们application的应用包名，默认情况下，start一个新的activity就会被装入该task当中，然后在这个task中进行堆叠，新打开的activity在上方，用户可以通过按下返回键回退到上一个activity当中。
每个activity，都有一个taskaffinity属性，标志了它想去的task是哪一个，如果你不填写，那么通常是默认的目标栈，但是要注意的是，taskaffinity需要和launchmode搭配在一起使用：
- 如果不设置launchmode（即采用默认的standard），那么你从activitya中启动一个设置了taskaffinity的activityb，你会发现它不生效，它仍然在当前包名的activitya的对应的任务栈当中。
- 如果你将taskaffinity配置和launchmode = singletask一起使用，在你打开了activityb时，你按下多任务按钮，你会发现一个app出现了两个task，即两个回退栈，这两个回退栈的分别对应activitya和activityb的对应的task的回退栈：
它们拥有相同的项目名称，因为只是名为router的app模块下的两个不同taskaffinity的activity，不过这个taskaffinity并不显示在多任务视图当中。
二. 四种启动模式详解
所以，四种启动模式，对应的具体的启动情况如下：
1. standard
在当前的task的回退栈中，启动一个activity实例，放在栈顶。
在这种模式下，使用taskaffinity是无效的。即使填写了taskaffinity，最终也会被创建在执行启动命令的activity对应的task栈的栈顶，而不是taskaffinity对应的task的栈顶。
2. singletask
在taskaffinity指定的退回栈中，尝试启动一个activity实例：
- 如果指定的回退栈中，含有该activity相同类型的实例，那么就回调onnewintent()方法，告知原先已经存在的实例x，然后回调onresume()方法，并将原先实例上方的实例全部移除出回退栈，这样一来，原先已经存在的实例x就会出现在栈顶。
- 如果指定的回退栈中，不包含activity相同类型的实例，那么就在栈顶创建，走正常的生命周期回调：
oncreate()->onstart()->onresume() - 如果taskaffinity对应的task都不存在的情况下，会先去创建目标task，再走创建activity实例的流程，最后压入栈顶。
- 如果没有指定taskaffinity，那么就指定为当前调用启动操作的activity的task，将activity压入该task回退栈的栈顶。
注意：
创建在当前task和其它task的activity跳转动画是不相同的。
singletask + taskaffinity实际上也是一种全局的单例，因为它的创建结果最终都会将activity创建在指定的taskaffinity的task下。即使不填写taskaffinity，也会只在当前activity对应的task下创建或者复用唯一的一个实例。
3. singletop
在taskaffinity指定的退回栈中，尝试在启动一个activity实例。和singletask类似，但是复用条件稍有不同。仅在目标task的回退栈的顶部含有相同类型的activity时，触发复用，回调onnewintent和onresume。
4.singleinstance
在taskaffinity指定的退回栈中，创建一个activity实例，但是，一个task中仅允许一个activity存在，如果两个activity对应的taskaffinity是相同的，例如从a中以singleinstance启动b，b中以singleinstance启动c，bc的taskaffinity是相同的。
这种情况下，如果我们在c中，呼出多任务视图菜单，我们会发现，此时栈中只有c和a对应的task，b对应的task并不存在，你可能会认为b和c在同一个栈中，b在c之下。但是如果你以另外一种方式： 在c中，呼出多任务菜单，回到c后，然后点击返回，你认为应该回到b，但是你会发现，直接退到桌面了。 或者你在c中，直接按回车，你会发现从c->b和从b->a的跳转过场动画，都是task间的转场动画，而不是task内部的跳转动画。
这涉及到另外我们就要讲另外一个问题，task间跳转时，task间的堆叠问题（task叠在另一个task上面），而打开多任务列表或者按下home键会导致堆叠被破坏。
b和c即使有同一个taskaffinity命名，并且根据我们说的一个task中仅允许一个activity存在，c打开时，b应该被关闭，从多任务上来看，似乎也是这样的，因为只有c和a的task在多任务视图中，但是我们确实又可以从c的task返回到b的task，在任务栈中我们又看不到b的身影，这可以下一个结论：多任务视图中的不可见的task不一定不存在，如果发生singleinstance + taskaffinity冲突的情况，例如：
activity a和activity b都是singleinstance的，并且又都是设置了taskaffinity为 com.example.newtask。如果既要保证ab都在同一个task中，又要保证该task只能有一个>activity，那么就会导致冲突。
经过测试，当冲突发生时，android会为两个activity都创建一个task，但是同一时间，只有一个能>在多任务视图中被看见，但是如果顺序启动：a、b，是可以在b中回退到a中的。并且回退的动画是task 间切换的动画。
那么task中可见的activity一定在运行吗？答案也是否定的，如果我们在activitya按下返回键，退回到桌面，我们此时打开多任务，我们会发现，activitya的task的快照仍然保留在多任务视图之上，但是它此时已经“死了”，我们点击它，实际上是创建了一个新的activitya。所以，多任务视图中中的不可见的task不一定不存在，多任务视图中可见的activity也不一定就是running状态的。
三. task间堆叠与task reparenting
1. task间堆叠
考虑如下的两个任务栈间切换场景：
我们需要从activityc中启动activity e，此时activitye的启动模式被设置成了：singletask，taskaffinity是task2。activitye被启动之后，在屏幕上显示出来了。
基于这个状态，接下来有几个问题：
- 问题1：如果此时按多次返回键，会发生什么？
- 问题2：如果此时先按home回到桌面，再从多任务列表打开task1，显示的是activityc还是activitye？
- 问题3：如果此时先按home回到桌面，再从多任务列表打开task2，显示的是activitye，如果此时不不断地按返回键，会发什么？
- 问题4：如果此时先打开多任务列表，再按返回，返回task2，此时显示的是activitye。如果此时不不断地按返回键，会发什么？
对于问题1，答案是：activity e/d/c/b/a同时出栈，a出栈之后回到桌面。 对于问题2，答案是：显示的是activityc 对于问题3、4，答案是：activity e/d出栈，d出栈之后，回到桌面，而不是activity c。
问题1的原因是因为，task2的任务被打开之后，整个task2成为了优先显示的task，被堆在屏幕之上，一旦task2的activity退完了，task1可以无缝地衔接上：
就好像task2被堆在了task1之上，这样的堆叠，保证了用户交互的连贯性。
这样的task间的堆叠跳转特性适用于用户跳转某个页面之后，按返回键不想马上跳回原activity的一种情况。
但是，这种堆叠仅限于task跳转刚刚发生的情况，一旦用户进行了：
- home键返回桌面
- 切出多任务视图
这类的操作，将顶端的task变为后台task之后，那么这种「堆叠」就会立刻失效，并且不再恢复，所以在问题3、4中，最后返回的是桌面，而不是task1的activityc，这种堆叠被破坏了，task1和task2又重新回到平级的状态了。
但是在最新的api32版本中，切到android 自带的多任务视图并不会导致task2重新被移动到task1平级的位置，这意味着，你从多任务切回来之后，在activitye按下返回，仍然会回退到到task1的activityc之上。
如果有一些场景，你希望打开activitye之后不退到d，直接退到c那应该怎么做呢？其实不设置singletask就好了，默认的就是这种情况，比如外卖平台支付订单之后，付款软件的的付款结果页的一个实例就被留在了外卖软件的task中。
2. task reparenting/task重定父级
通常来说，一个activity被装进一个task的栈之后，就不会去移动了，但是我们可以借助task reparenting来做父级的重新指定。
例如上述的例子中，我们队activitye设置：allowtaskreparenting。我们从task1中的activityc启动activitye时，activitye会启动在task1中。
一旦我们切到桌面，再重新从桌面图标重新打开task1时，我们会发现activitye从task1中消失了，而从桌面打开task2对应的app图标时，会发现，activitye重新回到了自己的task2中，例如我们按照如下定义：
<activity
android:name=".activitye"
android:allowtaskreparenting="true"
android:exported="false"
android:taskaffinity="com.example.anothertask" />
如果我们在默认的，和包名相同的com.red.router下创建该mainactivitye,那么此时的mainactivity会在当前的com.red.router下创建该mainactivitye实例，然后我退到桌面，再重新在桌面的app图标打开app，我会发现，启动的app的当前的activity变成了activityc，而不是activitye：
而且，多任务视图中的task2中的快照是空白的，我们点开task2，发现activitye回到了它taskaffinity指定的task中：
另外，如果同时设置了allowtaskreparenting=true和launchmode，那么launchmode会优先生效，activity会直接创建在其他的task中。
到此这篇关于android中的launch mode详情的文章就介绍到这了,更多相关android launch mode内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！