[0048]当所述网络链路连接不为长连接时，所述客户端从所述服务端拉取业务消息。
[0049]此外，当所述业务消息的类型为设定时间类消息时，客户端可以在该设定时间前预定时间拉取所述业务消息。
[0050]另外，客户端会实时监测网络类型变化，在监测到网络类型变化后，切换与所述服务端之间的网络链接状态，以确保业务消息的正常推送。
[0051]本实施例通过上述方案，客户端在从服务端获取到业务消息后，根据业务消息的类型调整心跳包发送策略；基于该心跳包发送策略保持与服务端之间的网络链路连接，以供业务消息的推送操作，由此可以更好的满足移动终端上各种应用业务消息的推送需求，并节省了移动终端的电量。
[0052]更为具体地，如图2所示，作为一种实施方式，上述步骤S102可以包括:
[0053]步骤S1021，判断业务消息的类型；当所述业务消息的类型为实时类消息时，进入步骤S1022 ;当业务消息的类型为设定时间类消息时，进入步骤S1023 ;当所述业务消息的类型为指令类消息时，进入步骤S1024 ；
[0054]步骤S1022，调整心跳包的发送间隔为第一预设时间段，并在第二预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第一预设时间段大于所述基准时间间隔，且小于所述第二预设时间段。
[0055]步骤S1023，调整心跳包的发送间隔为第三预设时间段，并在第四预设时间段后恢复心跳包的发送间隔为基准时间间隔；所述第三预设时间段大于所述基准时间间隔，且小于所述第四预设时间段。
[0056]步骤S1024，停止心跳包线程。
[0057]上述第一预设时间段与第三预设时间段可以相同，也可以不相同；上述第二预设时间段与第四预设时间段可以相同，也可以不相同。
[0058]以游戏营销业务为例，并设定客户端与服务端约定的基准心跳包间隔为60秒。
[0059]当客户端收到的推送消息为游戏实时类消息时，按照推送消息不能过于频繁的约定和经验数据，接下来60分钟内再有实时类消息的概率较小，因此，可以调整心跳包发送间隔为120秒，使得心跳包线程休眠120秒，以节省网络连接耗费和CPU运行耗费的手机电量。在60分钟之后，再恢复心跳包发送间隔为基准发送间隔60秒。
[0060]当收到的推送消息类型为游戏活动列表消息时，记录下活动时间，推送方案变化为主动拉取(polling)方式，通过定时器在活动时间前预定时间去拉取消息通知用户。同时，心跳包发送间隔调整为120秒，使得心跳包线程休眠120秒，从而节省了网络连接耗费和CPU运行耗费的手机电量。
[0061]当收到的推送消息为指令消息时，如果是关闭推送指令，则断开长连接，停止心跳包线程，停止Android Service,以节省网络连接耗费的手机电量。
[0062]此外，在关机或者用户关闭推送开关时，关闭推送流程，以节省网络连接耗费的手机电量。用户可以选择默认设置为晚间22:00到早间8:00，关闭推送流程，以节省网络连接耗费的手机电量。
[0063]由此，通过以上动态策略，在满足业务推送需求，节省手机流量的同时，可以较好的节省手机电量。
[0064]需要说明的是，本实施例中根据业务消息类型调整心跳包发送策略的方案可以不限于上述几种业务类型对应的应用场景，在其他实施例中，还可以采用更多或更细分的策略来调整心跳包策略。此外，本实施例中根据业务消息类型调整心跳包发送策略的方案可以由客户端侧定义，也可以由服务端下发给客户端，具体可以在客户端与服务端通过注册包建立连接后，服务端将推送策略下发给客户端，由客户端对接收的推送策略进行解析，获取心跳包调整策略。
[0065]如图3所不,本发明第二实施例提出一种信息推送方法,在上述第一实施例的基础上，在上述步骤SlOl之前还包括:
[0066]步骤S90，客户端与服务端通过注册包建立连接；
[0067]步骤S100，启动心跳包线程与所述服务端保持网络链路连接。
[0068]本实施例与上述第一实施例的区别在于，本实施例还包括启动心跳包线程与服务端建立初始网络链路连接的方案。
[0069]具体地，以Android手机为例,手机客户端在启动后，生成一个Android Service,然后与服务端通过注册包建立连接。之后，客户端启动心跳包线程，向服务端发送心跳包与服务端保持网络链路连接。通过该网络链路连接，客户端获取应用业务推送消息。
[0070]其中，根据手机终端网络类型的不同，网络链路连接也不同。通常，手机网络类型主要有三种:wif1、net,还有小一部分wap网络。由于wif1、net网络都支持长连接,而wap网络不支持长连接，因此，当手机网络类型为wif1、net时，客户端与服务端之间的网络链路连接为长连接，客户端获取的业务消息为服务端推送的业务消息。
[0071]当手机网络类型为wap网络时，客户端与服务端之间的网络链路连接不为长连接，则推送方案需要改变成拉(polling)的方式，由客户端主动从服务端拉取业务消息。
[0072]由此，客户端根据网络类型的不同，需要在上述两种连接状态中切换，在切换过程中，需要进行推送流程的切换。An droid系统中通过注册网络连接状态BroadcastReceiver,来接收网络变化广播通知，以此调整网络链路连接。
[0073]由此，通过建立的初始网络链路连接，可以使得客户端获取到系统推送的业务消肩、O
[0074]本实施例通过上述方案，客户端通过启动心跳包线程与服务端建立初始网络链路连接，基于该初始网络链路连接获取系统推送的业务消息，在从服务端获取到业务消息后，根据业务消息的类型调整心跳包发送策略；基于该心跳包发送策略保持与服务端之间的网络链路连接，以供业务消息的推送操作，由此可以更好的满足移动终端上各种应用业务消息的推送需求，并节省了移动终端的电量。
[0075]如图4所示，本发明第三实施例提出一种信息推送方法，在上述第二实施例的基础上，在上述步骤S90之后还包括:
[0076]步骤S80，所述客户端接收所述服务端下发的推送策略。
[0077]本实施例与上述第二实施例的区别在于，本实施例中，心跳包发送策略的调整方案由服务端下发给客户端，具体可以在客户端与服务端通过注册包建立连接后，服务端将推送策略下发给客户端，由客户端对接收的推送策略进行解析，获取心跳包调整策略。后续，当客户端获取到系统推送的业务消息后，即可以根据业务消息的类型采用相应的心跳包调整策略，以节省手机电量。
[0078]如图5所示，本发明第一实施例提出一种信息推送客户端，包括:获取模块201、调整模块202及推送操作模块203，其中:
[0079]获取模块201，用于从服务端获取业务消息；
[0080]调整模块202，用于根据所述业务消息的类型调整心跳包发送策略；
[0081]推送操作模块203，用于基于所述调整后的心跳包发送策略保持与所述服务端之间的网络链路连接，以供业务消息的推送操作。
[0082]本实施例方案涉及的信息推送系统包括客户端和服务端，以Android手机为例，客户端部分主要负责手机推送模块SDK，包括Android Servie的管理、心跳包线程的管理、手机上推送消息的展示，以及和服务端交互的流程处理，包括发送注册包、和服务端建立长连接、发送心跳包、推送消息回报等。
[0083]服务端部分主要负责长连接的请求管理、业务逻辑处理、推送消息、统计信息落地等。此外还包括I3USH WEB管理后台和应用业务(比如游戏业务)接入管理等。
[0084]由于现有的终端应用进行业务消息推送时，为保持客户端与服务端之间的网络链路连接(比如TCP长连接)，通常采用固定的心跳包发送策略，导致手机终端耗电量较大。
[0085]本实施例考虑到，根据服务端推送的业务消息的类型不同，可以允许心跳包线程具有不同的休眠时间，因此，本实施例采用以下解决方案:基于客户端获取的服务端下发的业务消息的类型，动态调整心跳包发送策略，在此策略的基础上保持客户端与服务端之间的网络链路连接，供业务消息的推送操作，以此节省手机终端的电量。
[0086]具体地，以Android手机为例，手机客户端在启动后，会生成一个AndroidServ