移动互联网中多应用融合消息推送平台的设计与实现

移动互联网中多应用融合消息推送平台的设计与实现5摘要：随着移动设备中安装的应用数量越来越多，用户需要打开多个应才能够成功接收应用的通知消息，这样导致的问题在于对移动终端电量和流量的较大消耗。业界现有的一些解决案没有对该问题进行较好的改进，它们存在系统依赖性较强或信息集成等方面的问题。同时，因为移动终端消息PUSH的特点，消息发布者发布消息所需成本也是很大的。本文中提出了一种应用融合消息推送平台的解决方案，它可以在保证用户接受消息准确性和即时性的情况下，有效解决移动终端消耗电量和流量较大的问题，并为消息发布者提供了更方便的消息发布方案。关键词：移动互联网；融合通知；消息推送；消息发布中图分类号：TP3991015TheDesignandRealizeofConvergenceNotificationPlatforminMobileInternetCHENZhe,XUPeng20(BeijingUniversityofPostsandTelecommunications,InstituteofNetworkTechnology,Beijing100876)Abstract:Astheapplicationsinthemobiledeviceincreased,theuserneedtoopensomeofthematthesametimesoastoreceivethenotificationssuccessfully.Inthiscase,theelectricityanddataflowiswastedunnecessarily.Someofthesolutionstothisproblemexistalotoflimitations,likesystemdependencyandmessageintegration.Atthesametime,asthespecialtyofpushinMobileInternet,italsocostsalottopublishamessage.Inthispaper,itputsforwardaConvergenceNotificationPlatformtodecreasetheelectricityanddatacost.Atthesametime,itcanmakesuretheaccuracyandimmediacyofthemessage.Alsotheplatformoffersawaytothemobilemessagepublisher.Keywords:Mobileinternet;Convergencenotification;Messagepush;Messagepublish25300引言随着信息产业的快速发展以及互联网的广泛普及，人们对于相关硬件设备的需求也达到了近些年来的高峰期，据预测，2015年全球的网络互联设备将超过150亿台，而以手机为代表的移动终端产品已经有慢慢取代PC的趋势。随着智能终端的硬件性能越来越强，其上35安装的应用数量也越来越多（每台智能设备上安装应用的平均数量为41个），人们的生活和娱乐因为有了这些应用而变得更加丰富，但这也带来了一些相应的问题：流量问题和手机耗电量问题。产生这种问题的原因在于移动应用中，消息的PUSH方式取代了传统互联网中用户主动GET信息的方式[1]，而实现这种方式的前提是需要移动设备同时运行多个应用，这样会使移动设备本来就存在的电量问题扩大化，而且会浪费用户的流量。同时，因为移动40终端PUSH的特点，信息发布者向用户推送消息必须要有自己的APP应用，这极大的增加了消息发布者发布信息的难度。-1-1融合消息推送平台1.1现存解决方案针对移动设备中多融合应用消息接收电量、流量消耗以及消息发布的问题，现在业界存45在以下解决方案：客户端轮询方式[2]：客户端周期性的去连接服务器获得数据信息，这种方式的实时性不强，而且如果每个应用都要进行轮询对移动终端的电量和流量是消耗很大的。WAPPUSH方式[3]：是应用比较广泛的一种方式，主要用于运营商SP业务的推广和拓展。其中，PUSH的内容以IP包进行封装，并通过TCP/IP协议发送到手机终端。这种方式50可以对内容字段进行特定的标示，进而形成链接使用户在手机侧可以直接操作，从而达到对SP业务进行推广的目的。但问题在于其内容的形式相对还是比较单一，而且采用这种方式要跟运营商合作，难度较大。苹果的APNS服务[1]：APNS是苹果公司为解决IOS设备上多应用消息通知而设计的一套解决方案。在这套系统中，第三方应用服务器将需要推送的消息发送至苹果的推送服务器，55然后推送服务器再将消息发送至苹果的终端设备，设备和苹果推送服务器间通过一个叫做DeviceToken的标示进行匹配。这种方式在一定意义上可以解决多应用消息推送的问题，但是缺点是对于移动终端系统的依赖性较强，而且消息发布者发布消息必须要首先开发相应的APP，成本较高。Google的C2DM服务[4]：C2DM服务可帮助第三方应用将消息推送到Android设备上，60终端设备上的应用程序无需运行，在消息到达后，Android系统使用Intent机制将相应的应用程序唤醒进行处理。同样，该解决方案的缺点也是对于移动终端系统的依赖性问题和消息发布者成本的问题。1.2融合消息推送系统方案通过以上分析可以看出，现在对于移动终端上多应用的各种推送方案存在各种各样的问65题，本文提出了一种融合消息推送系统，在解决了移动终端耗电量和流量问题的同时，也提供了一种综合消息（非针对APP）的PUSH机制。图1融合消息推送系统流程70图1中说明了融合消息推送系统的推送流程，以下为对系统各部分的功能描述：-2-消息发布平台。系统支持发布者发布富文本的消息类型，包括超链接、图片、特殊文本、音视频等。这些多媒体信息类型主要是针对综合消息发布者，用户可以使用系统的发布平台发布这些富文本信息。服务器端融合。系统拥有自己的消息推送服务器，可以接收第三方应用推送的消息，并75将消息通知推送到指定的移动终端，此终端没有设备类型的限制，也没有操作系统的限制。同时，服务器与客户端之间的交互采用TCP长连接的方式[5-6]，每6min客户端向服务器发送保活消息，如果服务器确定客户端不在线则会对收到的信息进行存储，待客户端上线后再发送消息，从而提供消息离线接收的功能。客户端融合。针对不同系统的客户端开发不同的客户端应用程序，对应用及其他综合信80息进行整合。接收到的信息处理分为两部分：APP消息，展示消息的通知信息，点击之后打开指定的应用；综合型信息，在客户端中直接展示消息的内容，其中内容均进行了进一步的客户端适配，使用户可以获得更好的阅读体验。智能通知模式。系统支持对于平台发布侧和客户端接收侧的通知模式设定，如用户可选择接收消息的应用及发布者、接收消息的时间段和消息类型等；消息发布者则可以指定消息85接收者的范围、定时发送等。2系统实现2.1消息发布平台设计消息发布平台为消息发布者提供了便捷的消息发布解决方案，发布者无需开发相应的客户端应用即可实时的向用户发送富文本信息，而且这种信息与移动平台无关，一经发送即可90被不同移动系统的用户接收。消息发布平台主要包括两个部分，消息发布系统和群组管理系统。-3-95图2freeGroup接口的基本流程图2为消息发布平台具体使用freeGroup接口的流程，利用群组管理接口可以完成系统的群组管理功能。以下为对两部分功能部件的描述：消息发布系统：使用百度富文本编辑器进行文本的编辑，使用户可以发布包括编辑文本（粗体、斜体等）、图片及超链接等内容。群组管理系统：使用子系统freeGroup提供处理群组关系的功能。消息发布平台使用了其群组创建、查询、更新等功能。1002.2融合推送服务器设计融合推送服务器负责接收第三方应用和消息发布平台发布的消息，并将第三方应用消息的通知和消息发布平台的具体消息内容发送至融合客户端。融合推送服务器具有存储离线消息的功能，一旦发现客户端不在线，则暂时将消息存储到离线消息队列，侦测到客户端上线之后将消息发送至客户端。105-4-110图3推送服务器架构图融合推送服务器的架构如图3所示。服务器是基于Openfire开源框架开发[7-9]，服务器与信息发布平台交互的部分以插件的形式运行在Openfire框架之上。推送服务器以REST接口的形式向消息发布平台提供服务，为了提升推送服务器的并发请求处理能力，使用NGIX将请求定向到流量控制模块。推送服务器与客户端建立并维护XMPP连接、用户登陆及注销、用户认证、即时消息推送以及离线消息推送功能均复用Openfire中的代码。Openfire框架本身维护着一个数据库，而推送服务器运行在Openfire之上，由于Openfire提供了较好115的数据库访问接口和插件构建数据表的机制，推送服务器使用的数据表也在Openfire的数据库中。2.3融合客户端设计融合客户端的架构设计实现两部分功能：UI呈现与推送消息的接收。这两部分需要实现一定程度上的解耦。-5-120推送模块架构设计如图4所示。推送模块的连接、登录、保活、注销操作直接在Asmack上封装。推送管理器要向UI层提供两个接口，注册推送服务接口和推送接收器接口。UI层125可以向推送模块注册推送服务，这样当融合推送服务器将新的消息推送到客户端时，客户端使用推送接收器将消息转发至UI层，消息的解析与呈现由UI层来实现。-6-130UI层架构设计如下图5所示。UI层本身采用MVC模式实现[10]，当综合消息发布者的推送的消息到达时，UI层从消息发布平台下载消息，下载完成后，将底层数据存储在Sqlite中，向用户发出通知；如果是第三方应用发布的通知消息，则直接从第三方应用接口处获得通知内容，进行呈现。3测试验证3.1流量135测试方案：使用八部终端，其中四部使用推送系统进行应用的保活，并测试保活流量消耗；另外四部使用正常的多应用保活机制（不接受任何应用的通知），测试保活流量消耗。测试时间为5天。测试工具：海卓上网大师140的1/4。表1流量消耗测试结果流量消耗测试结果如表1所示。采用融合通知推送系统后终端的保活流量可减少到原来3.2耗电量145测试方案：使用四部小米手机进行耗电量测试，其中两部使用推送系统并且接收消息，另外两部则测试微信消耗流量，接收的消息条数和内容与推送系统相当。测试时间为2天。测试工具：小米手机自带电量测试工具。表2电量消耗测试结果150耗电量测试结果如表2所示。采用融合通知推送系统的耗电量与微信相当。3.3推送消息可靠性测试方案：使用四部手机接收通过消息发布平台发布的消息，测试消息到达客户端的成功率及消息展示的正确性。155-7-160消息推送可靠性测试结果如表3所示。融合通知推送系统具有相当高的消息到达可靠性和消息显示正确率。4结论165本文给出了一种基于即时消息的融合通知推送系统解决方案。通过融合推送服