CN103634409B - 实现移动互联网应用永远在线的方法及系统 - Google Patents

Abstract

本发明公开了一种实现移动互联网应用永远在线的方法、系统及装置，包括终端应用客户端通过永远在线客户端和永远在线服务器，与终端应用服务端保持长连接；当有第三方应用产生应用推送通知时，经由永远在线服务器处理后推送给永远在线客户端，再由永远在线客户端分发给终端应用客户端，永远在线客户端接收来自各终端应用客户端的心跳连接，收敛多个终端应用客户端的心跳连接后统一发送给永远在线服务器；相应地，永远在线服务器，将接收到的心跳连接分发至对应的终端应用服务端。这样节省了信道占用，也降低了终端能耗。

Description

实现移动互联网应用永远在线的方法及系统

技术领域

本发明涉及移动互联网技术，尤指一种实现移动互联网应用永远在线的方法及系统。

背景技术

目前，随着移动互联网的发展，越来越多的移动互联网应用应运而生，实时为用户提供通信服务，比如QQ、微信、SNS、微博等。这类应用的用户群极其庞大，而且这类应用的客户端需与服务端保持连接，以维持用户的在线状态。应用的客户端与服务端间的交互具有应用心跳包发送频繁、状态更新频繁、单数据包数据量小等特点。因此，如果出现大量的信息交互同时爆发，将会给网络带来沉重的信令负荷。而对单个用户而言，终端上如果同时运行多个这类应用，也会大量消耗终端的电能。

针对上述问题，目前提出了通知推送服务，即移动互联网应用不需运行，也可自动接收来自服务端的应用推送通知并触发启动。

苹果推送通知服务（APNs，Apple Push Notification service）使用一种长IP连接的push技术，能够将第三方应用产生的应用推送通知推送给苹果操作系统（iOS）终端。每个iOS终端和服务端建立一个基于IP的长连接，这种长连接以加密的方式被iOS终端和服务端所信任。如果一个通知被从服务端推送到达iOS终端，而在iOS终端中对应的应用尚未运行，那么这个通知会提示用户有数据从网络发送给该应用。一条应用推送通知从构造到到达iOS终端应用上的过程大致包括：第三方应用服务器将需要发送的消息、目的iOS设备的标识（Token）打包后发给APNs；APNs在自身的已注册Push服务的iPhone列表中，查找有相应标识的iOS终端，并将通知发到该iOS终端；iOS终端将收到的通知传递给相应的应用程序，并且按照设定弹出Push通知。如果对应的应用程序没有被开启，iOS终端会给用户提示让用户选择是否需要打开该应用，如果选择打开应用程序，则将通知发送给应用程序进行处理，后续的业务数据直接在应用和应用的服务器端之间进行。

与苹果APNs类似，安卓（Android）云到设备的通讯（C2DM，Android Cloud toDevice Messaging）是一个可以帮助开发者从服务端向Android设备的应用发送数据的服务。这项服务保证了服务端可以告诉Android设备的应用直接与业务的服务端连接，获取更新的应用程序或者用户数据。

综上所述，目前保持移动互联网应用永远在线的方法，基本是通过通知推送机制来实现的，对于单个终端来讲，虽然达到了节约能耗的问题，但是，其具体实现是在移动终端操作系统内，实现比较基本的、简单的应用推送通知推送功能。内部实现机制相对封闭，仅为第三方应用提供接口。第三方应用开发者需针对不同操作系统的终端，开发不同的推送通知功能。第三方应用、终端用户不支持多样的消息推送策略和运营管理需求，即不能跨平台实现移动互联网应用永远在线，实际应用很不方便。

另外，虽然现有通过通知推送技术保证了在应用未运行时，能接收应用推送通知。但是，在应用运行时，仍然存在客户端与服务端的频繁交互，产生过多信令负荷的问题。

发明内容

为了解决上述技术问题，本发明提供了一种实现移动互联网应用永远在线的方法及系统，能够节省网络资源、降低终端能耗，并能够跨平台实现移动互联网应用永远在线。

为了达到本发明目的，本发明提供了一种实现移动互联网应用永远在线的方法，终端应用客户端通过永远在线客户端和永远在线服务器，与终端应用服务端保持长连接；该方法还包括：

永远在线客户端接收来自各终端应用客户端的心跳连接，收敛后发送给永远在线服务器；永远在线服务器将接收到的心跳连接分发至对应的终端应用服务端；

当有第三方应用产生应用推送通知时，经由永远在线服务器处理后推送给永远在线客户端，再由永远在线客户端分发给终端应用客户端。

所述永远在线服务器将接收到的心跳连接分发至对应的终端应用服务端包括：

当网络正常时，按照所述永远在线客户端的心跳连接请求频率，向对应的终端应用服务端转发心跳连接；

当网络出现异常时，所述永远在线服务器通知永远在线客户端网络状况异常，所述永远在线客户端与永远在线服务器之间通过协商降低所述永远在线客户端的心跳连接请求频率后，再向对应的终端应用服务器端转发心跳连接。

所述经由永远在线服务器处理后推送给永远在线客户端包括：

所述永远在线服务器在同时接收到多条应用推送通知时，按照预先设置的应用等级或用户等级，将应用推送通知转发给所述永远在线客户端。

所述经由永远在线服务器处理后推送给永远在线客户端之前，该方法还包括：

所述永远在线服务器对接收到的应用推送通知，按照预先设置的收敛策略处理；

所述经由永远在线服务器处理后推送给永远在线客户端之前还包括：

所述永远在线服务器根据预先设置的与终端应用服务端的应用推送通知对应的缓存时间段，在收到应用推送通知时，将存在对应的缓存时间段的应用推送通知，按照缓存时间段的时长缓存，在缓存时间段到达时再转发给永远在线客户端。

该方法还包括：所述永远在线服务器实时监测网络状态，当网络拥塞时，按预先设置的最大应用推送通知数，缓存或拒绝应用推送通知。

在所述永远在线服务器中预先设置用于保存终端应用服务端是否是垃圾终端应用服务端的第一黑白名单列表；该方法还包括：

所述永远在线服务器根据第一黑白名单列表，对接收到的垃圾通知消息进行过滤；

在所述永远在线客户端中预先设置用于保存终端应用服务端是否是垃圾终端应用服务端的第二黑白名单列表；该方法还包括：

所述永远在线客户端根据第二黑白名单列表，对接收到的应用推送通知进行过滤，在确定收到垃圾通知消息时，向所述永远在线服务器发送举报通知；

所述永远在线服务器接收到来自所述永远在线客户端的举报通知，将相应的终端应用服务端设置在所述第一黑白名单列表中。

本发明还提供一种实现移动互联网应用永远在线的系统，包括终端侧和网络侧，其中，终端侧至少包括：永远在线客户端、一个或一个以上终端应用客户端；网络侧至少包括永远在线服务器、一个或一个以上终端应用服务端；其中，

永远在线客户端内置于终端中，设置在终端操作系统之上，与终端一一对应。在一个终端中，多个终端应用客户端对应一个永远在线客户端；用于接收来自各终端应用客户端的心跳连接，收敛后发送给永远在线服务器；

永远在线服务器分别与永远在线客户端、各终端应用服务端相连；用于将接收到的心跳连接分发至对应的终端应用服务端；

永远在线服务器，在有第三方应用产生应用推送通知时，用于在同时接收到多条应用推送通知时，按照预先设置的应用等级或用户等级将应用推送通知转发给永远在线客户端；

所述永远在线服务器，还用于对接收到的应用推送通知，按照预先设置的收敛策略处理后再发送给所述永远在线客户端。

所述永远在线服务器，还用于根据预先设置的与终端应用服务端的应用推送通知对应的缓存时间段，在收到应用推送通知时，将存在对应的缓存时间段的应用推送通知，按照缓存时间段的时长缓存，在缓存时间段到达时再转发给所述永远在线客户端。

所述永远在线服务器，还用于实时监测网络状态，当网络拥塞时，按预先设置的最大应用推送通知数，缓存或拒绝应用推送通知；

所述永远在线客户端，用于接收来自永远在线服务器的应用推送通知，并分发给对应的终端应用客户端。

所述永远在线服务器，其中预先设置有用于保存终端应用服务端是否是垃圾终端应用服务端的第一黑白名单列表，还用于根据第一黑白名单列表，对接收到的垃圾通知消息进行过滤；

所述永远在线客户端，其中预先设置有用于保存终端应用服务端是否是垃圾终端应用服务端的第二黑白名单列表，还用于根据第二黑白名单列表，对接收到的应用推送通知进行过滤，在确定收到垃圾通知消息时，向所述永远在线服务器发送举报通知；

所述永远在线服务器，还用于接收到来自所述永远在线客户端的举报通知，将相应的终端应用服务端设置在第一黑白名单列表中。

所述永远在线服务器，在网络正常时，还用于按照永远在线客户端的心跳连接请求频率，向对应的终端应用服务器端转发心跳连接；

所述永远在线服务器，在网络出现异常时，还用于通知永远在线客户端网络状况异常；

所述永远在线客户端与永远在线服务器之间通过协商降低永远在线客户端的心跳连接请求频率后再向对应的终端应用服务器端转发心跳连接。

与现有技术相比，本发明包括终端应用客户端通过永远在线客户端和永远在线服务器，与终端应用服务端保持长连接；当有第三方应用产生应用推送通知时，经由永远在线服务器处理后推送给永远在线客户端，再由永远在线客户端分发给终端应用客户端，永远在线客户端接收来自各终端应用客户端的心跳连接，收敛多个终端应用客户端的心跳连接后统一发送给永远在线服务器；相应地，永远在线服务器，将接收到的心跳连接分发至对应的终端应用服务端。这样节省了信道占用，也降低了终端能耗。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

图1为本发明实现移动互联网应用永远在线的系统的组成结构示意图；

图2为本发明实现移动互联网应用永远在线的方法的流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1为本发明实现移动互联网应用永远在线的系统的组成结构示意图，如图1所示，包括终端侧和网络侧，其中，终端侧至少包括：永远在线客户端、一个或一个以上终端应用客户端；网络侧至少包括永远在线服务器、一个或一个以上终端应用服务端；其中，

永远在线客户端内置于终端中，设置在终端操作系统之上，与终端一一对应。在一个终端中，多个终端应用客户端对应一个永远在线客户端；用于接收来自各终端应用客户端的心跳连接，收敛后发送给永远在线服务器。永远在线客户端，用于管理终端内的永远在线应用状态及应用信息、认证终端应用、管理及收敛来自各终端应用客户端的心跳连接消息；将来自各终端应用客户端的连接请求发送至永远在线服务器；接收来自永远在线服务器的应用推送通知并分发给对应的终端应用客户端等。其中，永远在线应用状态信息包括但不限定为：注册、未注册、在线、离线、安装、卸载等。在终端内的应用在永远在线客户端注册成功后，永远在线客户端可以获知其应用状态，并根据不同的应用状态执行不同连接收敛、消息通知策略。这里，应用信息包括但不限定为：应用名称、用于标识应用的应用ID、用于应用服务端与应用客户端寻址，保证通知消息收发的安全性的应用Token等。

永远在线服务器分别与永远在线客户端、各终端应用服务端相连；用于将接收到的心跳连接分发至对应的终端应用服务端。永远在线服务器，用于管理永远在线客户端的状态、管理终端应用服务端的状态、认证永远在线客户端及终端应用服务端、管理与永远在线客户端的连接、接收来自终端应用服务端的应用推送通知并处理后发送至永远在线客户端等。其中，一方面，永远在线客户端需要向永远在线服务器注册，一个永远在线服务器上会注册多个永远在线客户端，因此，永远在线服务器可以获知永远在线客户端的状态及其上终端应用客户端的状态，包括：永远在线客户端ID，以及对应的状态已注册或未注册。另一方面，终端应用服务端也需要在永远在线服务器进行注册，一个永远在线服务器上会注册多个应用服务端，因此，永远在线服务器可以获知各终端应用服务端的状态，包括：终端应用服务端名称、ID、服务提供者名称等信息，以及其对应的状态已注册或未注册。

从上面描述可知，永远在线服务器与永远在线客户端和终端应用服务端的各个连接的状态、连接频率等均由永远在线服务器进行管理。

当有第三方应用产生应用推送通知时，

永远在线服务器，具体用于在同时接收到多条应用推送通知时，按照预先设置的应用等级或用户等级将应用推送通知转发给永远在线客户端。比如，优先发送应用等级高或用户等级高的应用推送通知。

本发明的实现移动互联网应用永远在线的系统不是基于终端操作系统的，而是是基于应用层的，向开发者提供开放接口，因此，实现了跨平台的移动互联网应用永远在线。

永远在线服务器，还用于对接收到的应用推送通知，按照预先设置的收敛策略处理后再发送给永远在线客户端；其中，应用推送通知携带有实时性标签；收敛策略可以是：对于实时性标签显示的实时性要求不高的应用推送通知，比如系统消息、软件更新、广告等，在预先设置的时间段内，将其缓存后再一同发送即收敛其占用一个信道一并发送，或者，在收到实时性标签显示的实时性高的实时应用推送通知时，再与收到的实时应用推送通知一并发送。

永远在线服务器，还用于根据预先设置的与终端应用服务端的应用推送通知对应的缓存时间段，在收到应用推送通知时，将存在对应的缓存时间段的应用推送通知，按照缓存时间段的时长缓存，在缓存时间段到达时再转发给永远在线客户端。

永远在线服务器，还用于实时监测网络状态，当网络拥塞时，按预先设置的最大应用推送通知数，缓存或拒绝应用推送通知。其中，缓存的应用推送通知可以在监测到网络条件好转后再发送。其中，最大应用推送通知数可以是针对单个应用设置的，也可以是很对多个应用设置的。这里，永远在线服务器会外接网络设备，从其获取网络实时状态信息，具体实现属于本领域技术人员的惯用技术手段，这里不再赘述。

对应地，永远在线客户端，用于接收来自永远在线服务器的应用推送通知，并分发给对应的终端应用客户端。

永远在线服务器，其中预先设置有用于保存终端应用服务端是否是垃圾终端应用服务端的第一黑白名单列表，还用于根据第一黑白名单列表，对接收到的垃圾通知消息进行过滤，即不发送给永远在线客户端；接收到来自永远在线客户端的举报通知，将相应的终端应用服务端设置在第一黑白名单列表中。

对应地，永远在线客户端，其中预先设置有用于保存终端应用服务端是否是垃圾终端应用服务端的第二黑白名单列表，还用于根据第二黑白名单列表，对接收到的应用推送通知进行过滤，在确定收到垃圾通知消息时，向永远在线服务器发送举报通知。

永远在线客户端，还用于接收来自各终端应用客户端的心跳连接，收敛多个终端应用客户端的心跳连接后统一发送给永远在线服务器；相应地，永远在线服务器，还用于将接收到的心跳连接分发至对应的终端应用服务端。这样节省了信道占用，也降低了终端能耗。

永远在线服务器，还用实时监测网络状态，当网络正常时，按照永远在线客户端的心跳连接请求频率，向对应的终端应用服务器端转发心跳连接；当网络出现异常时，所述永远在线服务器，还用于通知永远在线客户端网络状况异常；所述永远在线客户端与永远在线服务器之间通过协商降低永远在线客户端的心跳连接请求频率后再向对应的终端应用服务器端转发心跳连接。这样，当网络状态良好时，永远在线客户端与永远在线服务器之间的连接频率可以维持在约定数值，而当网络状态发生异常如网络负荷较大时，通过调整永远在线客户端与永远在线服务器之间的连接频率，降低了心跳连接次数，减少了网络资源的消耗，从而提高了网络资源的利用效率。

本发明实现移动互联网应用永远在线的系统还包括：针对心跳连接和应用推送通知的计费管理，并可实现用户行为分析。具体地，

永远在线服务器，对不同的计费策略进行管理，通过调用运营商现有的计费支撑系统（BSS）提供的接口与BSS对接，向其触发计费请求；而BSS完成相应的批价、计费。BSS的具体实现属于本领域技术人员的公知技术，这里不再赘述。

其中，计费策略可以包括但不限于：支持按条计费，如X元/100条心跳消息，Y元/100条应用推送通知；支持按周期计费，如X元/月，Y元/年；支持按应用等级计费，如普通应用：X元/月，高级应用：Y元/月，不同收费享受不同服务优先级；支持按应用开发者等级计费，如初级开发者A注册2个应用：X元/月，高级开发者B注册4个应用：Y元/月，不同收费享受不同服务优先级等。

BSS，还用于针对不同的计费策略发布不同的产品；而永远在线服务器，还用于根据不同的应用、不同开发者管理不同的计费策略，记录相应产品信息。

永远在线服务器，还用于根据心跳连接、应用推送通知的数据挖掘和统计分析，对用户行为进行估计，为应用开发者及运营商自身提供运营支撑。

永远在线服务器可根据心跳连接或应用推送通知携带的信息，关联用户终端应用的名称、类别、使用频率、使用时间段等信息，以实现用户行为的估计分析。比如：用户爱好分析，假设用户A终端内置的永远在线客户端频繁发送QQ、MSN、微信等心跳连接消息，接收这些应用的应用推送通知，可以分析出该用户是即时通信类软件的忠实用户；再如：用户使用习惯分析，假设用户B通过永远在线客户端设置时间从20：00～21：00不接收应用推送通知，则可以分析出该用户在此时间段内不希望被打扰，有重要事务正在进行。

图2为本发明实现移动互联网应用永远在线的方法的流程图，如图2所示，包括以下步骤：

步骤200：终端应用客户端通过永远在线客户端和永远在线服务器，与终端应用服务端保持长连接。

本步骤之前还包括：终端内的应用即终端应用客户端在永远在线客户端注册，注册成功后，永远在线客户端可以获知其应用状态，并根据不同的应用状态执行不同连接收敛、消息通知策略。这里，应用信息包括但不限定为：应用名称、用于标识应用的应用ID、用于应用服务端与应用客户端寻址，保证通知消息收发的安全性的应用Token等。

本步骤之前还包括：永远在线客户端向永远在线服务器注册，一个永远在线服务器上会注册多个永远在线客户端，因此，永远在线服务器可以获知永远在线客户端的状态及其上终端应用客户端的状态，包括：永远在线客户端ID，以及对应的状态已注册或未注册；终端应用服务端在永远在线服务器进行注册，一个永远在线服务器上会注册多个应用服务端，因此，永远在线服务器可以获知各终端应用服务端的状态，包括：终端应用服务端名称、ID、服务提供者名称等信息，以及其对应的状态已注册或未注册。

步骤201：永远在线客户端接收来自各终端应用客户端的心跳连接，收敛后发送给永远在线服务器；永远在线服务器，将接收到的心跳连接分发至对应的终端应用服务端。

各终端应用客户端的心跳请求均发送至永远在线客户端；而收敛时间窗口则由永远在线客户端与永远在线服务器协商确定，当收敛时间窗口到达时，再将一个收敛时间窗口内的所有心跳请求发至永远在线服务器。其中，收敛时间窗口可以综合考虑各终端应用客户端的连接频率情况，并结合网络状况，尽可能将更多的心跳请求收敛成一条。

需要说明的是，在永远在线服务器与终端应用服务端预先设置有最大时间阈值，收敛时间窗口需小于该最大时间阈值。举例来讲，比如，假设终端A上两个应用客户端连接频率分别为1次/2分钟、1次/1分钟，终端A上的永远在线客户端可以设置收敛时间窗口为2分钟，即每2分钟，将两个应用的心跳请求（即共3条）收敛成一条连接请求发送至永远在线服务器。又如，假设终端B上三个应用客户端连接频率分别为1次/1分钟、1次/2分钟、1次/3分钟，终端B上的永远在线客户端可以设置收敛时间窗口为6分钟，即每6分钟，将三个应用的心跳请求（即共11条）收敛成1条连接请求发送至永远在线服务器。

永远在线服务器将收敛的连接请求进行分拣后，分别发送至对应的终端应用服务端。

通过本步骤，一方面节省了信道占用，同时也降低了终端能耗。

本步骤中永远在线服务器将接收到的心跳连接分发至对应的终端应用服务端具体包括：当网络正常时，按照永远在线客户端的心跳连接请求频率，向对应的终端应用服务端转发心跳连接；

当网络出现异常时，永远在线服务器会通知永远在线客户端，永远在线客户端与永远在线服务器之间通过协商降低永远在线客户端的心跳连接请求频率后，再向对应的终端应用服务器端转发心跳连接。需要说明的是，当网络出现异常时，永远在线服务器也会同时通知终端应用服务端网络状况异常，并且永远在线服务器与终端应用服务端之间预先约定有最低频率阈值，即只要降低后的永远在线客户端的心跳连接请求频率不低于该最低频率阈值时，均被认为该应用在线。

这样，当网络状态良好时，永远在线客户端与永远在线服务器之间的连接频率可以维持在约定数值，而当网络状态发生异常如网络负荷较大时，通过调整永远在线客户端与永远在线服务器之间的连接频率，降低了心跳连接次数，减少了网络资源的消耗，从而提高了网络资源的利用效率。其中，

如何降低永远在线客户端的心跳连接请求频率，与网络的信令负荷情况有关。网络的信令负荷状态可以通过在永远在线服务器外接网络设备来获知，具体实现属于本领域技术人员的惯用技术手段，这里不再赘述。永远在线服务器将网络状态通知给永远在线客户端；永远在线客户端与永远在线服务器之间可以预先设置一个约定的频率阈值，在正常频率与最低频率之间，永远在线客户端可以根据网络状况，结合永远在线服务器的反馈时间，进行自适应调整。

步骤202：当有第三方应用产生应用推送通知时，经由永远在线服务器处理后推送给永远在线客户端，再由永远在线客户端分发给终端应用客户端。

本步骤中，永远在线服务器处理后推送给永远在线客户端包括：永远在线服务器在同时接收到多条应用推送通知时，按照预先设置的应用等级或用户等级将应用推送通知转发给永远在线客户端。比如，优先发送应用等级高或用户等级高的应用推送通知。

本步骤还包括：永远在线服务器对接收到的应用推送通知，按照预先设置的收敛策略处理后再发送给永远在线客户端；其中，应用推送通知携带有实时性标签；收敛策略可以是：对于实时性标签显示的实时性要求不高的应用推送通知，比如系统消息、软件更新、广告等，在预先设置的时间段内，将其缓存后再一同发送即收敛其占用一个信道一并发送，或者，在收到实时性标签显示的实时性高的实时应用推送通知时，再与收到的实时应用推送通知一并发送。

本步骤还包括：永远在线服务器根据预先设置的与终端应用服务端的应用推送通知对应的缓存时间段，在收到应用推送通知时，将存在对应的缓存时间段的应用推送通知，按照缓存时间段的时长缓存，在缓存时间段到达时再转发给永远在线客户端。

本发明方法还包括：永远在线服务器实时监测网络状态，当网络拥塞时，按预先设置的最大应用推送通知数，缓存或拒绝应用推送通知。其中，缓存的应用推送通知可以在监测到网络条件好转后再发送。其中，最大应用推送通知数可以是针对单个应用设置的，也可以是很对多个应用设置的。这里，永远在线服务器会外接网络设备，从其获取网络实时状态信息，具体实现属于本领域技术人员的惯用技术手段，这里不再赘述。

在永远在线服务器中预先设置用于保存终端应用服务端是否是垃圾终端应用服务端的第一黑白名单列表，本发明方法还包括：永远在线服务器根据第一黑白名单列表，对接收到的垃圾通知消息进行过滤，即不发送给永远在线客户端；接收到来自永远在线客户端的举报通知，将相应的终端应用服务端设置在第一黑白名单列表中。

进一步地，在永远在线客户端其中预先设置用于保存终端应用服务端是否是垃圾终端应用服务端的第二黑白名单列表，还包括：永远在线客户端根据第二黑白名单列表，对接收到的应用推送通知进行过滤，在确定收到垃圾通知消息时，向永远在线服务器发送举报通知。

本发明方法还包括：

针对心跳连接和应用推送通知的计费管理，并实现用户行为分析。其中，针对心跳连接和应用推送通知的计费管理包括：

预先在永远在线服务器中设置计费策略，可以包括但不限于：支持按条计费，如X元/100条心跳消息，Y元/100条应用推送通知；支持按周期计费，如X元/月，Y元/年；支持按应用等级计费，如普通应用：X元/月，高级应用：Y元/月，不同收费享受不同服务优先级；支持按应用开发者等级计费，如初级开发者A注册2个应用：X元/月，高级开发者B注册4个应用：Y元/月，不同收费享受不同服务优先级等。向现有计费系统发送计费触发请求，而BSS完成相应的批价、计费。BSS的具体实现属于本领域技术人员的公知技术，这里不再赘述。

本发明还包括：BSS针对不同的计费策略发布不同的产品；而永远在线服务器则根据不同的应用、不同开发者管理不同的计费策略，记录相应产品信息。比如：对应计费策略1为按条计费，且X元/100条，在BSS中发布为产品A；对应计费策略2为按周期计费，且X元/月，在BSS中发布为产品B；对应计费策略3为普通应用，且X元/月，在BSS中发布为产品C；且不同的产品对应各自的产品ID。相应地，永远在线服务器根据不同的场景，对应不同的计费策略，映射成不同的产品，在计费触发请求中，永远在线服务器根据不同的计费策略向BSS发送不同的请求，并将产品ID一并发送给BSS，BSS根据不同的产品执行相应的批价和扣费。

其中，根据心跳连接、应用推送通知的数据挖掘和统计分析，对用户行为进行估计，为应用开发者及运营商自身提供运营支撑。具体包括：

永远在线服务器可根据心跳连接或应用推送通知携带的信息，关联用户终端应用的名称、类别、使用频率、使用时间段等信息，以实现用户行为分析。比如：用户爱好分析，假设用户A终端内置的永远在线客户端频繁发送QQ、MSN、微信等心跳连接消息，接收这些应用的应用推送通知，可以分析出该用户是即时通信类软件的忠实用户；再如：用户使用习惯分析，假设用户B通过永远在线客户端设置时间从20：00～21：00不接收应用推送通知，则可以分析出该用户在此时间段内不希望被打扰，有重要事务正在进行。

虽然本发明所揭露的实施方式如上，但所述的内容仅为便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式及细节上进行任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims (8)

1.一种实现移动互联网应用永远在线的方法，其特征在于，基于应用层，终端应用客户端通过永远在线客户端和永远在线服务器，与终端应用服务端保持长连接；所述永远在线客户端内置于终端中，设置在终端操作系统之上，与终端一一对应，在一个终端中，多个终端应用客户端对应一个永远在线客户端；该方法还包括：

永远在线客户端接收来自各终端应用客户端的心跳连接，收敛后发送给永远在线服务器；永远在线服务器将接收到的心跳连接分发至对应的终端应用服务端；

当有第三方应用产生应用推送通知时，经由永远在线服务器处理后推送给永远在线客户端，再由永远在线客户端分发给终端应用客户端；

所述经由永远在线服务器处理后推送给永远在线客户端包括：所述永远在线服务器在同时接收到多条应用推送通知时，按照预先设置的应用等级或用户等级，将应用推送通知转发给所述永远在线客户端；

所述经由永远在线服务器处理后推送给永远在线客户端之前，该方法还包括：所述永远在线服务器对接收到的应用推送通知，按照预先设置的收敛策略处理；

所述永远在线服务器将接收到的心跳连接分发至对应的终端应用服务端包括：

当网络正常时，按照所述永远在线客户端的心跳连接请求频率，向对应的终端应用服务端转发心跳连接；当网络出现异常时，所述永远在线服务器通知永远在线客户端网络状况异常，所述永远在线客户端与永远在线服务器之间通过协商降低所述永远在线客户端的心跳连接请求频率后，再向对应的终端应用服务器端转发心跳连接。

2.根据权利要求1所述的方法，其特征在于，

所述经由永远在线服务器处理后推送给永远在线客户端之前还包括：

所述永远在线服务器根据预先设置的与终端应用服务端的应用推送通知对应的缓存时间段，在收到应用推送通知时，将存在对应的缓存时间段的应用推送通知，按照缓存时间段的时长缓存，在缓存时间段到达时再转发给永远在线客户端。

3.根据权利要求1所述的方法，其特征在于，该方法还包括：所述永远在线服务器实时监测网络状态，当网络拥塞时，按预先设置的最大应用推送通知数，缓存或拒绝应用推送通知。

4.根据权利要求1所述的方法，其特征在于，在所述永远在线服务器中预先设置用于保存终端应用服务端是否是垃圾终端应用服务端的第一黑白名单列表；该方法还包括：

所述永远在线服务器根据第一黑白名单列表，对接收到的垃圾通知消息进行过滤；

在所述永远在线客户端中预先设置用于保存终端应用服务端是否是垃圾终端应用服务端的第二黑白名单列表；该方法还包括：

所述永远在线客户端根据第二黑白名单列表，对接收到的应用推送通知进行过滤，在确定收到垃圾通知消息时，向所述永远在线服务器发送举报通知；

所述永远在线服务器接收到来自所述永远在线客户端的举报通知，将相应的终端应用服务端设置在所述第一黑白名单列表中。

5.一种实现移动互联网应用永远在线的系统，其特征在于，基于应用层，包括终端侧和网络侧，其中，终端侧至少包括：永远在线客户端、一个或一个以上终端应用客户端；网络侧至少包括永远在线服务器、一个或一个以上终端应用服务端；其中，

永远在线客户端内置于终端中，设置在终端操作系统之上，与终端一一对应；在一个终端中，多个终端应用客户端对应一个永远在线客户端；用于接收来自各终端应用客户端的心跳连接，收敛后发送给永远在线服务器；

永远在线服务器分别与永远在线客户端、各终端应用服务端相连；用于将接收到的心跳连接分发至对应的终端应用服务端；

永远在线服务器，在有第三方应用产生应用推送通知时，用于在同时接收到多条应用推送通知时，按照预先设置的应用等级或用户等级将应用推送通知转发给永远在线客户端；

所述永远在线服务器，还用于对接收到的应用推送通知，按照预先设置的收敛策略处理后再发送给所述永远在线客户端；在网络正常时，还用于按照永远在线客户端的心跳连接请求频率，向对应的终端应用服务器端转发心跳连接；在网络出现异常时，还用于通知永远在线客户端网络状况异常；所述永远在线客户端与永远在线服务器之间通过协商降低永远在线客户端的心跳连接请求频率后再向对应的终端应用服务器端转发心跳连接。

6.根据权利要求5所述的系统，其特征在于，所述永远在线服务器，还用于根据预先设置的与终端应用服务端的应用推送通知对应的缓存时间段，在收到应用推送通知时，将存在对应的缓存时间段的应用推送通知，按照缓存时间段的时长缓存，在缓存时间段到达时再转发给所述永远在线客户端。

7.根据权利要求5或6所述的系统，其特征在于，所述永远在线服务器，还用于实时监测网络状态，当网络拥塞时，按预先设置的最大应用推送通知数，缓存或拒绝应用推送通知；

所述永远在线客户端，用于接收来自永远在线服务器的应用推送通知，并分发给对应的终端应用客户端。

8.根据权利要求7所述的系统，其特征在于，所述永远在线服务器，其中预先设置有用于保存终端应用服务端是否是垃圾终端应用服务端的第一黑白名单列表，还用于根据第一黑白名单列表，对接收到的垃圾通知消息进行过滤；

所述永远在线客户端，其中预先设置有用于保存终端应用服务端是否是垃圾终端应用服务端的第二黑白名单列表，还用于根据第二黑白名单列表，对接收到的应用推送通知进行过滤，在确定收到垃圾通知消息时，向所述永远在线服务器发送举报通知；

所述永远在线服务器，还用于接收到来自所述永远在线客户端的举报通知，将相应的终端应用服务端设置在第一黑白名单列表中。