Android基础总结篇之三:Activity的task相关介绍

本篇文章主要介绍了android基础总结篇之三:Activity的task相关,具有一定的参考价值,有需要的可以了解一下。

今天我们来讲一下Activity的task相关内容。

上次我们讲到Activity的四种启动模式的时候,已经了解到一些关于task的技术,今天我再向大家介绍一下。task是一个具有栈结构的容器,可以放置多个Activity实例。启动一个应用,系统就会为之创建一个task,来放置根Activity;默认情况下,一个Activity启动另一个Activity时,两个Activity是放置在同一个task中的,后者被压入前者所在的task栈,当用户按下后退键,后者从task被弹出,前者又显示在幕前,特别是启动其他应用中的Activity时,两个Activity对用户来说就好像是属于同一个应用;

系统task和task之间是互相独立的,当我们运行一个应用时,按下Home键回到主屏,启动另一个应用,这个过程中,之前的task被转移到后台,新的task被转移到前台,其根Activity也会显示到幕前,过了一会之后,在此按下Home键回到主屏,再选择之前的应用,之前的task会被转移到前台,系统仍然保留着task内的所有Activity实例,而那个新的task会被转移到后台,如果这时用户再做后退等动作,就是针对该task内部进行操作了。

我们今天就讲一下和task相关的知识,主要分一下几点:

1.Activity的affinity(亲和力)

2.Intent几种常见的flags

3.<activity>与task相关属性

affinity:

affinity对于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属性值:

<application android:name="Browser"
    android:label="@string/application_name"
    android:icon="@drawable/ic_launcher_browser"
    android:backupAgent=".BrowserBackupAgent"
    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配置如下:

<activity android:name=".SecondActivity">
   <intent-filter>
    <action android:name="android.intent.action.APP_A_SECOND_ACTIVITY" />
    <category android:name="android.intent.category.DEFAULT" />
   </intent-filter>
  </activity>

然后,在appB中的FirstActivity跳转代码如下:

Intent intent = new Intent("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的正常运行,这种关系如下图所示:

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

Intent intent = new Intent("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时,跳转代码如下:

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

然后跳转后SecondActivity实例如下:

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

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

Intent intent = new Intent(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标记,所以前者会清除,后者不会。关于这个标记,可以下图示之:

这个标记对于应用存在分割点的情况会非常有用。比如我们在应用主界面要选择一个图片,然后我们启动了图片浏览界面,但是把这个应用从后台恢复到前台时,为了避免让用户感到困惑,我们希望用户仍然看到主界面,而不是图片浏览界面,这个时候我们就要在转到图片浏览界面时的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中,我们将跳转动作做以下改动:

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

进入appB时的界面:

启动web界面之后:

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

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

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

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

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

然后,在appB中的FirstActivity跳转代码改为:

Intent intent = new Intent("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迁徙过来的,再启动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>元素,如下:

<activity android:name=".FirstActivity"
android:clearTaskOnLaunch="true">
...
</activity> 

FristActivity界面如下:

然后我们让FirstActivity跳转到SecondActivity,结果如下:

然后我们按Home键回到主界面,再次启动appB,我们看到以下结果:
我们看到,再次启动appB时,我们只能看到FirstActivity界面,此时在FirstActivity之上的所有Activity都已经被清除出栈。示意图如下:

4.android:finishOnTaskLaunch

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

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

原文链接:http://blog.csdn.net/liuhe688/article/details/6761337

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • Android Activity启动模式之singleTask实例详解

    本文实例分析了Android Activity启动模式之singleTask.分享给大家供大家参考,具体如下: 前面的文章介绍了Android 活动Activity的启动模式:standard 和singleTop .本文继续介绍Activity的下一个启动模式:singleTask. singleTask:当设置活动的启动模式为singleTask时,首先检查返回栈中是否存在当前活动,如果存在当前活动的实例,则直接使用当前实例,并把当前活动之上的所有活动pop出栈,即当前活动位于栈顶位置. 代

  • Android入门之Activity四种启动模式(standard、singleTop、singleTask、singleInstance)

    当应用运行起来后就会开启一条线程,线程中会运行一个任务栈,当Activity实例创建后就会放入任务栈中.Activity启动模式的设置在AndroidManifest.xml文件中,通过配置Activity的属性android:launchMode=""设置. 一.启动模式介绍 启动模式简单地说就是Activity启动时的策略,在AndroidManifest.xml中的标签的android:launchMode属性设置: 启动模式有4种,分别为standard.singleTop.s

  • Android基础总结篇之三:Activity的task相关介绍

    本篇文章主要介绍了android基础总结篇之三:Activity的task相关,具有一定的参考价值,有需要的可以了解一下. 今天我们来讲一下Activity的task相关内容. 上次我们讲到Activity的四种启动模式的时候,已经了解到一些关于task的技术,今天我再向大家介绍一下.task是一个具有栈结构的容器,可以放置多个Activity实例.启动一个应用,系统就会为之创建一个task,来放置根Activity:默认情况下,一个Activity启动另一个Activity时,两个Activi

  • android基础总结篇之二:Activity的四种launchMode

    我们今天要讲的是Activity的四种launchMode. launchMode在多个Activity跳转的过程中扮演着重要的角色,它可以决定是否生成新的Activity实例,是否重用已存在的Activity实例,是否和其他Activity实例公用一个task里.这里简单介绍一下task的概念,task是一个具有栈结构的对象,一个task可以管理多个Activity,启动一个应用,也就创建一个与之对应的task. Activity一共有以下四种launchMode: 1.standard 2.

  • android基础总结篇之九:Intent应用详解

    今天我们来讲一下Android中Intent的原理和应用. 前面我们总结了几个Android中重要组件,相信大家对于这些组件已经有了清晰的认识,我们就来看一下几个常见的操作: 启动一个Activity:Context.startActivity(Intent intent); 启动一个Service:Context.startService(Intent service); 绑定一个Service:Context.bindService(Intent service, ServiceConnec

  • android基础总结篇之一:Activity生命周期

    近来回顾了一下关于Activity的生命周期,参看了相关书籍和官方文档,也有了不小的收获,对于以前的认知有了很大程度上的改善,在这里和大家分享一下. 熟悉javaEE的朋友们都了解servlet技术,我们想要实现一个自己的servlet,需要继承相应的基类,重写它的方法,这些方法会在合适的时间被servlet容器调用.其实Android中的Activity运行机制跟servlet有些相似之处,Android系统相当于servlet容器,Activity相当于一个servlet,我们的Activi

  • android基础总结篇之八:创建及调用自己的ContentProvider

    今天我们来讲解一下如何创建及调用自己的ContentProvider. 在前面两篇文章中我们分别讲了如何读写联系人和短消息,相信大家对于ContentProvider的操作方法已经有了一定程度的了解.在有些场合,除了操作ContentProvider之外,我们还有可能需要创建自己的ContentProvider,来提供信息共享的服务,这就要求我们很好的掌握ContentProvider的创建及使用技巧.下面我们就由表及里的逐步讲解每个步骤. 在正式开始实例演示之前,我们先来了解以下两个知识点:

  • Android基础之Fragment与Activity交互详解

    今天继续讲解Fragment组件的特性,主要是跟Activity的交互和生命周期的关系,我们前面已经说过Fragment是依赖于Activity的,而且生命周期也跟Activity绑定一起.下面我们看看Fragment跟Activity的关系. 1.为Activity创建事件回调方法在一些情况下, 你可能需要一个fragment与activity分享事件. 一个好的方法是在fragment中定义一个回调的interface, 并要求宿主activity实现它.当activity通过interfa

  • Android Bitmap的加载优化与Cache相关介绍

    一 . 高效加载 Bitmap BitMapFactory 提供了四类方法: decodeFile,decodeResource,decodeStream 和 decodeByteArray 分别用于从文件系统,资源,输入流以及字节数组中加载出一个 Bitmap 对象. 高效加载 Bitmap 很简单,即采用 BitMapFactory.options 来加载所需要尺寸图片.BitMapFactory.options 就可以按照一定的采样率来加载缩小后的图片,将缩小后的图片置于 ImageVie

  • 基于Android 监听ContentProvider 中数据变化的相关介绍

    如果ContentProvider的访问者需要知道ContentProvider中的数据的变化情况,可以在ContentProvider发生数据变化时调用getContentResolver().notifyChange(uri,null)来通知注册在此URI上的访问者. 复制代码 代码如下: public class PersonContentProvider extends ContentProvider[ public Uri insert(Uri uri,ContentValues va

  • Android入门教程之组件Activity的生命周期详解

    目录 返回栈 Activity 状态 1. 运行状态 2. 暂停状态 3. 停止状态 4. 销毁状态 Activity 的生存期 onCreate() onStart() onResume() onPause() onStop() onDestroy() onRestart() 完整生存期 可见生存期 前台生存期 Activity 回收处理 返回栈 Android 中的 Activity 是可以层叠的,我们每启动一个新的 Activity,就会覆盖在原有的 Activity 之上,然后点击 Ba

  • Android基础之隐藏标题栏/设置为全屏/横竖屏切换

    目录 隐藏标题栏 设置为全屏 横竖屏切换 屏幕旋转方式 动态设置屏幕方向 设置横竖屏切换 总结 隐藏标题栏 基于xml <application android:theme="@style/Theme.AppCompat.Light.NoActionBar"> 动态隐藏 //继承自Activity时使用 requestWindowFeature(Window.FEATURE_NO_TITLE); //继承自AppCompatActivity时使用 getSupportAct

随机推荐