服务执行的控制方法及装置与流程

本申请涉及终端设备的应用领域，尤其涉及一种服务执行的控制方法及装置。

背景技术

随着终端设备的不断发展，终端设备上的应用功能也越来越丰富，已成为了人们日常生活中不可或缺的部分。

使用过程中，终端设备上的应用会根据自身产品的定位，向用户提供相关的服务，例如天气预报、新闻推送、内存管理等。

目前，很多应用提供的服务具有重合度，对于用户来讲，一种服务只需要由一个应用执行即可满足大部分场景下的使用需求。若多个应用重复性执行一个服务，不仅会浪费终端设备的资源，还可能对用户的日常生活造成干扰，从而影响使用体验。

技术实现要素：

本申请实施例的目的是提供一种服务执行的控制方法及装置，能够避免同一服务在终端设备上被重复执行。

为达到上述目的，本申请实施例是这样实现的：

第一方面，本申请实施例提供了一种服务执行的控制方法，包括：

基于所述至少两个应用的配置状态和优先级的至少一种，从所述至少两个应用中，确定出需要激活目标服务的目标应用；

监控所述目标服务是否触发；

在所述目标服务触发时，控制所述目标应用执行所述目标服务。

第二方面，本申请实施例提供了一种服务执行的控制装置，包括：

获取模块，用于获取具备指定功能共同管理的至少两个应用；

确定模块，用于基于所述至少两个应用的配置状态和优先级的至少一种，从所述至少两个应用中，确定出需要激活目标服务的目标应用；

监控模块，用于监控所述目标服务是否触发；

控制模块，用于在所述目标服务触发时，控制所述目标应用执行所述目标服务。

第三方面，本申请实施例提供了一种终端设备，包括：存储器、处理器和存储在所述存储器上并可在所述处理器上运行的计算机可执行指令，所述计算机可执行指令被所述处理器执行时实现如上述第一方面所述的服务执行的控制方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机可执行指令，所述计算机可执行指令被处理器执行时实现如上述第一方面所述的服务执行的控制方法的步骤。

本申请实施例在能够提供目标服务的多个应用中，有目的性地选取更为合适的应用负责执行目标服务，从而降低目标服务被重复执行的概率。一方面，避免了同一服务被重复执行造成的资源浪费；另一方面，还能避免同一服务被重复执行对用户造成干扰。可见，本申请够提高了终端设备的使用体验，因此具有很高的实用价值。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的服务执行的控制方法的流程示意图；

图2为本申请实施例提供的服务执行的控制方法在处理器中运行的功能示意图；

图3为本申请实施例提供的服务执行的控制装置的逻辑结构示意图；

图4为本申请实施例提供的终端的实际结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

目前，绝大部分用户会在终端设备上安装不止一个的能够提供相同服务的应用，比如，在终端设备上安装多个闻新应用都能提供新闻推送服务。而对于用户来讲，一般情况下，针对一种服务仅需要一种应用执行即可，若多个应用重复性提供一种服务，不仅会浪费终端设备资源，还可能会对用户的日常生活产生干扰。

因此，针对现有的终端应用重复性提供服务的问题，本申请提供一种解决方案。

一方面，本申请的实施例提供一种应用于终端设备的服务执行的控制方法，如图1所示，包括：

步骤s102，获取具备指定功能共同管理的至少两个应用；

针对步骤s102需要说明的是：

上述指定功能是指共存管理功能，支持共存管理功能的多个应用可以被统一管理。

作为示例性介绍：

以避免干扰用户的角度出发，指定功能可以是通知功能共同管理，即，需要向用户发送通知(如消息通知、声音通知、震动通知等)的应用都可以归属由通知共存功能共同管理。这类应用在发送通知时可以被用户感知到，应尽量避免发送重复性通知而影响用户的日常生活。

以避免浪费终端设备资源的角度出发，指定功能可以是网络共存管理功能，即需要占用终端设备的带宽资源的应用都可以由网络共存管理功能共同管理。由于终端设备的带宽资源是有限的，应尽量避免带宽资源被无意义地占用。此外指定功能可以是后台处理资源共存管理功能，需要占用终端设备后台处理资源的应用都可以由后台处理资源共存管理功能共同管理。

综上所述，本申请实施例的共存管理功能的实现方式并不唯一，可以根据实际需求灵活配置，因此本文不再进行举例赘述。

步骤s104，基于至少两个应用的配置状态和优先级的至少一种，从至少两个应用中，确定出需要激活目标服务的目标应用；

针对步骤s104需要说明的是：

上述目标服务可以是天气预报服务、内存预警服务等，这类服务会向用户发送通知提醒，因此由通知共存管理功能共同管理；目标服务也可以定位服务、网络通讯服务等，这类服务在运行时会占用网络资源，因此由网络共存管理功能共同管理；或者，目标服务也可以是杀毒服务、内存监控服务，这类服务会在后台运行，占用终端设备上的后台处理资源。

此外，上述配置状态是指应用针对目标服务的开关状态，应用只有在开关状态开启时才能够激活目标服务。其中，开关状态可以由用户进行手动控制，从而实现优先用户选择的效果。例如，被用户手动关闭配置状态的应用无法作为执行目标服务的目标应用。

此外，上述优先级可以是针对执行目标服务的优先级，作为示例性介绍，假设终端设备上安装了a、b两个杀毒应用。其中，a是试用版本，b是付费版本，一般情况，b提供的杀毒服务的质量会高于a，因此b针对杀毒服务的优先级则会高于a。在实际应用中，优先级可以根据实际需求灵活设置，一般情况下，可由应用执行目标服务的效益决定。

显然，当终端安装有多个能够提供目标服务的应用时，基于配置状态和/或优先级，可以确定出更适合执行目标服务的应用。

步骤s106，监控目标服务是否触发；

针对步骤13需要说明的是：

监控目标服务是否触发可以基于目标应用来执行。例如当某一应用激活目标服务时，则可以根据自身策略决定目标服务的触发机制。

以目标服务为内存清理服务为例，当目标应用确定终端设备剩余的内存低于一定标准时，则触发内存清理服务；以天气预报服务为例，当目标应用向服务器获取新的天气数据，则触发天气预报服务；以杀毒服务为例，目标应用检测到终端设备出现与中毒相匹配的异常现象时，则触发杀毒服务。

步骤s108，在目标服务触发时，控制目标应用执行目标服务。

针对步骤s108需要说明的是：

在所有能够提供目标服务的应用中，只有目标应用负责执行目标服务，其余应用处于停用状态，从而保证目标服务不会被重复执行。

综上所述，本申请实施例在能够提供目标服务的多个应用中，有目的性地选取更为合适的应用负责执行目标服务，从而降低目标服务被重复执行的概率。一方面，避免了同一服务被重复执行造成的资源浪费；另一方面，还能避免同一服务被重复执行对用户造成干扰。可见，本申请够提高了终端设备的使用体验，因此具有很高的实用价值。

下面对本申请实施例的控制方法进行详细介绍。

本申请实施例的控制方法在执行上述步骤s102时，具体包括以下步骤：

步骤s1021，获取一应用列表，该应用列表包括终端设备上所有具备指定功能共同管理的应用；

步骤s1022，基于应用列表中的所有应用的公告信息，从应用列表中确定出够执行目标服务的至少两个应用。

作为步骤s1021和步骤s1022的示例性介绍：

上述应用列表可以预先设置，包含所有能够具备指定功能共同管理的应用。每个应用都会有公告信息，用于指示其自身所能提供的服务。因此，本申请实施例根据应用的公告信息，对应用列表中的应用进行匹配查询，找到能够执行目标服务所有应用，匹配查询出的应用来自于应用列别，因此符合具备指定功能共同管理且能够执行目标服务的要求。

在上述基础之上，本申请实施例还可以在步骤1022后，进一步执行：

步骤1023，建立一个上述指定功能共同管理的集合，包含所有能够执行目标服务且具备指定功能共同管理的所有应用。

若后续需要再次确定够执行目标服务且具备指定功能共同管理的所有应用时，可更为便捷地直接从该集合中进行查找，从而省去在应用列表中进行匹配查询的步骤。

在查找到指定功能共同管理的应用后，即可执行上述步骤104，以确定需要激活目标服务的目标应用。

具体地，上述步骤104可以包括：

步骤1041，基于上述至少两个应用的配置状态，在该至少两个应用中确定出针对指定功能的开关状态为开启的应用，并基于优先级，从确定出的应用中选取需要激活目标服务的目标应用。

作为步骤s1041的示例性介绍。

假设终端设备上安装有app1、app2、app3三个能够提供目标服务的应用。

其中，app1针对目标服务的优先级为10，app1针对目标服务的优先级为8，app3针对目标服务的优先级为4。

如果优先级取值越大，优先级越高，则根据上述内容来看，app1执行目标服务最具有效益。但用户因个人因素，不习惯使用app1执行目标服务，可将app1针对目标服务的开关状态手动设置为关闭，及用户关闭了app1的配置状态。

此时，在确定目标应用时，只在app2和app3两者中确定目标应用。如果同时能够执行所述目标服务的应用的个数为1，则优先级更高的app2作为目标应用，app3和app1针对目标服务处于停用状态。

当然，需要说明的是，上述同时能够执行所述目标服务的应用的个数并限于是1，可以根据实际需求进行灵活设置。即，本申请实施例在步骤s104之前，还可以包括：

步骤s103，配置同时能够执行目标服务的应用的个数。

其中，为了避免目标服务被过多次重复执行，同时能够执行目标服务的应用的个数应小于具备指定功能共同管理且能够提供目标服务的应用的总个数。

作为示例性介绍，假设巨白指定功能共同管理且能够提供目标服务的应用的总个数为5，则表示终端设备上有5个应用能够提供目标服务。

因此当配置同时能够执行目标服务的应用的个数不大于4时，都可以降低目标服务被重复执行的次数。

同理，当用户期望终端设备当前仅有一个应用执行目标服务，则在步骤s103中，将同时能够执行目标服务的应用的个数设置为1。

此外，需要说明的，作为其他可行方案，本申请的实施例可以只根据配置状态，确定目标应用；例如，步骤s104执行时，选取配置状态开启的应用作为目标应用。或者，申请的实施例也可以只根据优先级，确定目标应用；例如，步骤s104执行时，选取优先级最高的应用作为目标应用。

而同时基于配置状态和优先级确定目标应用，仅是本申请实施例的一种优选的实现方式，可以在满足用户使用习惯的前提下，选取最具有效益的应用来执行目标服务。

当然，上述步骤s104仅是确定当前时刻适用于执行目标服务的目标应用。在后续使用过程中，可能会因为一些突发因素导致目标应用不再具有时效性，此时需要重新确定目标应用。

例如：

当应用列表发生变化时，则表明终端设备进行了安装应用、卸载应用和更新应用中的任意一种。若安装了优先级更高的应用，或者卸载了当前优先级最高的应用，再或者是更新后出现新的优先级最高的应用，都会对目标应用造成改变，需要重新确定。

当执行目标服务的目标应用的配置状态发生变化时，表明用户手动关闭了目标应用针对目标服务的开关，此时也需要确定新的目标应用代替原有的目标应用来执行目标服务。

当终端设备的屏幕被激活时，由于后台程序不能长久保持的原因，可能已经关闭目标应用的进程，此场景下也需要确定新的目标应用，以保证目标服务被顺利执行。

因此，为避免上述情况发生导致目标应用失去时效，本申请实施例每当在发生预设事件时，重新执行上述步骤s102和步骤s104，以对目标应用进行动态更新。其中，预设事件即上述的应用列表发生变化、当前执行目标服务的目标应用的配置状态发生变化、终端设备的屏幕被激活中的至少一者。

通过上述重新确定目标应用的机制，本申请实施例的控制方法可以保证目标服务从始至终都能被更有效益的应用执行。

在实际应用中，本实施例的控制方法的执行主体可以是终端设备上的处理器、单片机、微处理器等硬件。

以处理器为例，本实施例的控制方法由处理器来控制执行目标服务的目标应用。参考图2所示，理器执行的控制方法的主要包括以下流程：

处理器在终端设备运行时，对终端设备的应用列表进行检测，建立共存管理功能，以共同管理app1、app2、app3三个应用。

处理器判断共存管理功能管理的app1、app2、app3的配置状态是否开启以及优先级是否最高。

是，则激活为执行目标服务的目标应用；否，则暂停目标服务。

此外，本实施例的控制方法的执行主体也可以是终端设备上的一个应用，由该应用主动与其他应用通过交互方式，决定由谁作为执行目标服务的目标应用。

作为示例性介绍：

假设终端设备安装有能够提供目标服务的第一应用和至少一个第二应用，第一应用和至少一个第二应用均具备指定功能共同管理。

其中，第一应用执行本实施例的控制方法，主要包括以下流程：

第一应用确定终端设备上具备指定功能共同管理且能够提供目标服务的第二应用(具体确定方法在上文中已经介绍)。

第一应用向该至少一个第二应用发送跨进程通信请求；

若该至少一个第二应用根据送跨进程通信请求，建立与第一应用的跨进程通信，则第一应用基于跨进程通信向至少一个第二应用获取该至少一个第二应用的配置状态以及优先级。

第一应用在接收到该至少一个第二应用的配置状态以及优先级后，从该至少一个第二应用中确定出一个优先级最高的第二应用。

当确定出的第二应用针对目标服务的通知优先级低于第一应用，则第一应用自身直接激活目标服务，以作为目标应用，且同时如果第二应用当前已经作为目标应用，则向该第二应用发送一去激活命令，使第二应用去激活目标服务以不再作为目标应用。

若后续用户手动关闭第一应用的配置状态，则第一应用在该至少一个第二应用中确定一针对目标服务通知优先级最高且配置状态为开启的第二应用，并向该第二应用发送激活命令，使其激活目标服务成为代替自己的目标应用。

同理，第一应用也可以接受来自第二应用的跨进程通信请求，以向第二应用提供其自身的配置状态和优先级，并接受第二应用发送的激活命令和去激活命令。

为避免第二应用以不正当竞争方式，通过去激活命令，故意使第一应用无法执行目标服务，第一应用与第二应用建立跨进程通信前，可以对第二应用进行安全验证，只有验证通过，才会与第二应用建立跨进程通信，接受第二应用发送的激活命令和去激活命令。

下面结合不同的实现方式，对本申请实施例的控制方法在应用侧执行的流程进行示例性介绍。

实现方式一

在实现方式一中，终端设备为手机，执行主体为手机上的应用，指定功能为通知功能共同管理，目标服务为新闻推送服务。

假设某一用户给自己的手机下载了提供新闻推送服务的应用：app1和app2。使用了一段时间后，当发生热点新闻时，用户会同时收到了app1和app2发送的新闻通知提醒。

对于此用户而言，这两条通知是相同的信息，重复发送会造成干扰。本实现方式一所示的控制方法旨在避免这种重复目的的通知发生，保证用户有效接收通知提醒前的提下，不影响使用体验。

其中，本实现方式一的流程主要包括：

对app1、app2和app3进行通知功能共同管理配置，并合理分配优先级。比如app1分配优先级为10，app2分配优先级为11(优先级取值越大，优先级越高)。

用户间隔一定时间分别安装了app1和app2两款应用(通知提醒功能默认开启)。考虑到用户的体验，当出现热点新闻的时候，应该是app2向用户发送推送通知。

若用户先安装app1，则app1在进程启动时，执行通知共存管理的初始化逻辑，app1根据“org.superclean.notification”action值(即上文所述公告信息的键值)，从应用列表中查询当前手机是否有匹配的能够提供新闻推送服务的应用。当app1检索发现只有自己一款应用时，激活自身新闻推送服务，在热点新闻发生时，向用户发送推送通知。

当用户紧跟着安装了app2后，app2进程启动时执行通知共存管理功能的初始化逻辑，然后根据“org.superclean.notification”action值查询当前设备是否有匹配的能够提供新闻推送服务的应用，检索发现app1和app2都有相似的新闻推送服务，app2通过跨进程接口主动向app1请求查询配置状态以及优先级。

app1在收到app2的跨进程请求时，根据app2产品包名，获取app2的签名信息，并根据签名信息在签名白名单进行匹配查询。若app2记录在白名单中，app1与app2建立跨进程通信，向app2反馈自身通知提醒模块的状态为开启，优先级为10。

app2获得数据后，通过本地决策发现需要自己来执行新闻推送服务，则通过跨进程接口向app1发送去激活命令，以使app1处于待命状态，暂时不能发送新闻推送通知。当出现热点新闻时，app2向用户发出新闻推送。

如果用户只喜欢从app2中浏览新闻内容，对其新闻推送服务不是很认可，则可以手动关闭app2的配置状态。

app2发现自身的配置状态已被关闭，需要交出新闻推送服务的优先执行权时，根据“org.superclean.notification”action值查询应用列表，确定当前设备是否有匹配的能够提供新闻推送服务的应用。当查询发现app1有相似的新闻推送服务时，app2通过跨进程接口主动向app1请求查询配置状态和优先级。

app1根据已有访问的app2产品包名，获取app2的签名信息，并在签名白名单中匹配查询，以验证app2的身份合法性，如果白名单中记录有app2，则与app2建立跨进程通信，通过跨进程通信向app2反馈自身配置状态为开启以及优先级为10。

app2在接收到后，确定app1具有执行新闻推送服务的优先权。此时app2本地去激活新闻推送服务，并通过跨进程接口向app1发送激活命令。

app1在接收到激活命令时，激活自身的新闻推送服务，开始向用户发送新闻推送通知。

实现方式二

在实现方式二中，终端设备为pad(平板电脑)，执行主体为pad上的应用，指定功能为网络功能共同管理，目标服务为天气预报服务。

假设某一用户给自己的手机安装三款能够提供天气预报服务的应用：app1、app2和app3。在使用过程中，app1、app2和app3进程开启时会占用带宽资源，以向服务请求天气数据。

对于用户而言，这三个应用具有相同作用，都是提供天气信息。本实现方式二所示的控制方法旨在控制其中一个应用提供天气信息，从而避免带宽资源被无意义的重复占用。

其中，本实现方式二的流程主要包括：

对app1、app2和app3进行网络功能共同管理配置，app1分配优先级为10，app2分配优先级为11，app3分配优先级为12(优先级取值越大，优先级越高)。

考虑到用户的体验，应该是app3优先工作，能够使用带宽资源想服务器获取天气数据。

若用户先安装app1，则app1进程启动时执行网络功能共同管理的初始化逻辑，app1根据“org.superclean.notification”action值(即上文所述公告信息的键值)，从应用列表中查询当前手机是否有匹配的能够提供天气预报服务的应用。

app1检索发现只有自己一款应用，则激活自身天气预报服务，使用pad上的带宽资源向服务器请求天气数据。

当用户紧跟着安装了app2和app3时，app2和app3在进程启动后，执行网络功能共同管理的初始化逻辑，然后根据“org.superclean.notification”action值查询当前设备是否有匹配的能够提供天气预报服务的应用。

以app2为例，当app2检索发现app1和app3都具有相似的天气预报服务时，通过跨进程接口主动向app1和app3请求查询配置状态和优先级。app1和app3在收到app2的跨进程请求时，分别根据app2的产品包名，获取app2的签名信息，并在签名白名单中进行匹配查询(白名单可以保存在云端或者pad本地)。当在从白名单中找到app2后，app1和app3与app2建立跨进程通信，向app2反馈自身的配置状态以及优先级。app2获得数据后，发现app3优先执行天气预报服务，则本地去激活天气预报服务，以处于待命状态。

以app3为例，app3当检索发现app1和app2都有相似的天气预报服务，通过跨进程接口主动向app1和app2请求查询配置状态和优先级。app1和app2在收到app3的跨进程请求时，根据app3产品包名，获取app3的签名信息，并在签名白名单中进行匹配查询(白名单可以保存在云端或者pad本地)，在从白名单中找到app3后，app1和在app2与app3建立跨进程通信，向app3反馈自身的配置状态以及优先级。app3获得数据后，发现自身就有执行天气预报服务的优先权，则本地激活天气预报服务，并向先前安装的app1发送去激活命令，使app1处于待命状态，从而停止占用带宽资源向服务器请求天气数据。

如果用户只喜欢app2的天气预报服务，对app3不是很认可，则可以手动关闭app3的配置状态。

app3若发现自身的配置状态已被关闭，则需要交出天气预报服务的优先执行权。具体地，app3根据“org.superclean.notification”action值查询应用列表，确定手机是否有匹配的其能够提供天气预报服务的应用。

当查询发现app1和app2有相似的天气预报服务时，app3通过跨进程接口主动向app1和app2查询配置状态和优先级。

app1和app2在接收到app3的跨进程请求后，根据已有访问的app3产品包名，获取app3的签名信息，并在签名白名单中进行匹配查询，以验证app3的身份合法性。如果白名单中记录有app3，则app1和app2与app3建立跨进程通信，向app3反馈自身配置状态以及优先级。

app3在接收到后，确定app2具有执行天气预报服务的优先权，此时app3本地去激活天气预报服务，并通过跨进程接口向app2发送激活命令，使app2执行天气预报服务。

app2在接收到激活命令时，开始占用带宽资源，向其服务器请求天气数据，以保证其应用中天气信息的时效性。

实现方式三

在实现方式三中，终端设备为手机，执行主体为手机上的应用，指定功能为后台资源功能共同管理，目标服务为内存预警服务。

假设某一用户给自己的手机在不同时刻下载了提供内存预警服务的应用：app1和app2。使用了一段时间后，app1和app2同时占用后台资源，监控手机上的内存。当内存占用比较大时，就会收到app1发送的内存加速通知“您的手机内存使用已超过xx％，快快加速吧”，以及app2发送的内存加速通知“您的手机内存只剩余xxm，快快加速吧”。

对于用户而言，app1和app2是同样的目标，都是监控手机内存状态，提醒用户执行加速，让手机释放更多的内存。本实现方式三所示的控制方法旨在避免这种重复目的的后台资源占用，从而用户的使用体验。

其中，本实现方式三的流程主要包括：

对app1、app2和app3进行后台资源功能共同管理配置，并合理分配优先级。比如app1分配优先级为10，app2分配优先级为11(优先级取值越大，优先级越高)。

用户间隔一定时间分别安装了app1和app2两款应用(通知提醒功能默认开启)。考虑到用户的体验，当内存占用比较大的时候，应该是app2优先工作，负责占用后台资源监控手机的内存。

当用户安装app1后，执行后台资源功能共同管理的初始化逻辑，app1根据“org.superclean.notification”action值，从应用列表中查询当前手机是否有匹配的能够执行内存预警服务的应用。

app1检索发现只有自己一款应用，激活自身内存预警服务，在后台监控内存变化，在内存占用过高，提醒用户“您的手机内存使用已超过xx％，快快加速吧”。

当用户紧跟着安装了app2时，app2在进程启动后，执行后台资源功能共同管理的初始化逻辑，然后根据“org.superclean.notification”action值查询当前设备是否有匹配的能够执行内存预警服务的应用，检索发现app1和app2都有相似的内存预警服务，app2通过跨进程接口主动向app1和app2请求查询配置状态和优先级。

app1在收到app2的跨进程请求时，根据app2的产品包名，获取app2的签名信息，并在签名白名单中进行匹配查询。当在白名单中找到app2时，app1建立与app2的跨进程通信，并通过跨进程通信向app2反馈自身配置状态为开启，优先级为10。

app2获得数据后，本地决策发现自身具有更高的执行优先级，此时app2本地去激活新闻推送服务，并则通过跨进程接口向app1发送去激活命令，使app1暂时不占用后台资源对内存进行监控。

当内存占用过高时，app2向用户发出“您的手机内存只剩余xxm，快快加速吧”。

如果用户只喜欢app2中的杀毒服务，对内存预警服务不是很认可则可以手动关闭app2的配置状态。

当app2发现自身的配置状态已被关闭时，需要交出内存预警服务的优先执行权。具体地，app2根据“org.superclean.notification”action值查询应用列表，确定当前设备是否有匹配的能够执行内存预警服务的应用。当查询发现app1有相似的内存预警服务时，app2通过跨进程接口主动向app1请求查询配置状态和优先级。

app1根据已有访问的app2产品包名，获取app2的签名信息，并在签名白名单中进行匹配查询，以验证app2的身份合法性。如果白名单中记录有app2，则与app2建立跨进程通信，通过跨进程通信向app2反馈自身配置状态为开启，优先级为10。

app2在接收到后，确定app1具有执行内存预警服务的优先权，此时app2自身去激活内存预警服务，并通过跨进程接口向app1发送激活命令。

app1在接收到激活命令时，开始执行内存预警服务，占用后台资源监控内存变化。当手机内存占用过高时，app1向用户发出“您的手机内存使用已超过xx％，快快加速吧”的通知提醒。

以上是对本申请实施例的服务执行的控制方法的介绍。与之对应地，本申请实施例还提供一种服务执行的控制装置，如图3所示，包括：

获取模块31，用于获取具备指定功能共同管理的至少两个应用；

确定模块32，用于基于所述至少两个应用的配置状态和优先级的至少一种，从所述至少两个应用中，确定出需要激活目标服务的目标应用；

监控模块33，用于监控所述目标服务是否触发；

控制模块34，用于在所述目标服务触发时，控制所述目标应用执行所述目标服务。

本申请实施例的控制装置能够在提供目标服务的多个应用中，选取更为合适的应用负责执行，可降低目标服务被重复执行的概率。一方面，避免了同一服务被重复执行造成的资源浪费；另一方面，还能避免同一服务被重复执行对用户造成干扰。

显然，本申请实施例提供的服务执行的控制装置是本申请实施例上文提供的控制方法执行主体，因此该控制方法执所能实现的技术效果，本本申请实施例提供的控制装置同样能够实现。

下面对本申请实施例的控制装置进行详细介绍。

本实施例的获取模块31具体用于：获取一应用列表，所述应用列表包括所述终端设备上所有具备指定功能共同管理的应用；基于应用列表中的所有应用的公告信息，从所述应用列表中确定出够执行所述目标服务的至少两个应用。

其中，上述应用列表可以预先设置，包含所有能够具备指定功能共同管理的应用。每个应用都会有公告信息，用于指示其自身所能提供的服务。因此，本申请实施例根据应用的公告信息，对应用列表中的应用进行匹配查询，找到能够执行目标服务所有应用。

在上述基础之上，本申请实施例的获取模块31还可以建立一个上述指定功能的集合，包含所有能够执行目标服务且具备指定功能共同管理的所有应用。若后续需要再次确定够执行目标服务且具备指定功能共同管理的所有应用时，可更为便捷地直接从该指定功能的集合中进行查找，从而省去在应用列表中进行匹配查询的步骤。

在获取模块31查找到指定功能共同管理的应用后，确定模块32即可确定需要激活目标服务的目标应用。

具体地，配置状态为其对应的应用针对所述目标服务的开关状态。确定模块32进一步用于：基于所述至少两个应用的配置状态，在所述至少两个应用中确定出针对所述指定功能的开关状态为开启的应用，并基于优先级，从确定出的应用中选取需要激活目标服务的目标应用。

此外，在上述基础之上，本申请本实施例的确定模块32还用于：

在确定出目标应用前，配置同时能够执行所述目标服务的应用的个数。

其中，为了避免目标服务被过多次重复执行，同时能够执行目标服务的应用的个数应小于具备指定功能共同管理且能够提供目标服务的应用的总个数。

当然，确定模块32仅是确定当前时刻适用于执行目标服务的目标应用。在后续使用过程中，会因为一些突发因此，而导致目标应用不再具有时效性。此时，需要重新再次确定目标应用。

因此在上述基础之上，当发生预设事件时，获取模块31重新执行获取具备指定功能共同管理的至少两个应用，以使确定模块32确定新的目标应用执行所述目标服务；

其中，预设事件包括以下至少一者：

所述应用列表发生变化、当前执行所述目标服务的目标应用的配置状态发生变化、所述终端设备的屏幕被激活。

当应用列表发生变化时，则表明终端设备对应用进行安装、卸载和更新中的任意一种。比如安装了优先级更高的应用、卸载了当前优先级最高的应用，更新后出现新的优先级最高的应用，都会对目标应用造成影响，需要重新确定。

当执行目标服务的目标应用的配置状态发生变化时，表明用户手动关闭了目标应用针对目标服务的开关，此时也需要确定新的目标应用

当终端设备的屏幕被激活时，由于自身后台程序不能长久保持的原因，可能已经关闭目标应用的进程，此场景下也需要确定新的目标应用，以保证能够执行目标服务。

由此可见，本申请实施例的控制装置能够实时动态地选择合适的目标应用，以保证目标服务从始至终都能被更有效益执行。

在实际应用中，本申请实施例的控制装置包括但不限于：手机、pad、pc、可穿戴设备等智能终端等，或者本申请实施例的控制装置还可以是装配在这些智能终端中具有控制功能的硬件。

此外，本申请实施例还提供了一种终端设备，图4为本申请实施例提供的终端设备的结构示意图。

如图4所示，终端设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器401和存储器402，存储器402中可以存储有一个或一个以上存储应用程序或数据。其中，存储器402可以是短暂存储或持久存储。存储在存储器402的应用程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对终端设备中的一系列计算机可执行指令。

更进一步地，处理器401可以设置为与存储器402通信，在终端设备上执行存储器402中的一系列计算机可执行指令。

终端设备还可以包括一个或一个以上电源403，一个或一个以上有线或无线网络接口404，一个或一个以上输入输出接口405，一个或一个以上键盘406等。

在一个具体的实施例中，终端设备包括存储器、处理器和存储在所述存储器上并可在所述处理器上运行的计算机可执行指令，所述计算机可执行指令被所述处理器执行时实现以下流程：

获取具备指定功能共同管理的至少两个应用；

基于所述至少两个应用的配置状态和优先级的至少一种，从所述至少两个应用中，确定出需要激活目标服务的目标应用；

监控所述目标服务是否触发；

在所述目标服务触发时，控制所述目标应用执行所述目标服务。

可选地，所述计算机可执行指令被所述处理器执行获取具备指定功能共同管理的至少两个应用的步骤，包括：

获取一应用列表，所述应用列表包括所述终端设备上所有具备指定功能共同管理的应用；

基于应用列表中的所有应用的公告信息，从所述应用列表中确定出够执行所述目标服务的至少两个应用。

其中，所述配置状态为其对应的应用针对所述目标服务的开关状态。

所述计算机可执行指令被所述处理器执行基于所述至少两个应用的配置状态和优先级，确定出需要激活目标服务的目标应用的步骤，包括：

基于所述至少两个应用的配置状态，在所述至少两个应用中确定出针对所述指定功能的开关状态为开启的应用，并基于优先级，从确定出的应用中选取需要激活目标服务的目标应用。

可选地，在发生预设事件时，所述计算机可执行指令被所述处理器重新执行获取具备指定功能共同管理的至少两个应用的步骤，以确定新的目标应用执行所述目标服务；

所述预设事件包括以下至少一者：

所述应用列表发生变化、当前执行所述目标服务的目标应用的配置状态发生变化、所述终端设备的屏幕被激活。

可选地，所述计算机可执行指令被所述处理器执行确定出所述目标应用前，还包括：

配置同时能够执行所述目标服务的应用的个数。

其中，同时能够执行所述目标服务的应用的个数小于具备指定功能共同管理且能够提供所述目标服务的应用的总个数。

进一步地，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机可执行指令，所述计算机可执行指令被处理器执行时实现以下流程：

获取具备指定功能共同管理的至少两个应用；

基于所述至少两个应用的配置状态和优先级的至少一种，从所述至少两个应用中，确定出需要激活目标服务的目标应用；

监控所述目标服务是否触发；

在所述目标服务触发时，控制所述目标应用执行所述目标服务。

可选地，所述计算机可执行指令被处理器执行获取具备指定功能共同管理的至少两个应用的步骤，包括：

获取一应用列表，所述应用列表包括所述终端设备上所有具备指定功能共同管理的应用；

基于应用列表中的所有应用的公告信息，从所述应用列表中确定出够执行所述目标服务的至少两个应用。

其中，所述配置状态为其对应的应用针对所述目标服务的开关状态。

可选地，所述计算机可执行指令被处理器执行基于所述至少两个应用的配置状态和优先级，确定出需要激活目标服务的目标应用的步骤，包括：

基于所述至少两个应用的配置状态，在所述至少两个应用中确定出针对所述指定功能的开关状态为开启的应用，并基于优先级，从确定出的应用中选取需要激活目标服务的目标应用。

可选地，在发生预设事件时，所述计算机可执行指令被处理器重新执行获取具备指定功能共同管理的至少两个应用的步骤，以确定新的目标应用执行所述目标服务；

其中，所述预设事件包括以下至少一者：

所述应用列表发生变化、当前执行所述目标服务的目标应用的配置状态发生变化、所述终端设备的屏幕被激活。

可选地，所述计算机可执行指令被处理器执行确定出所述目标应用前的步骤前，还包括：

配置同时能够执行所述目标服务的应用的个数。

其中，同时能够执行所述目标服务的应用的个数小于具备指定功能共同管理且能够提供所述目标服务的应用的总个数。

其中，所述指定功能共同管理为通知功能共同管理。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。