CN106936919A - 消息获取方法及装置 - Google Patents
消息获取方法及装置 Download PDFInfo
- Publication number
- CN106936919A CN106936919A CN201710202459.3A CN201710202459A CN106936919A CN 106936919 A CN106936919 A CN 106936919A CN 201710202459 A CN201710202459 A CN 201710202459A CN 106936919 A CN106936919 A CN 106936919A
- Authority
- CN
- China
- Prior art keywords
- client
- service
- message
- network request
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本申请实施例提供一种消息获取方法及装置。消息获取方法包括：根据客户端的当前状态，启用至少一种激活机制；在客户端处于当前状态期间，根据至少一种激活机制，分别激活客户端内的网络请求服务；以及根据被激活的网络请求服务和推送服务，从服务端获取消息。本申请实施例可以避免单独依靠APNS推送消息导致消息漏报的情况，提高消息传递的可靠性。
Description
技术领域
本申请涉及互联网技术领域，尤其涉及一种消息获取方法及装置。
背景技术
随着iOS平台的普及以及互联网技术的发展，基于iOS的互联网应用越来越多，这些互联网应用所提供的服务场景也更加多样化。在大多数服务场景中，互联网应用的服务端和互联网应用的客户端之间需要传递消息。
越来越多的互联网应用对准确传递消息提出了很高的要求，现有服务端与客户端之间传递消息的方式已不能满足互联网应用的需求，因此基于iOS的互联网应用面临着如何准确、可靠地传递消息的问题。
发明内容
在现有技术中，基于iOS的互联网应用大都采用图1所示方式传递消息。如图1所示，互联网应用的服务端与互联网应用的客户端之间传递消息主要包括以下几个阶段：
第一阶段：互联网应用的服务端把待发送消息和接收终端的标识打包，将打包消息发送给APNS(英文全拼为：Apple Push Notification Service)服务器。
第二阶段：APNS服务器在已注册推送服务的终端列表中，查找有相应标识的终端作为接收终端，并把打包消息中的待发送消息发送到接收终端。
第三阶段：接收终端将APNS服务器发送来的消息，传递给安装于所述接收终端上的互联网应用的客户端，并且按照设定的模式弹出通知消息。
本申请发明人跟踪研究了上述消息传递过程，发现：通过APNS服务器向客户端推送消息，可能出现消息遗漏的情况，可靠性相对较低。
然而，越来越多的互联网应用对准确传递消息提出了很高的要求，现有基于APNS服务器推送消息的方式已不能满足互联网应用的需求，因此基于iOS的互联网应用面临着如何准确、可靠地传递消息的问题。
针对上述技术问题，本申请发明人提供一种解决方案，其核心原理是：在基于APNS推送消息的基础上，在互联网应用的客户端(APP，英文全称为Aplication)内嵌网络请求服务，基于客户端的运行状态以不同方式激活客户端内部的网络请求服务，以便同时采用APNS推送消息和客户端内部的网络请求服务与服务端进行消息传递，避免单独依靠APNS推送消息导致消息漏报的情况，提高消息传递的可靠性。
基于上述，本申请一实施例提供一种消息获取方法，包括：
根据客户端的当前状态，启用至少一种激活机制；
在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务；以及
根据所述被激活的网络请求服务和推送服务，从服务端获取消息。
在一可选实施方式中，所述根据客户端的当前状态，启用至少一种激活机制，包括：在所述客户端当前处于非运行状态时，启用至少一种系统服务级的激活机制。
在一可选实施方式中，在所述客户端当前处于非运行状态时，启用至少一种系统服务级的激活机制，包括以下至少一种：
在所述客户端当前处于非运行状态时，启用操作系统提供的后台获取机制；
在所述客户端当前处于非运行状态时，启用操作系统提供的静默推送机制。
在一可选实施方式中，在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务，包括以下至少一种：
在所述客户端处于非运行状态期间，调用所述操作系统提供的后台获取API，以确定激活时间点，并在所述激活时间点激活所述网络请求服务；
在所述客户端处于非运行状态期间，接收所述服务端基于所述静默推送机制通过所述推送服务所推送的静默消息，并在接收到所述静默消息时，激活所述网络请求服务。
在一可选实施方式中，在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务，包括：
在所述客户端处于非运行状态期间，根据所述至少一种激活机制，将所述客户端从非运行状态变更为运行状态，在所述客户端处于运行状态时，激活所述网络请求服务。
在一可选实施方式中，根据客户端的当前状态，启用至少一种激活机制之前，所述方法还包括：监听所述客户端的状态；若监听到所述客户端处于挂起状态，确定所述客户端当前处于非运行状态。
在一可选实施方式中，所述方法还包括：在所述客户端进入后台状态时，调用操作系统提供的后台任务API，以使所述客户端在指定时间后进入挂起状态。
在一可选实施方式中，所述根据客户端的当前状态，启用至少一种激活机制，包括：在所述客户端当前处于运行状态时，启用至少一种应用级的激活机制。
在一可选实施方式中，在所述客户端当前处于运行状态时，启用至少一种应用级的激活机制，包括：在所述客户端当前处于运行状态时，启用所述客户端内的定时轮询机制。
在一可选实施方式中，在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务，包括：在所述客户端处于运行状态期间，根据所述定时轮询机制，定时激活所述网络请求服务。
在一可选实施方式中，根据客户端的当前状态，启用至少一种激活机制之前，所述方法还包括：监听所述客户端的状态；若监听到所述客户端处于非活动状态、活动状态或后台状态，确定所述客户端当前处于运行状态。
在一可选实施方式中，所述根据所述被激活的网络请求服务和推送服务，从服务端获取消息，包括：通过推送通道，接收所述服务端通过所述推送服务推送的第一消息；通过网络请求通道，接收服务端根据所述被激活的网络请求服务发送的网络请求而返回的第二消息；通过与所述客户端的当前状态相适应的展示方式，提示所述第一消息和/或第二消息的到达。
相应地，本申请另一实施例提供一种消息获取装置，包括：
启用单元，用于根据客户端的当前状态，启用至少一种激活机制；
激活单元，用于在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务；以及
获取单元，用于根据所述被激活的网络请求服务和推送服务，从服务端获取消息。
在一种可选实施方式中，所述启用单元具体用于：在所述客户端处于非运行状态时，启用至少一种系统服务级的激活机制。
在一种可选实施方式中，所述启用单元具体用于执行以下至少一种操作：
在所述客户端当前处于非运行状态时，启用操作系统提供的后台获取机制；
在所述客户端当前处于非运行状态时，启用操作系统提供的静默推送机制。
在一种可选实施方式中，所述激活单元具体用于执行以下至少一种操作：
在所述客户端处于非运行状态期间，调用所述操作系统提供的后台获取API，以确定激活时间点，并在所述激活时间点激活所述网络请求服务；
在所述客户端处于非运行状态期间，接收所述服务端基于所述静默推送机制通过所述推送服务所推送的静默消息，并在接收到所述静默消息时，激活所述网络请求服务。
在一可选实施方式中，所述激活单元具体用于：在所述客户端处于非运行状态期间，根据所述至少一种激活机制，将所述客户端从非运行状态变更为运行状态，在所述客户端处于运行状态时，激活所述网络请求服务。
在一种可选实施方式中，所述装置还包括：第一监听单元，用于监听所述客户端的状态；第一确定单元，用于在所述第一监听单元监听到所述客户端处于挂起状态时，确定所述客户端当前处于非运行状态。
在一种可选实施方式中，所述装置还包括：调用单元，用于在所述客户端进入后台状态时，调用操作系统提供的后台任务API，以使所述客户端在指定时间后进入挂起状态。
在一种可选实施方式中，所述启用单元具体用于：在所述客户端当前处于运行状态时，启用至少一种应用级的激活机制。
在一种可选实施方式中，所述启用单元具体用于：在所述客户端当前处于运行状态时，启用所述客户端内的定时轮询机制。
在一种可选实施方式中，所述激活单元具体用于：在所述客户端处于运行状态期间，根据所述定时轮询机制，定时激活所述网络请求服务。
在一种可选实施方式中，所述装置还包括：第二监听单元，用于监听所述客户端的状态；第二确定单元，用于在所述第二监听单元监听到所述客户端处于非活动状态、活动状态或后台状态时，确定所述客户端当前处于运行状态。
在一种可选实施方式中，所述获取单元具体用于：通过推送通道，接收所述服务端通过所述推送服务推送的第一消息；通过网络请求通道，接收服务端根据所述被激活的网络请求服务发送的网络请求而返回的第二消息；通过与所述客户端的当前状态相适应的展示方式，提示所述第一消息和/或第二消息的到达。
本申请实施例还提供一种终端设备，包括：存储器、处理器以及一互联网应用的客户端；所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令供所述处理器调用执行；
所述处理器用于：根据所述客户端的当前状态，启用至少一种激活机制；在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务；以及根据所述被激活的网络请求服务和推送服务，从服务端获取消息。
在一个可能的设计中，消息获取装置的结构中包括处理器和存储器，所述存储器用于存储支持消息获取装置执行上述实施例提供的消息获取方法的程序，所述处理器被配置为用于执行所述存储器中存储的程序。所述消息获取装置还可以包括通信接口，用于所述消息获取装置与其他设备或通信网络通信。
本申请实施例提供了一种计算机存储介质，用于储存消息获取装置所用的计算机软件指令，其包含用于执行上述实施例提供的消息获取方法为所述消息获取装置所涉及的程序。
在本申请实施例中，在推送服务的基础上，在客户端内嵌网络请求服务，基于客户端的运行状态以不同方式激活客户端内部的网络请求服务，以便同时采用推送服务和客户端内部的网络请求服务与服务端进行消息传递，避免单独依靠推送服务推送消息导致消息漏报的情况，提高消息传递的可靠性。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为现有技术中基于APNS推送服务的消息推送过程的示意图；
图2为本申请一实施例提供的消息获取方法的流程示意图；
图3为本申请另一实施例提供的消息获取方法的流程示意图；
图4为本申请又一实施例提供的消息通知架构的示意图；
图5为本申请又一实施例提供的消息获取装置的结构示意图；
图6为本申请又一实施例提供的消息获取装置的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
图2为本申请一实施例提供的消息获取方法的流程示意图。如图2所示，所述方法包括：
201、根据客户端的当前状态，启用至少一种激活机制。
202、在客户端处于当前状态期间，根据至少一种激活机制，分别激活客户端内的网络请求服务。
203、根据被激活的网络请求服务和推送服务，从服务端获取消息。
在本实施例中，客户端内嵌网络请求服务。当网络请求服务被激活时，可直接与客户端对应的服务端建立网络连接，并通过所述网络连接与服务端进行交互。所述服务端位于网络侧或云端，是为客户端服务的，例如向客户端提供资源，保存客户端的数据。所述资源主要包括客户端所需的消息和/或数据。网络请求服务与服务端之间的交互过程主要包括：网络请求服务向服务端发送网络请求；服务端接收网络服务请求发送的网络请求，并根据所述网络请求向网络请求服务返回相应信息的过程。
在本实施例中，结合客户端的状态，提供不同的激活机制，用以在客户端处于不同状态时激活所述网络请求服务。在客户端的每种状态下，提供有至少一种激活机制，并且至少一种激活机制之间相互独立，即所述至少一种激活机制可以各自独立地激活网络请求服务。当然，不同客户端状态对应的激活机制之间也相互独立。
当有多个激活机制同时激活网络请求服务时，客户端与服务端之间可以进行多次网络交互。可选地，可以在客户端与服务端之间建立一条网络连接，多次网络交互基于相同网络连接完成；或者，也可以在客户端与服务端之间建立多条不同的网络连接，多次网络交互基于不同的网络连接完成。
基于上述分析，当客户端需要从服务端获取消息时，一方面可以启用推送服务，由服务端通过推送服务推送消息；另一方面可以根据客户端的当前状态，启用与客户端当前状态相匹配的至少一种激活机制，在客户端处于当前状态期间，采用被启用的至少一种激活机制分别激活客户端内的网络请求服务，从而同时结合被激活的网络请求服务和推送服务，从服务端获取消息。由此可见，本实施例可以采用多种方式从服务端获取消息，与单纯依赖推送服务相比，有利于降低出现消息遗漏的概率，进而提高消息获取的可靠性。
其中，根据应用场景的不同，客户端可以从服务端获取的消息也会有所不同。以外卖系统为例，客户端可以从服务端获取的消息可以是订单通知消息、订单取消消息、系统通知消息等任意消息。
其中，根据应用场景的不同，上述推送服务也会有所不同。可选地，上述推送服务可以是现有的推送服务，也可以是在本案之后出现的新的推送服务。另外，根据应用场景的不同，上述推送服务可以是第三方推送服务，也可以是系统自身的推送服务。例如，对基于iOS平台开发的应用来说，上述推送服务可以是基于APNS服务器的推送服务，属于现有的第三方推送服务。又例如，对基于Android平台开发的应用来说，上述推送服务可以是互联网应用的服务端直接面向互联网应用的客户端提供的推送服务。
在上述实施例或下述实施例中，需要基于客户端的状态，启用相应的激活机制，以激活客户端内的网络请求服务。可选地，可以将客户端的状态划分为运行状态和非运行状态，但不限于此。这里的运行状态主要是指客户端的程序代码被加载到内存中并且具有执行能力(例如可以响应用户操作和/或系统操作)的状态。当客户端处于以下任一情况时都属于这里的运行状态：客户端位于前台但未接收事件处理，客户端位于前台并且接收到事件处理，以及客户端位于后台并且可以响应系统操作(主要是指可以接收操作系统发出的消息或指令)。这里的“前台”主要是指承载客户端的终端的屏幕上呈现有客户端的界面，可响应用户操作。这里的“后台”主要是指承载客户端的终端的屏幕上未呈现客户端的界面，无法响应用户操作。相应地，非运行状态是指客户端自身不具有执行能力，一般来说除用户或操作系统发起的可引起客户端状态变更的操作之外，不可响应其它操作的状态。
对于客户端处于运行状态的情况，客户端自身具有执行能力，因此可以启用至少一种应用级的激活机制。所述应用级的激活机制是指客户端内的激活机制，这些激活机制可被客户端执行。在客户端处于运行状态时，通过启用应用级的激活机制，使得客户端可以自己激活内部的网络请求服务，从而在客户端处于运行状态的情况下保证消息获取的可靠性。
对于客户端处于非运行状态的情况，客户端自身已经不具有执行能力，故可以启用至少一种系统服务级的激活机制。所述系统服务级的激活机制是指操作系统提供的激活机制，这些激活机制可用于改变客户端的状态但不属于客户端内的激活机制。在客户端处于非运行状态时，通过系统服务级的激活机制可以激活客户端内的网络请求服务，从而在客户端处于非运行状态的情况下保证消息获取的可靠性。
基于上述分析，本申请另一实施例提供的消息获取方法的流程，如图3所示，包括以下步骤：
301、监听客户端的状态。
302、判断客户端当前是否处于非运行状态；若判断结果为是，即客户端处于非运行状态，则执行步骤303；若判断结果为否，即客户端处于运行状态，则执行步骤305。
303、启用至少一种系统服务级的激活机制，继续执行步骤304。
304、根据至少一种系统服务级的激活机制，分别激活客户端内的网络请求服务，并继续执行步骤307。
305、启用至少一种应用级的激活机制，继续执行步骤306。
306、根据至少一种应用级的激活机制，分别激活客户端内的网络请求服务，并继续执行步骤307。
307、根据被激活的网络请求服务和推送服务，从服务端获取消息。
在本实施例中，通过监听客户端的状态，识别客户端是处于本申请实施例所定义的运行状态还是非运行状态，以便启用相应的激活机制激活客户端内的网络请求服务，从而保证无论客户端是处于运行状态还是处于非运行状态，都能够可靠地从服务端获得消息。
在上述实施例或下述实施例中，需要根据被启用的激活机制，激活客户端内的网络请求服务。可选地，若客户端处于非运行状态，则激活客户端内的网络请求服务包括：根据所述被启用的激活机制，首先将客户端从非运行状态变更至运行状态，在客户端处于运行状态下激活所述网络请求服务。
在上述实施例或下述实施例中，可选地，客户端的程序代码可基于iOS平台开发。基于iOS平台开发的APP包括以下状态：未运行(Not Running)状态、非活动(Inactive)状态、活动(Active)状态、后台(Background)状态以及挂起(Suspended)状态。其中，NotRunning状态是指客户端未启动，其程序代码尚未被加载至内存中的状态，一般来说除用户或操作系统发起的可引起客户端状态变更的操作之外，不可响应其它操作。Inactive状态是指客户端正在前台运行，此时有界面呈现，但是未接收到事件处理的状态。Active状态是指客户端正在前台运行，此时有界面呈现，并且接收到事件处理的状态。Background状态是指客户端处在后台，此时没有界面呈现，但还可以响应系统操作的状态，这是客户端在进入Suspended状态之前短暂停留的状态。Suspended状态是客户端处在后台，此时没有界面呈现，并且自身不具有执行能力，一般来说除用户或操作系统发起的可引起客户端状态变更的操作之外，不可响应其它操作的状态。
基于上述，在监听客户端的状态的过程中，若监听到客户端处于Not Running或Suspended状态，则可以确定客户端处于本申请实施例所定义的非运行状态；相应地，当监听到客户端处于Inactive状态、Active状态或者Background状态时，可以确定客户端处于本申请实施例所定义的运行状态。
进一步可选地，考虑到Background状态是客户端进入Suspended状态之前短暂停留的状态，Background状态的持续时间比较短，不利于监听操作，因此可以适当延长客户端处于Background状态的时间。为了延长客户端处于Background状态的时间，在客户端进入Background状态时，可以调用操作系统(即iOS)提供的后台任务(BackgroundTask)应用程序接口(Application Programming Interface，API)，以使客户端在指定时间后进入Suspended状态。简单来说，iOS提供了后台任务API，通过调用后台任务API可以使客户端在Background状态保持指定时间，例如3分钟，然后再进入Suspended状态。
在一可选实施方式中，系统服务级的激活机制可以包括操作系统提供的后台获取(Background Fetch)机制和/或操作系统提供的静默推送(Silent RemoteNotifications)机制，但不限于此。其中，Background Fetch机制是指使用操作系统提供的Background Fetch API的机制，Background Fetch API会根据客户端的一些使用情况确定激活时间点，进而可以在Background Fetch API确定的激活时间点激活网络请求服务。Silent Remote Notifications机制是指触发服务端周期性地通过APNS推送服务向客户端推送静默消息的机制，所述静默消息用于激活客户端内的网络请求服务。
基于上述，一种启用系统服务级的激活机制的实施方式可以包括：
在客户端处于非运行状态期间，启用操作系统提供的后台获取机制；和/或
在客户端处于非运行状态期间，启用操作系统提供的静默推送机制。
相应地，若在客户端处于非运行状态期间，启用操作系统提供的后台获取机制，则可以根据后台获取机制，激活客户端内的网络请求服务。激活操作的实施方式包括：在客户端处于非运行状态期间，调用操作系统提供的Background Fetch API，以确定激活时间点，并在所述激活时间点先将客户端从非运行状态变更为运行状态，再激活客户端内的网络请求服务。
相应地，若在客户端处于非运行状态期间，启用操作系统提供的静默推送机制，则可以根据静默推送机制，激活客户端内的网络请求服务。激活操作的实施方式包括：服务端通过APNS推送服务定时向客户端推送静默消息，因此在客户端处于非运行状态期间，可以接收服务端基于静默推送机制通过APNS推送服务推送的静默消息，并在接收到静默消息时，先将客户端从非运行状态变更为运行状态，再激活客户端内的网络请求服务。
相应地，若在客户端处于非运行状态期间，同时启用操作系统提供的后台获取机制和静默推送机制，则可以根据后台获取机制和/或静默推送机制，激活客户端内的网络请求服务。激活操作的实施例方式包括：在客户端处于非运行状态期间，一方面调用操作系统提供的后台获取API，可以根据客户端的一些使用情况确定激活时间点，并在所述激活时间点激活客户端内的网络请求服务；另一方面，接收服务端基于静默推送机制通过APNS推送服务所推送的静默消息，并在接收到静默消息时，激活客户端内的网络请求服务。在此需要说明，在多种(两种或两种以上)激活机制结合使用时，若多种激活机制激活所述网络请求服务的时间点不同，则只需由激活时间较早的激活机制，将客户端从非运行状态变更到运行状态，然后激活网络请求服务。其中，当客户端被从非运行状态变更至运行状态时，会触发启用应用级的触发机制而进入另一分支。若多种激活机制激活所述网络请求服务的时间点相同，则可以由任意一种或多种激活机制，将客户端从非运行状态变更到运行状态，然后激活网络请求服务。优选地，在实际操作上，可以只执行一次客户端状态的变更操作和网络请求服务的激活操作。
在一可选实施方式中，应用级的激活机制包括客户端内的定时轮询机制。定时轮询机制是指按照设定的定时间隔，定时激活网络请求服务的机制。
基于上述，一种启用应用级的激活机制的实施方式可以包括：在客户端当前处于运行状态时，启用客户端内的定时轮询机制。相应地，若在客户端当前处于运行状态时，启用客户端内的定时轮询机制，则可以根据定时轮询机制，激活客户端内的网络请求服务。激活操作的实施方式包括：在客户端处于运行状态期间，根据定时轮询机制，定时激活网络请求服务。其中，定时间隔可根据应用场景适应性设置，本实施例对此不作限定。
在上述实施例或下述实施例中，在激活网络请求服务之后，需要根据被激活的网络请求服务以及推送服务，从服务端获取消息。一种根据被激活的网络请求服务以及推送服务，从服务端获取消息的可选实施方式包括：一方面，通过推送通道，接收服务端通过推送服务推送的第一消息；另一方面，通过网络请求通道，接收服务端根据被激活的网络请求服务发送的网络请求而返回的第二消息；然后，通过与客户端的当前状态相适应的展示方式，提示第一消息和/或第二消息的到达。提示方式包括但不限于：展示第一消息和/或第二消息以进行提示，和/或，通过提示音进行提示。
其中，通过推送通道接收第一消息的操作，与通过网络请求通道接收第二消息的操作之间没有先后顺序的限定，具体视触发时机而定。这两种操作可以并行执行，也可以其中任一种操作先执行，另一种操作后执行。
理论上来说，在不存在消息漏报的情况下，服务端通过推送服务推送的第一消息与通过被激活的网络请求服务请求到的第二消息应该相同，则在展示时可以展示第一消息和第二消息中的任一消息。但实际应用过程中，服务端通过推送服务推送消息时可能存在消息漏报的情况，相应地，通过网络请求服务从服务端请求消息时也可能存在消息漏报的情况，在这些情况下，第一消息和第二消息不完全相同，则可以同时展示第一消息和第二消息，或者展示第一消息和第二消息两者的并集等。在本实施方式中，将两种方式结合，可以相互弥补彼此漏报的消息，从而提高了消息从服务端到达客户端的可靠性。
在展示第一消息和/或第二消息时，可结合客户端的当前状态，采用合适的方式。当客户端处于运行状态，并且位于前台时，会呈现一界面，则可以在所述界面展示第一消息和/或第二消息，以提示用户有消息到达。当客户端处于运行状态，并且位于后台时，或者当客户端处于非运行状态，并且位于后台时，没有界面呈现，则可以调用操作系统提供的本地通知Local Notification提示用户有消息到达。其中，基于Local Notification提示用户有消息到达的方式包括：通过弹窗展示第一消息和/或第二消息，以提示用户有消息到达，或者，通过声音提示用户有消息到来，或者也可以结合弹窗和声音提示用户有消息到来。
在一外卖应用场景中，外卖系统包括服务端、商户客户端和用户客户端。随着iOS终端设备的广泛应用，针对iOS终端设备开发iOS版本的商户客户端和用户客户端，商户客户端和用户客户端可安装于各种iOS终端设备上；同时，对服务端的功能做适应性扩展，使得服务端可以支持iOS版的商户客户端和用户客户端。所述iOS终端设备可以是手机、笔记本电脑或平板电脑等。
在实际应用过程中，用户通过用户客户端进行下单。当用户点击订单页面上的提交按钮提交订单时，用户客户端向服务端发送一条订单消息。为了便于商户及时了解订单状况以及是否有新订单到达，服务端在收到用户客户端发送的订单消息时，可以向商户客户端发送一条订单通知消息，以通知商户有新订单。为了保证商户客户端能够可靠、及时地收到订单通知消息，则商户客户端获取订单通知消息的过程可以采用本申请上述实施例提供的方法实现。除此之外，在用户客户端获取服务端推送的与商品或商家有关的消息时，也可以采用上述实施例提供的方法实现。又例如，在服务端获取用户客户端或商户客户端的状态等信息时，也可以采用上述实施例提供的方法实现。在下面实施例中，以本申请上述实施例提供的方法在商户客户端获取订单通知消息过程中的应用为例进行说明，但并不限于此。
在本实施例中，为了保证订单通知消息安全可靠地到达商户一端，采用图4所示的消息通知架构。基于图4所示的消息通知架构，商户客户端获取订单通知消息的过程包括以下几方面的操作：
第一种操作流程如图4中标①的连接线所示，该操作流程不受商户客户端的状态的限制，即在商户客户端处于任何状态时都可实施。具体地，服务端每当接收到用户客户端提交的订单消息时，通过现有的推送服务，即APNS推送服务向商户客户端推送订单通知消息。其详细流程为：用户客户端向服务端提交订单消息；服务端接收用户客户端提交的订单消息；服务端生成订单通知消息，将订单通知消息发送至APNS服务端，APNS服务端将订单通知消息发送至承载商户客户端的终端设备；终端设备将订单通知消息通知给商户客户端。其中，通知方式与商户客户端的状态有关。若此时商户客户端处于运行状态，并且位于前台，即处于Inactive状态或Active状态，商户客户端在终端设备上呈现有一界面，则可以通过所述界面将订单通知消息展示出来，即图4中标①的实线所示；若此时商户客户端处于运行状态，并且位于后台，即处于Background状态，或者商户客户端处于非运行状态，并且位于后台，即处于Suspended状态，商户客户端在终端设备上未呈现有界面，则可以调用iOS提供的Local Notification，通过弹窗和/或声音的方式提示商户有订单通知消息到达，即图4中标①的虚线所示。
第二种操作流程如图4中标②的连接线所示，该操作流程与商户客户端的状态有关。具体地，在商户客户端处于Inactive状态、Active状态或Background状态时，商户客户端内开启一个定时轮询机制，例如可以是30s轮询一次，按照轮询间隔定时激活网络请求服务。即，按照轮询间隔定时向服务端发送网络请求，以向服务端请求订单通知消息；服务端接收到商户客户端发送的网络请求之后，在有订单通知消息的情况下，向商户客户端返回订单通知消息。其中，通知方式与商户客户端的状态有关。若此时商户客户端处于运行状态，并且位于前台，即处于Inactive状态或Active状态，则商户客户端在终端设备上呈现有一界面，则可以通过所述界面将订单通知消息展示出来，即图4中标②的实线所示；若此时商户客户端处于运行状态，并且位于后台，即处于Background状态，商户客户端在终端设备上未呈现有界面，则可以调用iOS提供的Local Notification，通过弹窗和/或声音的方式提示商户有订单通知消息到达，即图4中标②的虚线所示。
可选地，为了延长客户端处于Background状态的时间，如图4中标③的连接线所示：商户客户端在进入Background状态时，可以调用iOS提供的Background Task。其中，使用BackgroundTask，可以使商户客户端在一定时间，例如3分钟内一直处于Background状态。这样，在这3分钟内，可结合上述30秒的定时轮询机制，每30秒主动向服务端请求一次订单通知消息，进而获得最新的订单状态。
第三种操作流程如图4中标④的连接线所示，该操作流程与商户客户端的状态有关。具体地，在商户客户端处于Suspended状态时，调用iOS提供的Background Fetch API，Background Fetch根据商户客户端的使用情况确定激活时间点，然后在所述激活时间点先将客户端从非运行状态变更为运行状态，例如Background状态，再激活网络请求服务。即，向服务端发送网络请求，以向服务端请求订单通知消息；服务端接收到商户客户端发送的网络请求之后，在有订单通知消息的情况下，向商户客户端返回订单通知消息。此时，商户客户端已经处于运行状态，并且位于后台，即处于Background状态，商户客户端在终端设备上未呈现有界面，则可以调用iOS提供的Local Notification，通过弹窗和/或声音的方式提示商户有订单通知消息到达，即图4中标④的虚线所示。
第四种操作流程如图4中标⑤的连接线所示，该操作流程与商户客户端的状态有关。具体地，在商户客户端处于Suspended状态时，采用iOS提供的Silent RemoteNotifications机制，基于Silent Remote Notifications机制，服务端定时通过APNS服务端向商户客户端推送静默消息，该静默消息是服务端定时推送的而不依赖于订单通知消息；当接收到APNS服务端发送的静默消息时，先将客户端从非运行状态变更为运行状态，例如Background状态，再激活网络请求服务。即，向服务端发送网络请求，以向服务端请求订单通知消息；服务端接收到商户客户端发送的网络请求之后，在有订单通知消息的情况下，向商户客户端返回订单通知消息。此时，商户客户端已经处于运行状态，并且位于后台，即处于Background状态，商户客户端在终端设备上未呈现有界面，则可以调用iOS提供的Local Notification，通过弹窗和/或声音的方式提示商户有订单通知消息到达，即图4中标⑤的虚线所示。
值得说明的是，在商户客户端处于本申请实施例所定义的运行状态时，可按照各自的执行逻辑一并执行上述第一种操作和第二种操作；在商户客户端处于本申请实施例所定义的非运行状态时，可按照各自的执行逻辑一并执行上述第一种操作、第三种操作和第四种操作。
由此可见，在本实施例中，结合现有APNS推送服务，在商户客户端内部开启一个定时轮询机制，以轮询方式定时从服务端拉取最新的订单通知消息，使得在商户客户端处于运行状态的情况下能够可靠、及时地获取订单通知消息，及时了解最新的订单状态。同时，使用iOS平台提供的多种后台运行机制，保证商户客户端处于非运行状态的情况下也能够可靠、及时地获取最新的订单通知消息，及时了解最新的订单状态。
需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤201至步骤203的执行主体可以为设备A；又比如，步骤201和202的执行主体可以为设备A，步骤203的执行主体可以为设备B；等等。
图5为本申请又一实施例提供的消息获取装置的结构示意图。如图5所示，装置包括：启用单元51、激活单元52和获取单元53。
启用单元51，用于根据客户端的当前状态，启用至少一种激活机制。
激活单元52，用于在客户端处于当前状态期间，根据启用单元51启用的至少一种激活机制，分别激活客户端内的网络请求服务。
获取单元53，用于根据被激活单元52激活的网络请求服务和推送服务，从服务端获取消息。
在一可选实施方式中，启用单元51具体用于：在客户端处于非运行状态时，启用至少一种系统服务级的激活机制。
进一步，启用单元51具体用于执行以下至少一种操作：
在客户端当前处于非运行状态时，启用操作系统提供的后台获取机制；
在客户端当前处于非运行状态时，启用操作系统提供的静默推送机制。
相应地，激活单元52具体用于执行以下至少一种操作：
在客户端处于非运行状态期间，调用操作系统提供的后台获取API，以确定激活时间点，并在激活时间点激活网络请求服务；
在客户端处于非运行状态期间，接收服务端基于静默推送机制通过推送服务所推送的静默消息，并在接收到静默消息时，激活网络请求服务。
在一可选实施方式中，激活单元52具体用于：在客户端处于非运行状态期间，根据至少一种激活机制，将客户端从非运行状态变更为运行状态，在客户端处于运行状态时，激活网络请求服务。
在一可选实施方式中，如图6所示，装置还包括：第一监听单元61和第一确定单元62。
第一监听单元61，用于监听客户端的状态。
第一确定单元62，用于在第一监听单元61监听到客户端处于挂起状态时，确定客户端当前处于非运行状态，以向启用单元51提供客户端当前所处的状态信息。
在一可选实施方式中，如图6所示，装置还可以包括：调用单元63。
调用单元63，用于在客户端进入后台状态时，调用操作系统提供的后台任务API，以使客户端在指定时间后进入挂起状态。
在一可选实施方式中，启用单元51具体用于：在客户端当前处于运行状态时，启用至少一种应用级的激活机制。
进一步，启用单元51具体用于：在客户端当前处于运行状态时，启用客户端内的定时轮询机制。
相应地，激活单元52具体用于：在客户端处于运行状态期间，根据定时轮询机制，定时激活网络请求服务。
在一可选实施方式中，如图6所示，装置还包括：第二监听单元64和第二确定单元65。
第二监听单元64，用于监听客户端的状态；
第二确定单元65，用于在第二监听单元64监听到客户端处于非活动状态、活动状态或后台状态时，确定客户端当前处于运行状态，以向启用单元51提供客户端当前所处的状态信息。
在一可选实施方式中，获取单元53具体用于：通过推送通道，接收服务端通过推送服务推送的第一消息；通过网络请求通道，接收服务端根据被激活的网络请求服务发送的网络请求而返回的第二消息；通过与客户端的当前状态相适应的展示方式，展示第一消息和/或第二消息。
值得说明的是，第一监听单元61和第二监听单元64可以是同一单元，也可以是两个独立的单元。相应地，第一确定单元62和第二确定单元65可以是同一单元，也可以是两个独立的单元。
本实施例提供的消息获取装置可作为客户端内部的一功能模块，位于客户端内部实现；或者，也可以独立于客户端，例如作为客户端的一插件模块实现。
本实施例提供的消息获取装置可用于执行上述方法实施例的流程，其具体工作原理以及流程不再赘述，详见方法实施例的描述。
本实施例提供的消息获取装置，可以在推送服务的基础上，基于客户端内嵌的网络请求服务，结合客户端的运行状态以不同方式激活客户端内部的网络请求服务，以便同时采用推送服务和客户端内部的网络请求服务与服务端进行消息传递，避免单独依靠推送服务推送消息导致消息漏报的情况，提高消息传递的可靠性。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。
本申请实施例公开A1、一种消息获取方法，包括：
根据客户端的当前状态，启用至少一种激活机制；
在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务；以及
根据所述被激活的网络请求服务和推送服务，从服务端获取消息。
A2、如A1所述的方法中，所述根据客户端的当前状态，启用至少一种激活机制，包括：
在所述客户端当前处于非运行状态时，启用至少一种系统服务级的激活机制。
A3、如A2所述的方法中，在所述客户端当前处于非运行状态时，启用至少一种系统服务级的激活机制，包括以下至少一种：
在所述客户端当前处于非运行状态时，启用操作系统提供的后台获取机制；
在所述客户端当前处于非运行状态时，启用操作系统提供的静默推送机制。
A4、如A3所述的方法中，在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务，包括以下至少一种：
在所述客户端处于非运行状态期间，调用所述操作系统提供的后台获取API，以确定激活时间点，并在所述激活时间点激活所述网络请求服务；
在所述客户端处于非运行状态期间，接收所述服务端基于所述静默推送机制通过所述推送服务所推送的静默消息，并在接收到所述静默消息时，激活所述网络请求服务。
A5、如A2所述的方法中，在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务，包括：
在所述客户端处于非运行状态期间，根据所述至少一种激活机制，将所述客户端从非运行状态变更为运行状态，在所述客户端处于运行状态时，激活所述网络请求服务。
A6、如A2-A5任一项所述的方法中，根据客户端的当前状态，启用至少一种激活机制之前，所述方法还包括：
监听所述客户端的状态；
若监听到所述客户端处于挂起状态，确定所述客户端当前处于非运行状态。
A7、如A6所述的方法中，所述方法还包括：
在所述客户端进入后台状态时，调用操作系统提供的后台任务API，以使所述客户端在指定时间后进入挂起状态。
A8、如A1所述的方法中，所述根据客户端的当前状态，启用至少一种激活机制，包括：
在所述客户端当前处于运行状态时，启用至少一种应用级的激活机制。
A9、如A8所述的方法中，在所述客户端当前处于运行状态时，启用至少一种应用级的激活机制，包括：
在所述客户端当前处于运行状态时，启用所述客户端内的定时轮询机制。
A10、如A9所述的方法中，在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务，包括：
在所述客户端处于运行状态期间，根据所述定时轮询机制，定时激活所述网络请求服务。
A11、如A8-A10任一项所述的方法中，根据客户端的当前状态，启用至少一种激活机制之前，所述方法还包括：
监听所述客户端的状态；
若监听到所述客户端处于非活动状态、活动状态或后台状态，确定所述客户端当前处于运行状态。
A12、如A1-A5以及A8-A10中任一项所述的方法中，所述根据所述被激活的网络请求服务和推送服务，从服务端获取消息，包括：
通过推送通道，接收所述服务端通过所述推送服务推送的第一消息；
通过网络请求通道，接收服务端根据所述被激活的网络请求服务发送的网络请求而返回的第二消息；
通过与所述客户端的当前状态相适应的展示方式，提示所述第一消息和/或第二消息的到达。
本申请实施例还公开了B13、一种消息获取装置，包括：
启用单元，用于根据客户端的当前状态，启用至少一种激活机制；
激活单元，用于在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务；以及
获取单元，用于根据所述被激活的网络请求服务和推送服务，从服务端获取消息。
B14、如B13所述的装置中，所述启用单元具体用于：
在所述客户端处于非运行状态时，启用至少一种系统服务级的激活机制。
B15、如B14所述的装置中，所述启用单元具体用于执行以下至少一种操作：
在所述客户端当前处于非运行状态时，启用操作系统提供的后台获取机制；
在所述客户端当前处于非运行状态时，启用操作系统提供的静默推送机制。
B16、如B15所述的装置中，所述激活单元具体用于执行以下至少一种操作：
在所述客户端处于非运行状态期间，调用所述操作系统提供的后台获取API，以确定激活时间点，并在所述激活时间点激活所述网络请求服务；
在所述客户端处于非运行状态期间，接收所述服务端基于所述静默推送机制通过所述推送服务所推送的静默消息，并在接收到所述静默消息时，激活所述网络请求服务。
B17、如B14所述的装置中，所述激活单元具体用于：
在所述客户端处于非运行状态期间，根据所述至少一种激活机制，将所述客户端从非运行状态变更为运行状态，在所述客户端处于运行状态时，激活所述网络请求服务。
B18、如B14-B17任一项所述的装置，还包括：
第一监听单元，用于监听所述客户端的状态；
第一确定单元，用于在所述第一监听单元监听到所述客户端处于挂起状态时，确定所述客户端当前处于非运行状态。
B19、如B18所述的装置，还包括：
调用单元，用于在所述客户端进入后台状态时，调用操作系统提供的后台任务API，以使所述客户端在指定时间后进入挂起状态。
B20、如B13所述的装置中，所述启用单元具体用于：
在所述客户端当前处于运行状态时，启用至少一种应用级的激活机制。
B21、如B20所述的装置中，所述启用单元具体用于：
在所述客户端当前处于运行状态时，启用所述客户端内的定时轮询机制。
B22、如B21所述的装置中，所述激活单元具体用于：
在所述客户端处于运行状态期间，根据所述定时轮询机制，定时激活所述网络请求服务。
B23、如B20-B22任一项所述的装置，还包括：
第二监听单元，用于监听所述客户端的状态；
第二确定单元，用于在所述第二监听单元监听到所述客户端处于非活动状态、活动状态或后台状态时，确定所述客户端当前处于运行状态。
B24、如B13-B17以及B20-B22中任一项所述的装置中，所述获取单元具体用于：
通过推送通道，接收所述服务端通过所述推送服务推送的第一消息；
通过网络请求通道，接收服务端根据所述被激活的网络请求服务发送的网络请求而返回的第二消息；
通过与所述客户端的当前状态相适应的展示方式，提示所述第一消息和/或第二消息的到达。
本申请实施例还公开了C25、一种终端设备，包括：存储器和处理器；所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时能够实现以下步骤：
根据承载于所述终端设备的客户端的当前状态，启用至少一种激活机制；在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务；以及根据所述被激活的网络请求服务和推送服务，从服务端获取消息。
C26、如C25所述的终端设备中，所述处理器在执行启用操作时，具体用于：
在所述客户端处于非运行状态时，启用至少一种系统服务级的激活机制。
C27、如C26所述的终端设备中，所述处理器具体用于执行以下至少一种操作：
在所述客户端当前处于非运行状态时，启用操作系统提供的后台获取机制；
在所述客户端当前处于非运行状态时，启用操作系统提供的静默推送机制。
C28、如C27所述的终端设备中，所述处理器在执行激活操作时，具体用于执行以下至少一种操作：
在所述客户端处于非运行状态期间，调用所述操作系统提供的后台获取API，以确定激活时间点，并在所述激活时间点激活所述网络请求服务；
在所述客户端处于非运行状态期间，接收所述服务端基于所述静默推送机制通过所述推送服务所推送的静默消息，并在接收到所述静默消息时，激活所述网络请求服务。
C29、如C26所述的终端设备中，所述处理器在执行激活操作时，具体用于：
在所述客户端处于非运行状态期间，根据所述至少一种激活机制，将所述客户端从非运行状态变更为运行状态，在所述客户端处于运行状态时，激活所述网络请求服务。
C30、如C26-C29任一项所述的终端设备中，所述处理器还用于：
监听所述客户端的状态；
在监听到所述客户端处于挂起状态时，确定所述客户端当前处于非运行状态。
C31、如C30所述的终端设备中，所述处理器还用于：
在所述客户端进入后台状态时，调用操作系统提供的后台任务API，以使所述客户端在指定时间后进入挂起状态。
C32、如C25所述的终端设备中，所述处理器在执行启用操作时，具体用于：
在所述客户端当前处于运行状态时，启用至少一种应用级的激活机制。
C33、如C32所述的终端设备中，所述处理器具体用于：
在所述客户端当前处于运行状态时，启用所述客户端内的定时轮询机制。
C34、如C33所述的终端设备中，所述处理器在执行激活操作时，具体用于：
在所述客户端处于运行状态期间，根据所述定时轮询机制，定时激活所述网络请求服务。
C35、如C32-C34任一项所述的终端设备中，所述处理器还用于：
监听所述客户端的状态；
在监听到所述客户端处于非活动状态、活动状态或后台状态时，确定所述客户端当前处于运行状态。
C36、如C25-C29以及C32-C34中任一项所述的终端设备，还包括：
接收器，用于通过推送通道，接收所述服务端通过所述推送服务推送的第一消息；以及通过网络请求通道，接收服务端根据所述被激活的网络请求服务发送的网络请求而返回的第二消息；
所述处理器具体用于：通过所述接收器获取所述第一消息和所述第二消息，并通过与所述客户端的当前状态相适应的展示方式，提示所述第一消息和/或第二消息的到达。
本申请实施例还公开了D37、一种计算机存储介质，存储有以下程序指令：
第一程序指令，用于根据客户端的当前状态，启用至少一种激活机制；
第二程序指令，用于在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务；
第三程序指令，用于根据所述被激活的网络请求服务和推送服务，从服务端获取消息。
D38、如D37所述的计算机存储介质中，所述第一程序指令具体用于：
在所述客户端处于非运行状态时，启用至少一种系统服务级的激活机制。
D39、如D38所述的计算机存储介质中，所述第一程序指令具体用于执行以下至少一种操作：
在所述客户端当前处于非运行状态时，启用操作系统提供的后台获取机制；
在所述客户端当前处于非运行状态时，启用操作系统提供的静默推送机制。
D40、如D39所述的计算机存储介质中，所述第二程序指令具体用于执行以下至少一种操作：
在所述客户端处于非运行状态期间，调用所述操作系统提供的后台获取API，以确定激活时间点，并在所述激活时间点激活所述网络请求服务；
在所述客户端处于非运行状态期间，接收所述服务端基于所述静默推送机制通过所述推送服务所推送的静默消息，并在接收到所述静默消息时，激活所述网络请求服务。
D41、如D38所述的计算机存储介质中，所述第二程序指令具体用于：
在所述客户端处于非运行状态期间，根据所述至少一种激活机制，将所述客户端从非运行状态变更为运行状态，在所述客户端处于运行状态时，激活所述网络请求服务。
D42、如D38-D41任一项所述的计算机存储介质中，所述第一程序指令还用于：
监听所述客户端的状态；在监听到所述客户端处于挂起状态时，确定所述客户端当前处于非运行状态。
D43、如D42所述的计算机存储介质中，所述第一程序指令还用于：
在所述客户端进入后台状态时，调用操作系统提供的后台任务API，以使所述客户端在指定时间后进入挂起状态。
D44、如D37所述的计算机存储介质中，所述第一程序指令具体用于：
在所述客户端当前处于运行状态时，启用至少一种应用级的激活机制。
D45、如D44所述的计算机存储介质中，所述第一程序指令具体用于：
在所述客户端当前处于运行状态时，启用所述客户端内的定时轮询机制。
D46、如D45所述的计算机存储介质中，所述第二程序指令具体用于：
在所述客户端处于运行状态期间，根据所述定时轮询机制，定时激活所述网络请求服务。
D47、如D44-D46任一项所述的计算机存储介质中，所述第一程序指令还用于：
监听所述客户端的状态；
在监听到所述客户端处于非活动状态、活动状态或后台状态时，确定所述客户端当前处于运行状态。
D48、如D37-D41以及D44-D46中任一项所述的计算机存储介质中，所述第三程序指令具体用于：
通过推送通道，接收所述服务端通过所述推送服务推送的第一消息；
通过网络请求通道，接收服务端根据所述被激活的网络请求服务发送的网络请求而返回的第二消息；
通过与所述客户端的当前状态相适应的展示方式，提示所述第一消息和/或第二消息的到达。
Claims (10)
1.一种消息获取方法，其特征在于，包括：
根据客户端的当前状态，启用至少一种激活机制；
在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务；以及
根据所述被激活的网络请求服务和推送服务，从服务端获取消息。
2.根据权利要求1所述的方法，其特征在于，所述根据客户端的当前状态，启用至少一种激活机制，包括：
在所述客户端当前处于非运行状态时，启用至少一种系统服务级的激活机制。
3.根据权利要求2所述的方法，其特征在于，在所述客户端当前处于非运行状态时，启用至少一种系统服务级的激活机制，包括以下至少一种：
在所述客户端当前处于非运行状态时，启用操作系统提供的后台获取机制；
在所述客户端当前处于非运行状态时，启用操作系统提供的静默推送机制。
4.根据权利要求3所述的方法，其特征在于，在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务，包括以下至少一种：
在所述客户端处于非运行状态期间，调用所述操作系统提供的后台获取API，以确定激活时间点，并在所述激活时间点激活所述网络请求服务；
在所述客户端处于非运行状态期间，接收所述服务端基于所述静默推送机制通过所述推送服务所推送的静默消息，并在接收到所述静默消息时，激活所述网络请求服务。
5.根据权利要求1所述的方法，其特征在于，所述根据客户端的当前状态，启用至少一种激活机制，包括：
在所述客户端当前处于运行状态时，启用至少一种应用级的激活机制。
6.根据权利要求5所述的方法，其特征在于，在所述客户端当前处于运行状态时，启用至少一种应用级的激活机制，包括：
在所述客户端当前处于运行状态时，启用所述客户端内的定时轮询机制。
7.根据权利要求6所述的方法，其特征在于，在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务，包括：
在所述客户端处于运行状态期间，根据所述定时轮询机制，定时激活所述网络请求服务。
8.一种消息获取装置，其特征在于，包括：
启用单元，用于根据客户端的当前状态，启用至少一种激活机制；
激活单元，用于在所述客户端处于当前状态期间，根据所述至少一种激活机制，分别激活所述客户端内的网络请求服务；以及
获取单元，用于根据所述被激活的网络请求服务和推送服务，从服务端获取消息。
9.根据权利要求8所述的装置，其特征在于，所述启用单元具体用于：
在所述客户端处于非运行状态时，启用至少一种系统服务级的激活机制。
10.根据权利要求9所述的装置，其特征在于，所述启用单元具体用于执行以下至少一种操作：
在所述客户端当前处于非运行状态时，启用操作系统提供的后台获取机制；
在所述客户端当前处于非运行状态时，启用操作系统提供的静默推送机制。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710202459.3A CN106936919A (zh) | 2017-03-30 | 2017-03-30 | 消息获取方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710202459.3A CN106936919A (zh) | 2017-03-30 | 2017-03-30 | 消息获取方法及装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN106936919A true CN106936919A (zh) | 2017-07-07 |
Family
ID=59425350
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710202459.3A Pending CN106936919A (zh) | 2017-03-30 | 2017-03-30 | 消息获取方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106936919A (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108717653A (zh) * | 2018-05-16 | 2018-10-30 | 北京三快在线科技有限公司 | 外卖订单处理方法、装置、计算机设备及存储介质 |
| CN110445849A (zh) * | 2019-07-23 | 2019-11-12 | 深圳市云充吧科技有限公司 | 一种移动终端低电池电量状态提醒方法 |
| CN110912973A (zh) * | 2019-11-11 | 2020-03-24 | 深圳市云充吧科技有限公司 | 一种移动电源信息提醒方法 |
| CN115334464A (zh) * | 2022-07-18 | 2022-11-11 | 中国电信股份有限公司 | 激活短信发送方法、装置、电子设备及存储介质 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102238108A (zh) * | 2011-06-28 | 2011-11-09 | 北京神州泰岳软件股份有限公司 | 离线消息传输方法 |
| CN103167009A (zh) * | 2011-12-19 | 2013-06-19 | 北京磊友信息科技有限公司 | 一种通过客户端对系统消息进行调用的方法及系统 |
| CN103490981A (zh) * | 2013-09-11 | 2014-01-01 | 曹欢欢 | 一种跨移动应用的消息推送方法和装置 |
| CN103516588A (zh) * | 2012-06-30 | 2014-01-15 | 北京神州泰岳软件股份有限公司 | 一种客户端进行后台处理的方法和系统 |
| CN104349288A (zh) * | 2013-07-25 | 2015-02-11 | 腾讯科技（深圳）有限公司 | 一种消息传输方法及装置 |
| CN106254448A (zh) * | 2016-07-29 | 2016-12-21 | 北京小度信息科技有限公司 | 一种信息获取方法及装置 |
-
2017
- 2017-03-30 CN CN201710202459.3A patent/CN106936919A/zh active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102238108A (zh) * | 2011-06-28 | 2011-11-09 | 北京神州泰岳软件股份有限公司 | 离线消息传输方法 |
| CN103167009A (zh) * | 2011-12-19 | 2013-06-19 | 北京磊友信息科技有限公司 | 一种通过客户端对系统消息进行调用的方法及系统 |
| CN103516588A (zh) * | 2012-06-30 | 2014-01-15 | 北京神州泰岳软件股份有限公司 | 一种客户端进行后台处理的方法和系统 |
| CN104349288A (zh) * | 2013-07-25 | 2015-02-11 | 腾讯科技（深圳）有限公司 | 一种消息传输方法及装置 |
| CN103490981A (zh) * | 2013-09-11 | 2014-01-01 | 曹欢欢 | 一种跨移动应用的消息推送方法和装置 |
| CN106254448A (zh) * | 2016-07-29 | 2016-12-21 | 北京小度信息科技有限公司 | 一种信息获取方法及装置 |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108717653A (zh) * | 2018-05-16 | 2018-10-30 | 北京三快在线科技有限公司 | 外卖订单处理方法、装置、计算机设备及存储介质 |
| CN110445849A (zh) * | 2019-07-23 | 2019-11-12 | 深圳市云充吧科技有限公司 | 一种移动终端低电池电量状态提醒方法 |
| CN110912973A (zh) * | 2019-11-11 | 2020-03-24 | 深圳市云充吧科技有限公司 | 一种移动电源信息提醒方法 |
| CN115334464A (zh) * | 2022-07-18 | 2022-11-11 | 中国电信股份有限公司 | 激活短信发送方法、装置、电子设备及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11956187B2 (en) | Natural language processing for information extraction | |
| US11616801B2 (en) | Systems and methods for an artificial intelligence driven smart template | |
| CN106936919A (zh) | 消息获取方法及装置 | |
| US11676576B2 (en) | Organizational-based language model generation | |
| CN106572173A (zh) | 一种配置信息更新方法、装置和系统 | |
| CN108234636A (zh) | 语音播报方法、装置、系统以及智能播报设备 | |
| US10348761B2 (en) | Systems and methods for situational localization of AIDA | |
| US11790886B2 (en) | System and method for synthesizing automated test cases from natural interactions | |
| CN110362337A (zh) | 应用程序的版本发布方法、装置、设备及存储介质 | |
| US10715549B2 (en) | Systems and methods for AIDA based role models | |
| US11075007B2 (en) | Dynamic selection of virtual agents in a mutli-domain expert system | |
| CN110719222A (zh) | 用于撤回资源的方法、用于退还资源的方法、设备和介质 | |
| CN110275736A (zh) | 获取应用程序的运行数据方法、装置、设备及可读介质 | |
| CN110113391A (zh) | 一种客户端上线方法、装置及一种客户端运行方法、装置 | |
| CN106445479A (zh) | 信息推送方法及装置 | |
| CN107819937A (zh) | 一种备忘信息提醒方法及装置、终端和可读存储介质 | |
| CN107204897A (zh) | 网络链路的故障检测方法及系统 | |
| US20140164523A1 (en) | Automated enabling of instant messaging communications in a client system | |
| CN103326892B (zh) | Web接口的操作方法及装置 | |
| CN110400043A (zh) | 订单分配方法、装置、设备和存储介质 | |
| US20230290348A1 (en) | Coordination and execution of actions on a plurality of heterogenous ai systems during a conference call | |
| CN106210025B (zh) | 应用程序下载量确定方法及装置 | |
| CN107295179A (zh) | 一种短信息显示的方法和装置 | |
| US10990458B2 (en) | Event communication between applications | |
| CN109753610A (zh) | 技能的分享方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20170707 |
|
| RJ01 | Rejection of invention patent application after publication |