CN104703146A - 信息推送方法、客户端及系统 - Google Patents

Abstract

本发明涉及一种信息推送方法、客户端及系统，其方法包括：客户端从服务端获取业务消息；判断业务消息的类型，根据业务消息的类型调整心跳包发送策略；基于调整后的心跳包发送策略保持与服务端之间的网络链路连接，以供业务消息的推送操作。本发明在满足移动终端上各种应用业务消息的推送需求的同时，可以节省移动终端的电量。

Description

信息推送方法、客户端及系统

技术领域

本发明涉及移动互联网技术领域，尤其涉及一种信息推送方法、客户端及系统。

背景技术

随着移动互联网技术的发展，信息推送技术已成为各种平台（比如Android平台）中应用（APP）上很重要的部分。目前的信息推送方案有多种，比如极光推送，还有各个互联网应用产品自身业务私有的推送模块，比如网易新闻、腾讯新闻的消息推送等。现有的这些推送方案的实现都是通过心跳包（heartbeat）与推送后台保持TCP长连接，以此来接收推送消息。

但是，现有的信息推送方案存在的缺陷是：耗费终端电量较多，而对于电量有限的移动终端（比如Android手机）而言，则因应用消耗电量大而无法满足用户长时间使用应用的需求。

发明内容

本发明实施例提供一种信息推送方法、客户端及系统，旨在满足业务推送需求的同时，节省终端电量。

本发明实施例提出一种信息推送方法，包括：

客户端从服务端获取业务消息；

判断所述业务消息的类型，当所述业务消息的类型为实时类消息时，调整心跳包的发送间隔为第一预设时间段，并在第二预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第一预设时间段大于所述基准时间间隔，且小于所述第二预设时间段；基于所述调整后的心跳包发送策略保持与所述服务端之间的网络链路连接，以供业务消息的推送操作。

本发明实施例还提出一种信息推送客户端，包括：

获取模块，用于从服务端获取业务消息；

调整模块，用于判断所述业务消息的类型，当所述业务消息的类型为实时类消息时，调整心跳包的发送间隔为第一预设时间段，并在第二预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第一预设时间段大于所述基准时间间隔，且小于所述第二预设时间段；

推送操作模块，用于基于调整后的心跳包发送策略保持与所述服务端之间的网络链路连接，以供业务消息的推送操作。

本发明实施例还提出一种信息推送系统，包括：客户端和服务端，其中：

所述客户端为如上所述的客户端；

所述服务端用于向所述客户端下发业务消息；基于客户端根据业务消息的类型调整的心跳包发送策略，与所述客户端保持网络链路连接，进行业务消息的推送操作。

本发明实施例提出的一种信息推送方法、客户端及系统，客户端在从服务端获取到业务消息后，判断业务消息的类型，根据业务消息的类型调整心跳包发送策略；基于该心跳包发送策略保持与服务端之间的网络链路连接，以供业务消息的推送操作，由此可以更好的满足移动终端上各种应用业务消息的推送需求，并节省了移动终端的电量。

附图说明

图1是本发明信息推送方法第一实施例的流程示意图；

图2是本发明实施例中根据所述业务消息的类型调整心跳包发送策略的流程示意图；

图3是本发明信息推送方法第二实施例的流程示意图；

图4是本发明信息推送方法第三实施例的流程示意图；

图5是本发明信息推送客户端第一实施例的功能模块示意图；

图6是本发明信息推送客户端第二实施例的功能模块示意图；

图7是本发明信息推送系统较佳实施例的结构示意图。

为了使本发明的技术方案更加清楚、明了，下面将结合附图作进一步详述。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，本发明第一实施例提出一种信息推送方法，包括：

步骤S101，客户端从服务端获取业务消息；

本实施例方案涉及的信息推送系统包括客户端和服务端，以Android手机为例，客户端部分主要负责手机推送模块SDK，包括Android Servie的管理、心跳包线程的管理、手机上推送消息的展示，以及和服务端交互的流程处理，包括发送注册包、和服务端建立长连接、发送心跳包、推送消息回报等。

服务端部分主要负责长连接的请求管理、业务逻辑处理、推送消息、统计信息落地等。此外还包括PUSH WEB管理后台和应用业务（比如游戏业务）接入管理等。

由于现有的终端应用进行业务消息推送时，为保持客户端与服务端之间的网络链路连接（比如TCP长连接），通常采用固定的心跳包发送策略，导致手机终端耗电量较大。

本实施例考虑到，根据服务端推送的业务消息的类型不同，可以允许心跳包线程具有不同的休眠时间，因此，本实施例采用以下解决方案：基于客户端获取的服务端下发的业务消息的类型，动态调整心跳包发送策略，在此策略的基础上保持客户端与服务端之间的网络链路连接，供业务消息的推送操作，以此节省手机终端的电量。

具体地，以Android手机为例，手机客户端在启动后，会生成一个AndroidService，然后与服务端通过注册包建立连接。之后，客户端启动心跳包线程，向服务端发送心跳包与服务端保持网络链路连接。通过该网络链路连接，获取应用业务推送消息。

其中，根据手机终端网络类型的不同，网络链路连接也不同。通常，手机网络类型主要有三种：wifi、net，还有小一部分wap网络。由于wifi、net网络都支持长连接，而wap网络不支持长连接，因此，当手机网络类型为wifi、net时，客户端与服务端之间的网络链路连接为长连接，客户端获取的业务消息为服务端推送的业务消息。

当手机网络类型为wap网络时，客户端与服务端之间的网络链路连接不为长连接，则推送方案需要改变成拉（polling）的方式，由客户端主动从服务端拉取业务消息。

由此，客户端根据网络类型的不同，需要在上述两种连接状态中切换，在切换过程中，需要进行推送流程的切换。Android系统中通过注册网络连接状态BroadcastReceiver，来接收网络变化广播通知，以此调整网络链路连接。

步骤S102，根据所述业务消息的类型调整心跳包发送策略；

本实施例可以根据不同的业务消息类型调整心跳包发送策略，以节省手机电量。

其中，业务消息类型可以分为实时类消息、设定时间类消息以及指令类消息等。

以游戏营销业务为例，在游戏营销业务中，推送消息分为游戏实时消息、游戏营销活动消息、推送指令消息等类型。

游戏实时消息是指游戏最新的版本更新消息和道具打折消息以及其它实时消息。

游戏营销活动消息是指游戏运营策划的一些活动消息，其具有固定的推送时间。

推送指令消息包括推送关闭消息，或者临时下发的推送策略消息等。

对于不同的业务消息类型采用不同的心跳包发送间隔。比如，对于实时类消息，按照推送消息不能过于频繁的约定和经验数据，在接收到该实时类消息后接下来一段时间（比如60分钟）内再有实时类消息的概率较小，可以调整心跳包的发送间隔大于客户端与服务端约定的基准时间间隔，从而节省了网络连接耗费和CPU运行耗费的手机电量；然后在设定的时间段后，恢复心跳包发送间隔为基准时间间隔。

对于设定时间类消息，由于消息推送时间已预先设定，同样可以调整心跳包的发送间隔大于客户端与服务端约定的基准时间间隔，从而可以节省网络连接耗费和CPU运行耗费的手机电量。

对于指令类消息，以推送关闭消息为例，当客户端接收到该推送指令消息后，则会停止心跳包的发送，关闭与服务端之间的网络链路连接，节省了网络连接耗费的手机电量。

步骤S103，基于所述调整后的心跳包发送策略保持与所述服务端之间的网络链路连接，以供业务消息的推送操作。

其中，消息推送系统在进行业务消息的推送操作时，需要根据网络链路连接的类型采取相应的推送方案，其中：

当所述网络链路连接为长连接时，所述客户端接收所述服务端推送的业务消息；

当所述网络链路连接不为长连接时，所述客户端从所述服务端拉取业务消息。

此外，当所述业务消息的类型为设定时间类消息时，客户端可以在该设定时间前预定时间拉取所述业务消息。

另外，客户端会实时监测网络类型变化，在监测到网络类型变化后，切换与所述服务端之间的网络链接状态，以确保业务消息的正常推送。

本实施例通过上述方案，客户端在从服务端获取到业务消息后，根据业务消息的类型调整心跳包发送策略；基于该心跳包发送策略保持与服务端之间的网络链路连接，以供业务消息的推送操作，由此可以更好的满足移动终端上各种应用业务消息的推送需求，并节省了移动终端的电量。

更为具体地，如图2所示，作为一种实施方式，上述步骤S102可以包括：

步骤S1021，判断业务消息的类型；当所述业务消息的类型为实时类消息时，进入步骤S1022；当业务消息的类型为设定时间类消息时，进入步骤S1023；当所述业务消息的类型为指令类消息时，进入步骤S1024；

步骤S1022，调整心跳包的发送间隔为第一预设时间段，并在第二预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第一预设时间段大于所述基准时间间隔，且小于所述第二预设时间段。

步骤S1023，调整心跳包的发送间隔为第三预设时间段，并在第四预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第三预设时间段大于所述基准时间间隔，且小于所述第四预设时间段。

步骤S1024，停止心跳包线程。

上述第一预设时间段与第三预设时间段可以相同，也可以不相同；上述第二预设时间段与第四预设时间段可以相同，也可以不相同。

以游戏营销业务为例，并设定客户端与服务端约定的基准心跳包间隔为60秒。

当客户端收到的推送消息为游戏实时类消息时，按照推送消息不能过于频繁的约定和经验数据，接下来60分钟内再有实时类消息的概率较小，因此，可以调整心跳包发送间隔为120秒，使得心跳包线程休眠120秒，以节省网络连接耗费和CPU运行耗费的手机电量。在60分钟之后，再恢复心跳包发送间隔为基准发送间隔60秒。

当收到的推送消息类型为游戏活动列表消息时，记录下活动时间，推送方案变化为主动拉取（polling）方式，通过定时器在活动时间前预定时间去拉取消息通知用户。同时，心跳包发送间隔调整为120秒，使得心跳包线程休眠120秒，从而节省了网络连接耗费和CPU运行耗费的手机电量。

当收到的推送消息为指令消息时，如果是关闭推送指令，则断开长连接，停止心跳包线程，停止Android Service，以节省网络连接耗费的手机电量。

此外，在关机或者用户关闭推送开关时，关闭推送流程，以节省网络连接耗费的手机电量。用户可以选择默认设置为晚间22：00到早间8：00，关闭推送流程，以节省网络连接耗费的手机电量。

由此，通过以上动态策略，在满足业务推送需求，节省手机流量的同时，可以较好的节省手机电量。

需要说明的是，本实施例中根据业务消息类型调整心跳包发送策略的方案可以不限于上述几种业务类型对应的应用场景，在其他实施例中，还可以采用更多或更细分的策略来调整心跳包策略。此外，本实施例中根据业务消息类型调整心跳包发送策略的方案可以由客户端侧定义，也可以由服务端下发给客户端，具体可以在客户端与服务端通过注册包建立连接后，服务端将推送策略下发给客户端，由客户端对接收的推送策略进行解析，获取心跳包调整策略。

如图3所示，本发明第二实施例提出一种信息推送方法，在上述第一实施例的基础上，在上述步骤S101之前还包括：

步骤S90，客户端与服务端通过注册包建立连接；

步骤S100，启动心跳包线程与所述服务端保持网络链路连接。

本实施例与上述第一实施例的区别在于，本实施例还包括启动心跳包线程与服务端建立初始网络链路连接的方案。

具体地，以Android手机为例，手机客户端在启动后，生成一个AndroidService，然后与服务端通过注册包建立连接。之后，客户端启动心跳包线程，向服务端发送心跳包与服务端保持网络链路连接。通过该网络链路连接，客户端获取应用业务推送消息。

其中，根据手机终端网络类型的不同，网络链路连接也不同。通常，手机网络类型主要有三种：wifi、net，还有小一部分wap网络。由于wifi、net网络都支持长连接，而wap网络不支持长连接，因此，当手机网络类型为wifi、net时，客户端与服务端之间的网络链路连接为长连接，客户端获取的业务消息为服务端推送的业务消息。

当手机网络类型为wap网络时，客户端与服务端之间的网络链路连接不为长连接，则推送方案需要改变成拉（polling）的方式，由客户端主动从服务端拉取业务消息。

由此，客户端根据网络类型的不同，需要在上述两种连接状态中切换，在切换过程中，需要进行推送流程的切换。Android系统中通过注册网络连接状态BroadcastReceiver，来接收网络变化广播通知，以此调整网络链路连接。

由此，通过建立的初始网络链路连接，可以使得客户端获取到系统推送的业务消息。

本实施例通过上述方案，客户端通过启动心跳包线程与服务端建立初始网络链路连接，基于该初始网络链路连接获取系统推送的业务消息，在从服务端获取到业务消息后，根据业务消息的类型调整心跳包发送策略；基于该心跳包发送策略保持与服务端之间的网络链路连接，以供业务消息的推送操作，由此可以更好的满足移动终端上各种应用业务消息的推送需求，并节省了移动终端的电量。

如图4所示，本发明第三实施例提出一种信息推送方法，在上述第二实施例的基础上，在上述步骤S90之后还包括：

步骤S80，所述客户端接收所述服务端下发的推送策略。

本实施例与上述第二实施例的区别在于，本实施例中，心跳包发送策略的调整方案由服务端下发给客户端，具体可以在客户端与服务端通过注册包建立连接后，服务端将推送策略下发给客户端，由客户端对接收的推送策略进行解析，获取心跳包调整策略。后续，当客户端获取到系统推送的业务消息后，即可以根据业务消息的类型采用相应的心跳包调整策略，以节省手机电量。

如图5所示，本发明第一实施例提出一种信息推送客户端，包括：获取模块201、调整模块202及推送操作模块203，其中：

获取模块201，用于从服务端获取业务消息；

调整模块202，用于根据所述业务消息的类型调整心跳包发送策略；

推送操作模块203，用于基于所述调整后的心跳包发送策略保持与所述服务端之间的网络链路连接，以供业务消息的推送操作。

本实施例方案涉及的信息推送系统包括客户端和服务端，以Android手机为例，客户端部分主要负责手机推送模块SDK，包括Android Servie的管理、心跳包线程的管理、手机上推送消息的展示，以及和服务端交互的流程处理，包括发送注册包、和服务端建立长连接、发送心跳包、推送消息回报等。

服务端部分主要负责长连接的请求管理、业务逻辑处理、推送消息、统计信息落地等。此外还包括PUSH WEB管理后台和应用业务（比如游戏业务）接入管理等。

由于现有的终端应用进行业务消息推送时，为保持客户端与服务端之间的网络链路连接（比如TCP长连接），通常采用固定的心跳包发送策略，导致手机终端耗电量较大。

本实施例考虑到，根据服务端推送的业务消息的类型不同，可以允许心跳包线程具有不同的休眠时间，因此，本实施例采用以下解决方案：基于客户端获取的服务端下发的业务消息的类型，动态调整心跳包发送策略，在此策略的基础上保持客户端与服务端之间的网络链路连接，供业务消息的推送操作，以此节省手机终端的电量。

具体地，以Android手机为例，手机客户端在启动后，会生成一个AndroidService，然后与服务端通过注册包建立连接。之后，客户端启动心跳包线程，向服务端发送心跳包与服务端保持网络链路连接。获取模块201通过该网络链路连接，获取应用业务推送消息。

其中，根据手机终端网络类型的不同，网络链路连接也不同。通常，手机网络类型主要有三种：wifi、net，还有小一部分wap网络。由于wifi、net网络都支持长连接，而wap网络不支持长连接，因此，当手机网络类型为wifi、net时，客户端与服务端之间的网络链路连接为长连接，客户端获取的业务消息为服务端推送的业务消息。

当手机网络类型为wap网络时，客户端与服务端之间的网络链路连接不为长连接，则推送方案需要改变成拉（polling）的方式，由客户端主动从服务端拉取业务消息。

由此，客户端根据网络类型的不同，需要在上述两种连接状态中切换，在切换过程中，需要进行推送流程的切换。Android系统中通过注册网络连接状态BroadcastReceiver，来接收网络变化广播通知，以此调整网络链路连接。

本实施例可以根据不同的业务消息类型调整心跳包发送策略，以节省手机电量。

其中，业务消息类型可以分为实时类消息、设定时间类消息以及指令类消息等。

以游戏营销业务为例，在游戏营销业务中，推送消息分为游戏实时消息、游戏营销活动消息、推送指令消息等类型。

游戏实时消息是指游戏最新的版本更新消息和道具打折消息以及其它实时消息。

游戏营销活动消息是指游戏运营策划的一些活动消息，其具有固定的推送时间。

推送指令消息包括推送关闭消息，或者临时下发的推送策略消息等。

调整模块202对于不同的业务消息类型采用不同的心跳包发送间隔。比如，对于实时类消息，按照推送消息不能过于频繁的约定和经验数据，在接收到该实时类消息后接下来一段时间（比如60分钟）内再有实时类消息的概率较小，可以调整心跳包的发送间隔大于客户端与服务端约定的基准时间间隔，从而节省了网络连接耗费和CPU运行耗费的手机电量；然后在设定的时间段后，恢复心跳包发送间隔为基准时间间隔。

对于设定时间类消息，由于消息推送时间已预先设定，同样可以调整心跳包的发送间隔大于客户端与服务端约定的基准时间间隔，从而可以节省网络连接耗费和CPU运行耗费的手机电量。

对于指令类消息，以推送关闭消息为例，当客户端接收到该推送指令消息后，则会停止心跳包的发送，关闭与服务端之间的网络链路连接，节省了网络连接耗费的手机电量。

后续，客户端推送操作模块203，基于所述调整后的心跳包发送策略保持与所述服务端之间的网络链路连接，通过该网络链路连接实现业务消息的推送操作。

其中，消息推送系统在进行业务消息的推送操作时，需要根据网络链路连接的类型采取相应的推送方案，其中：

当所述网络链路连接为长连接时，所述客户端接收所述服务端推送的业务消息；

当所述网络链路连接不为长连接时，所述客户端从所述服务端拉取业务消息。

此外，当所述业务消息的类型为设定时间类消息时，客户端可以在该设定时间前预定时间拉取所述业务消息。

另外，客户端会实时监测网络类型变化，在监测到网络类型变化后，切换与所述服务端之间的网络链接状态，以确保业务消息的正常推送。

本实施例通过上述方案，客户端在从服务端获取到业务消息后，根据业务消息的类型调整心跳包发送策略；基于该心跳包发送策略保持与服务端之间的网络链路连接，以供业务消息的推送操作，由此可以更好的满足移动终端上各种应用业务消息的推送需求，并节省了移动终端的电量。

更为具体地，所述调整模块202，还用于当所述业务消息的类型为实时类消息时，调整心跳包的发送间隔为第一预设时间段，并在第二预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第一预设时间段大于所述基准时间间隔，且小于所述第二预设时间段；当所述业务消息的类型为设定时间类消息时，调整心跳包的发送间隔为第三预设时间段，并在第四预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第三预设时间段大于所述基准时间间隔，且小于所述第四预设时间段；以及当所述业务消息的类型为指令类消息时，停止心跳包线程。

上述第一预设时间段与第三预设时间段可以相同，也可以不相同；上述第二预设时间段与第四预设时间段可以相同，也可以不相同。

以游戏营销业务为例，并设定客户端与服务端约定的基准心跳包间隔为60秒。

当客户端收到的推送消息为游戏实时类消息时，按照推送消息不能过于频繁的约定和经验数据，接下来60分钟内再有实时类消息的概率较小，因此，可以调整心跳包发送间隔为120秒，使得心跳包线程休眠120秒，以节省网络连接耗费和CPU运行耗费的手机电量。在60分钟之后，再恢复心跳包发送间隔为基准发送间隔60秒。

当收到的推送消息类型为游戏活动列表消息时，记录下活动时间，推送方案变化为主动拉取（polling）方式，通过定时器在活动时间前预定时间去拉取消息通知用户。同时，心跳包发送间隔调整为120秒，使得心跳包线程休眠120秒，从而节省了网络连接耗费和CPU运行耗费的手机电量。

当收到的推送消息为指令消息时，如果是关闭推送指令，则断开长连接，停止心跳包线程，停止Android Service，以节省网络连接耗费的手机电量。

此外，在关机或者用户关闭推送开关时，关闭推送流程，以节省网络连接耗费的手机电量。用户可以选择默认设置为晚间22：00到早间8：00，关闭推送流程，以节省网络连接耗费的手机电量。

由此，通过以上动态策略，在满足业务推送需求，节省手机流量的同时，可以较好的节省手机电量。

需要说明的是，本实施例中根据业务消息类型调整心跳包发送策略的方案可以不限于上述几种业务类型对应的应用场景，在其他实施例中，还可以采用更多或更细分的策略来调整心跳包策略。

此外，本实施例中根据业务消息类型调整心跳包发送策略的方案可以由客户端侧定义，也可以由服务端下发给客户端，具体可以在客户端与服务端通过注册包建立连接后，服务端将推送策略下发给客户端，由客户端对接收的推送策略进行解析，获取心跳包调整策略。

如图6所示，本发明第二实施例提出一种信息推送客户端，在上述第一实施例的基础上，还包括：

启动模块200，用于与服务端通过注册包建立连接；启动心跳包线程与所述服务端保持网络链路连接。

本实施例与上述第一实施例的区别在于，本实施例还包括启动心跳包线程与服务端建立初始网络链路连接的方案。

具体地，以Android手机为例，手机客户端在启动后，生成一个AndroidService，然后与服务端通过注册包建立连接。之后，客户端启动心跳包线程，向服务端发送心跳包与服务端保持网络链路连接。通过该网络链路连接，客户端获取应用业务推送消息。

其中，根据手机终端网络类型的不同，网络链路连接也不同。通常，手机网络类型主要有三种：wifi、net，还有小一部分wap网络。由于wifi、net网络都支持长连接，而wap网络不支持长连接，因此，当手机网络类型为wifi、net时，客户端与服务端之间的网络链路连接为长连接，客户端获取的业务消息为服务端推送的业务消息。

当手机网络类型为wap网络时，客户端与服务端之间的网络链路连接不为长连接，则推送方案需要改变成拉（polling）的方式，由客户端主动从服务端拉取业务消息。

由此，客户端根据网络类型的不同，需要在上述两种连接状态中切换，在切换过程中，需要进行推送流程的切换。Android系统中通过注册网络连接状态BroadcastReceiver，来接收网络变化广播通知，以此调整网络链路连接。

由此，通过建立的初始网络链路连接，可以使得客户端获取到系统推送的业务消息。

本实施例通过上述方案，客户端通过启动心跳包线程与服务端建立初始网络链路连接，基于该初始网络链路连接获取系统推送的业务消息，在从服务端获取到业务消息后，根据业务消息的类型调整心跳包发送策略；基于该心跳包发送策略保持与服务端之间的网络链路连接，以供业务消息的推送操作，由此可以更好的满足移动终端上各种应用业务消息的推送需求，并节省了移动终端的电量。

进一步地，所述启动模块200，还用于在与服务端通过注册包建立连接后接收所述服务端下发的推送策略。即心跳包发送策略的调整方案由服务端下发给客户端，具体可以在客户端与服务端通过注册包建立连接后，服务端将推送策略下发给客户端，由客户端对接收的推送策略进行解析，获取心跳包调整策略。后续，当客户端获取到系统推送的业务消息后，即可以根据业务消息的类型采用相应的心跳包调整策略，以节省手机电量。

如图7所示，本发明较佳实施例还提出一种信息推送系统，包括：客户端301和与客户端301通信连接的服务端302，其中：

所述客户端301可以采用上述实施例所述的客户端；

所述服务端302用于向所述客户端301下发业务消息；基于客户端301根据业务消息的类型调整的心跳包发送策略，与所述客户端301保持网络链路连接，进行业务消息的推送操作。

具体地，以Android手机为例，客户端301部分主要负责手机推送模块SDK，包括Android Servie的管理、心跳包线程的管理、手机上推送消息的展示，以及和服务端302交互的流程处理，包括发送注册包、和服务端302建立长连接、发送心跳包、推送消息回报等。

服务端302部分主要负责长连接的请求管理、业务逻辑处理、推送消息、统计信息落地等。此外还包括PUSH WEB管理后台和应用业务（比如游戏业务）接入管理等。

由于现有的终端应用进行业务消息推送时，为保持客户端301与服务端302之间的网络链路连接（比如TCP长连接），通常采用固定的心跳包发送策略，导致手机终端耗电量较大。

本实施例考虑到，根据服务端302推送的业务消息的类型不同，可以允许心跳包线程具有不同的休眠时间，因此，本实施例采用以下解决方案：基于客户端301获取的服务端302下发的业务消息的类型，动态调整心跳包发送策略，在此策略的基础上保持客户端301与服务端302之间的网络链路连接，供业务消息的推送操作，以此节省手机终端的电量。

具体地，以Android手机为例，手机客户端301在启动后，会生成一个Android Service，然后与服务端302通过注册包建立连接。之后，客户端301启动心跳包线程，向服务端302发送心跳包与服务端302保持网络链路连接。通过该网络链路连接，获取应用业务推送消息。

其中，根据手机终端网络类型的不同，网络链路连接也不同。通常，手机网络类型主要有三种：wifi、net，还有小一部分wap网络。由于wifi、net网络都支持长连接，而wap网络不支持长连接，因此，当手机网络类型为wifi、net时，客户端301与服务端302之间的网络链路连接为长连接，客户端301获取的业务消息为服务端302推送的业务消息。

当手机网络类型为wap网络时，客户端301与服务端302之间的网络链路连接不为长连接，则推送方案需要改变成拉（polling）的方式，由客户端301主动从服务端302拉取业务消息。

由此，客户端301根据网络类型的不同，需要在上述两种连接状态中切换，在切换过程中，需要进行推送流程的切换。Android系统中通过注册网络连接状态BroadcastReceiver，来接收网络变化广播通知，以此调整网络链路连接。

本实施例可以根据不同的业务消息类型调整心跳包发送策略，以节省手机电量。

其中，业务消息类型可以分为实时类消息、设定时间类消息以及指令类消息等。

以游戏营销业务为例，在游戏营销业务中，推送消息分为游戏实时消息、游戏营销活动消息、推送指令消息等类型。

游戏实时消息是指游戏最新的版本更新消息和道具打折消息以及其它实时消息。

游戏营销活动消息是指游戏运营策划的一些活动消息，其具有固定的推送时间。

推送指令消息包括推送关闭消息，或者临时下发的推送策略消息等。

对于不同的业务消息类型采用不同的心跳包发送间隔。比如，对于实时类消息，按照推送消息不能过于频繁的约定和经验数据，在接收到该实时类消息后接下来一段时间（比如60分钟）内再有实时类消息的概率较小，可以调整心跳包的发送间隔大于客户端301与服务端302约定的基准时间间隔，从而节省了网络连接耗费和CPU运行耗费的手机电量；然后在设定的时间段后，恢复心跳包发送间隔为基准时间间隔。

对于设定时间类消息，由于消息推送时间已预先设定，同样可以调整心跳包的发送间隔大于客户端301与服务端302约定的基准时间间隔，从而可以节省网络连接耗费和CPU运行耗费的手机电量。

对于指令类消息，以推送关闭消息为例，当客户端301接收到该推送指令消息后，则会停止心跳包的发送，关闭与服务端302之间的网络链路连接，节省了网络连接耗费的手机电量。

之后，客户端301基于所述调整后的心跳包发送策略保持与所述服务端302之间的网络链路连接，以供业务消息的推送操作。

其中，消息推送系统在进行业务消息的推送操作时，需要根据网络链路连接的类型采取相应的推送方案，其中：

当所述网络链路连接为长连接时，所述客户端301接收所述服务端302推送的业务消息；

当所述网络链路连接不为长连接时，所述客户端301从所述服务端302拉取业务消息。

此外，当所述业务消息的类型为设定时间类消息时，客户端301可以在该设定时间前预定时间拉取所述业务消息。

另外，客户端301会实时监测网络类型变化，在监测到网络类型变化后，切换与所述服务端302之间的网络链接状态，以确保业务消息的正常推送。

本实施例通过上述方案，客户端301在从服务端302获取到业务消息后，根据业务消息的类型调整心跳包发送策略；基于该心跳包发送策略保持与服务端302之间的网络链路连接，以供业务消息的推送操作，由此可以更好的满足移动终端上各种应用业务消息的推送需求，并节省了移动终端的电量。

更为具体地，客户端301根据所述业务消息的类型调整心跳包发送策略可以采用以下方案：

首先，判断业务消息的类型；当所述业务消息的类型为实时类消息时，调整心跳包的发送间隔为第一预设时间段，并在第二预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第一预设时间段大于所述基准时间间隔，且小于所述第二预设时间段；

当所述业务消息的类型为设定时间类消息时，调整心跳包的发送间隔为第三预设时间段，并在第四预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第三预设时间段大于所述基准时间间隔，且小于所述第四预设时间段。

当所述业务消息的类型为指令类消息时，停止心跳包线程。

上述第一预设时间段与第三预设时间段可以相同，也可以不相同；上述第二预设时间段与第四预设时间段可以相同，也可以不相同。

以游戏营销业务为例，并设定客户端301与服务端302约定的基准心跳包间隔为60秒。

当客户端301收到的推送消息为游戏实时类消息时，按照推送消息不能过于频繁的约定和经验数据，接下来60分钟内再有实时类消息的概率较小，因此，可以调整心跳包发送间隔为120秒，使得心跳包线程休眠120秒，以节省网络连接耗费和CPU运行耗费的手机电量。在60分钟之后，再恢复心跳包发送间隔为基准发送间隔60秒。

当收到的推送消息类型为游戏活动列表消息时，记录下活动时间，推送方案变化为主动拉取（polling）方式，通过定时器在活动时间前预定时间去拉取消息通知用户。同时，心跳包发送间隔调整为120秒，使得心跳包线程休眠120秒，从而节省了网络连接耗费和CPU运行耗费的手机电量。

当收到的推送消息为指令消息时，如果是关闭推送指令，则断开长连接，停止心跳包线程，停止Android Service，以节省网络连接耗费的手机电量。

此外，在关机或者用户关闭推送开关时，关闭推送流程，以节省网络连接耗费的手机电量。用户可以选择默认设置为晚间22：00到早间8：00，关闭推送流程，以节省网络连接耗费的手机电量。

由此，通过以上动态策略，在满足业务推送需求，节省手机流量的同时，可以较好的节省手机电量。

需要说明的是，本实施例中根据业务消息类型调整心跳包发送策略的方案可以不限于上述几种业务类型对应的应用场景，在其他实施例中，还可以采用更多或更细分的策略来调整心跳包策略。

此外，本实施例中根据业务消息类型调整心跳包发送策略的方案可以由客户端301侧定义，也可以由服务端302下发给客户端301，具体可以在客户端301与服务端302通过注册包建立连接后，服务端302将推送策略下发给客户端301，由客户端301对接收的推送策略进行解析，获取心跳包调整策略。

本发明实施例信息推送方法、客户端及系统，客户端在从服务端获取到业务消息后，根据业务消息的类型调整心跳包发送策略；基于该心跳包发送策略保持与服务端之间的网络链路连接，以供业务消息的推送操作，由此可以更好的满足移动终端上各种应用业务消息的推送需求，并节省了移动终端的电量。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端设备（可以是手机，计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。

以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (18)

1.一种信息推送方法，其特征在于，包括：

客户端从服务端获取业务消息；

判断所述业务消息的类型，当所述业务消息的类型为实时类消息时，调整心跳包的发送间隔为第一预设时间段，并在第二预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第一预设时间段大于所述基准时间间隔，且小于所述第二预设时间段；基于调整后的心跳包发送策略保持与所述服务端之间的网络链路连接，以供业务消息的推送操作。

2.根据权利要求1所述的方法，其特征在于，所述客户端从服务端获取业务消息的步骤包括：

所述客户端接收所述服务端推送的业务消息；或者，所述客户端从所述服务端拉取业务消息。

3.根据权利要求1所述的方法，其特征在于，所述判断业务消息的类型的步骤之后还包括：

当所述业务消息的类型为设定时间类消息时，调整心跳包的发送间隔为第三预设时间段，并在第四预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第三预设时间段大于所述基准时间间隔，且小于所述第四预设时间段。

4.根据权利要求1所述的方法，其特征在于，所述判断业务消息的类型的步骤之后还包括：

当所述业务消息的类型为指令类消息时，停止心跳包线程。

5.根据权利要求1-4中任一项所述的方法，其特征在于，所述客户端从服务端获取业务消息的步骤之前还包括：

客户端与服务端通过注册包建立连接；

启动心跳包线程与所述服务端保持网络链路连接。

6.根据权利要求5所述的方法，其特征在于，所述客户端与服务端通过注册包建立连接的步骤之后还包括：

所述客户端接收所述服务端下发的推送策略。

7.根据权利要求5所述的方法，其特征在于，所述业务消息的推送操作包括：

当所述网络链路连接为长连接时，所述客户端接收所述服务端推送的业务消息；

当所述网络链路连接不为长连接时，所述客户端从所述服务端拉取业务消息。

8.根据权利要求7所述的方法，其特征在于，所述业务消息的推送操作还包括：

当所述业务消息的类型为设定时间类消息时，所述客户端在所述设定时间前预定时间拉取所述业务消息。

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

所述客户端在监测到网络类型变化后，切换与所述服务端之间的网络链接状态。

10.一种信息推送客户端，其特征在于，包括：

获取模块，用于从服务端获取业务消息；

调整模块，用于判断所述业务消息的类型，当所述业务消息的类型为实时类消息时，调整心跳包的发送间隔为第一预设时间段，并在第二预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第一预设时间段大于所述基准时间间隔，且小于所述第二预设时间段；

推送操作模块，用于基于调整后的心跳包发送策略保持与所述服务端之间的网络链路连接，以供业务消息的推送操作。

11.根据权利要求10所述的客户端，其特征在于，

所述获取模块，还用于接收所述服务端推送的业务消息；或者，所述客户端从所述服务端拉取业务消息。

12.根据权利要求10所述的客户端，其特征在于，

所述调整模块，还用于当所述业务消息的类型为设定时间类消息时，调整心跳包的发送间隔为第三预设时间段，并在第四预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第三预设时间段大于所述基准时间间隔，且小于所述第四预设时间段；以及当所述业务消息的类型为指令类消息时，停止心跳包线程。

13.根据权利要求10、11或12所述的客户端，其特征在于，还包括：

启动模块，用于与服务端通过注册包建立连接；启动心跳包线程与所述服务端保持网络链路连接。

14.根据权利要求13所述的客户端，其特征在于，

所述启动模块，还用于在与服务端通过注册包建立连接后接收所述服务端下发的推送策略。

15.根据权利要求13所述的客户端，其特征在于，

所述推送操作模块，还用于当所述网络链路连接为长连接时，接收所述服务端推送的业务消息；当所述网络链路连接不为长连接时，从所述服务端拉取业务消息。

16.根据权利要求15所述的客户端，其特征在于，

所述推送操作模块，还用于当所述业务消息的类型为设定时间类消息时，在所述设定时间前预定时间拉取所述业务消息。

17.根据权利要求15所述的客户端，其特征在于，

所述推送操作模块，还用于在监测到网络类型变化后，切换与所述服务端之间的网络链接状态。

18.一种信息推送系统，其特征在于，包括：客户端和服务端，其中：

所述客户端为权利要求10-17中任一项所述的客户端；

所述服务端用于向所述客户端下发业务消息；基于客户端根据业务消息的类型调整的心跳包发送策略，与所述客户端保持网络链路连接，进行业务消息的推送操作。