Android Intent.setFlags()

在Activity 之间进行跳转时常常会用到一些Flags。官方文档解释：

public Intent setFlags (int flags)

Added in API level 1

Set special flags controlling how this intent is handled. Most values here depend on the type of component being executed by the Intent, specifically the FLAG_ACTIVITY_* flags are all for use withContext.startActivity() and the FLAG_RECEIVER_* flags are all for use withContext.sendBroadcast().

See the Tasks and Back Stack documentation for important information on how some of these options impact the behavior of your application.

Parameters

flagsThe desired flags.

Returns

• Returns the same Intent object, for chaining multiple calls into a single statement.

See Also

• getFlags()
• addFlags(int)
• FLAG_GRANT_READ_URI_PERMISSION
• FLAG_GRANT_WRITE_URI_PERMISSION
• FLAG_GRANT_PERSISTABLE_URI_PERMISSION
• FLAG_GRANT_PREFIX_URI_PERMISSION
• FLAG_DEBUG_LOG_RESOLUTION
• FLAG_FROM_BACKGROUND
• FLAG_ACTIVITY_BROUGHT_TO_FRONT
• FLAG_ACTIVITY_CLEAR_TASK
• FLAG_ACTIVITY_CLEAR_TOP
• FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET
• FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS
• FLAG_ACTIVITY_FORWARD_RESULT
• FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY
• FLAG_ACTIVITY_MULTIPLE_TASK
• FLAG_ACTIVITY_NEW_DOCUMENT
• FLAG_ACTIVITY_NEW_TASK
• FLAG_ACTIVITY_NO_ANIMATION
• FLAG_ACTIVITY_NO_HISTORY
• FLAG_ACTIVITY_NO_USER_ACTION
• FLAG_ACTIVITY_PREVIOUS_IS_TOP
• FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
• FLAG_ACTIVITY_REORDER_TO_FRONT
• FLAG_ACTIVITY_SINGLE_TOP
• FLAG_ACTIVITY_TASK_ON_HOME
• FLAG_RECEIVER_REGISTERED_ONLY

Intent.setFlags()函数用法：

Intent的常用Flag参数：

FLAG_ACTIVITY_CLEAR_TOP：
例如现在的栈情况为：A B C D 。D此时通过intent跳转到B，如果这个intent添加FLAG_ACTIVITY_CLEAR_TOP标记，则栈情况变为：A B。如果没有添加这个标记，则栈情况将会变成：A B C D B。也就是说，如果添加了FLAG_ACTIVITY_CLEAR_TOP标记，并且目标Activity在栈中已经存在，则将会把位于该目标activity之上的activity从栈中弹出销毁。这跟上面把B的Launch mode设置成singleTask类似。

FLAG_ACTIVITY_NEW_TASK：
例如现在栈1的情况是：A B C。C通过intent跳转到D，并且这个intent添加了FLAG_ACTIVITY_NEW_TASK标记，如果D这个Activity在Manifest.xml中的声明中添加了Task affinity，并且和栈1的affinity不同，系统首先会查找有没有和D的Task affinity相同的task栈存在，如果有存在，将D压入那个栈，如果不存在则会新建一个D的affinity的栈将其压入。如果D的Task affinity默认没有设置，或者和栈1的affinity相同，则会把其压入栈1，变成：A B C D，这样就和不加FLAG_ACTIVITY_NEW_TASK标记效果是一样的了。注意如果试图从非activity的非正常途径启动一个activity，比如从一个service中启动一个activity，则intent必须要添加FLAG_ACTIVITY_NEW_TASK标记。

FLAG_ACTIVITY_NO_HISTORY：
例如现在栈情况为：A B C。C通过intent跳转到D，这个intent添加FLAG_ACTIVITY_NO_HISTORY标志，则此时界面显示D的内容，但是它并不会压入栈中。如果按返回键，返回到C，栈的情况还是：A B C。如果此时D中又跳转到E，栈的情况变为：A B C E，此时按返回键会回到C，因为D根本就没有被压入栈中。

FLAG_ACTIVITY_SINGLE_TOP：和上面Activity的Launch mode的singleTop类似。如果某个intent添加了这个标志，并且这个intent的目标activity就是栈顶的activity，那么将不会新建一个实例压入栈中。
Activity的主要属性：（在 AndroidManifest.xml中 <activity  android:XXX  />）
allowTaskReparenting：设置成true时，和Intent的FLAG_ACTIVITY_NEW_TASK标记类似。
alwaysRetainTaskStat:   如果用户长时间将某个task移入后台，则系统会将该task的栈内容弹出只剩下栈底的activity，此时用户再返回，则只能看到根activity了。如果栈底的activity的这个属性设置成true，则将阻止这一行为，从而保留所有的栈内容。
clearTaskOnLaunch：根activity的这个属性设置成true时，和上面的alwaysRetainTaskStat的属性为true情况搞好相反。
finishOnTaskLaunch：对于任何activity，如果它的这个属性设置成true，则当task被放置到后台，然后重新启动后，该activity将不存在了。

以下来自：http://peirenlei.iteye.com/blog/1717716

Android 的一个特色就是 application A 的 activity 可以启动 application B 的 activity，尽管 A 和 B 是毫无干系的，而在用户看来，两个场景紧密联系，视觉上二者构成了一个整体。Android 就是把这种误觉定义为 Task，它既不是 class，也不是 AndroidMainifest.xml 中的一个元素。从表现上看 Task 就像是一个 stack，一个一个的 activity 是构成 stack 的元素，做着入栈 (push) 和出栈 (pop-up)这样简单重复性的劳动。

默认的规则总是满足大多数的应用场景，但是也总会有一些例外打破习以为常的惯例。Task 的默认规则同样并非牢不可破，修改的方法还是有的。借助 Intent 中的 flag 和 AndroidMainifest.xml 中 activity 元素的属性，就可以控制到 Task 里 Activity 的关联关系和行为。

在 android.content.Intent 中一共定义了20种不同的 flag，其中和 Task 紧密关联的有四种：
1.FLAG_ACTIVITY_NEW_TASK
2.FLAG_ACTIVITY_CLEAR_TOP
3.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
4.FLAG_ACTIVITY_SINGLE_TOP

在使用这四个 flag 时，一个 Intent 可以设置一个 flag，也可以选择若干个进行组合。

默认情况下，通过 startActivity() 启动一个新的 Activity，新的 Activity 将会和调用者在同一个 stack 中。但是，如果在传递给 startActivity() 的 Intent 对象里包含了 FLAG_ACTION_NEW_TASK，情况将发生变化，–系统将为新的 Activity “寻找”一个不同于调用者的 Task。不过要找的 Task 是不是一定就是 NEW 呢？如果是第一次执行，则这个设想成立，如果说不是，也就是说已经有一个包含此 Activity 的Task 存在，则不会再启动 Activity。

如果 flag 是 FLAG_ACTIVITY_CLEAR_TOP，同时当前的 Task 里已经有了这个 Activity，那么情形又将不一样。Android 不但不会启动新的 Activity 实例，而且还会将 Task 里 该 Activity 之上的所有 Activity 一律结束掉，然后将 Intent 发给这个已存在的 Activity。Activity 收到 Intent 之后，可以在 onNewIntent() 里做下一步的处理，也可以自行结束然后重新创建自己。如果 Activity 在 AndroidMainifest.xml 里将启动模式设置成”multiple”，– 默认模式，并且 Intent 里也没有设置 FLAG_ACTIVITY_SINGLE_TOP，那么它将选择后者。否则，它将选择前者。FLAG_ACTIVITY_CLEAR_TOP 还可以和 FLAG_ACTION_NEW_TASK 配合使用。

如果 flag 设置的是 FLAG_ACTIVITY_SINGLE_TOP，则意味着如果 Activity 已经是运行在 Task 的 top，则该 Activity 将不会再被启动。

 

设置intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);  

下面是关于setFlags的一下属性的解释：

一、Activity和Task(栈)的关系
Task就像一个容器，而Activity就相当与填充这个容器的东西，第一个东西（Activity）则会处于最下面，最后添加的东西（Activity）则会在最低端。从Task中取出东西（Activity）则是从最顶端取出，也就是说最先取出的是最后添加的东西（Activity），一次类推，最后取出的是第一次添加的Activity，而Activity在Task中的顺序是可以控制的，那则在Activity跳转时用到Intent Flag
二、界面跳转和服务的启动都会用到Intent，现在介绍Intent Flag是关于Activity的跳转
Intent intent = new Intent(this,xxx.class);
//如果activity在task存在，拿到最顶端,不会启动新的Activity
intent.addFlags(Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT);
//如果activity在task存在，将Activity之上的所有Activity结束掉
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
//默认的跳转类型,将Activity放到一个新的Task中
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
//如果Activity已经运行到了Task，再次跳转不会在运行这个Activity
intent.addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP);

来自：http://www.anddevs.com/?p=118

 

1.Activity的affinity(亲和力)

2.Intent几种常见的flags

3.<activity>与task相关属性

affinity：

task对于Activity来说就好像它的身份证一样，可以告诉所在的task，自己属于这个task中的一员；拥有相同affinity的多个Activity理论同属于一个task，task自身的affinity决定于根Activity的affinity值。affinity在什么场合应用呢？1.根据affinity重新为Activity选择宿主task（与allowTaskReparenting属性配合工作）；2.启动一个Activity过程中Intent使用了FLAG_ACTIVITY_NEW_TASK标记，根据affinity查找或创建一个新的具有对应affinity的task。我们会在后面进行详细讲解。

默认情况下，一个应用内的所有Activity都具有相同的affinity，都是从Application（参考<application>的taskAffinity属性）继承而来，而Application默认的affinity是<manifest>中的包名，我们可以为<application>设置taskAffinity属性值，这样可以应用到<application>下的所有<activity>，也可以单独为某个Activity设置taskAffinity。例如：在系统自带的Browser中，package为com.android.browser，但是<application>却自定义一个taskAffinity属性值：

 

[html] view plaincopy

1. <application   android:name="Browser"  
2.                android:label="@string/application_name"  
3.                android:icon="@drawable/ic_launcher_browser"  
4.                android:backupAgent=".BrowserBackupAgent"  
5.                android:taskAffinity="android.task.browser" >  

 

Intent几种常见的flags：

在android.content.Intent中定义了若干个flags，其中最重要的有以下几个：

1.FLAG_ACTIVITY_NEW_TASK：当Intent对象包含这个标记时，系统会寻找或创建一个新的task来放置目标Activity，寻找时依据目标Activity的taskAffinity属性进行匹配，如果找到一个task的taskAffinity与之相同，就将目标Activity压入此task中，如果查找无果，则创建一个新的task，并将该task的taskAffinity设置为目标Activity的taskActivity，将目标Activity放置于此task。注意，如果同一个应用中Activity的taskAffinity都使用默认值或都设置相同值时，应用内的Activity之间的跳转使用这个标记是没有意义的，因为当前应用task就是目标Activity最好的宿主。下面我们会通过实例进行演示这个特性：

我们新建两个项目，分别命名为appA和appB，并且分别创建FirstActivity和SecondActivity，我们准备让appB中的FirstActivity跳转到appA的SecondActivity。appA中的SecondActivity配置如下：

 

[html] view plaincopy

1. <activity android:name=".SecondActivity">  
2.             <intent-filter>  
3.                 <action android:name="android.intent.action.APP_A_SECOND_ACTIVITY" />  
4.                 <category android:name="android.intent.category.DEFAULT" />  
5.             </intent-filter>  
6.         </activity>  

然后，在appB中的FirstActivity跳转代码如下：

 

 

[java] view plaincopy

1. Intent intent = new Intent("android.intent.action.APP_A_SECOND_ACTIVITY");  
2. startActivity(intent);  

我们要演示几个步骤：1.在appB中的FirstActivity点击按钮跳转到appA中的SecondActivity；2.按Home键回到主屏，在主选单中再次启动appB；3.按Home键回到主屏，在主选单中启动appA。演示过程如图所示：

 

再次启动appB应用：

启动appA应用：

我们发现在从appB跳转到appA的SecondActivity之后，SecondActivity实例好像是嵌入到了appB中，但是不影响appA的正常运行，这种关系如下图所示：

然后我们修改一下跳转的代码：

 

[java] view plaincopy

1. Intent intent = new Intent("android.intent.action.APP_A_SECOND_ACTIVITY");  
2. intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);  
3. startActivity(intent);  

我们加上了FLAG_NEW_TASK标记，在来看一下演示结果：

 

再次启动appB：

启动appA：

我们看到差别了吧，当我们再次启动appB时已经看不到刚才启动的appA中的SecondActivity，而启动appA时却直接看到了，说明这个SecondActivity实例并不在appB的task内，而是创建了一个task，这个task的affinity就是SecondActivity默认的affinity，由于appA的SecondActivity的affinity是从Application继承而来，所以当appA启动时会直接找到这个task，而不是创建新的task。我们看一下解析图：

2.FLAG_ACTIVITY_CLEAR_TOP：当Intent对象包含这个标记时，如果在栈中发现存在Activity实例，则清空这个实例之上的Activity，使其处于栈顶。例如：我们的FirstActivity跳转到SecondActivity，SecondActivity跳转到ThirdActivity，而ThirdActivity又跳到SecondActivity，那么ThirdActivity实例将被弹出栈，使SecondActivity处于栈顶，显示到幕前，栈内只剩下FirstActivity和SecondActivity。这个SecondActivity既可以在onNewIntent()中接收到传来的Intent，也可以把自己销毁之后重新启动来接受这个Intent。在使用默认的“standard”启动模式下，如果没有在Intent使用到FLAG_ACTIVITY_SINGLE_TOP标记，那么它将关闭后重建，如果使用了这个FLAG_ACTIVITY_SINGLE_TOP标记，则会使用已存在的实例；对于其他启动模式，无需再使用FLAG_ACTIVITY_SINGLE_TOP，它都将使用已存在的实例，Intent会被传递到这个实例的onNewIntent()中。

下面我们来验证一下这个过程：

首先，Activity启动模式都按照默认值“standard”。从FirstActivity跳转到SecondActivity，SecondActivity实例如下：

从ThirdActivity跳转到SecondActivity时，跳转代码如下：

 

[java] view plaincopy

1. Intent intent = new Intent(this, SecondActivity.class);  
2. intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);  
3. startActivity(intent);  

然后跳转后SecondActivity实例如下：

 

从序列号可以看到这两个实例是不同的，证明它是经过了销毁和重新的过程。

然后我们把ThirdActivity中的跳转代码添加FLAG_ACTIVITY_SINGLE_TOP标记：

 

[java] view plaincopy

1. Intent intent = new Intent(this, SecondActivity.class);  
2. intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP);  
3. startActivity(intent);  

两次实例均如下图所示：

如果我们不想添加FLAG_ACTIVITY_SINGLE_TOP，那么把SecondActivity的启动模式改为“standard”之外的三种即可，效果和上面一样，都不会创建新的实例。

3.FLAG_ACTIVITY_SINGLE_TOP：当task中存在目标Activity实例并且位于栈的顶端时，不再创建一个新的，直接利用这个实例。我们在上边的例子中也有讲到。

4.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET：如果一个Intent中包含此属性，则它转向的那个Activity以及在那个Activity其上的所有Activity都会在task重置时被清除出task。当我们将一个后台的task重新回到前台时，系统会在特定情况下为这个动作附带一个FLAG_ACTIVITY_RESET_TASK_IF_NEEDED标记，意味着必要时重置task，这时FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET就会生效。经过测试发现，对于一个处于后台的应用，如果在主选单点击应用，这个动作中含有FLAG_ACTIVITY_RESET_TASK_IF_NEEDED标记，长按Home键，然后点击最近记录，这个动作不含FLAG_ACTIVITY_RESET_TASK_IF_NEEDED标记,所以前者会清除，后者不会。关于这个标记，可以下图示之：

这个标记对于应用存在分割点的情况会非常有用。比如我们在应用主界面要选择一个图片，然后我们启动了图片浏览界面，但是把这个应用从后台恢复到前台时，为了避免让用户感到困惑，我们希望用户仍然看到主界面，而不是图片浏览界面，这个时候我们就要在转到图片浏览界面时的Intent中加入此标记。

5.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED：这个标记在以下情况下会生效：1.启动Activity时创建新的task来放置Activity实例；2.已存在的task被放置于前台。系统会根据affinity对指定的task进行重置操作，task会压入某些Activity实例或移除某些Activity实例。我们结合上面的CLEAR_WHEN_TASK_RESET可以加深理解。

<activity>的task相关属性

在<activity>中定义了几个常见的task相关属性，它们分别代表了task内部不同的行为特征，我们就来逐个介绍一下：

1.android:allowTaskReparenting

这个属性用来标记一个Activity实例在当前应用退居后台后，是否能从启动它的那个task移动到有共同affinity的task，“true”表示可以移动，“false”表示它必须呆在当前应用的task中，默认值为false。如果一个这个Activity的<activity>元素没有设定此属性，设定在<application>上的此属性会对此Activity起作用。例如在一个应用中要查看一个web页面，在启动系统浏览器Activity后，这个Activity实例和当前应用处于同一个task，当我们的应用退居后台之后用户再次从主选单中启动应用，此时这个Activity实例将会重新宿主到Browser应用的task内，在我们的应用中将不会再看到这个Activity实例，而如果此时启动Browser应用，就会发现，第一个界面就是我们刚才打开的web页面，证明了这个Activity实例确实是宿主到了Browser应用的task内。我们就来结合实例演示一下这个过程：

首先，在appB的FirstActivity中，我们将跳转动作做以下改动：

 

[java] view plaincopy

1. Intent viewIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.google.com.hk"));  
2. startActivity(viewIntent);  

进入appB时的界面：

 

启动web界面之后：

然后我们按Home键，是当前应用退居后台，我们回到主选单，重新启动appB，界面如下：

此时我们在主选单中启动Browser应用，出现在我们眼前的界面是这样的：

以上这种行为也证明了我们前面的论断，为了更清楚的说明问题，也为了让大家自己可以验证，下面我们要再次演示一下appB和appA的启动过程：

对于appA，在上面的基础上，不用修改其他地方，只需为SecondActivity的<activity>元素添加一个属性，如下：

 

[html] view plaincopy

1. <activity android:name=".SecondActivity" android:allowTaskReparenting="true">  
2. ...           
3. </activity>  

然后，在appB中的FirstActivity跳转代码改为：

 

 

[java] view plaincopy

1. Intent intent = new Intent("android.intent.action.APP_A_SECOND_ACTIVITY");  
2. startActivity(intent);  

我们启动appB，看到一下界面：

 

然后点击按钮，跳转到appA中的SecondActivity，界面如下：

此时appB中的FirstActivity和appA中的SecondActivity处于同一个task中taskid为28，然后我们按下Home键，在主选单中再次启动appB，我们发现appA的SecondActivity不见了，我们看到的是：

然后我们启动appA，这是我们不会看到它的FirstActivity，而是看到了它的SecondActivity：

通常两个应用分别有自己的task，它们的taskid肯定不同，但这里的SecondActivity却显示taskid与appB相同，我们想一下也许就明白了，原来它是appB迁徙过来的，再启动appA时并未生成任何新的Activity实例。这个时候如果我们按下后退键，appA就会立即退出，证明了此时appA的task里只有一个Activity实例，也就是这个SecondActivity实例。

需要注意的是，如果appB退居后台之后，没有再次启动appB，而是直接启动appA，将不会出现以上现象。重新宿主的动作发生在appB再次启动的过程中。

android:allowReparenting的效果图如下：

2.android:alwaysRetainTaskState

这个属性用来标记应用的task是否保持原来的状态，“true”表示总是保持，“false”表示不能够保证，默认为“false”。此属性只对task的根Activity起作用，其他的Activity都会被忽略。

默认情况下，如果一个应用在后台呆的太久例如30分钟，用户从主选单再次选择该应用时，系统就会对该应用的task进行清理，除了根Activity，其他Activity都会被清除出栈，但是如果在根Activity中设置了此属性之后，用户再次启动应用时，仍然可以看到上一次操作的界面。

这个属性对于一些应用非常有用，例如Browser应用程序，有很多状态，比如打开很多的tab，用户不想丢失这些状态，使用这个属性就极为恰当。

3.android:clearTaskOnLaunch

这个属性用来标记是否从task清除除根Activity之外的所有的Activity，“true”表示清除，“false”表示不清除，默认为“false”。同样，这个属性也只对根Activity起作用，其他的Activity都会被忽略。

如果设置了这个属性为“true”，每次用户重新启动这个应用时，都只会看到根Activity，task中的其他Activity都会被清除出栈。如果我们的应用中引用到了其他应用的Activity，这些Activity设置了allowTaskReparenting属性为“true”，则它们会被重新宿主到有共同affinity的task中。

无图无真相，我们就来以实例演示一下这个过程，我们首先修改appB的根Activity的<activity>元素，如下：

 

[html] view plaincopy

1. <activity android:name=".FirstActivity"  
2.                   android:clearTaskOnLaunch="true">  
3.         ...      
4. </activity>  

 

FristActivity界面如下：

然后我们让FirstActivity跳转到SecondActivity，结果如下：

然后我们按Home键回到主界面，再次启动appB，我们看到以下结果：

我们看到，再次启动appB时，我们只能看到FirstActivity界面，此时在FirstActivity之上的所有Activity都已经被清除出栈。示意图如下：

4.android:finishOnTaskLaunch

这个属性和android:allowReparenting属性相似，不同之处在于allowReparenting属性是重新宿主到有共同affinity的task中，而finishOnTaskLaunch属性是销毁实例。如果这个属性和android:allowReparenting都设定为“true”，则这个属性胜出。

以上就是今天总结的内容，这些都是常用的知识，除此之外还有很多等着我们去探索，继续努力。