Android Push開源解決方案

在 Android 上，由於 Google 本身實現的 Android 標配的 GCM (Google Cloud Messaging，原來叫 C2DM) 在國內基本不可用，因此，對於開發者來講，若是須要 Push功能，怎麼樣選擇成爲了一個問題。

到目前爲止，國內尚沒有徹底向開發者免費、開放的 Push 服務可用。國外有幾家第三方推送服務，但通常都要收費。因此通常來講，國內的開發者不得不考慮本身來搭建 Push服務。

本身構建 Push服務時，一個比較天然的選擇就是，基於開源的如今方案來作。

使用 Google或者百度搜索 「Android Push 推送」等關鍵詞，代表已經有很多人研究過。排在前邊的是這樣幾篇文章：

• Android實現推送方式解決方案

• 用androidpn來實現推送

• Android上實現Push

• Android Push Notification實現信息推送使用

上面文章說起的方案裏，基本上都說起了一個開源的 Android Push實現: androidpn。

androidpn 它本質上服務器端基於 Openfire，客戶端基於 asmack，這兩者都最 XMPP  IM 開源實現裏的二個基本組件，應該說 androidpn 只是把兩者更多地結合起來用於作 Push的場景。

本人作過聊天App，願意在這裏，把基於 XMPP開源系統作 IM 的實踐經驗分享給你們。

咱們作聊天類App，比較天然地，剛開始時也是從研究開源的 XMPP IM 系統入手。

先說服務器端選擇。Openfire 是一個 XMPP  最古老的開源 IM Server，幾乎全部作 IM 的都應該有研究過。可是，它也是最不合適運用到生產的 IM Server，由於：單機併發頗有限，集羣方案不成熟，代碼古老而缺少及時更新。舉個具體的例子：Openfire 的集羣組件叫 Connection Manager，可是，你在 Openfire官方網站能夠看到，最近一個版本是 2009 年 2 月份發佈的。可見，基於 Openfire 實現的 androidpn 的根基是不夠穩的。

還有另外二個其實相對好一點的選擇： ejabberd, tigase。ejabberd 是用 Erlang語言實現的，懂 Erlang 的用戶不多，因此通常不會選。咱們當時初步的聊天服務器端選擇是 tigase。

tigase 做者維護很活躍，集羣測試結果可以支撐比較大的容量，這是吸引咱們的地方。但通過實際生產運營狀況來看，因爲其集羣方案實現的複雜性，以及單節點容量的有限，咱們對支撐到 50 萬用戶在集羣節點上沒有信心，因此在到達 50 萬用戶以前，趕快本身開發了替代方案。

再來講 XMPP 協議與客戶端的問題：對於移動客戶端來講，原始的 XMPP 有些複雜並且流量消耗大。XMPP 本質上協議體都在字符串的 xml 結構上，每一個協議都量一堆的字符串，xml裏還有不少無心義的結構。另外，XMPP爲了其靈活性，就登陸這個事情都須要有 N 個來回。對於手機客戶端很在意流量與電量來講，XMPP 比較笨重。

咱們的做法是：協議格式上改成二進制，協議內容上簡化交互，但保留對原始  XMPP的兼容。

androidpn 是開源的 Push 實現，是基於 XMPP 開源組件集成的，它沒有爲手機應用場景作必要的優化。另外，XMPP  本質上雙向 IM 協議，而直接基於 XMPP 來實現 Push 功能，也是沒有特別地爲  Push 的特色優化的，好比客戶端網絡鏈接的策略等。

總結一下以 androidpn 爲典型的開源 Android Push 方案會存在的問題：

１）容量大了開源服務器實現頂不住，仍是須要本身去改進開源實現，或者徹底從新用新方案，開發投入與高成本是不可避免的。

２）協議與實現上如流量消耗、網絡鏈接策略等，不是專門爲移動 Push 優化過的，是不經濟的。

基於咱們團隊基於 XMPP開源系統實現聊天App的實踐經驗，咱們得出的結論是，在移動端的 IM場景裏，開源方案不是個可用好用的方案。後來咱們本身徹底從新架構了整套系統。以後，正是基於這套全新架構的 IM 系統，演變出來了極光推送。

極光推送專門爲移動場景下的實時 Push 來研發，咱們想要去解決國內 Android 開發者沒有可用好用的 Push方案的問題，是免費的，徹底向普通開發者開放。若是你也有這個 Android Push 的需求，不妨到極光推送官方網站進一步地瞭解。

原始文章出處：http://blog.jpush.cn/index.php/android_push_opensource_androidpn_xmpp_openfire/