flag_activity_new_task(flag_activity_new_task 简单)
为什么有时候启动Activity需要加FLAG
Activity intent经常使用的 FLAG
Intent.FLAG_ACTIVITY_NEW_TASK
默认的跳转类型,会重新创建一个新的Activity，不过与这种情况，比方说Task1中有A,B,C三个Activity,此时在C中启动D的话，如果在Manifest.xml文件中给D添加了Affinity的值和Task中的不一样的话，则会在新标记的Affinity所存在的Task中压入这个Activity。如果是默认的或者指定的Affinity和Task一样的话，就和标准模式一样了启动一个新的Activity.
FLAG_ACTIVITY_SINGLE_TOP
这个FLAG就相当于加载模式中的singletop，比如说原来栈中情况是A,B,C,D在D中启动D，栈中的情况还是A,B,C,D
FLAG_ACTIVITY_CLEAR_TOP
这个FLAG就相当于加载模式中的SingleTask，这种FLAG启动的Activity会把要启动的Activity之上的Activity全部弹出栈空间。类如：原来栈中的情况是A,B,C,D这个时候从D中跳转到B，这个时候栈中的情况就是A,B了
FLAG_ACTIVITY_BROUGHT_TO_FRONT
这个网上很多人是这样写的。如果activity在task存在，拿到最顶端,不会启动新的Activity。这个有可能会误导大家！ 他这个FLAG其实是这个意思！ 比方说我现在有A，在A中启动B，此时在A中Intent中加上这个标记。此时B就是以 FLAG_ACTIVITY_BROUGHT_TO_FRONT 这个启动的，此时在B中再启动C，D（正常启动C,D），如果这个时候在D中再启动B，这个时候最后的栈的情况是 A,C,D,B. 特别注意的是，我上面说的网上人描述的这个FLAG，会很容易让人误解成这样，A,B,C,D都是标准加载，然后我在D中启动A，这个intent加上FLAG_ACTIVITY_BROUGHT_TO_FRONT ，就会误认为变成B,C,D,A！！其实不是，这个时候应该是A,B,C,D,A.不信的人大家试试看。不过下面这个标记和这个标记就会让大家明白了！
FLAG_ACTIVITY_REORDER_TO_FRONT
就按在 Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT 最后说的，如果在A,B,C,D正常启动的话，不管B有没有用FLAG_ACTIVITY_BROUGHT_TO_FRONT启动，此时在D中启动B的话，还是会变成A,C,D,B的。
FLAG_ACTIVITY_NO_HISTORY
用这个标记顾名思义！ 意思就是说用这个FLAG启动的Activity，一旦推出，他就不会存在于栈中，比方说！原来是A,B,C 这个时候再C中以这个FLAG启动D的 ， D再启动E，这个时候栈中情况为A,B,C,E。
Android： Activity启动模式 FLAG_ACTIVITY_NEW_TASK 详细探索
最近遇到了一个小问题，在我使用了多种Activity启动模式的时候，重新打开其中的一个Activity会启动另一个我已经停止的Activity，从而调用了一些已经失效的方法导致程序崩溃。
由于项目工程复杂，Activity名称不够直观，我新建了一个ActivityTaskTest 工程来重现遇到的问题。
ActivityA是工程的主活动。因为一些必要的原因， ActivityA的启动模式是SingleInstance的。ActivityA可以启动ActivityB，ActivityB没有设置任何启动模式，即默认的standard启动模式。在ActivityB中，将会启动一个ServiceA。 ServiceA中启动一个了一个ActivityC，由于Activity是在非Acitivity环境下启动的，需要设置 FLAG_ACTIVITY_NEW_TASK标签（这里就是我们讨论的重点，稍候会详细分析）。当ActivityC完成任务后会重新跳转到ActivityA。
最后，见证奇葩的时刻到了，我们点击ActivityA的启动ActivityB的button，ActivityC出现在了我们的眼前，而不是ActivityB！！这一刻我仿佛刘谦附体，但在我发现我身边并没有董卿之后，我深刻地意识到了我是一个工程师，不能搞这些装神弄鬼的事情。ok，Let's find out what‘s going on with our precious app！
关于Activity启动模式和Activity Task的内容推荐一篇非常好的文章： Android中Activity四种启动模式和taskAffinity属性详解 。这篇文章已经讲得非常详细了，这里就不再赘述了，偷个懒哈哈。
如果你已经看了文章，你应该已经知道问题的所在了，对，就是这个该死的taskAffinity。简单的说，就是我们虽然使用了FLAG_ACTIVITY_NEW_TASK标签去启动了ActivityC，但是因为我们忘了给Activity设置taskAffinity这个小婊砸，所以导致ActivityC的taskAffinity值和ActivityB一样都是默认的包名。所以我们启动ActivityC的时候系统将ActivityC压入了ActivityB所在的task。我们可以使用adb shell dumpsys activity activities 指令看下一在我们重新从A中启动B之前，Task的情况：
我们可以看到正如我们所想的，ActivityC和ActivityB在一个Task中，由于ActivityA是singleInstance模式，所以A只能做一辈子单身狗了。那么为什么我们明明启动的是B，怎么会出现C呢？
我们来先看看Google官方文档对于FLAG_ACTIVITY_NEW_TASK是怎么说的：
注意文档中的内容，“如果要启动的 activity 已经运行于某 task 中，则那个 task 将调入前台，最后保存的状态也将恢复”，注意这里是所在task被直接调入前台，也就是说B所在的整个Task将被移入前台。这就解释了为什么我们去启动B而出现的是C了。看起来我们好像大功告成了，但是，等等，总觉得哪里有点不太对劲，我们的ActivityB明明没有设置启动模式啊，你这个是FLAG_ACTIVITY_NEW_TASK标签，我没用啊，我读书多你可别骗我。
仔细想想应该是ActivityA的singleInstance的锅。
我们再来看看Google官方文档对于singleInstance是怎么说的吧：
看到最后一句，终于可以结案了。也就是说，当一个被设置为singleInstance的Activity去启动其他的Activity的时候，其默认是自带FLAG_ACTIVITY_NEW_TASK标签的。
1、FLAG_ACTIVITY_NEW_TASK标签必须配合taskAffinity属性使用，如果不设置taskAffinity属性值，将不会生成新task。
2、当从启动模式为singleInstance的Acitivity中启动新的Acitivity时，新的Activity自带FLAG_ACTIVITY_NEW_TASK标签。
心得：官方文档是个好东西。
Android:开发中，在广播接收器中显示Activity为什么要设置Intent.FLAG_ACTIVITY_NEW_TASK标记？
告诉activity使用自己的任务栈来维护界面，因为自己没有界面，没有任务栈创建
android 的Service里面多次启动一个Activity只能用FLAG_ACTIVITY_NEW_TASK，那么怎么才能只启动一次呢？
Activity只启动一次，需要设置Activity的启动模式。Activity启动模式有4种，分别为standard、singleTop、singleTask、singleInstance,只要设置为 singleTask就只会启动一次。
关于Activity四种启动模式的说明：
1.standard 默认模式，可以不用写配置。在这个模式下，都会默认创建一个新的实例。因此，在这种模式下，可以有多个相同的实例，也允许多个相同Activity叠加。
2.singleTop 可以有多个实例，但是不允许多个相同Activity叠加。即，如果Activity在栈顶的时候，启动相同的Activity，不会创建新的实例，而会调用其onNewIntent方法。
3.singleTask 只有一个实例。在同一个应用程序中启动他的时候，若Activity不存在，则会在当前task创建一个新的实例，若存在，则会把task中在其之上的其它Activity destory掉并调用它的onNewIntent方法。
3.singleInstance只有一个实例，并且这个实例独立运行在一个task中，这个task只有这个实例，不允许有别的Activity存在。
Android Service启动Activity
Android Service 基础知识点
我们都知道Activity中启动Activity，只需要startActivity，如果在Service中启动Activity呢？
在Service中启动Activity，很多人说在非Activity中启动Activity需要加FLAG_ACTIVITY_NEW_TASK flag，如果我不加会怎么样呢？
并没有出现异常和崩溃，跳转也是正常的，但是与之前所说的会崩溃报出异常不符合啊？！难道是与版本有关吗？于是我使用了Android 23去测试果然抛出了异常
ContextImpl在Android studio中属于隐藏源码，在IDE中可能看不到，那就需要在SDK中去找 我的是：D:\AndroidSdk\sources\android-23\android\app\ContextImpl.java
可以看到只是判断条件不同而已，android-23中发现没有Intent.FLAG_ACTIVITY_NEW_TASK会直接抛出异常，而android-26中我们在非 Activity 调用 startActivity() 的时候，我们这个 options 通常是 null 的，所以在 26 之间的时候，误把判断条件 options == null 写成了 options != null 导致进不去 if，从而不会抛出异常
附加：在android 24-android 27（即android N-android O）之间出现了bug，也就是说即使没有加Intent.FLAG_ACTIVITY_NEW_TASK也会正常跳转
可以很明显看到判断条件targetSdkVersion Build.VERSION_CODES.N || targetSdkVersion = Build.VERSION_CODES.P 即在24-27
看Activity中启动Activity的源码
Activity.startActivity() -startActivityForResult()-mInstrumentation.execStartActivity() ...最终还是Ams去启动Activity 也就是Activity中重写了startActivity()方法所以不会出现这个异常
其实直观很好理解，如果不是在Activity中启动的，那就可以看做不是用户主动的行为，也就说这个界面可能出现在任何APP之上，如果不用Intent.FLAG_ACTIVITY_NEW_TASK将其限制在自己的Task中，那用户可能会认为该Activity是当前可见APP的页面，这是不合理的。举个例子：我们在听音乐，这个时候如果邮件Service突然要打开一个Activity，如果不用Intent.FLAG_ACTIVITY_NEW_TASK做限制，那用户可能认为这个Activity是属于音乐APP的，因为用户点击返回的时候，可能会回到音乐，而不是邮件（如果邮件之前就有界面）
对比源码发现，在我们非 Activity 调用 startActivity() 的时候，我们这个 options 通常是 null 的，所以在 24~27 之间的时候，误把判断条件 options == null 写成了 options != null 导致进不去 if，从而不会抛出异常，如此我们使用 Context.startActivity() 的时候是一定要加上 FLAG_ACTIVITY_NEW_TASK 的，但是在 Android N 到 O-MR1，即 24~27 之间却出现了 bug，即使没有加也会正确跳转
结语：感谢各位大佬的分享，对此有疑问的可以去运行跑一下，看一下相关的源码，如有错误的需要改进的地方，请留言评论指出，谢谢！
参考文章：