從前文知道，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]: http://www.lxweimin.com/p/a488f06524dd