一种应用互相唤醒的方法及系统与流程

本申请涉及应用唤醒技术领域，尤其涉及一种应用互相唤醒的方法及系统。

背景技术：

现有技术中，移动终端一般通过一个应用去唤醒其他应用，再通过被唤醒的应用继续去唤醒其他应用，来保持移动终端中后台运行的应用的活性。但是，现有技术中，应用互相唤醒一般是基于移动终端出厂时既定的策略，策略一旦设定无法更改，应用互相唤醒的灵活性较差。

技术实现要素：

为至少在一定程度上克服相关技术中存在的问题，本申请提供一种应用互相唤醒的方法及系统。

本申请的方案如下：

根据本申请实施例的第一方面，提供一种应用互相唤醒的方法，包括：

接收移动终端发送的策略配置请求；所述策略配置请求是所述移动终端在预设应用启动时发送的；所述策略配置请求中包含有所述移动终端当前启动的所述预设应用的标记信息；

根据所述策略配置请求中的所述标记信息，在策略数据库中获取所述预设应用对应的策略配置信息，并打包发送到所述移动终端；所述策略配置信息至少包括：待唤醒应用列表、唤醒方式和唤醒时间间隔；所述策略配置信息用于使所述移动终端当前启动的所述预设应用对所述待唤醒应用列表中的应用按照所述唤醒方式和唤醒时间间隔依次进行唤醒。

优选的，在本申请一种可实现的方式中，还包括：

对所述移动终端中的预设应用集成统一策略sdk(softwaredevelopmentkit，软件开发工具包)。

优选的，在本申请一种可实现的方式中，所述接收移动终端发送的策略配置请求，具体包括：

接收所述移动终端在所述预设应用启动时，初始化并采集所述策略sdk，并通过所述策略sdk发送的包含有当前启动的所述预设应用的标记信息的策略配置请求。

优选的，在本申请一种可实现的方式中，还包括：提供可操作的策略配置界面，所述策略配置界面用于配置所述待唤醒应用列表、唤醒方式和唤醒时间间隔。

优选的，在本申请一种可实现的方式中，还包括：将所述策略配置界面配置完毕的策略配置信息存储到所述策略数据库，并与预设应用一一建立对应关系。

优选的，在本申请一种可实现的方式中，所述接收移动终端发送的策略配置请求，具体还包括：

接收所述移动终端在被唤醒的应用启动时，初始化并采集所述策略sdk，并通过所述策略sdk发送的包含有当前启动的所述预设应用的标记信息的策略配置请求。

优选的，在本申请一种可实现的方式中，所述唤醒方式具体包括：

使所述移动终端当前启动的预设应用向所述待唤醒应用列表内的应用按照所述唤醒时间间隔发送广播，使所述待唤醒应用列表内的应用作为广播接收者被唤醒。

优选的，在本申请一种可实现的方式中，所述唤醒方式具体还包括：

接收所述移动终端当前启动的预设应用按照所述待唤醒应用列表和所述唤醒时间间隔依次发送的唤醒请求；

根据所述唤醒请求向所述移动终端发送唤醒指令，使所述移动终端对所述唤醒请求对应的应用进行唤醒。

优选的，在本申请一种可实现的方式中，所述唤醒方式具体还包括：

使所述移动终端当前启动的预设应用进行自检测，每隔所述唤醒时间间隔进行自启动。

根据本申请实施例的第二方面，提供一种应用互相唤醒的系统，包括：

处理器和存储器；

所述处理器与存储器通过通信总线相连接：

其中，所述处理器，用于调用并执行所述存储器中存储的程序；

所述存储器，用于存储程序，所述程序至少用于执行以上任一项所述的一种应用互相唤醒的方法

本申请提供的技术方案可以包括以下有益效果：本申请中，在接收移动终端发送的策略配置请求后，在策略数据库中获取移动终端当前启动的预设应用对应的策略配置信息，并打包发送到移动终端。本申请中，策略配置信息至少包括：待唤醒应用列表、唤醒方式和唤醒时间间隔，配置好的策略配置信息存储在策略数据库中，并与移动终端上的应用一一对应。由于策略配置信息不是随移动终端出厂既定的，策略配置信息可以根据需要进行更改和替换，移动终端当前启动的预设应用可以灵活的根据策略配置信息对待唤醒应用列表中的应用按照唤醒方式和唤醒时间间隔依次进行唤醒。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是本申请一个实施例提供的一种应用互相唤醒的方法的流程示意图；

图2是本申请一个实施例提供的一种应用互相唤醒的系统的结构示意图。

附图标记：

处理器-21；存储器-22。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

图1是本申请一个实施例提供的一种应用互相唤醒的方法的流程示意图，参照图1，一种应用互相唤醒的方法，包括：

s11：接收移动终端发送的策略配置请求；策略配置请求是移动终端在预设应用启动时发送的；策略配置请求中包含有移动终端当前启动的预设应用的标记信息；

s12：根据策略配置请求中的标记信息，在策略数据库中获取预设应用对应的策略配置信息，并打包发送到移动终端；策略配置信息至少包括：待唤醒应用列表、唤醒方式和唤醒时间间隔；策略配置信息用于使移动终端当前启动的预设应用对待唤醒应用列表中的应用按照唤醒方式和唤醒时间间隔依次进行唤醒。

本实施例中，通过外设服务器的方式，通过服务器与移动终端进行交互。

本实施例中的应用互相唤醒的方法，准备工作包括：

对移动终端中的预设应用集成统一策略sdk。

在同一台移动终端上，集成了统一策略sdk的预设应用可以实现互相唤醒拉活，且不需要区分应用类型，只要移动终端上的预设应用集成了统一的策略sdk，就可以根据服务器的策略配置信息，进行应用间的互相唤醒拉活，所有的唤醒策略均由服务器端配置控制，根据不同的需求，进行不同的应用唤醒拉活。

服务器端提供可操作的策略配置界面，策略配置界面用于配置待唤醒应用列表、唤醒方式和唤醒时间间隔。

将策略配置界面配置完毕的策略配置信息存储到策略数据库，并与预设应用一一建立对应关系。

优选的，唤醒时间间隔可以为2s。

一些实施例中的应用互相唤醒的方法，接收移动终端发送的策略配置请求，具体包括：

接收移动终端在预设应用启动时，初始化并采集策略sdk，并通过策略sdk发送的包含有当前启动的预设应用的标记信息的策略配置请求。

在移动终端的当前应用唤醒了其他应用后，接收移动终端发送的策略配置请求，具体还包括：

接收移动终端在被唤醒的应用启动时，初始化并采集策略sdk，并通过策略sdk发送的包含有当前启动的预设应用的标记信息的策略配置请求。

即，其他应用被唤醒拉活后，同样可以通过sdk向服务器发送策略请求，继续进行其他应用的唤醒。

唤醒方式具体包括：

1)使移动终端当前启动的预设应用向待唤醒应用列表内的应用按照唤醒时间间隔发送广播，使待唤醒应用列表内的应用作为广播接收者被唤醒。

2)接收移动终端当前启动的预设应用按照待唤醒应用列表和唤醒时间间隔依次发送的唤醒请求；

根据唤醒请求向移动终端发送唤醒指令，使移动终端对唤醒请求对应的应用进行唤醒。

3)使移动终端当前启动的预设应用进行自检测，每隔唤醒时间间隔进行自启动。

举例进行说明

移动终端上的a应用在启动后，通过sdk向服务器发送策略请求，服务器根据策略配置请求中的标记信息，在策略数据库中获取a应用对应的策略配置信息，并打包发送到移动终端。

移动终端进行解包，获取策略配置信息中的待唤醒应用列表、唤醒方式和唤醒时间间隔。

待唤醒应用列表为b、c、d。

唤醒方式为广播方式唤醒。

唤醒时间间隔为2s。

a应用通过广播方式对b应用进行唤醒，在2s后通过广播方式对c应用进行唤醒，再2s后通过广播方式对d应用进行唤醒。

b应用启动后，可以再通过sdk向服务器发送策略请求，服务器根据策略配置请求中的标记信息，在策略数据库中获取b应用对应的策略配置信息，并打包发送到移动终端。

移动终端进行解包，获取策略配置信息中的待唤醒应用列表、唤醒方式和唤醒时间间隔。

待唤醒应用列表为e。

唤醒方式为通过sdk向服务器发送的e应用唤醒请求；

服务器根据唤醒请求向移动终端发送唤醒指令，使移动终端对e应用进行唤醒。

c应用启动后，可以再通过sdk向服务器发送策略请求，服务器根据策略配置请求中的标记信息，在策略数据库中获取c应用对应的策略配置信息，并打包发送到移动终端。

移动终端进行解包，获取策略配置信息中的待唤醒应用列表、唤醒方式和唤醒时间间隔。

唤醒方式为进行自检测，每隔唤醒时间间隔进行自启动。

唤醒时间间隔可以为10分钟、20分钟等。

本实施例中的应用互相唤醒的方法，在接收移动终端发送的策略配置请求后，在策略数据库中获取移动终端当前启动的预设应用对应的策略配置信息，并打包发送到移动终端。本申请中，策略配置信息至少包括：待唤醒应用列表、唤醒方式和唤醒时间间隔，配置好的策略配置信息存储在策略数据库中，并与移动终端上的应用一一对应。由于策略配置信息不是随移动终端出厂既定的，策略配置信息可以根据需要进行更改和替换，移动终端当前启动的预设应用可以灵活的根据策略配置信息对待唤醒应用列表中的应用按照唤醒方式和唤醒时间间隔依次进行唤醒。

一种应用互相唤醒的系统，参照图2，包括：

处理器21和存储器22；

处理器21与存储器22通过通信总线相连接：

其中，处理器21，用于调用并执行存储器中存储的程序；

存储器22，用于存储程序，程序至少用于执行以上任一实施例中的一种应用互相唤醒的方法。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。