[0135] process=":pn"/>
[0136] 扩展后,各个组件可以按照p0到pn进程运行。
[0137] 进一步地,步骤S102在宿主的配置文件中注册多个预留进程时,可以在宿主的配置文件中写入进程信息,以注册各个预留进程,其中,进程信息至少可以包括进程的编号、进程的状态、进程对应的插件名、插件中不同类型的组件的使用数量,等等,本发明实施例不限于此。
[0138] 在步骤S110在目标预留进程中运行任意组件之后,还可以将目标预留进程的状态标记为表示已分配的状态,以表示目标预留进程被占用。
[0139] 本发明实施例除了可以实现多进程匹配,还可以根据插件Activity的TaskAffinity的区分并动态匹配Activity。
[0140] 图3示出了根据本发明一实施例的动态匹配活动界面的方法的流程图,在Android系统中,活动界面为Activity。在图3中,该方法至少包括以下步骤S302至S310。
[0141] 步骤S302,获取宿主的插件的多个任务,其中,多个任务各自能够实现插件的不同功能。
[0142] 在该步骤中,例如手机卫士上的防盗插件有多个任务,分别能够实现定位、报警等功能。
[0143] 步骤S304,在宿主的配置文件中注册多个任务各自的活动界面所属的Task,其中,不同的任务各自的活动界面属于不同的Task。
[0144] 步骤S306,当宿主加载插件并启动多个任务中的任意任务的当前活动界面时,在配置文件中查找当前活动界面所属的目标Task。
[0145] 步骤S308,在宿主中查找目标Task对应的所有注册界面,并依据预设的选取策略从目标Task对应的所有注册界面中选取目标注册界面。
[0146] 步骤S310,将目标注册界面分配给当前活动界面使用。
[0147] 可以看到,本发明实施例在宿主的配置文件中注册多个任务各自的活动界面所属的Task,并且不同的任务各自的活动界面属于不同的Task,这样使得不同的任务之间能够自由切换,无需退出任务。并且,本发明实施例在启动任意任务的当前活动界面时,能够从当前活动界面所属的目标Task对应的所有注册界面中选取目标注册界面,将目标注册界面分配给当前活动界面使用,保证了任务界面的正常启动。
[0148] 宿主的Task是固定的,且有多个,每个Task包含多个活动界面,都预埋或配置在宿主的配置文件中。以Android系统为例,宿主的每个Task包含多个Activity,都预埋在宿主的配置文件AndroidManifest.xml中。宿主的每个Task中能够放置或装载多个Activity,其回退和打开的顺序逻辑和基本的数据结构栈是一致的。
[0149] 进一步地,步骤S304中在宿主的配置文件中注册多个任务各自的活动界面所属的Task,本发明实施例提供了一种可选的方案,在该方案中,可以获取宿主的多个Task,进而在宿主的配置文件中注册多个任务各自的活动界面在多个Task中所属的Task。例如,宿主的多个Task分别为Task1、Task2、Task3,则可以在宿主的配置文件中注册多个任务各自的活动界面属于Task1、Task2或者Task3,需要说明的是,此处例举仅是示意性的,并不对本发明实施例进行限制。
[0150] 此外,步骤S304中限定了不同的任务各自的活动界面属于不同的Task,从而使得不同的任务之间能够自由切换,无需退出任务。在可选的实施例中,为了保证同一任务的不同活动界面的快速、有效切换,同一个任务的活动界面属于同一个Task。
[0151] 在本发明的可选实施例中,上述在宿主的配置文件中注册多个任务各自的活动界面在多个Task中所属的Task时,可以在宿主的配置文件中注册多个任务各自的活动界面的TaskAffinity属性,由该属性指示活动界面在多个Task中所属的Task。仍然以上述例举为例,对于多个任务中的各个任务,可以在宿主的配置文件中注册各个任务的活动界面的TaskAffinity属性,由该属性指示活动界面属于Task1、Task2或者Task3。
[0152] 如上文介绍,宿主的Task是固定的,且有多个,每个Task包含多个活动界面,都预埋或配置在宿主的配置文件中。因而,上述获取宿主的多个Task时,可以读取宿主的配置文件,进而查找在宿主的配置文件中注册的宿主的多个Task。进一步地,本发明实施例还可以在宿主中为多个Task中的各个Task预设多个注册界面,以提供给活动界面使用,并且对各个Task预设的多个注册界面进行分组,其中,各组对应一个或多个注册界面。
[0153] 在本发明的可选实施例中,将不同的启动模式分配给各个注册界面的LaunchMode属性,以指示各个注册界面的启动模式,这里,不同的启动模式可以包括Standard、SingleTop、SingleTask、SingleInstance中的任意之一。以Android系统为例,下面将详细介绍这几种启动模式的区别。
[0154] (1)哪个任务存放着Activity,用来对行为进行响应。对Standard和SingleTop这两个启动模式来说,这个任务是产生行为,并且调用StartActivity()的那个。
[0155] (2)它们是否可以有多个实例。Standard和SingleTop类型的Activity可以被实例化多次。它们可以属于多个任务,一个特定的任务也可以拥有同一个Activity的多个实例。
[0156] (3)作为比较SingleTask和SingleInstance类型的Activity只限定有一个实例。因为这些Activity是任务的根。这个限制意味着,在设备上不能同时有超过一个任务的实例。
[0157] (4)是否能有其他的Activity在它所在的任务中。SingleInstance类型的Activity是它所在任务中唯一的Activity。如果它启动了其他的Activity,不管那个Activity的启动模式如何,它都会加载到一个不同的任务中。在其他的方面,SingleInstance和SingleTask启动模式是相同的。
[0158] (5)其他三种模式运行任务中有多个Activity。SingleTask总是任务中的根Activity,但是它可以启动其他的Activity并分配到它所在的任务中。Standard和SingleTop类型的Activity可以出现在任务中的任何地方。
[0159] (6)是否启动一个新的实例来处理一个新的行为。对默认的Standard启动模式来说,对于每一个行为都会创建一个新的实例来响应。每个实例只处理一个行为。对于SingleTop启动模式,如果一个已经存在的实例位于目标任务Activity栈的栈顶,那么它将被重用来处理这个行为。如果它不在栈顶,它将不会被重用,而是为行为创建一个新的实例,并压入栈中。
[0160] 例如,一个任务的Activity栈由根Activity A、B、C和D从上到下按这样的顺序组成,所以这个栈就是A-B-C-D。一个行为指向类型为D的Activity。如果D是默认的Standard启动模式,一个新的实例会被启动,栈现在就是这样A-B-C-D-D。但是,如果D的加载模式是SingleTop,已经存在的实例会用来处理这个行为(因为它在栈的顶端),并且栈中还应该是A-B-C-D。
[0161] 在前面提到,SingleTask和SingleInstance类型的Activity最多只有一个实例,所以它们的实例应该会处理每个新的行为。SingleInstance类型的Activity总是在栈的顶端(因为它是任务中唯一的一个Activity),所以总是能够适当的处理行为。然而,SingleTask类型的Activity也许会有其他的Activity在它的上面。如果是这样的话,那就不能处理这个行为,这个行为被丢弃。即使这个行为被丢弃了,它的到来也会导致那些应该保留不变任务显示到前台来。
[0162] 进一步地,在对各个Task预设的多个注册界面进行分组时,可以按照不同的启动模式对各个Task预设的多个注册界面进行分组,其中,一种启动模式对应一个组。
[0163] 如图4所示,存在LaunchMode为SingleTask的行1),为Standard的行2),以及为SingleTop的行3)。图4中的每个圆圈表示注册界面,可以看到,1)已被占用了两个注册界面,2)被占用一个注册界面,3)没有被占用。在理解时类似停车位,假如用户想停车,则应该有如下几个步骤。
[0164] 步骤1,首先要知道自己是什么车。如果是轿车,则可以停;如果是水泥罐车,也许就不行了。也即明确自己的Activity类型,不能把SingleTask的Activity停在Standard的位置上。
[0165] 步骤2,通过观察或者咨询物业管理员,以寻找适合自己的空余车位。也即从多个注册界面寻找应该使用哪个。
[0166] 步骤3,将车准确停在车位上。也即将目标注册界面分配给当前活动界面使用。
[0167] 步骤4,下次找时,直接找车位即可。毕竟相似的车很常见。也就是说,直接通过遍历所有注册界面,从中寻找符合的目标注册界面即可。
[0168] 基于上述对各个Task预设的多个注册界面的分组,即一种启动模式对应一个组,上文步骤S308中依据预设的选取策略从目标Task对应的所有注册界面中选取目标注册界面,本发明实施例提供了一种可选的方案,图5示出了根据本发明一实施例的选取目标注册界面的方法的流程图。如图5所示,该方法至少可以包括以下步骤S502至S508。
[0169] 步骤S502,确定当前活动界面的启动模式。
[0170] 步骤S504,在目标Task对应的多组注册界面中,查找当前活动界面的启动模式对应的分组。
[0171] 步骤S506,在当前活动界面的启动模式对应的分组中查找所有注册界面。
[0172] 步骤S508,在查找到的所有注册界面中确定使用状态为空余状态的注册界面,并从中选取任意注册界面作为目标注册界面。
[0173] 本发明实施例基于不同的启动模式选取目标注册界面,实现快速、有效地选取目的,保证了任务界面的正常启动。
[0174] 进一步地,在上文步骤S310中将目标注册界面分配给当前活动界面使用时,本发明实施例可以将目标注册界面的信息传递给插件的加载器,由插件的加载器根据目标注册界面的信息启动目标注册界面,供当前活动界面使用。
[0175] 下面将通过一具体实施例来详细介绍本发明的实现插件的多任务栈的方法的过程。该实施例以Android系统为例,活动界面为Activity,Task为Activity栈,宿主的配置文件为AndroidManifest.xml。
[0176] 图6示出了根据本发明一实施例的实现插件的多任务栈的方法的流程图。如图6所示,该方法至少可以包括以下步骤S602至S620。
[0177] 步骤S602,读取宿主的配置文件,查找在宿主的配置文件中注册的宿主的多个Task。
[0178] 步骤S604,在宿主中为多个Task中的各个Task预设多个注册界面。
[0179] 步骤S606,对各个Task预设的多个注册界面进行分组,其中,各组对应一个或多个注册界面。
[0180] 在该步骤中,例如可以分组为N组,每组有M个注册界面。并且,可以按照不同的启动模式对各个Task预设的多个注册界面进行分组,其中,一种启动模式对应一个组。这里,不同的启动模式可以包括Standard、SingleTop、SingleTask、SingleInstance中的任意之一,关于各种启动模式的区别请参见前文介绍,此处不再赘述。
[0181] 步骤S608,获取宿主的插件的多个任务。
[0182] 在该步骤中,插件的多个任务,其各自能够实现插件的不同功能。
[0183] 步骤S610,在宿主的配置文件中,注册多个任务各自的活动界面在宿主的多个Task中所属的Task。
[0184] 例如,宿主的多个Task分别为Task1、Task2、Task3,则可以在宿主的配置文件中注册多个任务各自的活动界面属于Task1、Task2或者Task3,需要说明的是,此处例举仅是示意性的,并不对本发明实施例进行限制。
[0185] 进一步地,可以在宿主的配置文件中注册多个任务各自的活动界面的TaskAffinity属性,由该属性指示活动界面在多个Task中所属的Task。仍然以上述例举为例,对于多个任务中的各个任务,可以在宿主的配置文件中注册各个任务的活动界面的TaskAffinity属性,由该属性指示活动界面属于Task1、Task2或者Task3。
[0186] 步骤S612,当宿主加载插件并启动多个任务中的任意任务的当前活动界面时,在配置文件中查找当前活动界面所属的目标Task。
[0187] 步骤S614,确定当前活动界面的启动模式,在目标Task对应的多组注册界面中,查找当前活动界面的启动模式对应的分组。
[0188] 步骤S616,在当前活动界面的启动模式对应的分组中查找所有注册界面。
[0189] 步骤S618,在查找到的所有注册界面中确定使用状态为空余状态的注册界面,并从中选取任意注册界面作为目标注册界面。
[0190] 步骤S620,将目标注册界面的信息传递给插件的加载器,由插件的加载器根据目标注册界面的信息启动目标注册界面,供当前活动界面使用。
[0191] 举例来说,在宿主的配置文件AndroidManifest.xml中注册插件的某个任务的Activity1属于Task1,则框架会到宿主中查找Task1的所有Activity,找到合适的Activity的时候,就将它分配给插件的Activity1使用。
[0192] 本发明实施例在宿主的配置文件中注册多个任务各自的活动界面所属的Task,并且不同的任务各自的活动界面属于不同的Task,这样使得不同的任务之间能够自由切换,无需退出任务。并且,本发明实施例在启动任意任务的当前活动界面时,能够从当前活动界面所属的目标Task对应的所有注册界面中选取目标注册界面,将目标注册界面分配给当前活动界面使用,保证了任务界面的正常启动。
[0193] 需要说明的是,实际应用中,上述所有可选实施方式可以采用结合的方式任意组合,形成本发明的可选实施例,在此不再一一赘述。
[0194] 基于上文各个实施例提供的插件的多进程管理方法,基于同一发明构思,本发明实施例还提供了一种插件的多进程管理装置。
[0195] 图7示出了根据本发明一实施例的插件的多进程管理装置的结构示意图。如图7所示,该装置至少可以包括第一注册模块710、读取模块720、建立模块730、查找模块740以及运行模块750。
[0196] 现介绍本发明实施例的插件的多进程管理装置的各组成或器件的功能以及各部分间的连接关系:
[0197] 第一注册模块710,适于在宿主的配置文件中注册多个预留进程;
[0198] 读取模块720,与第一注册模块710相耦合,适于当宿主加载插件时,读取宿主加载的插件中每个组件声明的进程;
[0199] 建立模块730,与读取模块720相耦合,适于在所述每个组件声明的进程与注册的多个预留进程之间建立对应关系;
[0200] 查找模块740,与建立模块730相耦合,适于当在插件中启动任意组件时,根据所述对应关系查找所述任意组件声明的进程对应的目标预留进程;
[0201] 运行模块750,与查找模块740相耦合,适于在所述目标预留进程中运行所述任意组件。
[0202] 在本发明一实施例中,插件中每个组件的类型包括下列至少之一:
[0203] 活动界面Activity、服务Service、内容提供者Content Provider、广播接收器Broadcast Receiver。
[0204] 在本发明一实施例中,所述第一注册模块710还适于:
[0205] 获取宿主的插件中每个组件声明的进程;
[0206] 根据所述每个组件声明的进程,在宿主的配置文件中注册相应的多个预留进程。
[0207] 在本发明一实施例中,所述第一注册模块710还适于:
[0208] 在宿主的配置文件中写入进程信息,以注册各个预留进程,其中,所述进程信息至少包括以下信息:
[0209] 进程的编号、进程的状态、进程对应的插件名、插件中不同类型的组件的使用数量。
[0210] 在本发明一实施例中,如图8所示,上文图7展示的装置还可以包括:
[0211] 标记模块810,与运行模块750相耦合,适于在所述运行模块750在所述目标预留进程中运行所述任意组件之后,将所述目标预留进程的状态标记为表示已分配的状态。
[0212] 在本发明一实施例中,上文图7展示的装置还可以包括:
[0213] 获取模块(附图中未示出),适于获取宿主的插件的多个任务,其中,所述多个任务各自能够实现插件的不同功能;
[0214] 第二注册模块(附图中未示出),与获取模块相耦合,适于在宿主的配置文件中注册所述多个任务各自的活动界面所属的Task,其中,不同的任务各自的活动界面属于不同的Task;
[0215] 目标Task查找模块(附图中未示出),与第二注册模块相耦合,适于当宿主加载插件并启动所述多个任务中的任意任务的当前活动界面时,在所述配置文件中查找所述当前活动界面所属的目标Task;
[0216] 选取模块(附图中未示出),与目标Task查找模块相耦合,适于在宿主中查找所述目标Task对应的所有注册界面,并依据预设的选取策略从所述目标Task对应的所有注册界面中选取目标注册界面;
[0217] 分配模块(附图中未示出),与选取模块相耦合,适于将所述目标注册界面分配给所述当前活动界面使用。
[0218] 在本发明一实施例中,所述Task是具有栈结构的容器,能够放置一个或多个活动界面。
[0219] 在本发明一实施例中,同一个任务的活动界面属于同一个Task。
[0220] 在本发明一实施例中,所述第二注册模块还适于:
[0221] 获取宿主的多个Task;
[0222] 在宿主的配置文件中注册所述多个任务各自的活动界面的TaskAffinity属性,由该属性指示活动界面在所述多个Task中所属的Task。
[0223] 在本发明一实施例中,所述第二注册模块还适于:
[0224] 读取宿主的配置文件;
[0225] 查找在宿主的配置文件中注册的宿主的多个Task。
[0226] 在本发明一实施例中,上文图7展示的装置还可以包括:
[0227] 配置模块(附图中未示出),适于在宿主中为所述多个Task中的各个Task预设多个注册界面;对各个Task预设的多个注册界面进行分组,其中,各组对应一个或多个注册界面。
[0228] 在本发明一实施例中,所述配置模块还适于:
[0229] 按照不同的启动模式对各个Task预设的多个注册界面进行分组,其中,一种启动模式对应一个组,所述不同的启动模式包括下列任意之一:
[0230] Standard、SingleTop、SingleTask、SingleInstance。
[0231] 在本发明一实施例中,所述选取模块还适于:
[0232] 确定所述当前活动界面的启动模式;
[0233] 在所述目标Task对应的多组注册界面中,查找所述当前活动界面的启动模式对应的分组;
[0234] 在所述当前活动界面的启动模式对应的分组中查找所有注册界面;
[0235] 在查找到的所有注册界面中确定使用状态为空余状态的注册界面,并从中选取任意注册界面作为目标注册界面。
[0236] 在本发明一实施例中,所述分配模块还适于:
[0237] 将所述目标注册界面的信息传递给插件的加载器,由插件的加载器根据所述目标注册界面的信息启动目标注册界面供所述当前活动界面使用。
[0238] 根据上述任意一个可选实施例或多个可选实施例的组合,本发明实施例能够达到如下有益效果:
[0239] 在本发明实施例中,在宿主的配置文件中注册多个预留进程,当宿主加载插件时,读取宿主加载的插件中每个组件声明的进程;随后,在每个组件声明的进程与注册的多个预留进程之间建立对应关系;之后,当在插件中启动任意组件时,根据对应关系查找任意组件声明的进程对应的目标预留进程;在目标预留进程中运行任意组件。可以看到,本发明实施例在每个组件声明的进程与注册的多个预留进程之间建立对应关系,从而,当在插件中启动任意组件时,根据对应关系查找任意组件声明的进程对应的目标预留进程,进而在目标预留进程中运行任意组件,解决了现有技术中插件的组件只能运行在同一个进程的问题,实现了插件的多进程运行的目的。
[0240] 进一步地,本发明实施例在宿主的配置文件中注册多个任务各自的活动界面所属的Task,并且不同的任务各自的活动界面属于不同的Task,这样使得不同的任务之间能够自由切换,无需退出任务。并且,本发明实施例在启动任意任务的当前活动界面时,能够从当前活动界面所属的目标Task对应的所有注册界面中选取目标注册界面,将目标注册界面分配给当前活动界面使用,保证了任务界面的正常启动。
[0241] 在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
[0242] 类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
[0243] 本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
[0244] 此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
[0245] 本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的一种插件的多进程管理装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
[0246] 应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
[0247] 至此,本领域技术人员应认识到,虽然本文已详尽示出和描述了本发明的多个示例性实施例,但是,在不脱离本发明精神和范围的情况下,仍可根据本发明公开的内容直接确定或推导出符合本发明原理的许多其他变型或修改。因此,本发明的范围应被理解和认定为覆盖了所有这些其他变型或修改。