FLAG_ACTIVITY_NEW_TASK和SingleInstance的设计思路(多task的应用)

这部分的想法都是基于以下两点:

1.Activity可能被复用,可能是复用Activity的功能,还可能是复用Activity的状态;

2.Task的作用:target,同一个task中的Activity服务于相同的或者接近的目标(target)。

(一个task的目标往往由task的root Activity决定,因为是root Activity造就了这个task)。

Activity复用情景1

在当前App中,通过Intent,打开了当前App或其他App的一个Activity(standard或singleTop),则这个Activity变成当前task的一部分。

即:在当前task中打开了一个activity

使用理由:

为了完成task的目标,需要新的Activity的完全参与进来,需要它成为task的一部分,可以这样子复用;

Activity复用情景2

在当前App中,通过Intent,使用FLAG_ACTIVITY_NEW_TASK打开了当前App(新Activity的task_affinity与当前app中其他Activity不同)或其他App的一个Activity(非singleInstance),

1. 假如这个Activity没有被打开过,且没有一个task的affinity与这个Activity相同,则这个Activity变为新的task的root Activity,创建了一个新的task。

2. 如果有其他的task的affinity与这个Activity相同,则会将旧的task调起,将这个Activity在这个task中打开,

3.假如这个Activity已经被打开过,则会将旧的task调起,如果配合FLAG_ACTIVITY_CLEAR_TOP标签,新的Activity以上的Activity会被销毁,也就是打开了一个全新的Activity以供复用。

4. 如果要打开的Activity为singleTask,不论有没有加FLAG_ACTIVITY_CLEAR_TOP标签,都有上层Activity出栈的效果。

以上四种情况都可以归纳为在新的task中打开了要复用的Activity

使用理由:

为了完成task的目标,需要用到新的Activity,但是这个Activity的功能,与原来task的目标有一定差距,体验上是一个新的功能,则需要创建一个独立的task,在这个task完成它的任务后,旧的task可能就不关心这个task了(比如新的task中的activity只是显示一个通知,让用户看一眼,看完就可以不管),或者,新的Activity不应该过度参与到旧的task中,(比如通知看完了就不应该再存在在task中),这种情况下就可以这样复用。

与第一种复用情形还有一个区别,这个Task中的Activity在被销毁前是可以被其他task重用的。

Activity复用情景3

在当前App中,通过Intent,打开了一个SingleInstance的Activity,会创建一个新的task,且新的task中永远只有一个Activity。

使用理由:

与复用情形2一样,因为新的Activity的功能与原来的task的目标有一定差距,所以不能视为同一个task,所以要在新的task中打开这个Activity。

但与情形2不同的是,情形2中,旧的task不关心打开的新Activity,但打开的新Activity所在的task,可以继续创建Activity为新task的目标服务(比如添加附件功能)。

 

而在情形3中,新的task只有一个目标,就是发挥当前Activity的功能。不愿过多地执行更多功能,就需要使用singleInstance的模式。(比如打电话就是纯粹的打电话,打完电话该做什么不是打电话所在的这个task该关心的)

另一方面,新的task在被复用的时候,不会增加Activity,也可以保证其他task重用这个task的时候,不会受到其他task复用时新增Activity的影响

情形2和情形3使得创建后的Activity可以被复用,节省了创建时的开销。

时间: 2024-10-28 09:35:41

FLAG_ACTIVITY_NEW_TASK和SingleInstance的设计思路(多task的应用)的相关文章

Pongo网页版JavaScript源代码及设计思路

1.游戏背景介绍(写在前面的废话): 五月初的某天,看到某网推荐了这款游戏,Pongo,看着还不错的样子就用ipad下下来试玩了下,玩了两局感觉还错挺过瘾的,因为是手欠类游戏嘛大家懂的. 但是没一会发现游戏在ipad似乎有些bug,玩一会就会卡住然后只能强退了,真是揪心,记录还等着破呢. 怎么办?玩游戏不如玩自己的游戏的念头又邪恶的出现了,然后就把pad丢给了朋友虐心去,我默默回到电脑前开始动手自己写个不会卡的. 大概两小时吧,写出了基本框架,然后扔sinaapp里试了下效果基本能玩就洗洗睡了.

JS表格分页组件:fupage的设计思路和具体用法(未来考虑开源,争取在2015年)

一.背景         之前在秒针工作的时候,某js高级工程师写了很多自己的组件,其中一套是分页组件,叫做st-grid.不过在我看来,bug太多,我经常给他反馈bug,我也不清楚为啥别人没有发现.    回到武汉工作后,我自己利用业余实践完善自己的官网,从前端到后端,都是自己一个人亲自搞定.    第1个分页的需求是,文章下方的评论,异步加载.第2个需求是,表格管理,比如后台管理系统,经常需要列出user.log等表的记录.   二.实例 <table class="table tab

流程管理中WEB表单开发服务需求分析及设计思路

在流程管理应用中,BPM产品所提供的表单设计工具,主要是面向开发人员的.而一些办公系统产品所提供的表单设计工具,受自身平台限制,无法在大型定制化应用中使用.在此通过对用户需求分析,提出WEB表单开发服务设计思路. 一.需求分析 现如今,在创新与改革社会环境推动下,办公管理系统的管理需求变化已经是常态了,如何让信息系统快速响应支撑管理需求的多变,已经成为使信息化建设和运维人员头痛的事情.特别是在一些大型企事业单位,快速支撑需求更突出.而原有信息系统很难适应这样的需求,必须走创新的路来解决这些需求,

用MongoDB数据库来管理办公系统中文档型的表单和信息——通用流程化应用审批单设计思路(二,续)

1.办公系统中文档的定义 办公系统中的文档就是指对数据不敏感的业务,例如流程中的审批单.信息专栏.数据上报.信息记录等.而对于这些信息的管理,特别是时效性较强的管理记录,仍采用关系型数据库进行管理. (1)流程中审批单 流程中审批单由功能按钮区.特殊功能区.业务表单区.附件区.审批意见区等区域构成,其中,业务表单区理论上包含附件和意见,但是由于附件和意见的业务特殊性,需要单独进行管理,剩下的业务表单就可以看作文档了. 在一些流程审批业务中,业务信息有的是以Excel或word文件等方式专递,这样

这一设计思路显然降低了新 DBMS 部署方案

数据库管理系统(简称 DBMS)无疑是任何数据密集型应用程序当中最为重要的组成部分,其肩负着处理大量数据以及高复杂性工作负载的重任.然而,数据库管理系统本身却往往难于管理,因为其中通常包含数百种配置"旋钮",用于控制诸如缓存内存分配量以及存储介质数据写入频率等要素.各类企业一般需要聘请专业人士以协助相关调配工作,但对于大多数企业而言,此类专业人才的开价亦相当高昂.而实际上,DBA所面临的挑战还远不止这些. 而今天一则名为"OtterTune"的机器学习DBMS系统刷

Redis设计思路学习与总结

版权声明:本文由宋增宽原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/222 来源:腾云阁 https://www.qcloud.com/community 宋增宽,腾讯工程师,16年毕业加入腾讯,从事海量服务后台设计与研发工作,现在负责QQ群后台等项目,喜欢研究技术,并思考技术演变,专注于高并发业务架构的设计与性能优化. 下半年利用空余时间研究和分析了部分Redis源码,本文从网络模型.数据结构和内存管理.持久化和多机

测试用例的设计思路

在结对项目中,我负责测试用力的设计以及执行.在设计测试用例的过程中,我运用到了以下思路. 良好测试用例的特征: 可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求既不过分复杂.也不能过分简单 使软件缺陷的表现可以清楚的判定 测试用例包含期望的正确的结果待查的输出结果或文件必须尽量简单明了 不包含重复的测试用例 测试用例内容清晰.格式一致.分类组织 测试用例的几种设计思路: 对于白盒测试: 1. 语句覆盖:设计若干个测试用例,使程序中的每个可执行语句至  

基于Java Bean Validation对Request参数进行校验的设计思路

摘自Hibernate Validator文档: 数据校验是任何一个应用程序都会用到的功能,无论是显示层还是持久层. 通常,相同的校验逻辑会分散在各个层中, 这样,不仅浪费了时间还会导致重复代码的发生. 为了避免重复, 开发人员经常会把这些校验逻辑直接写在领域模型里面, 但是这样又把领域模型代码和校验代码混杂在了一起, 而这些校验逻辑更应该是描述领域模型的元数据. JSR 303 - Bean Validation (version 1.1)- 为实体验证定义了元数据模型和API. 默认的元数据

俄罗斯方块的设计思路

前段时间帮人写了个俄罗斯方块的Demo,今天有时间分享下设计思路. 分析: 游戏中会出现7种形状,每种形状在游戏中都能够旋转,形成新的形状.每种形状都是由方形的色块组成的. 数据类: Shape:形状类,总共7个. Block:方块类,其实只有一个贴图的属性. 关于旋转: 为每个形状寻找旋转点,每个形状的旋转点都是固定的. 红色的点为参考点,所在行列为(x,y) 在Shape的数据中将旋转后的各个Block相对于红色Block的位置都记录下来,游戏中旋转的时候直接根据红色的Block确定其他的位