上图片抓取总是失败，可以到这里Activity启动模式二
阅读，谢谢！
上篇文章Activity启动模式一主要介绍了Activity的四种启动模式，这些启动模式都是在AndroidManifest中进行配置的。除此之外，Android系统还通过Intent类提供了一些标志位，同样可以指定Activity的启动模式。本文将介绍下这些和Activity启动相关的标志位。
一般情况下，我们在启动目标Activity的Intent中指定这些标志位，如下所示：
Intent intent = new Intent();
intent.setClass(MainActivity.this,FirstActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP);
startActivity(intent);
当同时在配置文件中指定launchMode和在Intent中指定上面的标志位时，以标志位为准，即代码的优先级比AndroidManifest的优先级更高！
下面我们通过具体案例看下和Activity启动相关的4种标志位：
Activity启动相关的四种标志位
FLAG_ACTIVITY_NEW_TASK
官方文档上介绍该标志位和SingleTask启动模式具有相同效果，其实不然。应该是FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TOP一起等同于SingleTask启动模式。
这里我们通过4个案例，看下单独使用FLAG_ACTIVITY_NEW_TASK标志位和一起使用FLAG_ACTIVITY_NEW_TASK、FLAG_ACTIVITY_CLEAR_TOP标志位的具体效果。
案例1
两个Activity的taskAffinity属性相同，具体步骤如下所示：
- 创建MainActivity和FirstActivity，且两者的启动模式都是Standard，TaskAffinity也相同。
- 首先启动MainActivity，接着通过MainActivity启动FirstActivity，然后再通过FirstActivity启动MainActivity，如此反复。
- 启动FirstActivity的Intent中指定了FLAG_ACTIVITY_NEW_TASK标志位，启动MainActivity的Intent不包含任何标志位。
经过MainActivity -> FirstActivity -> MainActivity后，最终的任务栈如下所示：
[图片上传失败...(image-ab0b5-1571789169660)]
可见，因为两个Activity的taskAffinity属性相同，所以第一次启动FirstActivity时并没有创建新的任务栈。
最后，MainActivity再次启动FirstActivity后，最终的任务栈如下所示：
[图片上传失败...(image-171689-1571789169660)]
因为只有FLAG_ACTIVITY_NEW_TASK标志位，没有FLAG_ACTIVITY_CLEAR_TOP，所以无法清除FirstActivity之上的MainActivity，复用已有FirstActivity。而是创建了新的FirstActivity。
通过上面的任务栈可知：在taskAffinity相同的情况下，单独添加FLAG_ACTIVITY_NEW_TASK不起任何作用。
案例2
两个Activity的taskAffinity属性不相同，具体步骤如下所示：
- 创建MainActivity和FirstActivity，且两者的启动模式都是Standard，但是TaskAffinity不同。
- 首先启动MainActivity，接着通过MainActivity启动FirstActivity，然后再通过FirstActivity启动MainActivity，如此反复。
- 启动FirstActivity的Intent中指定了FLAG_ACTIVITY_NEW_TASK标志位，启动MainActivity的Intent不包含任何标志位。
经过MainActivity -> FirstActivity -> MainActivity后，最终的任务栈如下所示：
可见，因为两个Activity的taskAffinity属性不同，所以第一次启动FirstActivity时，创建了新的任务栈（TaskId为1979）.
最后，MainActivity再次启动FirstActivity后，最终的任务栈如下所示：
[图片上传失败...(image-86c3a2-1571789169660)]
可以看到，任务栈没有发生任何变化，也没有创建新的FirstActivity实例。这是因为FirstActivity实例已经存在于它所期望的任务栈中，而单独添加FLAG_ACTIVITY_NEW_TASK标志位又不会清除任务栈中位于FirstActivity之上的Activity实例，所以就没有发生跳转。
通过上面的任务栈可知：在taskAffinity不同的情况下，第一次启动FirstActivity时，会新建一个任务栈，并将FirstActivity实例添加到该task中。这与SingleTask启动模式产生的效果是一致的。但是，当企图再次从MainActivity进入到FirstActivity时，却什么也没有发生，原因上面已经说明了。
综上所述，单独使用FLAG_ACTIVITY_NEW_TASK会产生非常奇怪的行为，因此一般和FLAG_ACTIVITY_CLEAR_TOP标志位一起使用，这样可以实现类似SingleTask的效果，但是不完全相同，下面会进行介绍。
下面我们再通过两个案例看下FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TOP一起使用的效果。
案例3
两个Activity的taskAffinity属性相同，具体步骤如下所示：
- 创建MainActivity和FirstActivity，且两者的启动模式都是Standard，TaskAffinity也相同。
- 首先启动MainActivity，接着通过MainActivity启动FirstActivity，然后再通过FirstActivity启动MainActivity，如此反复。
- 启动FirstActivity的Intent中指定了
FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TOP标志位，启动MainActivity的Intent不包含任何标志位.
经过MainActivity -> FirstActivity -> MainActivity后，最终的任务栈如下所示：
[图片上传失败...(image-719efa-1571789169660)]
可见，因为两个Activity的taskAffinity属性相同，所以第一次启动FirstActivity时并没有创建新的任务栈。
最后，MainActivity再次启动FirstActivity后，最终的任务栈如下所示：
[图片上传失败...(image-bd3fd8-1571789169660)]
貌似是和SingTask启动模式的效果相同，但是细看一下就会发现区别：前后两次FirstActivity实例是不同的，也就是没有复用第一次启动的FirstActivity，而是清除了FirstActivity及其之上的所有Activity，然后新建FirstActivity实例添加到了当前任务栈。
通过上面的任务栈可知：在taskAffinity相同的情况下，FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TOP标志位组合确实不会创建新的任务栈，但是会清除了FirstActivity及其之上的所有Activity，并新建FirstActivity实例添加到了当前任务栈，这点是和SingleTask模式的差异。（SingleTask仅会清除FirstActivity之上的Activity，然后复用已有的FirstActivity）
案例4
两个Activity的taskAffinity属性不相同，具体步骤如下所示：
- 创建MainActivity和FirstActivity，且两者的启动模式都是Standard，但是TaskAffinity不同。
- 首先启动MainActivity，接着通过MainActivity启动FirstActivity，然后再通过FirstActivity启动MainActivity，如此反复。
- 启动FirstActivity的Intent中指定了
FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TOP标志位，启动MainActivity的Intent不包含任何标志位。
经过MainActivity -> FirstActivity -> MainActivity后，最终的任务栈如下所示：
[图片上传失败...(image-5bff63-1571789169660)]
可见，因为两个Activity的taskAffinity属性不同，所以第一次启动FirstActivity时，创建了新的任务栈（TaskId为1980）.
最后，MainActivity再次启动FirstActivity后，最终的任务栈如下所示：
[图片上传失败...(image-5cab4b-1571789169660)]
可以看到，和案例3 taskAffinity属性相同的情况类似（除了创建了新的任务栈），直接清除了FirstActivity及其之上的所有Activity，然后创建新的FirstActivity实例添加到新的任务栈（TaskId为1980）。
通过上面的任务栈可知：在taskAffinity不同的情况下，FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TOP标志位组合会为首次启动的FirstActivity创建新的任务栈，其他的逻辑与案例3基本相同，都是直接清除了FirstActivity及其之上的所有Activity，然后创建新的FirstActivity实例，这也是和SingleTask模式的区别。
综上所述，FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TOP标志位组合产生的效果总体上和SingleTask模式相同，除了不会复用FirstActivity实例之外。
FLAG_ACTIVITY_CLEAR_TOP
该标志位在上面已经使用过了，作用是清除包含目标Activity的任务栈中位于该Activity实例之上的其他Activity实例。但是是复用已有的目标Activity，还是像上面那样先删除后重建，则有以下规则：
- 若是单独使用FLAG_ACTIVITY_CLEAR_TOP，那么只有非Standard启动模式的目标Activity才会被复用，其他启动模式的目标Activity都先被删除，然后被重新创建并入栈。
- 若是使用FLAG_ACTIVITY_SINGLE_TOP和FLAG_ACTIVITY_CLEAR_TOP标志位组合，那么不管目标Activity是什么启动模式，都会被复用。
因为上面的案例3和案例4都不符合上面的两条规则，所以FirstActivity才会先被清除，然后重建。
下面我们通过几个具体案例，验证下上面的两条规则：
案例1
具体步骤如下所示：
- 创建MainActivity和FirstActivity，且两者的启动模式都是Standard。
- 首先启动MainActivity，接着通过MainActivity启动FirstActivity，然后再通过FirstActivity启动MainActivity，如此反复。
- 启动FirstActivity的Intent中指定了
FLAG_ACTIVITY_CLEAR_TOP标志位，启动MainActivity的Intent不包含任何标志位。
经过MainActivity -> FirstActivity -> MainActivity后，最终的任务栈如下所示：
[图片上传失败...(image-f2049f-1571789169660)]
最后，MainActivity再次启动FirstActivity后，最终的任务栈如下所示：
[图片上传失败...(image-d6a89a-1571789169660)]
通过上面的任务栈可知：第二次MainActivity -> FirstActivity时，会先把FirstActivity以及之上的Activity全部销毁，然后创建新的FirstActivity入栈，正符合我们的预期。
案例2
具体步骤如下所示：
- 创建MainActivity和FirstActivity，MainActivity的启动模式是Standard，FirstActivity的启动模式是SingleTop。
- 首先启动MainActivity，接着通过MainActivity启动FirstActivity，然后再通过FirstActivity启动MainActivity，如此反复。
- 启动FirstActivity的Intent中指定了
FLAG_ACTIVITY_CLEAR_TOP标志位，启动MainActivity的Intent不包含任何标志位。
经过MainActivity -> FirstActivity -> MainActivity后，最终的任务栈如下所示：
[图片上传失败...(image-929577-1571789169660)]
最后，MainActivity再次启动FirstActivity后，最终的任务栈如下所示：
[图片上传失败...(image-ae0831-1571789169660)]
通过上面的任务栈可知：第二次MainActivity -> FirstActivity时，会先把FirstActivity之上的Activity全部销毁，然后复用已有的FirstActivity实例，也符合我们的预期。
此外，当FirstActivity是SingleTask和SingleInstance模式时，其效果和SingleTop启动模式一样，也是首先销毁FirstActivity之上的所有Activity，然后复用已有的FirstActivity实例。
这里仅给出我验证的任务栈：
当FirstActivity是SingleTask模式时（taskAffinity相同），经过MainActivity -> FirstActivity -> MainActivity后，最终的任务栈如下所示：
最后，MainActivity再次启动FirstActivity后，最终的任务栈如下所示：
[图片上传失败...(image-2033ce-1571789169660)]
可见，确实复用了已有的FirstActivity实例。
当FirstActivity是SingleInstance模式时，经过MainActivity -> FirstActivity -> MainActivity后，最终的任务栈如下所示：
最后，MainActivity再次启动FirstActivity后，最终的任务栈如下所示：
[图片上传失败...(image-b9bbdc-1571789169660)]
可见，确实复用了已有的FirstActivity实例。
综上所述，通过案例1和案例2，我们验证了规则1是OK的。
下面我们继续验证下规则2：
案例3
具体步骤如下所示：
- 创建MainActivity和FirstActivity，且两者的启动模式都是Standard。
- 首先启动MainActivity，接着通过MainActivity启动FirstActivity，然后再通过FirstActivity启动MainActivity，如此反复。
- 启动FirstActivity的Intent中指定了
FLAG_ACTIVITY_SINGLE_TOP + FLAG_ACTIVITY_CLEAR_TOP标志位，启动MainActivity的Intent不包含任何标志位。
经过MainActivity -> FirstActivity -> MainActivity后，最终的任务栈如下所示：
[图片上传失败...(image-1755e0-1571789169660)]
最后，MainActivity再次启动FirstActivity后，最终的任务栈如下所示：
[图片上传失败...(image-b839b2-1571789169660)]
通过上面的任务栈可知：第二次MainActivity -> FirstActivity时，会先把FirstActivity之上的Activity全部销毁，然后复用已有的FirstActivity实例，也符合我们的预期。
综上所述，既然在FLAG_ACTIVITY_SINGLE_TOP + FLAG_ACTIVITY_CLEAR_TOP标志位组合的情况下，Standard模式的FirstActivity都已经被复用了，那么其他启动模式的Activity也必然会被复用。（单独使用FLAG_ACTIVITY_CLEAR_TOP都会被复用，何况又添加了FLAG_ACTIVITY_SINGLE_TOP标志位，通过Demo验证也确实如此，就不再给出具体案例了）。
综上所述，上面的两条规则还要是遵守的_。
FLAG_ACTIVITY_CLEAR_TASK
该标志位一般和FLAG_ACTIVITY_CLEAR_TASK一起使用，目的是启动目标Activity时，首先清空已经存在的目标Activity实例所在的任务栈，这自然也就清除了之前存在的目标Activity实例，然后创建新的目标Activity实例并入栈。
经过Demo测试发现，单独使用FLAG_ACTIVITY_CLEAR_TASK标志位，不管taskAffinity是否相同，都不会产生什么效果。例如下面是单独使用该标志位的最终任务栈（taskAffinity相同 or 不同都是这样）：
[图片上传失败...(image-da08ca-1571789169660)]
感兴趣的可以自行尝试，这里不再赘述。
下面看下FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TASK标志位组合在taskAffinity相同 and 不同的情况下的效果。
案例1
两个Activity的taskAffinity属性相同，具体步骤如下所示：
- 创建MainActivity和FirstActivity，且两者的启动模式都是Standard，taskAffinity也相同。
- 首先启动MainActivity，接着通过MainActivity启动FirstActivity，然后再通过FirstActivity启动MainActivity，如此反复。
- 启动FirstActivity的Intent中指定了
FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TASK标志位，启动MainActivity的Intent不包含任何标志位。
第一次启动MainActivity后，任务栈如下所示：
[图片上传失败...(image-eea7c-1571789169660)]
接着MainActivity启动FirstActivity后，任务栈如下所示：
[图片上传失败...(image-12b579-1571789169660)]
首先启动的MainActivity居然被清除了，然后才创建了FirstActivity实例。
然后FirstActivity启动MainActivity后，任务栈如下所示：
[图片上传失败...(image-834c6b-1571789169660)]
最后MainActivity再次启动FirstActivity后，任务栈如下所示：
[图片上传失败...(image-d1d89-1571789169660)]
可见，系统再次清除了FirstActivity及其之上的MainActivity，然后重新创建了新的FirstActivity实例并入栈。
通过上面的任务栈可知：当通过FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TASK标志位组合启动FirstActivity时，首先会清空FirstActivity所在的任务栈，然后再创建新的FirstActivity实例并入栈。
案例2
两个Activity的taskAffinity属性不相同，具体步骤如下所示：
- 创建MainActivity和FirstActivity，且两者的启动模式都是Standard，taskAffinity不相同。
- 首先启动MainActivity，接着通过MainActivity启动FirstActivity，然后再通过FirstActivity启动MainActivity，如此反复。
- 启动FirstActivity的Intent中指定了
FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TASK标志位，启动MainActivity的Intent不包含任何标志位。
第一次MainActivity启动FirstActivity后，任务栈如下所示：
[图片上传失败...(image-8f36ac-1571789169660)]
因为taskAffinity不同，所以为FirstActivity实例创建了新的任务栈。
然后FirstActivity启动MainActivity后，任务栈如下所示：
[图片上传失败...(image-2878f1-1571789169660)]
最后MainActivity再次启动FirstActivity后，任务栈如下所示：
[图片上传失败...(image-d44223-1571789169660)]
可见，系统首先清除了任务栈（TaskId为2040）中FirstActivity及其之上的MainActivity，然后重新创建了新的FirstActivity实例并入栈（TaskId为2040）。
通过上面的任务栈可知：当通过FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TASK标志位组合启动FirstActivity时，首先会清空FirstActivity所在的任务栈，然后再创建新的FirstActivity实例并入栈，这和taskAffinity属性相同是一致的效果，只不过这里第一次为FirstActivity创建了新的任务栈。
综上所述，当通过FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TASK标志位组合启动目标Activity时，首先会清空目标Activity所在的任务栈（若目标Activity是第一次启动，那么会清空目标Activity所期望的任务栈），然后创建新的目标Activity实例并入栈。
FLAG_ACTIVITY_SINGLE_TOP
该标志单独使用就可以达到SingleTop启动模式的效果，该类效果可以参考前篇文章，这里不再赘述。
Activity启动相关的属性
这里简单介绍一些AndroidManifest配置文件中与启动模式相关的属性。其实前一篇文章已经介绍了两个比较常用的属性：android:taskAffinity和android:allowTaskReparenting，下面再补充一些不常用的属性。
android:clearTaskOnLaunch
字面意思是：是否在启动时清除任务栈，该属性默认为false，表示是否在APP启动时，清除任务栈中除根Activity之外的其他Activity实例。该属性只对任务栈内的根Activity起作用，任务栈内其他的Activity都会被忽略。
比如：我们有一个App，依次启动了ActivityA、ActivityB和ActivityC，其中ActivityA和ActivityB都设置clearTaskOnLaunch属性为true。那么首先点击“Home”建回到Launcher界面，然后再启动该App，我们看到是ActivityA界面，而ActivityB和ActivityC都被销毁了。
除非栈底的ActivityA已经被销毁，那么上面设置clearTaskOnLaunch属性为true的activity(B)才会生效。
android:finishOnTaskLaunch
该属性默认值为false，表示当离开当前Activity所在的任务栈时，立即销毁当前Activity，而其他Activity不受影响。
android:alwaysRetainTaskState
该属性默认值为false，表示App的任务栈是否保持原来的状态。该属性只对task的根Activity起作用，其他的Activity都会被忽略。 默认情况下，若一个App在后台停留的时间太长，那么再启动该App时，系统会清除任务栈中除了根Activity之外的其他Activity，但是如果根Activity设置了该属性，那么再次启动应用时，就不会清除Task中的Activity，而是保持原样，因此仍然可以看到上一次操作的界面。
OK，Activity启动模式相关的内容就介绍这些吧，希望对自己对感兴趣的同学都有所帮助_。