成煥宇 周紫薇

摘 要：針對目前Android系統(tǒng)自帶推送服務(wù)不穩(wěn)定及第三方推送服務(wù)不安全問題，采用MINA框架、XMPP協(xié)議、Asmack等相關(guān)技術(shù)，并以開源AndroidPN作為實現(xiàn)基礎(chǔ)，設(shè)計了離線緩存機制和斷線重連功能，實現(xiàn)了一個可靠的自定義推送系統(tǒng)，增加了多媒體消息推送，滿足了當前信息多樣化需求。實驗結(jié)果表明，該系統(tǒng)穩(wěn)定性高、安全性強，能夠保證一定的消息達到率，具有一定推廣及使用價值。

關(guān)鍵詞：消息推送；MINA；XMPP；Asmack

DOI：10.11907/rjdk.172798

中圖分類號：TP319

文獻標識碼：A 文章編號：1672-7800（2018）005-0083-03

Abstract：Mobile messaging suffers from problems like instability of the Android system service and third-party push service insecurity. In order to meet the arrival rate of certain push messages， this paper applies MINA framework， XMPP protocol， Asmack and other related technologies， and employs open source AndroidPN as the basis for the realization of the design of the offline cache mechanism and disconnection function in the achievement of a reliable user defined push system so as to increase the push of multimedia messages and meet the needs of the current diversification of information. It is confirmed that the system has high stability and strong security to guarantee certain rate of news arrival， and thus has market and application value.

Key Words：message push； MINA； XMPP； Asmack

0 引言

隨著移動通信技術(shù)的快速發(fā)展和Web應(yīng)用技術(shù)的不斷提高，移動端成為人們獲取消息的主要途徑。依據(jù)傳輸方式，消息推送可以分為拉取和推送兩大類。拉取一般采用輪詢方式實現(xiàn)，但如果輪詢的頻率太快會消耗大量移動端的流量和電量，如果太慢則會導致消息延遲，甚至導致重要消息遺漏， 所以適用場景有限。而推送方式是指服務(wù)器主動給客戶端推送消息，不但可以控制數(shù)據(jù)的傳輸，使其盡量迅速地抵達用戶端，而且可以最大程度地降低網(wǎng)絡(luò)流量與系統(tǒng)資源損失[1]。推送的實現(xiàn)方式一般都是通過客戶端向服務(wù)器發(fā)送心跳包來維持TCP長連接[2]。

Android系統(tǒng)自身提供GCM（Google Cloud Messaging）服務(wù)，但是Google對每一個應(yīng)用能夠發(fā)送的總消息數(shù)以及向一臺特定設(shè)備發(fā)送的消息數(shù)作出了限制，而且在Android客戶端能運行GCM有一定的條件限制[3]：很多情況下需要用戶在移動設(shè)備上綁定谷歌賬號，容易導致用戶隱私泄露。并且由于國內(nèi)對于Google服務(wù)有一定的限制，使得Google推送服務(wù)不穩(wěn)定。目前一般都選擇第三方實現(xiàn)自己的推送需求，市場上有許多第三方推送服務(wù)，比如極光推送等。但是第三方推送需要連接第三方公司的服務(wù)器，可能會產(chǎn)生數(shù)據(jù)不安全[4]，對于一些重要的功能需要收費而且不能保證消息一定到達客戶端。這樣使得第三方推送在特定的應(yīng)用場景中存在一定的缺陷，比如在水費繳費類型的APP中需要推送用戶欠費通知、用戶繳費以及用戶用水情況等，保證客戶一定能收到推送消息以及涉及用戶的一些敏感信息。本文實現(xiàn)的推送系統(tǒng)以滿足一定的推送消息到達率為約束條件，實現(xiàn)對于推送消息是否已到達客戶端必須有明確的反饋?；谝陨戏治觯疚脑陂_源AndroidPN的基礎(chǔ)上實現(xiàn)一個推送系統(tǒng)。本系統(tǒng)根據(jù)客戶端是否接收到消息反饋決定是否將消息保存到服務(wù)器，當客戶端再次上線時將服務(wù)器里未接收的消息推送給客戶端，以及客戶端在網(wǎng)絡(luò)不穩(wěn)定或進行網(wǎng)絡(luò)切換時主動與服務(wù)器進行重連，因而需要設(shè)計具有推送消息的離線緩存機制和客戶端斷線重連功能，并增加多媒體消息推送以滿足當前信息多樣化框架需求，保證每條推送消息都能到達客戶端，最大程度上保證消息的到達率。

1 系統(tǒng)概述

本系統(tǒng)總體分為3個主要功能模塊：離線消息推送模塊、客戶端斷線重連模塊、富媒體消息推送模塊。系統(tǒng)總體如圖1所示。

消息推送如圖2所示。

如圖2所示，推送消息通過推送管理員將消息推送出去。推送的消息可以根據(jù)推送設(shè)備在服務(wù)器注冊生成的唯一標識進行推送[5]，客戶端收到推送消息就會向服務(wù)器發(fā)送一條反饋消息，進而服務(wù)器將推送的消息在數(shù)據(jù)庫中刪除。

對各個功能模塊的描述如下：

（1）離線消息緩存機制：主要是解決服務(wù)器向客戶端推送消息但客戶端未收到的情況。為了保證消息推送能滿足到達率的要求，在推送消息時，如果用戶不在線，則需要將消息保存到數(shù)據(jù)庫中，當用戶下次上線并推送消息時先在數(shù)據(jù)庫中查找并推送給用戶，為此需設(shè)計一個離線消息緩存的機制。

（2）斷線重連模塊：為了保證消息推送能滿足到達率的要求，當客戶端網(wǎng)絡(luò)狀態(tài)不好或者網(wǎng)絡(luò)狀態(tài)發(fā)生改變以及用戶登錄異常時，客戶端能自動與服務(wù)器建立連接從而保證客戶端在線接收推送消息。為此需增加斷線重連機制。

（3）多媒體消息推送模塊：為了滿足當前信息多樣化需求，推送消息可能是圖片等多媒體信息，通過增加多媒體消息推送模塊滿足這一需求。

2 各模塊設(shè)計與實現(xiàn)

本系統(tǒng)的推送是基于XMPP協(xié)議實現(xiàn)的，其一個消息的推送需要經(jīng)過以下幾個步驟[6]：

（1）客戶端與服務(wù)器建立連接。

（2）客戶端在服務(wù)器中進行注冊和登錄。

（3）客戶端接收服務(wù)器推送的消息。

客戶端在服務(wù)器中登錄注冊流圖如圖3所示。

由圖3所示，如果服務(wù)器數(shù)據(jù)庫中有此客戶端對應(yīng)的信息則登錄成功，否則將此客戶端的信息保存至數(shù)據(jù)庫再進行登錄操作。

具體過程如下：首先客戶端要向服務(wù)器發(fā)送會話請求，主要是將XML數(shù)據(jù)發(fā)送到服務(wù)器的IP地址，當服務(wù)器接收到XML數(shù)據(jù)[7]后，服務(wù)器會向請求連接的客戶端分配一個唯一ID以及指定客戶端的IP地址，如果客戶端與服務(wù)器握手成功，則客戶端初始化新的流給服務(wù)器，反之，則關(guān)閉TCP連接。為了在服務(wù)器上注冊和登錄，客戶端需要將賬號、加密的密碼以及資源名發(fā)給服務(wù)器。如果服務(wù)器有這個賬號則登錄成功；如果沒有，服務(wù)器需要發(fā)送數(shù)據(jù)告知客戶端數(shù)據(jù)庫中沒有此用戶，客戶端接收到反饋后，需要向服務(wù)器發(fā)送注冊請求。服務(wù)器接收到請求后會向數(shù)據(jù)庫中插入此用戶。完成注冊后，客戶端和服務(wù)器再進行一次交互就能完成登錄。當客戶端登錄服務(wù)器后，服務(wù)器進行消息推送，這樣就實現(xiàn)了推送的基本過程。

2.1 離線消息緩存機制

離線消息緩存是為了保證推送消息到達率及增加用戶體驗。當客戶端掉線時，用戶無法及時收到服務(wù)器推送的消息。為了使消息不被遺漏，離線消息緩存使客戶端再次上線時依然能收到服務(wù)器推送的消息，即將客戶端未收到的消息保存到數(shù)據(jù)庫中，當用戶再次上線時優(yōu)先通過數(shù)據(jù)庫，將消息發(fā)送到對應(yīng)的客戶端。

離線消息緩存流程如圖4所示。

如圖4所示，當服務(wù)器未收到客戶端接收消息的反饋時，就會把這條消息保存到數(shù)據(jù)庫中。每當有客戶端連接上服務(wù)器時，服務(wù)器會優(yōu)先查找是否有客戶端未接收到的消息，如果有就將這條消息推送給對應(yīng)的客戶端，直到客戶端接收到此條消息并返回反饋消息時該消息才會從服務(wù)器數(shù)據(jù)庫中刪除。

2.2 客戶端斷線重連模塊

客戶端與服務(wù)器的連接會經(jīng)過連接、注冊、登錄3個過程[8]，當客戶端網(wǎng)絡(luò)狀態(tài)發(fā)生改變以及連接、注冊、登錄出現(xiàn)異常時需要啟動重連操作，確保出現(xiàn)上述狀況后能及時連上服務(wù)器。

上述3個過程分別用3個線程控制并放在TaskList列表中以確保3個線程的執(zhí)行順序。若其中一個過程發(fā)生異常則需要將已經(jīng)添加入任務(wù)列表的任務(wù)刪除再啟動重連線程。當網(wǎng)絡(luò)狀態(tài)發(fā)生改變時客戶端需要進行重連操作，若網(wǎng)絡(luò)斷開，客戶端需要主動關(guān)閉連接，以便網(wǎng)絡(luò)連接后能恢復(fù)。

2.3 多媒體消息推送模塊

多媒體消息是重要的信息媒介，所以具有穩(wěn)定的推送系統(tǒng)集成功能十分必要。本節(jié)主要以圖片信息為例介紹多媒體信息推送。由于推送系統(tǒng)的通信協(xié)議基于XMPP協(xié)議[9]，但是XMPP協(xié)議只能傳輸二進制流，所以導致推送系統(tǒng)無法推送圖片等多媒體信息[10]。因此，本文結(jié)合HTTP協(xié)議解決XMPP協(xié)議的這個缺點。

圖片消息推送流圖如圖5所示。

由圖5可知，通過瀏覽器將圖片上傳到服務(wù)器，服務(wù)器將圖片保存到本地文件中，然后將存放圖片的URL放入推送消息中，客戶端可以根據(jù)解析出來的URL從服務(wù)器獲取圖片并在終端顯示出來，從而實現(xiàn)圖片消息推送。其它多媒體消息推送思路類似。

3 實驗測試

3.1 實驗測試結(jié)果

推送消息時將客戶端網(wǎng)絡(luò)關(guān)閉，消息記錄在數(shù)據(jù)庫中，如圖6所示。

在客戶端中增加歷史消息記錄功能，可以展示所有推送消息的歷史記錄?？蛻舳送扑拖v史記錄，如圖7所示。

當客戶端接收到消息之后，服務(wù)器端離線消息數(shù)據(jù)庫如圖8所示。

通過一定數(shù)據(jù)量的測試，在客戶端離線后推送的消息都可以在客戶端上線時推送給客戶端，到達率有一定的保證。

3.2 性能測試

為了確定服務(wù)器在負載逐漸增加時的性能，對推送消息的到達率進行測試。服務(wù)器端配置如表1所示。

其中，每個客戶端最多發(fā)起25 000個連接，在所有連接建立完成后，分別進行1～100、1～1 000以及全體的推送。測試各種情況下所需的時間、推送成功率和服務(wù)器負載情況，結(jié)果如表2所示。

可以看到在局域網(wǎng)絡(luò)環(huán)境下所有消息的到達率都是100%，推送時間延遲主要取決于推送消息數(shù)量。

4 結(jié)語

本文實現(xiàn)了一個可靠的自定義推送系統(tǒng)，并根據(jù)具體需求進行相應(yīng)的功能擴展。系統(tǒng)測試表明，各個功能模塊能正常工作，滿足對消息到達率有一定要求的應(yīng)用場景，可以應(yīng)用到實際項目中。本系統(tǒng)基于XMPP協(xié)議實現(xiàn)消息推送，由于XMPP協(xié)議比較復(fù)雜、冗余、費流量等缺點，導致該系統(tǒng)在流量和電量的消耗控制方面不是很好。同時當用戶達到一定規(guī)模后，本系統(tǒng)使用的MINA框架對于單臺服務(wù)器的連接數(shù)不足，而且離線消息推送模塊對于數(shù)據(jù)庫的操作存在一定瓶頸，后期希望在流量和電量的控制方面能進行深度優(yōu)化。

參考文獻：

[1] 陳怡馨.基于JavaEE與Android的消息推送系統(tǒng)的研究與實現(xiàn)[J].中國新通信，2016，18（23）：37-38.

[2] 沈曉.TCP異步長連接的選擇及心跳處理機制的實現(xiàn)[J].中國金融電腦，2014（4）：37-39.

[3] Wikipedia.Google Cloud Messaging[EB/OL].2015-11-20.

[4] 張長學，張偉，董智明.移動推送技術(shù)面面觀[J].移動通信，2011，35（5）：21-27.

[5] 陳三清，殷鵬.基于Android平臺的推送技術(shù)應(yīng)用設(shè)計與實現(xiàn)[J].無線互聯(lián)科技，2017（14）：44-47.

[6] 汪海占，邸萌，黃祥林.基于XMPP協(xié)議的Android消息推送設(shè)計與實現(xiàn)[J].科技廣場，2015（2）：40-46.

[7] 施濟瑜，苗放，王華軍，李剛.基于XMPP協(xié)議文件傳輸?shù)难芯颗c實現(xiàn)[J].計算機測量與控制，2009，17（4）：732-733+741.

[8] 張雷，金德.基于Push通道客戶端的智能心跳機制研究與優(yōu)化[J].工業(yè)控制計算機，2013，26（1）：82-84.

[9] 孫澤軍，常新峰.基于XMPP推送技術(shù)在移動OA中的應(yīng)用研究[J].實驗室研究與探索，2015，34（7）：130-134.

[10] SAINT-ANDRE P. Stream XML with Jabber/SMPP[J].IEEE Internet Computing，2005，9（5）：82-89.

（責任編輯：江 艷）