基于AndroidPN的可靠自定義推送系統(tǒng)實(shí)現(xiàn)

成煥宇 周紫薇

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

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

DOI：10.11907/rjdk.172798

中圖分類號(hào)：TP319

文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：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 引言

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

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

1 系統(tǒng)概述

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

消息推送如圖2所示。

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

對(duì)各個(gè)功能模塊的描述如下：

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

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

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

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

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

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

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

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

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

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

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

2.1 離線消息緩存機(jī)制

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

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

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

2.2 客戶端斷線重連模塊

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

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

2.3 多媒體消息推送模塊

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

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

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

3 實(shí)驗(yàn)測(cè)試

3.1 實(shí)驗(yàn)測(cè)試結(jié)果

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

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

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

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

3.2 性能測(cè)試

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

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

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

4 結(jié)語

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

參考文獻(xiàn)：

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

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

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

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

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

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

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

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

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

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

（責(zé)任編輯：江 艷）