详解Activity启动模式（三）Intent Flags

从前文知道，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.jianshu.com/p/a488f06524dd

最后编辑于：2017.12.03 04:07:35

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 203,456评论 5赞 477
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 85,370评论 2赞 381
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 150,337评论 0赞 337
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 54,583评论 1赞 273
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 63,596评论 5赞 365
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 48,572评论 1赞 281
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 37,936评论 3赞 395
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 36,595评论 0赞 258
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 40,850评论 1赞 297
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 35,601评论 2赞 321
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 37,685评论 1赞 329
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 33,371评论 4赞 318
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 38,951评论 3赞 307
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 29,934评论 0赞 19
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 31,167评论 1赞 259
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 43,636评论 2赞 349
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 42,411评论 2赞 342

详解Activity启动模式（三）Intent Flags

常用Intent Flags

实例验证

推荐阅读更多精彩内容