java推送技術

這段時間一直在做關於伺服器端向APP端推送訊息，查閱了大量的資料，這裡做下總結。

關於推送我們常見的推送有APP外推送，APP內推送。APP外推送有各大平臺極光，友盟等，而APP內的推送可以用的服務基本需要自己去實現，這裡我給大家介紹的就是關於APP內的推送技術，我會再下面的文章介紹如何實現APP內推送。

推送協議分類

這些是我從網上查詢出的協議對比

方案1、 使用GCM服務（Google Cloud Messaging）
簡介：Google推出的雲訊息服務，即第二代的G2DM。
優點：Google提供的服務、原生、簡單，無需實現和部署服務端。
缺點：Android版本限制（必須大於2.2版本），該服務在國內不夠穩定、需要使用者繫結Google帳號，受限於Google。

方案2、 使用XMPP協議（Openfire + Spark + Smack）
簡介：基於XML協議的通訊協議，前身是Jabber，目前已由IETF國際標準化組織完成了標準化工作。
優點：協議成熟、強大、可擴充套件性強、目前主要應用於許多聊天系統中，且已有開源的Java版的開發例項androidpn。
缺點：協議較複雜、冗餘（基於XML）、費流量、費電，部署硬體成本高。

簡介：輕量級的、基於代理的“釋出/訂閱”模式的訊息傳輸協議。
優點：協議簡潔、小巧、可擴充套件性強、省流量、省電，目前已經應用到企業領域（參考： http://mqtt.org/software ），且已有C++版的服務端元件rsmb。
缺點：不夠成熟、實現較複雜、服務端元件rsmb不開源，部署硬體成本較高。

方案4、 使用HTTP輪循方式
簡介：定時向HTTP服務端介面（Web Service API）獲取最新訊息。
優點：實現簡單、可控性強，部署硬體成本低。
缺點：實時性差。

從以上協議對比，可以看出第一種國內不可以使用排除，第四種效率太低不建議使用，然後就只有第二，三種可以選擇，然後我們繼續篩選。

mqtt協議比較靈活，但是需要實現東西太多，如果團隊人數足夠，時間充足可以自己去實現。
但是團隊人太少，我建議使用XMPP實現，因為實現簡單，開發快速，成本較小。

使用框架

在公司專案中經過各種討論對比，最終我們選擇了XMPP協議實現的推送服務。

經過對比在公司產品上，使用XMPP時，XMPP的缺點（協議較複雜、冗餘（基於XML）、費流量、費電，部署硬體成本高）
可以接受，在訊息內容上，只推送少量關鍵資料，主要的資料還是靠http拉取的方式，並且現在都是4G的情況下，XMPP的協議的缺點都是可以接受。XMPP的很多實現我們都可以使用，減少了我們開發的時間。

xmpp技術介紹

服務端元件Openfire

是開源的、基於可拓展通訊和表示協議(XMPP)、採用Java程式語言開發的實時協作伺服器。 Openfire安裝和使用都非常簡單，並利用Web進行管理。單臺伺服器可支援上萬併發使用者。

Java開發庫Smack

Smack是一個開源，易於使用的XMPP（jabber）客戶端類庫。

客戶端元件Spark

xmpp 客戶端元件，使用XMPP實現的聊天工具。

在專案中我們使用的就是smack庫進行XMPP訊息的推送，客戶端android和ios的實現也有相應的類庫。這裡不作介紹，我瞭解的都是伺服器端的實現。