name="android.intent.category.DEFAULT"/>
然后,在appB中的FirstActivity跳转代码如下:
Intentintent=newIntent("android.intent.action.APP_A_SECOND_ACTIVITY");
startActivity(intent);
我们要演示几个步骤:
1.在appB中的FirstActivity点击按钮跳转到appA中的SecondActivity;2.按Home键回到主屏,在主选单中再次启动appB;3.按Home键回到主屏,在主选单中启动appA。
演示过程如图所示:
再次启动appB应用:
启动appA应用:
我们发现在从appB跳转到appA的SecondActivity之后,SecondActivity实例好像是嵌入到了appB中,但是不影响appA的正常运行,这种关系如下图所示:
然后我们修改一下跳转的代码:
Intentintent=newIntent("android.intent.action.APP_A_SECOND_ACTIVITY");
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
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时,跳转代码如下:
Intentintent=newIntent(this,SecondActivity.class);
intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
startActivity(intent);
然后跳转后SecondActivity实例如下:
从序列号可以看到这两个实例是不同的,证明它是经过了销毁和重新的过程。
然后我们把ThirdActivity中的跳转代码添加FLAG_ACTIVITY_SINGLE_TOP标记:
Intentintent=newIntent(this,SecondActivity.class);
intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP|Intent.FLAG_ACTIVITY_SINGLE_TOP);
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标记,所以前者会清除,后者不会。
关于这个标记,可以下图示之(下图显示仅仅是SecondActivity之上的Activity被清除,这个需要验证,但是知道此概念和作用):
这个标记对于应用存在分割点的情况会非常有用。
比如我们在应用主界面要选择一个图片,然后我们启动了图片浏览界面,但是把这个应用从后台恢复到前台时,为了避免让用户感到困惑,我们希望用户仍然看到主界面,而不是图片浏览界面,这个时候我们就要在转到图片浏览界面时的Intent中加入此标记。
5.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED:
这个标记在以下情况下会生效:
1.启动Activity时创建新的task来放置Activity实例;2.已存在的task被放置于前台。
系统会根据affinity对指定的task进行重置操作,task会压入某些Activity实例或移除某些Activity实例。
我们结合上面的CLEAR_WHEN_TASK_RESET可以加深理解。
的task相关属性
在中定义了几个常见的task相关属性,它们分别代表了task内部不同的行为特征,我们就来逐个介绍一下:
1.android:
allowTaskReparenting
这个属性用来标记一个Activity实例在当前应用退居后台后,再次启动时(场景),是否能从启动它的那个task移动到有共同affinity的task,“true”表示可以移动,“false”表示它必须呆在当前应用的task中,默认值为false。
如果一个这个Activity的元素没有设定此属性,设定在上的此属性会对此Activity起作用。
例如在一个应用中要查看一个web页面,在启动系统浏览器Activity后,这个Activity实例和当前应用处于同一个task,当我们的应用退居后台之后用户再次从主选单中启动应用,此时这个Activity实例将会重新宿主到Browser应用的task内,在我们的应用中将不会再看到这个Activity实例,而如果此时启动Browser应用,就会发现,第一个界面就是我们刚才打开的web页面,证明了这个Activity实例确实是宿主到了Browser应用的task内。
我们就来结合实例演示一下这个过程:
首先,在appB的FirstActivity中,我们将跳转动作做以下改动:
IntentviewIntent=newIntent(Intent.ACTION_VIEW,Uri.parse(".hk"));
startActivity(viewIntent);
进入appB时的界面:
启动web界面之后:
然后我们按Home键,是当前应用退居后台,我们回到主选单,重新启动appB,界面如下:
此时我们在主选单中启动Browser应用,出现在我们眼前的界面是这样的:
以上这种行为也证明了我们前面的论断,为了更清楚的说明问题,也为了让大家自己可以验证,下面我们要再次演示一下appB和appA的启动过程:
对于appA,在上面的基础上,不用修改其他地方,只需为SecondActivity的元素添加一个属性,如下:
name=".SecondActivity"android:
allowTaskReparenting="true">
...
然后,在appB中的FirstActivity跳转代码改为:
Intentintent=newIntent("android.intent.action.APP_A_SECOND_ACTIVITY");
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迁徙过来的(但是taskid没有变化),再启动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的元素,如下:
name=".FirstActivity"
android:
clearTaskOnLaunch="true">
...
FristActivity界面如下:
然后我们让FirstActivity跳转到SecondActivity,结果如下:
然后我们按Home键回到主界面,再次启动appB,我们看到以下结果:
我们看到,再次启动appB时,我们只能看到FirstActivity界面,此时在FirstActivity之上的所有Activity都已经被清除出栈。
示意图如下:
4.android:
finishOnTaskLaunch
这个属性和android:
allowReparenting属性相似,不同之处在于allowReparenting属性是重新宿主到有共同affinity的task中,而finishOnTaskLaunch属性是销毁实例。
如果这个属性和android:
allowReparenting都设定为“true”,则这个属性胜出。
以上就是今天总结的内容,这些都是常用的知识,除此之外还有很多等着我们去探索,继续努力。