背景技术
推送(Push )业务是时下众多终端业务中的一种。 推送业务主要是指终端 与推送业务的建立连接后,会一直保持这个连接, 当服务器有消息向终端发送 时, 可以采用这个连接将消息实时发送到终端上。
以安装有即时通信软件的手机为例, 当启用该软件的推送功能后, 即使该 软件处于关闭状态, 该手机也可以实时接收到其他终端发送来的会话消息, 并 显示在屏幕上。
推送业务的关键点之一是终端需要与服务器之间建立长连接。之所以称为 长连接,是因为终端需要一直保持该长连接与服务器之间的状态是连通的。现 有技术中, 保持长连接的方法主要是发送心跳消息。 具体的, 在应用处理器 ( Application Processor, AP )侧设置推送代理 ( Push Agent )程序。 Push Agent 用于与开启推送功能的应用程序的提供方的服务器(Provider Server )通信, 查询是否有推送消息到达。 当有推送消息到达时,提供推送业务的推送服务器 ( Push Server )会通过长时间保持的线程(Socket ) 向 Push Agent发送推送消 息到达通知。 当一定时间内没有推送消息到达时, Push Agent 需要定期唤醒 AP向 Push Server发送心跳消息来维持 Socket链接。在发送心跳消息的过程中, 还需要调用调制解调器 ( Modem )将终端的数字信号翻译成可沿空口网络传播 的脉冲信号。
由于在硬件层面, AP与 Modem是具有不同功能的两个芯片或结构, 因 此, 现有技术中, 发送心跳消息的方法需要同时采用 AP与 Modem两个硬件 架构执行, 功耗较高, 而心跳消息需要周期性发送, 这进一步导致终端的平均 待机功耗较大, 缩短了终端的待机时间。 发明内容
有鉴于此, 本发明提供一种发送心跳消息的方法及移动终端, 通过在 Modem侧实现 Push Agent, 在发送心跳消息时不再唤醒 AP , 从而解决了终端 发送心跳消息时功耗过大的问题。 其具体方案如下:
根据本申请的第一方面的第一种可能的实现方式,本申请提供一种发送心 跳消息的方法,应用于移动终端中, 所述移动终端至少包括应用处理器和调制 解调器, 所述方法包括:
根据心跳消息发送周期, 确定需要发送心跳消息的第一时间点; 在所述第一时间点到来之前, 判断是否接收到推送消息,得到第一判断结 果;
当所述第一判断结果为否且所述第一时间点到来时,唤醒所述调制解调器 向推送业务的服务器发送心跳消息。
结合第一方面的第二种可能的实现方式,在判断是否接收到推送消息,得 到第一判断结果之后, 所述方法还包括:
当所述第一判断结果为是时,通过所述调制解调器按照预设协议解析接收 到的所述推送消息, 得到所述推送消息对应的内容信息;
根据所述内容信息, 确定所述推送消息对应的应用程序;
将所述推送消息发送至设置在所述应用处理器上的所述应用程序。
结合第一方面的第二种可能的实现方式的第一种具体实施方式,所述确定 所述推送消息对应的应用程序之前, 还包括:
获取所述内容信息中的程序标识信息;
所述确定所述推送消息对应的应用程序, 具体包括:
确定所述程序标识信息对应的应用程序。
结合第一方面的三种可能的实现方式中的任意一种,所述唤醒所述调制解 调器向推送业务的服务器发送心跳消息之后, 还包括:
设置所述调制解调器进入低功耗模式;
按照所述心跳消息发送周期设置第二时间点;
当所述第二时间点到来且在所述第二时间点到来之前没有接收到推送消 息时, 唤醒所述调制解调器向推送业务的服务器发送心跳消息。
结合第一方面的第二种可能的实现方式的任意一种,所述将所述推送消息
发送至设置在所述应用处理器上的所述应用程序之后, 还包括:
设置所述应用处理器进入休眠状态。
结合第一方面的第二种可能的实现方式的任意一种,所述将所述推送消息 发送至设置在所述应用处理器上的所述应用程序之前, 还包括:
当所述应用处理器处于休眠状态时, 唤醒所述应用处理器。 根据本申请的第二方面的第一种可能的实现方式, 本申请提供移动终端, 所述移动终端至少包括应用处理器和调制解调器, 所述移动终端包括:
确定单元, 用于根据心跳消息发送周期,确定需要发送心跳消息的第一时 间点;
判断单元, 用于在所述第一时间点到来之前, 判断是否接收到推送消息, 得到第一判断结果;
唤醒单元, 用于当所述第一判断结果为否且所述第一时间点到来时, 唤醒 所述调制解调器向推送业务的服务器发送心跳消息。
结合第二方面的第二种可能的实现方式, 所述终端还包括: 推送消息解析 单元和发送单元;
所述推送消息解析单元, 用于在判断是否接收到推送消息,得到第一判断 结果之后, 当所述第一判断结果为是时,通过所述调制解调器按照预设协议解 析接收到的所述推送消息, 得到所述推送消息对应的内容信息;
所述确定单元,还用于根据所述内容信息,确定所述推送消息对应的应用 程序;
所述发送单元,用于将所述推送消息发送至设置在所述应用处理器上的所 述应用程序。
结合第二方面的第二种可能的实现方式的第一种具体实施方式,所述终端 还包括:
获取单元, 用于在确定所述推送消息对应的应用程序之前, 获取所述内容 信息中的程序标识信息;
所述确定单元, 具体包括:
确定子单元, 用于确定所述程序标识信息对应的应用程序。
结合第二方面的三种可能的实现方式中的任意一种, 所述终端还包括: 设置单元,用于在所述唤醒所述调制解调器向推送业务的服务器发送心跳 消息之后, 设置所述调制解调器进入低功耗模式;
所述设置单元, 还用于按照所述心跳消息发送周期设置第二时间点; 当所述第二时间点到来且在所述第二时间点到来之前没有接收到推送消 息时, 唤醒所述调制解调器向推送业务的服务器发送心跳消息。
结合第二方面的第二种可能的实现方式中的任意一种, 所述终端还包括: 休眠模式设置单元,用于在将所述推送消息发送至设置在所述应用处理器 上的所述应用程序之后, 设置所述应用处理器进入休眠状态。
结合第二方面的第二种可能的实现方式中的任意一种,所述唤醒单元还用 于:
在所述将所述推送消息发送至设置在所述应用处理器上的所述应用程序 之前, 唤醒处于休眠状态的所述应用处理器。 从上述的技术方案可以看出,本申请实施例的发送心跳消息的方法及移动 终端,通过唤醒调制解调器向推送业务的服务器发送心跳消息。可以不需要唤 醒应用处理器,发送心跳消息的主要功耗为调制解调器的功耗。 与现有技术相 比, 由于不需要唤醒应用处理器, 所以可以降低终端发送心跳消息的功耗, 进 而可以降低终端的平均待机功耗, 延长终端的待机时间。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施 例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地, 下面描述 中的附图仅仅是本发明的一些实施例, 对于本领域普通技术人员来讲,在不付 出创造性劳动的前提下, 还可以根据这些附图获得其他的附图。
图 1为本申请的发送心跳消息的方法实施例 1的流程图;
图 2为本申请的发送心跳消息的方法实施例 2的流程图;
图 3为本申请的移动终端实施例 1的结构图;
图 4为本申请的系统架构示意图;
图 5为本申请的计算节点的结构图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清 楚、 完整地描述, 显然, 所描述的实施例仅仅是本发明一部分实施例, 而不是 全部的实施例。基于本发明中的实施例, 本领域普通技术人员在没有做出创造 性劳动前提下所获得的所有其他实施例, 都属于本发明保护的范围。 本申请的发送心跳消息的方法,应用于移动终端中。 所述移动终端可以包 括手机,平板电脑等。所述移动终端具有联网功能,可以通过无线保真(wireless fidelity, WiFi )方式或者第三代移动通信技术( 3rd-generation, 3G )方式接收 或上传数据。 所述移动终端至少包括应用处理器( Application Processor, AP ) 和调制解调器(Modem )。 所述调制解调器, 用于把移动终端的数字信号翻译 成可沿空口网络传播的脉冲信号,同时也可以把空口无线网络的脉冲信号翻译 成移动终端可以识别的数字信号。 所述应用处理器是在低功耗 CPU的基石出上 扩展音视频功能和专用接口的超大规模集成电路。所述应用处理器主要负责应 用程序的运行。 图 1为本申请的发送心跳消息的方法实施例 1的流程图。如图 1所示, 该 方法可以包括:
步骤 101 :根据心跳消息发送周期,确定需要发送心跳消息的第一时间点; 所述心跳消息发送周期可以根据实际需求进行设定, 可以是几秒,也可以 是几十秒。假设上一次发送心跳消息的时间为 10点 10分整, 心跳消息发送周 期为 30秒,则可以确定 10点 10分零 30秒为需要发送心跳消息的第一时间点。
所述第一时间点用于表示从开始执行步骤 101的时刻起,经过最短的时长 所到达的需要发送心跳消息的时间点。 同样以上面的 4叚设为例, 4叚设上一次发 送心跳消息的时间为 10点 10分整, 心跳消息发送周期为 30秒, 则可以确定 10点 10分零 30秒为需要发送心跳消息的时间点, 10点 11分整也是需要发送 心跳消息的时间点。在本实施例中, 步骤 101是在上一次心跳消息发送完毕或 者上一次推送消息接收完毕以后开始执行的。假设在 10点 10分整之后立即执 行步骤 101 , 则可以确定经过最短的时长所到达的需要发送心跳消息的时间点 为 10点 10分零 30秒。 即 10点 10分零 30秒为第一时间点。
步骤 102: 在所述第一时间点到来之前, 判断是否接收到推送消息, 得到 第一判断结果;
确定第一时间点之后, 可以采用计时器进行计时, 以便监测第一时间点是 否到来。在计时过程中, 可以实时判断是否接收到推送业务的服务器发送来的 推送消息。 如果接收到推送消息, 则第一判断结果为是; 如果没有接收到推送 消息, 则第一判断结果为否。
当接收到推送消息后, 可以将推送消息发送至设置在 AP上的对应的应用 程序, 由对应的应用程序进行处理并进行推送显示。
当没有接收到推送消息时, 则需要向推送业务的服务器发送心跳消息, 以 便保持与推送业务的服务器的连接。
步骤 103: 当所述第一判断结果为否且所述第一时间点到来时, 唤醒所述 调制解调器向推送业务的服务器发送心跳消息。
本步骤中, 唤醒的是调制解调器, 而不是应用处理器。 所述调制解调器在 唤醒之前处于低功耗模式。 唤醒所述调制解调器之后, 所述调制解调器可以向 推送业务的服务器发送心跳消息, 以便保持与推送业务的服务器的连接。
综上所述, 本实施例的发送心跳消息的方法是, 通过确定需要发送心跳消 息的第一时间点; 在所述第一时间点到来之前, 判断是否接收到推送消息; 当 没有接收到推送消息时, 唤醒调制解调器向推送业务的服务器发送心跳消息。 现有技术中发送心跳消息的方法需要唤醒应用处理器,通过应用处理器发送心 跳消息至调制解调器,再通过调制解调器将心跳消息发送至服务器,发送心跳 消息的主要功耗为应用处理器与调制解调器两者的功耗之和。而本实施例中的 方法不需要唤醒应用处理器, 发送心跳消息的主要功耗为调制解调器的功耗。
与现有技术相比, 由于不需要唤醒应用处理器, 所以本实施例的方法可以 降低终端发送心跳消息的功耗, 进而可以降低终端的平均待机功耗,延长终端 的待机时间。
需要说明的是,本申请中各个实施例中的应用处理器与调制解调器均可以 是单独的两个芯片,也可以是同一芯片中的不同硬件结构。本申请中各个实施 例的方法对应的程序均在调制解调器一侧实现。 具体的, 所述程序可以采用 C 语言编写, 并保存在调制解调器的存储空间中。
图 2为本申请的发送心跳消息的方法实施例 2的流程图。该流程可以包括: 步骤 201 :根据心跳消息发送周期,确定需要发送心跳消息的第一时间点; 步骤 202: 在所述第一时间点到来之前, 判断是否接收到推送消息, 得到 第一判断结果; 当所述第一判断结果为否时, 执行步骤 203 ; 当所述第一判断 结果为是时, 执行步骤 204。
步骤 203: 当所述第一判断结果为否且所述第一时间点到来时, 唤醒所述 调制解调器向推送业务的服务器发送心跳消息。
心跳消息发送完毕后可以执行步骤 209。
步骤 204: 当所述第一判断结果为是时, 通过所述调制解调器按照预设协 议解析接收到的所述推送消息, 得到所述推送消息对应的内容信息;
所述预设协议, 可以是第三代合作伙伴项目 (3GPP )协议, 也可以是长 期演进(Long Term Evolution, LTE )协议。 这取决于终端与发送推送消息的 服务器之间采用的预先设定的协议的类型。
所述内容信息至少可以包括应用程序的程序标识信息, 具体可以是 id号。 不同的应用程序对应不同的 id号。
步骤 205: 根据所述内容信息, 确定所述推送消息对应的应用程序; 具体的, 可以获取所述内容信息中的程序标识信息;
确定所述程序标识信息对应的应用程序。
步骤 206: 唤醒处于休眠状态的所述应用处理器。
因为需要将推送消息发送至设置在所述应用处理器上的所述应用程序,所 以需要唤醒所述应用处理器, 由应用处理器运行所述应用程序后,对所述推送 消息进行处理。
步骤 207: 将所述推送消息发送至设置在所述应用处理器上的所述应用程 序。
所述应用程序可以按照程序本身设定的方式对推送消息进行处理。所述处 理可以包括:在指定的位置显示所述推送消息;生成对于所述应用程序的链接, 以便用户点击屏幕上显示的所述推送消息时, 可以启动所述应用程序。
步骤 208: 设置所述应用处理器进入休眠状态。
推送消息发送完毕后, 可以设置所述应用处理器进入休眠状态。休眠状态
下, 可以降低所述应用处理器的功耗。
步骤 209: 设置所述调制解调器进入低功耗模式;
推送消息发送完毕或者心跳消息发送完毕后,还可以设置所述调制解调器 进入低功耗模式。 在低功耗模式下, 所述调制解调器的功耗较低, 并且可以按 照心跳消息发送周期被定期唤醒, 唤醒后可以发送心跳消息。
步骤 210: 按照所述心跳消息发送周期设置第二时间点, 以便在所述第二 时间点到来且在所述第二时间点到来之前没有接收到推送消息时,唤醒所述调 制解调器向推送业务的服务器发送心跳消息。
当推送消息发送完毕或者心跳消息发送完毕后,均可以按照所述心跳消息 发送周期重新开始计时, 将计时结束后到达的时间点设置为第二时间点。
本实施例中,在应用处理器对所述推送消息处理完毕之后, 可以将所述应 用处理器设置为休眠模式, 降低应用处理器的功耗; 在调制解调器发送完毕心 跳消息后,可以将调制解调器设置为低功耗模式,进一步降低移动终端的功耗, 延长待机时间。 本申请还公开了一种移动终端。 所述移动终端可以是手机或者平板电脑。 图 3为本申请的移动终端实施例 1的结构图。如图 3所示, 该移动终端可以包 括:
确定单元 301 , 用于根据心跳消息发送周期, 确定需要发送心跳消息的第 一时间点;
判断单元 302, 用于在所述第一时间点到来之前, 判断是否接收到推送消 息, 得到第一判断结果;
唤醒单元 303 , 用于当所述第一判断结果为否且所述第一时间点到来时, 唤醒所述调制解调器向推送业务的服务器发送心跳消息。
与现有技术相比, 由于不需要唤醒应用处理器, 所以本实施例的移动终端 可以降低终端发送心跳消息的功耗, 进而可以降低终端的平均待机功耗,延长 终端的待机时间。
实际应用中, 所述终端还可以包括: 推送消息解析单元和发送单元; 所述推送消息解析单元, 用于在判断是否接收到推送消息,得到第一判断
结果之后, 当所述第一判断结果为是时,通过所述调制解调器按照预设协议解 析接收到的所述推送消息, 得到所述推送消息对应的内容信息;
所述确定单元 301 , 还用于根据所述内容信息, 确定所述推送消息对应的 应用程序;
所述发送单元,用于将所述推送消息发送至设置在所述应用处理器上的所 述应用程序。
所述终端还可以包括:
获取单元, 用于在确定所述推送消息对应的应用程序之前, 获取所述内容 信息中的程序标识信息;
所述确定单元 301 , 具体包括:
确定子单元, 用于确定所述程序标识信息对应的应用程序。
所述终端还可以包括:
设置单元,用于在所述唤醒所述调制解调器向推送业务的服务器发送心跳 消息之后, 设置所述调制解调器进入低功耗模式;
所述设置单元, 还用于按照所述心跳消息发送周期设置第二时间点; 当所述第二时间点到来且在所述第二时间点到来之前没有接收到推送消 息时, 唤醒所述调制解调器向推送业务的服务器发送心跳消息。
实际应用中, 所述终端还可以包括:
休眠模式设置单元,用于在将所述推送消息发送至设置在所述应用处理器 上的所述应用程序之后, 设置所述应用处理器进入休眠状态。 实际应用中, 所 述唤醒单元 303还用于:
在所述将所述推送消息发送至设置在所述应用处理器上的所述应用程序 之前, 唤醒处于休眠状态的所述应用处理器。
图 4为本申请的系统架构示意图。 如图 4所示, 该移动终端可以包括: 应用处理器 401 , 调制解调器 402, 推送服务器 403和应用程序提供方服 务器 404。 所述调制解调器 402中设置有推送代理程序 4021。
其中, 应用处理器 401 , 用于执行设置在应用处理器 401上的应用程序。 调制解调器 402可以执行设置在调制解调器 402上的推送代理程序 ( Push Agent ) 4021。
具体地, 所述推送代理程序 4021具体可以包括:
确定单元 301 , 用于根据心跳消息发送周期, 确定需要发送心跳消息的第 一时间点;
判断单元 302, 用于在所述第一时间点到来之前, 判断是否接收到推送消 息, 得到第一判断结果;
唤醒单元 303 , 用于当所述第一判断结果为否且所述第一时间点到来时, 唤醒所述调制解调器向推送业务的服务器发送心跳消息。
推送代理程序 4021中各单元的具体实现参见图 3所示实施例中的相应单 元, 在此不赘述„
实际应用中,可以在应用处理器 401与调制解调器 402之间建立一个通信 接口。 应用程序可以通过该通信接口将自身的推送业务在推送代理程序 4021 上进行注册。 调制解调器 402侧可以实现一个精简的 TCP/IP协议栈, 调制解 调器 402侧的推送代理程序 4021可以通过调制解调器 402侧的 TCP/IP协议栈 维持与远端推送服务器 403的连接, 处理推送数据 (即推送消息 )并将数据通 过应用处理器 401与调制解调器 402的接口发送给对应的应用程序。
当没有推送消息到来时, 调制解调器 402侧的推送代理程序 4021可以定 期唤醒调制解调器 402, 而不必唤醒应用处理器 401 , 减少了应用处理器 401 唤醒这一环节, 节省了唤醒应用处理器 401后应用处理器 401消耗的电流。
当有推送消息到来时, 消息首先从调制解调器 402侧的 3GPP协议栈解析 出,推送代理程序 4021可以使用调制解调器 402侧的 TCP/IP协议栈解析出推 送消息的内容信息, 再根据内容信息确定应该把推送消息发送给哪个应用程 序。
图 5为本申请的计算节点的结构图。 如图 5所示, 计算节点 700包括: 处理器(processor ) 710, 通信接口 ( Communications Interface ) 720, 存 储器(memory ) 730, 总线 740。
处理器 710,通信接口 720,存储器 730通过总线 740完成相互间的通信。 处理器 710, 用于执行程序 732。
具体地,程序 732可以包括程序代码,所述程序代码包括计算机操作指令。 处理器 710 可能是一个中央处理器 CPU , 或者是特定集成电路 ASIC
( Application Specific Integrated Circuit ),或者是被配置成实施本申请实施例的 一个或多个集成电路。
存储器 730, 用于存放程序 732。 存储器 730可能包含高速 RAM存储器, 也可能还包括非易失性存储器( non-volatile memory ), 例如至少一个磁盘存储 器。 程序 732具体可以包括:
确定单元 301 , 用于根据心跳消息发送周期, 确定需要发送心跳消息的第 一时间点;
判断单元 302, 用于在所述第一时间点到来之前, 判断是否接收到推送消 息, 得到第一判断结果;
唤醒单元 303 , 用于当所述第一判断结果为否且所述第一时间点到来时, 唤醒所述调制解调器向推送业务的服务器发送心跳消息。
程序 732中各单元的具体实现参见图 3所示实施例中的相应单元,在此不 贅述。 本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是 与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于 实施例公开的移动终端而言, 由于其与实施例公开的方法相对应, 所以描述的 比较简单, 相关之处参见方法部分说明即可。
专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例 的单元及算法步骤,能够以电子硬件或者电子硬件与计算机软件相结合的方式 来实现。 为了清楚地说明部分硬件和软件的可互换性,在上述说明中已经按照 功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软硬件结 合的方式来执行,取决于技术方案的特定应用和设计约束条件。 专业技术人员 应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处 理器执行的软件模块, 或者二者的结合来实施。软件模块可以置于随机存储器 ( RAM )、内存、只读存储器 ( ROM )、电可编程 ROM、电可擦除可编程 ROM, 寄存器、 硬盘、 可移动磁盘、 CD-ROM, 或技术领域内所公知的任意其它形式
的存储介质中。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本 发明。 对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见 的, 本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下, 在 其它实施例中实现。 因此, 本发明将不会被限制于本文所示的这些实施例, 而 是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
+