CN108121580B - 应用程序通知服务的实现方法及装置 - Google Patents

Abstract

本公开涉及了一种应用程序通知服务的实现方法及装置，该种应用程序通知服务的实现方法包括：获取预先创建的通知集合中存储的通知属性描述符，所述通知集合包括待发送通知集合和失败通知集合；由所述通知属性描述符中提取通知内容，根据所述通知内容向应用程序发起通知请求；等待接收所述应用程序返回的响应消息；在等待超时或者接收到的所述响应消息指示应用程序通知失败时，将所述通知属性描述符存储至所述失败通知集合。采用本公开所提供的应用程序通知服务的实现方法及装置能够有效地提高通知的处理效率。

Description

应用程序通知服务的实现方法及装置

技术领域

本公开涉及计算机应用技术领域，尤其涉及一种应用程序通知服务的实现方法及装置。

背景技术

过去，应用程序经常需要主动查询其相应的通知服务，以了解其是否有任何需要等待处理的通知。这种主动查询的方式虽然有效，但是频繁查询反而降低了应用程序的处理效率。

基于此，出现了一种应用程序通知服务，通过向应用程序推送通知的方式取代了应用程序的主动查询。该应用程序通知服务维护一个消息队列，用来存储待发送的通知内容和通知失败的通知内容，并通过线程来循环该消息队列，以尽可能地将消息队列中存储的通知内容通知到相应的应用程序。

然而，现有的应用程序通知服务，一旦通知失败的通知内容的处理逻辑发生改变，可能会影响到待发送的通知内容的正常处理，即通知失败的通知内容的处理逻辑和待发送的通知内容的处理逻辑无法解耦，而影响了应用程序通知服务对通知的处理效率。

发明内容

基于此，本公开的一个目的在于提供一种应用程序通知服务的实现方法，用于解决现有技术中通知的处理效率较低的问题。

此外，本公开的另一个目的在于提供一种应用程序通知服务的实现装置，用于解决现有技术中通知的处理效率较低的问题。

为了解决上述技术问题，本公开所采用的技术方案为：

一种应用程序通知服务的实现方法，包括：获取预先创建的通知集合中存储的通知属性描述符，所述通知集合包括待发送通知集合和失败通知集合；由所述通知属性描述符中提取通知内容，根据所述通知内容向应用程序发起通知请求；等待接收所述应用程序返回的响应消息；在等待超时或者接收到的所述响应消息指示应用程序通知失败时，将所述通知属性描述符存储至所述失败通知集合。

一种应用程序通知服务的实现装置，包括：第一描述符获取模块，用于获取预先创建的通知集合中存储的通知属性描述符，所述通知集合包括待发送通知集合和失败通知集合；第一请求发起模块，用于由所述通知属性描述符中提取通知内容，根据所述通知内容向应用程序发起通知请求；等待接收模块，用于等待接收所述应用程序返回的响应消息；失败存储模块，用于在等待超时或者接收到的所述响应消息指示应用程序通知失败时，将所述通知属性描述符存储至所述失败通知集合。

与现有技术相比，本公开具有以下有益效果：

通过预先创建包括待发送通知集合和失败通知集合的通知集合，将待发送的通知属性描述符存储于待发送通知集合，并将通知失败的通知属性描述符存储于失败通知集合，有效地做到了通知失败的通知属性描述符的处理逻辑和待发送的通知属性描述符的处理逻辑的解耦，以此提高了应用程序通知服务对通知的处理效率。

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

附图说明

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

图1是现有技术所涉及的应用程序通知服务的实现方法的具体实现示意图；

图2是根据一示例性实施例示出的一种终端设备的框图；

图3是根据一示例性实施例示出的一种应用程序通知服务的实现方法的流程图；

图4是根据一示例性实施例示出的另一种应用程序通知服务的实现方法的流程图；

图5是根据一示例性实施例示出的另一种应用程序通知服务的实现方法的流程图；

图6是图3应实施例中将所述通知属性描述符存储至所述失败通知集合步骤在一个实施例的流程图；

图7是图6对应实施例中更新所述通知属性描述符中的通知失败属性，通过所述更新获取所述通知属性描述符的优先级步骤在一个实施例的流程图；

图8是图7对应实施例中以更新的所述通知失败次数和最后一次通知失败时间作为预设的优先级比较算子的输入，计算得出所述通知属性描述符的优先级步骤在一个实施例的流程图；

图9是根据一示例性实施例示出的另一种应用程序通知服务的实现方法的流程图；

图10是根据一示例性实施例示出的另一种应用程序通知服务的实现方法的流程图；

图11是一应用场景中一种应用程序通知服务的实现方法的具体实现示意图；

图12是根据一示例性实施例示出的一种应用程序通知服务的实现装置的框图；

图13是根据一示例性实施例示出的一种应用程序通知服务的实现装置的框图；

图14是根据一示例性实施例示出的一种应用程序通知服务的实现装置的框图；

图15是图12对应实施例中失败存储模块在一个实施例的框图；

图16是图15对应实施例中优先级获取单元在一个实施例的框图；

图17是图16对应实施例中优先级计算单元在一个实施例的框图；

图18是根据一示例性实施例示出的另一种应用程序通知服务的实现装置的框图；

图19是根据一示例性实施例示出的另一种应用程序通知服务的实现装置的框图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述，这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

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

如前所述，应用程序通知服务通过向应用程序推送通知的方式取代了应用程序的主动查询。

具体地，如图1所示，该应用程序通知服务获取待发送的通知内容，并将其组装成待发送的通知描述符(101)，进而将该待发送的通知描述符压入消息队列的队列尾(102)。

待消息队列不为空，则通过消费者线程由消息队列的队列头读取待发送的通知描述符(103)，以向相应的应用程序发送通知。

在接收到应用程序返回的返回码指示应用程序通知成功(success)时，继续通过消费者线程进行下一个待发送的通知描述符的读取(103)。反之，在接收到的应用程序返回的返回码指示应用程序通知失败(failed)时，将通知失败的通知描述符重新压入消息队列的队列尾(105)，以供消费者线程后续继续读取，进而达到尽可能通知应用程序的目的。

然而，由于待发送的通知描述符和通知失败的通知描述符均存储于同一个消息队列中，使得二者的处理逻辑无法解耦，而导致应用程序通知服务对通知的处理效率较低。

因此，为了提高通知的处理效率，特提出了一种应用程序通知服务的实现方法，该种应用程序通知服务的实现方法可由终端设备执行。例如，终端设备可以是智能手机、平板电脑、计算机等等。

图2是根据一示例性实施例示出的一种终端设备的框图。该硬件结构只是一个适用本公开的示例，不能认为是对本公开的使用范围的任何限制，也不能解释为本公开需要依赖于该终端设备200。

该终端设备200可因配置或者性能的不同而产生较大的差异，如图2所示，终端设备200包括：电源210、接口230、至少一存储介质250、以及至少一中央处理器(CPU，CentralProcessing Units)270。

该终端设备200可因配置或者性能的不同而产生较大的差异，如图2所示，终端设备200包括：电源210、接口230、至少一存储介质250、以及至少一中央处理器(CPU，CentralProcessing Units)270。

其中，电源210用于为终端设备200上的各硬件设备提供工作电压。

接口230包括至少一有线或无线网络接口231、至少一串并转换接口233、至少一输入输出接口235以及至少一USB接口237等，用于与外部设备通信。

存储介质250作为资源存储的载体，可以是随机存储介质、磁盘或者光盘等，其上所存储的资源包括操作系统251、应用程序253及数据255等，存储方式可以是短暂存储或者永久存储。其中，操作系统251用于管理与控制终端设备200上的各硬件设备以及应用程序253，以实现中央处理器270对海量数据255的计算与处理，其可以是Windows ServerTM、MacOS XTM、UnixTM、LinuxTM、FreeBSDTM等。应用程序253是基于操作系统251之上完成至少一项特定工作的计算机程序，其可以包括至少一模块(图示未示出)，每个模块都可以分别包含有对终端设备200的一系列操作指令。数据255可以是存储于磁盘中的文档、图片等等。

中央处理器270可以包括一个或多个以上的处理器，并设置为通过总线与存储介质250通信，用于运算与处理存储介质250中的海量数据255。

如上面所详细描述的，适用本公开的终端设备200将实现应用程序通知服务，即通过中央处理器270读取存储介质250中存储的一系列操作指令的形式来实现应用程序通知服务，以使运行于终端设备200中的各种应用程序能够接收到由应用程序通知服务推送的通知。

此外，通过硬件电路或者硬件电路结合软件指令也能同样实现本公开，因此，实现本公开并不限于任何特定硬件电路、软件以及两者的组合。

请参阅图3，在一示例性实施例中，一种应用程序通知服务的实现方法适用于图2所示出的终端设备200，该种应用程序通知服务的实现方法可以由终端设备200执行，可以包括以下步骤：

步骤310，获取预先创建的通知集合中存储的通知属性描述符。

本实施例中，通知集合包括待发送通知集合和失败通知集合。该待发送通知集合用于存储待发送的通知属性描述符，该失败通知集合用于存储通知失败的通知属性描述符。

需要说明的是，待发送的通知属性描述符是从未通知过的通知属性描述符，而通知失败的通知属性描述符是曾经通知过但没有通知成功的通知属性描述符。

其中，通知属性描述符是通过组装通知内容得到的。当然，通知属性描述符还可以包含其他内容，例如，通知类型、通知次数、通知时间、通知对象等等。

在不同的应用场景中，通知集合可以是消息队列的形式，也可以是数据库表的形式。例如，在系统并发率不高的应用场景中，通知集合为数据库表的形式，以采用数据库表进行待发送的通知属性描述符和通知失败的通知属性描述符的存储。

较优地，通知集合为消息队列的形式，以此提高系统性能，避免系统中由于并发率过高而出现IO瓶颈。其中，该消息队列可以是先进先出消息队列，也可以是优先级消息队列。

进一步地，消息队列在创建过程中，会对外提供将属性描述符写入该消息队列的写入接口、以及由该消息队列中读取通知属性描述符的读取接口。

更进一步地，在创建过程中，消息队列还会对写入接口和读取接口使用线程锁同步，以此保证同一时间内仅有一个线程能够访问写入接口或者读取接口，从而避免多线程竞争而导致系统崩溃的现象。

由上可知，通过调用消息队列所提供的读取接口，即可由消息队列中获取到其中存储的通知属性描述符。

进一步地，通知属性描述符既可以由待发送通知集合对应的消息队列中获取，也可以由失败通知集合对应的消息队列中获取，还可以同时由上述两个消息队列中获取。也就是说，由上述两个消息队列中获取通知属性描述符可以并发进行，以此提高通知的处理效率。

步骤330，由通知属性描述符中提取通知内容，根据通知内容向应用程序发起通知请求。

由于通知属性描述符是通过组装通知内容得到的，因此，通知内容可由通知属性描述符中提取。在提取出通知内容之后，即可通过该通知内容生成通知请求，并将该通知请求发送至应用程序。

具体地，所述生成是通过消息携带的方式完成的，即通知请求中携带该通知内容，以使应用程序在接收到该通知请求时，能够获取到其中携带的通知内容。

步骤350，等待接收应用程序返回的响应消息。

应当理解，应用程序若接收到通知请求，即可通过响应该通知请求生成响应消息，并将该响应消息返回至应用程序通知服务。反之，若未接收到通知请求，则不进行响应消息的返回。

进一步地，响应消息中携带返回码，该返回码用于指示应用程序是否被成功通知。例如，返回码为success，表示应用程序通知成功；返回码为failed，表示应用程序通知失败。当然，返回码也可以通过数字来表示应用程序是否通知成功。

基于此，应用程序通知服务在向应用程序发起通知请求之后，将等待接收应用程序返回的响应消息，以此获悉其向应用程序推送通知是否成功。

步骤370，在等待超时或者接收到的响应消息指示应用程序通知失败时，将通知属性描述符存储至失败通知集合。

当等待超时，即规定时间(例如，10s)内未接收到应用程序返回的响应消息，则表示应用程序并未接收到应用程序通知服务发起的通知请求，相应地，应用程序通知失败。

又或者，在接收到的响应消息指示应用程序通知失败时，例如，响应消息携带的返回码为failed，也表示应用程序通知失败。

因此，应用程序通知服务在获悉应用程序通知失败时，将通知属性描述符存储至失败通知集合，以便于对该通知属性描述符进行重新发送，由此达到尽可能通知应用程序的目的。具体地，所述存储是通过调用失败通知集合对应的消息队列所提供的写入接口完成的。

通过如上所述的过程，实现了待发送的通知属性描述符和通知失败的通知属性描述符的分开存储，做到了二者处理逻辑的解耦，以此有效地提高了通知的处理效率。

此外，通过分开存储，使得通知属性描述符的获取可以并发进行，即通知失败的通知属性描述符可以不必等待其前面的待发送的通知属性描述符通知完毕，以此保证其可以及时地重新发送，进一步有效地提高了通知的处理效率。

请参阅图4，在一示例性实施例中，步骤310之前，如上所述的方法还可以包括以下步骤：

步骤410，获取由其他服务生成的通知内容。

其他服务指的是区别于应用程序通知服务的应用层服务。可以理解，其他服务生成的通知内容是其他服务需要通知至应用程序的。

举例来说，A服务有更新信息需要发送到B应用程序，则A服务将根据该更新信息生成相应的通知内容，并将该通知内容发送至应用程序通知服务，以通过应用程序通知服务将该通知内容推送至B应用程序，进而使得B应用程序获取到上述更新信息，譬如，以通知的形式将该更新信息显示在B应用程序的显示界面中。

相应地，在其他服务发送通知内容之后，应用程序通知服务即可获取到该通知内容。

进一步地，在获取到其他服务生成的通知内容之后，应用程序通知服务可以立即向其他服务返回应答消息，以表示其已成功接收了通知内容，并在后续以异步方式将该通知内容推送至其他服务需要通知的应用程序，进而使得其他服务在接收到该应答消息之后即可进行其他任务，以避免不必要的等待，尤其是因应用程序通知服务内部阻塞或者通知内容推送时间过长而导致的等待，从而有利于提高系统的处理效率。

步骤430，根据通知内容组装通知属性描述符，并将通知属性描述符存储至待发送通知集合。

在获取到通知内容之后，即可进行通知属性描述符的组装。当然，通知内容还可以与通知类型、通知次数、通知时间、通知对象等等一起组装得到通知属性描述符。

在完成通知属性描述符的组装之后，即可将该通知属性描述符存储至待发送通知集合。具体地，所述存储是通过调用待发送通知集合对应的消息队列所提供的写入接口完成的。

通过如上所述的过程，即完成待发送的通知属性描述符的存储，进而有利于后续实现其与通知失败的通知属性描述符的分开存储。

请参阅图6，在一示例性实施例中，通知属性描述符包括通知失败属性，该通知失败属性能够反映出通知属性描述符等待重新发送的急迫性。

该通知失败属性可以通过通知失败次数来表示，还可以通过最后一次通知失败时间来表示。例如，若通知失败次数为0，则表示通知属性描述符暂时无需等待重新发送；若通知失败次数为10，则表示通知属性描述符通知失败的次数较多，再次通知失败的可能性较大，相应地，其等待重新发送的急迫性较低。

相应地，步骤370可以包括以下步骤：

步骤371，更新通知属性描述符中的通知失败属性，通过更新获取通知属性描述符的优先级。

如前所述，应用程序通知服务在获悉应用程序通知失败时，将通知属性描述符存储至失败通知集合，以便于对该通知属性描述符进行重新发送，由此达到尽可能通知应用程序的目的。

存储可以基于先进先出的原则，即先存储的通知属性描述符先重新发送；也可以基于优先级的原则，即优先级最高的通知属性描述符先重新发送。

为了使急迫性最高的通知属性描述符能够最先重新发送，以实现合理地通知调度，较优地，本实施例中，存储基于优先级的原则完成。

基于此，在通知属性描述符进行存储之前，需要获取通知属性描述符的优先级，以便于后续按照通知属性描述符的优先级进行通知属性描述符的存储。

具体地，在获悉应用程序通知失败时，应用程序通知服务将对通知失败的通知属性描述符进行通知失败属性的更新，以便于其能够准确地反映出通知属性描述符等待重新发送的急迫性。

以通知失败属性通过通知失败次数来表示为例，若通知失败之前，通知失败次数为9，则通知失败之后，通知失败次数被更新为10，相应地，通知属性描述符的优先级即可设置为通知失败次数10。可以理解，通知失败次数越大，表示通知属性描述符的优先级越低，其重新发送后再次通知失败的机率也越大，因此其等待重新发送的急迫性越低。

步骤373，按照通知属性描述符的优先级将通知属性描述符存储至失败通知集合。

具体而言，失败通知集合对应的消息队列为优先级消息队列。在获取到通知属性描述符的优先级之后，通过调用该优先级消息队列所提供的写入接口，即可按照通知属性描述符的优先级将该通知属性描述符存储至优先级消息队列中相应的存储位置。

换而言之，完成存储的通知属性描述符在该优先级消息队列中已经完成了优先级的排序，即存储于优先级消息队列的队列头的通知属性描述符的优先级最高，相应地，存储于优先级消息队列的队列尾的通知属性描述符的优先级最低。

进一步地，请参阅图7，在一示例性实施例中，通知失败属性包括通知失败次数和最后一次通知失败时间。

相应地，步骤371可以包括以下步骤：

步骤3711，将通知失败次数加一，并将最后一次通知失败时间更新为系统当前时间。

应当理解，该系统当前时间指的是应用程序通知服务获悉通知属性描述符通知失败的时间。

步骤3713，以更新的通知失败次数和最后一次通知失败时间作为预置的优先级比较算子的输入，计算得出通知属性描述符的优先级。

本实施例中，预置的优先级比较算子的比较逻辑为通知失败次数越大，最后一次通知失败时间与系统当前时间的时间差越小，则通知属性描述符的优先级越低。其中，该系统当前时间为准备对通知属性描述符进行重新发送的时间。

也就是说，长时间未重新发送并且重新发送后再次通知失败的机率较小的通知属性描述符，其通知失败属性经过预置的优先级比较算子计算得出的优先级较高。

更进一步地，请参阅图8，在一示例性实施例中，步骤3713可以包括以下步骤：

步骤3713a，通过预定义的通知失败次数与等待时间之间的映射关系，获取通知失败次数对应的等待时间。

映射关系中定义了不同的通知失败次数所对应的等待时间。

举例来说，预定义的映射关系中，通知失败次数为1时，其对应的等待时间为15s，通知失败次数为2时，其对应的等待时间为30s，通知失败次数为3时，其对应的等待时间为60s。即，通知失败次数越大，其对应的等待时间越长。

基于此，当更新的通知失败次数为3，即可通过预定义的映射关系，获取到其对应的等待时间为60s。

步骤3713c，根据通知失败次数对应的等待时间、最后一次通知失败时间和系统当前时间，计算得到通知属性描述符的优先级。

如前所述，该系统当前时间为准备对通知属性描述符进行重新发送的时间。

具体地，预置的优先级比较算子遵循以下公式：

cmp＝map[notify_failed_times]+notify_last_failed_time-current_time，

其中，cmp表示通知属性描述符的优先级，map表示预定义的映射关系，notify_failed_times表示通知失败次数，map[notify_failed_times]表示通知失败次数对应的等待时间，notify_last_failed_time表示最后一次通知失败时间，current_time表示系统当前时间。

由上可知，cmp越小，则优先级越高，通知属性描述符重新发送的急迫性越高，相应地，该通知属性描述的存储位置越靠近优先级消息队列的队列头。

通过如上所述的过程，实现了按照优先级对通知失败的通知属性描述符的存储，使得该通知属性描述符重新发送时不再遵循先进先出的原则，而是将优先级最高的通知属性描述符排在优先级消息队列的队列头，以便于最急迫重新发送的通知属性描述符最先重新发送，由此实现了通知的合理调度，进一步有效地提高了通知的处理效率。

请参阅图5，在一示例性实施例中，步骤330之前，如上所述的方法还可以包括以下步骤：

步骤510，根据优先级判断通知属性描述符是否达到重发时间。

其中，通知属性描述符由设置优先级的失败通知集合中获取得到。

由于通知失败的通知属性描述符是曾经通知过但未通知成功的，其仅需要在规定时间内进行重新发送即可。因此，本实施例中，在重新发送通知属性描述符之前，需要判断该通知属性描述符是否达到了重发时间。

具体而言，重发时间是否达到的判断将通过优先级实现。

如前所述，预置的优先级比较算子遵循以下公式：

cmp＝map[notify_failed_times]+notify_last_failed_time-current_time，

其中，cmp表示通知属性描述符的优先级，map表示预定义的映射关系，notify_failed_times表示通知失败次数，map[notify_failed_times]表示通知失败次数对应的等待时间，notify_last_failed_time表示最后一次通知失败时间，current_time表示系统当前时间。

由上可知，cmp反映了通知属性描述符重新发送的急迫性，其可以用来表示重发时间。

当cmp为0，表示重发时间已达到，则进入步骤330，由通知属性描述符中提取通知内容，根据通知内容向应用程序发起通知请求，以对该通知属性描述符进行重新发送。

反之，cmp大于0，表示重发时间未达到。由于按照优先级完成存储的通知属性描述符在优先级消息队列中已经完成了优先级的排序，因此，若队列头的通知属性描述符的重发时间未达到，则表示该优先级消息队列中其他所有的通知属性描述符的重发时间均未达到，即没有一个通知属性描述符需要在系统当前时间进行重新发送。相应地，则进入步骤530。

当然，在其他实施例中，也可以设置重发时间阈值，只要cmp小于重发时间阈值，即视为重发时间已达到。

步骤530，释放重发所占用的CPU资源。

当判断到没有一个通知属性描述符需要在系统当前时间进行重新发送，则释放重发所占用的CPU资源，以此避免不必要的系统开销，有利于提高系统的处理效率。

进一步地，所述释放可以在等待预设时间周期(例如1s)之后进行，以此保证在等待期间仍未有需要进行重新发送的通知属性描述符，由此避免系统资源因释放占用过于频繁而导致系统崩溃，从而有利于提高系统的稳定性。

在一示例性实施例中，如上所述的方法还可以包括以下步骤：

存储通知属性描述符至预设存储空间，并将存储的通知属性描述符的任务状态初始化为未通知状态。

其中，该预设存储空间是为通知属性描述符的持久化存储而开辟的，并不是指临时存储空间。换而言之，即使终端设备异常，例如系统意外终止，预设存储空间内存储的内容也不会丢失，例如，预设存储空间为磁盘中的某段内存。

进一步地，所述存储是与待发送通知集合中的存储同时进行的，即当待发送的通知属性描述符存储至待发送通知集合中时，该待发送的通知属性描述符也同时被存储至预设存储空间中。

在将通知属性描述符存储至预设存储空间之后，即对该通知属性描述符进行任务状态的设置。任务状态用于指示通知属性描述符是否已通知成功，其包括未通知状态和已通知状态。

可以理解，通知失败的通知属性描述符在存储至失败通知集合中时，不必再次存储至预设存储空间，因为预设存储空间中已经存储过该通知属性描述符，即不曾通知过的通知属性描述符才会被存储至预设存储空间中，因此，存储至预设存储空间的通知属性描述符的任务状态均初始化为未通知状态。

相应地，如图9所示，如上所述的方法还可以包括以下步骤：

步骤610，在终端设备异常时，由预设存储空间中获取任务状态为未通知状态的通知属性描述符。

步骤630，通过该通知属性描述符向应用程序发起通知请求，以等待接收应用程序返回的响应消息。

可以理解，若终端设备异常，例如系统意外终止，则消息队列中没有处理的通知属性描述符将全部丢失，而导致应用程序接收不到相应的通知推送，且无法进行恢复。

因此，基于预设存储空间中所进行的通知属性描述符的存储，在终端设备异常时，可以由预设存储空间中获取任务状态为未通知状态的通知属性描述符，以继续进行终端设备异常发生之前消息队列中没有执行完成的任务。

在获取到通知属性描述符之后，即可从中提取出通知内容，以根据通知内容生成通知请求，并将该通知请求发送至应用程序，以等待应用程序响应通知请求而返回的响应消息。具体过程与上述实施例中所描述的一致，在此不再一一赘述。

值得一提的是，由预设存储空间中获取通知属性描述符是在终端设备异常时进行的，当终端设备正常时不必额外开启消费者线程对预设存储空间中存储的通知属性描述符进行循环处理，以此节省系统开销，有利于提高系统的处理效率。

请参阅图10，在一示例性实施例中，如上所述的方法还可以包括以下步骤：

步骤710，在接收到的响应消息指示应用程序通知成功时，将通知属性描述符的任务状态由未通知状态更新为已通知状态。

若等待超时或者接收到的响应消息指示应用程序通知失败时，表示通知属性描述符未通知成功，仍然需要再次进行通知，相应地，该通知属性描述符的任务状态仍为未通知状态，此时，不必对预设存储空间中的该通知属性描述符进行任务状态的更新。

反之，若接收到的响应消息指示应用程序通知成功时，表示通知属性描述符已通知成功，相应地，该通知属性描述符的任务状态应该为已通知状态，此时，则对预设存储空间中的该通知属性描述符进行任务状态的更新，即将该通知属性描述符的任务状态由未通知状态更新为已通知状态。

值得一提的是，对通知属性描述符的任务状态进行更新，不仅适用于由待发送通知集合中获取到的通知属性描述符，也适用于由失败通知集合中获取到的通知属性描述符，还适用于由预设存储空间中获取到的通知属性描述符。

步骤730，对任务状态为已通知状态的通知属性描述符进行删除处理。

任务状态更新完成后，可以对任务状态为已通知状态的通知属性描述符进行删除处理，以此节省预设存储空间的存储资源。

进一步地，删除处理可以是在更新完成之后立即进行，也可以是定期(例如每12小时)进行。

通过如上所述的过程，实现了通知属性描述符的持久化存储，即使终端设备异常也不会导致丢失，防止未知原因而导致的丢失问题的发生，进而保证了通知属性描述符中的通知内容通知到相应的应用程序，进一步有效地提高了通知的处理效率。

图11是一应用场景中一种应用程序通知服务的实现方法的具体实现示意图。

在该应用场景中，应用程序通知服务维护两个消息队列：正常通知队列和失败通知队列。其中，正常通知队列为先进先出消息队列，用于存储待发送的通知属性描述符，失败通知队列为优先级消息队列，用于存储通知失败的通知属性描述符。

上述两个消息队列可以同时通过消费者线程并发地由队列头读取通知属性描述符，以向相应地应用程序进行通知推送，并根据应用程序返回的响应消息中携带的返回码判断本次通知推送是否成功，进而在通知推送成功时继续由队列头读取通知属性描述符，在通知推送失败时将该通知失败的通知属性描述符存储至失败通知队列，以供后续重新发送。

此外，应用程序通知服务还设置了数据库作为预设存储空间，以进行通知属性描述符的持久化存储。

即，待发送的通知属性描述符在存储至正常通知队列时也将被存储至数据库中，且该通知属性描述符的任务状态初始化为未通知状态，并在通知推送成功时将该通知属性描述符的任务状态由未通知状态更新为已通知状态，以供后续对任务状态为已通知状态的通知描述符所进行的删除处理。

在本公开各实施例中，在达到通知应用程序的目的同时，有效地提高了通知的处理效率。

下述为本公开装置实施例，可以用于执行本公开所涉及的应用程序通知服务的实现方法。对于本公开装置实施例中未披露的细节，请参照本公开所涉及的应用程序通知服务的实现方法的方法实施例。

请参阅图12，在一示例性实施例中，一种应用程序通知服务的实现装置900包括但不限于：第一描述符获取模块910、第一请求发起模块930、等待接收模块950和失败存储模块970。

其中，第一描述符获取模块910用于获取预先创建的通知集合中存储的通知属性描述符。通知集合包括待发送通知集合和失败通知集合。

第一请求发起模块930用于由通知属性描述符中提取通知内容，根据通知内容向应用程序发起通知请求。

等待接收模块950用于等待接收应用程序返回的响应消息。

失败存储模块970用于在等待超时或者接收到的响应消息指示应用程序通知失败时，将通知属性描述符存储至失败通知集合。

请参阅图13，在一示例性实施例中，如上所述的装置还包括但不限于：通知获取模块1010和待发送存储模块1030。

其中，通知获取模块1010用于获取由其他服务生成的通知内容。该通知内容是其他服务需要通知至应用程序的。

待发送存储模块1030用于根据通知内容组装通知属性描述符，并将通知属性描述符存储至待发送通知集合。

请参阅图14，在一示例性实施例中，如上所述的装置还包括但不限于：判断模块1110和资源释放模块1130。

其中，判断模块1110用于根据优先级判断通知属性描述符是否达到重发时间。通知属性描述符由设置优先级的失败通知集合中获取得到。若为是，则进入第一请求发起模块930。否则，进入资源释放模块1130。

资源释放模块1130用于释放重发所占用的CPU资源。

请参阅图15，在一示例性实施例中，通知属性描述符包括通知失败属性。

相应地，失败存储模块970包括但不限于：优先级获取单元971和优先级存储单元973。

其中，优先级获取单元971用于更新通知属性描述符中的通知失败属性，通过更新获取通知属性描述符的优先级。

优先级存储单元973用于按照通知属性描述符的优先级将通知属性描述符存储至失败通知集合。

请参阅图16，在一示例性实施例中，通知失败属性包括通知失败次数和最后一次通知失败时间。

相应地，优先级获取单元971包括但不限于：属性更新单元9711和优先级计算单元9713。

其中，属性更新单元9711用于将通知失败次数加一，并将最后一次通知失败时间更新为系统当前时间。

优先级计算单元9713用于以更新的通知失败次数和最后一次通知失败时间作为预置的优先级比较算子的输入，计算得出通知属性描述符的优先级。

请参阅图17，在一示例性实施例中，优先级计算单元9713包括但不限于：映射单元9713a和计算单元9713c。

其中，映射单元9713a用于通过预定义的通知失败次数与等待时间之间的映射关系，获取通知失败次数对应的等待时间。

计算单元9713c用于根据通知失败次数对应的等待时间、最后一次通知失败时间和系统当前时间，计算得到通知属性描述符的优先级。

在一示例性实施例中，如上所述的装置还包括但不限于：持久存储模块。

其中，持久存储模块，用于存储通知属性描述符至预设存储空间，并将存储的通知属性描述符的任务状态初始化为未通知状态。

相应地，如图18所示，如上所述的装置还包括但不限于：第二描述符获取模块1210和第二请求发起模块1230。

其中，第二描述符获取模块1210用于在终端设备异常时，由预设存储空间中获取任务状态为未通知状态的通知属性描述符。

第二请求发起模块1230用于通过该通知属性描述符向应用程序发起通知请求，以等待接收应用程序返回的响应消息。

请参阅图19，在一示例性实施例中，如上所述的装置还包括但不限于：状态更新模块1310和描述符删除模块1330。

其中，状态更新模块1310用于在接收到的响应消息指示应用程序通知成功时，将通知属性描述符的任务状态由未通知状态更新为已通知状态。

描述符删除模块1330用于对任务状态为已通知状态的通知属性描述符进行删除处理。

需要说明的是，上述实施例所提供的应用程序通知服务的实现装置在实现应用程序通知服务时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即应用程序通知服务的实现装置的内部结构将划分为不同的功能模块，以完成以上描述的全部或者部分功能。

另外，上述实施例所提供的应用程序通知服务的实现装置与应用程序通知服务的实现方法的方法实施例属于同一构思，其中各个模块执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。

上述内容，仅为本公开的较佳示例性实施例，并非用于限制本公开的实施方案，本领域普通技术人员根据本公开的主要构思和精神，可以十分方便地进行相应的变通或修改，故本公开的保护范围应以权利要求书所要求的保护范围为准。

Claims (17)

1.一种应用程序通知服务的实现方法，其特征在于，包括：

并发地调用不同的消息队列所提供的读取接口，获取预先创建的通知集合中存储的通知属性描述符，所述通知集合包括待发送通知集合和失败通知集合，所述待发送通知集合是用于存储待发送的通知属性描述符的消息队列，所述失败通知集合是用于存储通知失败的通知属性描述符的消息队列，所述通知失败的通知属性描述符以优先级排序的方式存储在所述失败通知集合对应的消息队列中；

由所述待发送通知集合和所述失败通知集合各自对应的消息队列存储的通知属性描述符中提取通知内容，根据所述通知内容向应用程序发起通知请求；

等待接收所述应用程序返回的响应消息；

在等待超时或者接收到的所述响应消息指示应用程序通知失败时，将所述通知属性描述符存储至所述失败通知集合对应的消息队列，以根据所述失败通知集合对应的消息队列中存储的通知属性描述符重新向所述应用程序发起通知请求。

2.如权利要求1所述的方法，其特征在于，所述并发地调用不同的消息队列所提供的读取接口，获取预先创建的通知集合中存储的通知属性描述符的步骤之前，所述方法还包括：

获取由其他服务生成的所述通知内容，该通知内容是所述其他服务需要通知至所述应用程序的；

根据所述通知内容组装所述通知属性描述符，并将所述通知属性描述符存储至所述待发送通知集合对应的消息队列。

3.如权利要求1所述的方法，其特征在于，所述由所述待发送通知集合和所述失败通知集合各自对应的消息队列存储的通知属性描述符中提取通知内容，根据所述通知内容向应用程序发起通知请求的步骤之前，所述方法还包括：

根据优先级判断所述通知属性描述符是否达到重发时间，所述通知属性描述符由设置所述优先级的所述失败通知集合对应的消息队列中获取得到；

若为是，则进入由所述通知属性描述符中提取通知内容，根据所述通知内容向应用程序发起通知请求的步骤；

否则，释放重发所占用的CPU资源。

4.如权利要求1所述的方法，其特征在于，所述通知属性描述符包括通知失败属性，所述将所述通知属性描述符存储至所述失败通知集合对应的消息队列的步骤包括：

更新所述通知属性描述符中的通知失败属性，通过所述更新获取所述通知属性描述符的优先级；

按照所述通知属性描述符的优先级将所述通知属性描述符存储至所述失败通知集合对应的消息队列。

5.如权利要求4所述的方法，其特征在于，所述通知失败属性包括通知失败次数和最后一次通知失败时间，所述更新所述通知属性描述符中的通知失败属性，通过所述更新获取所述通知属性描述符的优先级的步骤包括：

将所述通知失败次数加一，并将所述最后一次通知失败时间更新为系统当前时间；

以更新的所述通知失败次数和最后一次通知失败时间作为预置的优先级比较算子的输入，计算得出所述通知属性描述符的优先级。

6.如权利要求5所述的方法，其特征在于，所述以更新的所述通知失败次数和最后一次通知失败时间作为预设的优先级比较算子的输入，计算得出所述通知属性描述符的优先级的步骤包括：

通过预定义的通知失败次数与等待时间之间的映射关系，获取所述通知失败次数对应的等待时间；

根据所述通知失败次数对应的等待时间、最后一次通知失败时间和系统当前时间，计算得到所述通知属性描述符的优先级。

7.如权利要求1所述的方法，其特征在于，所述方法还包括：

存储所述通知属性描述符至预设存储空间，并将存储的所述通知属性描述符的任务状态初始化为未通知状态；

相应地，所述方法还包括：

在终端设备异常时，由所述预设存储空间中获取所述任务状态为未通知状态的通知属性描述符；

通过该通知属性描述符向所述应用程序发起通知请求，以等待接收所述应用程序返回的响应消息。

8.如权利要求7所述的方法，其特征在于，所述方法还包括：

在接收到的所述响应消息指示应用程序通知成功时，将所述通知属性描述符的任务状态由所述未通知状态更新为已通知状态；

对所述任务状态为已通知状态的通知属性描述符进行删除处理。

9.一种应用程序通知服务的实现装置，其特征在于，包括：

第一描述符获取模块，用于并发地调用不同的消息队列所提供的读取接口，获取预先创建的通知集合中存储的通知属性描述符，所述通知集合包括待发送通知集合和失败通知集合，所述待发送通知集合是用于存储待发送的通知属性描述符的消息队列，所述失败通知集合是用于通过失败的通知属性描述符的消息队列，所述通知失败的通知属性描述符以优先级排序的方式存储在所述失败通知集合对应的消息队列中；

第一请求发起模块，用于由所述待发送通知集合和所述失败通知集合各自对应的消息队列存储的通知属性描述符中提取通知内容，根据所述通知内容向应用程序发起通知请求；

等待接收模块，用于等待接收所述应用程序返回的响应消息；

失败存储模块，用于在等待超时或者接收到的所述响应消息指示应用程序通知失败时，将所述通知属性描述符存储至所述失败通知集合对应的消息队列，以根据所述失败通知集合对应的消息队列中存储的通知属性描述符重新向所述应用程序发起通知请求。

10.如权利要求9所述的装置，其特征在于，所述装置还包括：

通知获取模块，用于获取由其他服务生成的所述通知内容，该通知内容是所述其他服务需要通知至所述应用程序的；

待发送存储模块，用于根据所述通知内容组装所述通知属性描述符，并将所述通知属性描述符存储至所述待发送通知集合对应的消息队列。

11.如权利要求9所述的装置，其特征在于，所述装置还包括：

判断模块，用于根据优先级判断所述通知属性描述符是否达到重发时间，所述通知属性描述符由设置所述优先级的所述失败通知集合对应的消息队列中获取得到；若为是，则进入所述第一请求发起模块；否则，进入资源释放模块；

所述资源释放模块，用于释放重发所占用的CPU资源。

12.如权利要求9所述的装置，其特征在于，所述通知属性描述符包括通知失败属性，所述失败存储模块包括：

优先级获取单元，用于更新所述通知属性描述符中的通知失败属性，通过所述更新获取所述通知属性描述符的优先级；

优先级存储单元，用于按照所述通知属性描述符的优先级将所述通知属性描述符存储至所述失败通知集合对应的消息队列。

13.如权利要求12所述的装置，其特征在于，所述通知失败属性包括通知失败次数和最后一次通知失败时间，所述优先级获取单元包括：

属性更新单元，用于将所述通知失败次数加一，并将所述最后一次通知失败时间更新为系统当前时间；

优先级计算单元，用于以更新的所述通知失败次数和最后一次通知失败时间作为预置的优先级比较算子的输入，计算得出所述通知属性描述符的优先级。

14.如权利要求13所述的装置，其特征在于，所述优先级计算单元包括：

映射单元，用于通过预定义的通知失败次数与等待时间之间的映射关系，获取所述通知失败次数对应的等待时间；

计算单元，用于根据所述通知失败次数对应的等待时间、最后一次通知失败时间和系统当前时间，计算得到所述通知属性描述符的优先级。

15.如权利要求9所述的装置，其特征在于，所述装置还包括：

持久存储模块，用于存储所述通知属性描述符至预设存储空间，并将存储的所述通知属性描述符的任务状态初始化为未通知状态；

相应地，所述装置还包括：

第二描述符获取模块，用于在终端设备异常时，由所述预设存储空间中获取所述任务状态为未通知状态的通知属性描述符；

第二请求发起模块，用于通过该通知属性描述符向所述应用程序发起通知请求，以等待接收所述应用程序返回的响应消息。

16.如权利要求15所述的装置，其特征在于，所述装置还包括：

状态更新模块，用于在接收到的所述响应消息指示应用程序通知成功时，将所述通知属性描述符的任务状态由所述未通知状态更新为已通知状态；

描述符删除模块，用于对所述任务状态为已通知状态的通知属性描述符进行删除处理。

17.一种终端设备，其特征在于，包括：

存储器，存储有计算机可读指令；

处理器，读取存储器存储的计算机可读指令，以执行权利要求1-8中的任一项所述的方法。

Images