从前文知道，Android中任务栈（Task）会随着启动模式的不同而表现出不同的状况。
其实除了在Mainfest中定义的启动模式，我们还可以通过为调用Activity的Intent添加Flags的方式改变Activity在栈中的行为。并且，
常用Intent Flags
- Intent.FLAG_ACTIVITY_NEW_TASK
这个是最常用的，但是往往会被误解，在程序根Activity的Task栈里加此标识开启新Activity都不会创建新的Task，只有当另一程序（进程）启动带有改标识的Activity时，才会创建新的Task。如果配合FLAG_ACTIVITY_NEW_MULTI_TASK，则无论什么情况都会创建新的Task，就成了类似 singleInstance 的情况了（singleInstance中的Activity独占一个栈）。如果配合 FLAG_ACTIVITY_CLEAR_TASK，则会先清空该栈，然后向栈中添加目标Activity，栈ID不变。
- Intent.FLAG_ACTIVITY_CLEAR_TOP
有些文章中直接把该Flag说成作用和singleTask 相同，这是大错特错的。
如果在ABCD的堆栈状态下，以该标识启动B，则会销毁CD，且B也是重新创建的（与singleTask有区别），如果配合FLAG_ACTIVITY_SINGLE_TOP，则就会成为 singleTask 的模式.
- Intent.FLAG_ACTIVITY_SINGLE_TOP
同singleTop启动模式.
- Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT
这个Flag主要用来改变Task堆栈顺序，如果在ABCD的状态下，以该标识启动B，则会成为ACDB，且B不会重新创建
- Intent.FLAG_ACTIVITY_REORDER_TO_FRONT
这个Flag主要用来改变Task堆栈顺序，如果在ABCD的状态下，以该标识启动B，则会成为ACDB，且B不会重新创建
- Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
这个标识主要用于创建一个还原点，再次启动该Task时会将还原点之上包括其本身都销毁掉，如果在一个程序中以该标识启动了另外一个程序的功能，如一个用于看图的软件，当退出桌面，再点击这个程序，看图软件会消失。
- Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS
有此标识的 Activity 不会出现在历时列表里.
- Intent.FLAG_ACTIVITY_FORWARD_RESULT
如果设置，并且该intent会启动一个新的Activity，则返回消息的目标会从当前Activity转移到新的Activity中。（在这个案例中，返回消息的目标最开始为B）
实例验证
我们先假设我们的Task任务栈中目前如下：
Running activities (most recent first):
TaskRecord{537a56cc #16 A com.zlq.app_intent_flags U 0}
Run #5: ActivityRecord{537a2518 com.zlq.app_intent_flags/.ActivityD}
Run #4: ActivityRecord{5377e810 com.zlq.app_intent_flags/.ActivityC}
Run #3: ActivityRecord{53764490 com.zlq.app_intent_flags/.ActivityB}
Run #2: ActivityRecord{5374c970 com.zlq.app_intent_flags/.ActivityA}
Run #1: ActivityRecord{53789390 com.zlq.app_intent_flags/.MainActivity}
其实在程序运行过程中，我们无法真正保证每次初始状态都是这样（主要针对ActivityRecord的id），这里只是为了行文方便，而做的假设。
- Intent.FLAG_ACTIVITY_NEW_TASK
- 单独使用无特殊作用，感觉和没加一样....
- 以 FLAG_ACTIVITY_NEW_TASK|FLAG_ACTIVITY_CLEAR_TASK 为Flag启动ActivityB后：
TaskRecord{5376d624 #16 A com.zlq.app_intent_flags U 0}
Run #2: ActivityRecord{53852b60 com.zlq.app_intent_flags/.ActivityB}
启动过程中相关Activity的生命周期变化如下：
```
04-12 09:12:23.636 5399-5399/com.zlq.app_intent_flags V/zlq: MainActivity-onDestroy
04-12 09:12:23.636 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityA-onDestroy
04-12 09:12:23.636 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onDestroy
04-12 09:12:23.640 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityC-onDestroy
04-12 09:12:23.640 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onPause
04-12 09:12:23.644 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onCreate
04-12 09:12:23.648 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onStart
04-12 09:12:23.648 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onResume
04-12 09:12:24.008 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onStop
04-12 09:12:24.008 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onDestroy
我们看到，ActivityA，ActivityB，ActivityC，ActivityD悉数出栈，然后加入ActivityB，最终，该栈中仅剩余一个ActivityB位于栈底。
* 以 FLAG_ACTIVITY_NEW_TASK|FLAG_ACTIVITY_CLEAR_TASK 为Flag启动ActivityB后：
```
TaskRecord{538c7160 #17 A com.zlq.app_intent_flags U 0}
Run #6: ActivityRecord{538c6ffc com.zlq.app_intent_flags/.ActivityB}
TaskRecord{537a56cc #16 A com.zlq.app_intent_flags U 0}
Run #5: ActivityRecord{537a2518 com.zlq.app_intent_flags/.ActivityD}
Run #4: ActivityRecord{5377e810 com.zlq.app_intent_flags/.ActivityC}
Run #3: ActivityRecord{53764490 com.zlq.app_intent_flags/.ActivityB}
Run #2: ActivityRecord{5374c970 com.zlq.app_intent_flags/.ActivityA}
Run #1: ActivityRecord{53789390 com.zlq.app_intent_flags/.MainActivity}
```
我们可以看到，新启的ActivityB是在一个新栈#17中启动的，和原来的#16不是同一个栈。并且重复该动作，每次新启的栈的ID都不一样。这就和LuanchMode中的 singleInstance 有点像了，区别是，这里在新启的栈中再以普通形式启动的Activity是可以和ActivityB共处一个栈的，而LuanchMode为singleInstance 中的Activity是独占一个栈的。
2. Intent.FLAG_ACTIVITY_CLEAR_TOP
* 以 FLAG_ACTIVITY_CLEAR_TOP 为Flag启动ActivityB后：
TaskRecord{5376bf34 #16 A com.zlq.app_intent_flags U 0}
Run #4: ActivityRecord{537b8578 com.zlq.app_intent_flags/.ActivityB}
Run #3: ActivityRecord{5374c970 com.zlq.app_intent_flags/.ActivityA}
Run #2: ActivityRecord{53789390 com.zlq.app_intent_flags/.MainActivity}
启动过程中相关Activity的生命周期变化如下：
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityC-onDestroy
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onPause
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onDestroy
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onCreate
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onStart
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onResume
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onStop
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onDestroy
我们可以看到除了栈内原来位于ActivityB之上的ActivityC和ActivityD被移除栈之外，我们的ActiviyB也不是原来的那个实例了，而是被销毁后重新新建的一个(原来的那个是`53764490`，后面新建的是`537b8578`)。
* 以FLAG_ACTIVITY_CLEAR_TOP|FLAG_ACTIVITY_SINGLE_TOP 为Flag启动ActivityB后：
TaskRecord{5376bf34 #16 A com.zlq.app_intent_flags U 0}
Run #4: ActivityRecord{53764490 com.zlq.app_intent_flags/.ActivityB}
Run #3: ActivityRecord{5374c970 com.zlq.app_intent_flags/.ActivityA}
Run #2: ActivityRecord{53789390 com.zlq.app_intent_flags/.MainActivity}
启动过程中相关Activity的生命周期变化如下：
04-12 08:58:45.200 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityC-onDestroy
04-12 08:58:45.204 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onPause
04-12 08:58:45.208 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onNewIntent
04-12 08:58:45.208 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onRestart
04-12 08:58:45.208 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onStart
04-12 08:58:45.208 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onResume
04-12 08:58:45.560 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onStop
04-12 08:58:45.560 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onDestroy
我们看到，和仅使用FLAG_ACTIVITY_CLEAR_TOP一个Flag的区别是：这里的ActivityB并不是重新新建的，没有调用ActivityB的onCreate()方法，而是一次调用的onNewIntent()和onRestart()方法来复用，两者的ActivityRecord记录的ID也同为`53764490`。这样一来，其表现出来的特性就和LuancMode中的SingleTask一致了（更严格的说法是就和LuancMode中的**SingleTask在未定义android:taskAffinity属性时**一致了）。
3. Intent.FLAG_ACTIVITY_SINGLE_TOP
以 FLAG_ACTIVITY_CLEAR_TOP 为Flag启动ActivityD后：
Running activities (most recent first):
TaskRecord{537a56cc #16 A com.zlq.app_intent_flags U 0}
Run #5: ActivityRecord{537a2518 com.zlq.app_intent_flags/.ActivityD}
Run #4: ActivityRecord{5377e810 com.zlq.app_intent_flags/.ActivityC}
Run #3: ActivityRecord{53764490 com.zlq.app_intent_flags/.ActivityB}
Run #2: ActivityRecord{5374c970 com.zlq.app_intent_flags/.ActivityA}
Run #1: ActivityRecord{53789390 com.zlq.app_intent_flags/.MainActivity}
发现并没有发生任何变化。只在LogCat中打印出了：
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onPause
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onNewIntent
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onResume
可见，使用了该Flag启动Activity时，其表现和LaunchMode中的SingleTop一样。
4. Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT
以FLAG_ACTIVITY_BROUGHT_TO_FRONT为Flag启动ActivityB后：
Running activities (most recent first):
TaskRecord{537a56cc #16 A com.zlq.app_intent_flags U 0}
Run #3: ActivityRecord{53764490 com.zlq.app_intent_flags/.ActivityB}
Run #5: ActivityRecord{537a2518 com.zlq.app_intent_flags/.ActivityD}
Run #4: ActivityRecord{5377e810 com.zlq.app_intent_flags/.ActivityC}
Run #2: ActivityRecord{5374c970 com.zlq.app_intent_flags/.ActivityA}
Run #1: ActivityRecord{53789390 com.zlq.app_intent_flags/.MainActivity}
我们看到，栈内顺序发生了变化，把ActivityB从栈中移到了栈顶。实例还是那个实例：**_53764490_**.
而各个Activiy生命周期的变化如LogCat中所示：
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onPause
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onNewIntent
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onRestart
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onStart
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityB-onResume
04-12 5399-5399/com.zlq.app_intent_flags V/zlq: ActivityD-onStop
5. Intent.FLAG_ACTIVITY_REORDER_TO_FRONT
经验证，和Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT作用一样。
# 参考资料
[关于intent.setFlags()的故事][1]
[1]: //www.greatytc.com/p/a488f06524dd