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 的根基是不夠穩的。 更新：與一個基於 Openfire 做聊天App的朋友交流，他們的使用者量比較大，有多個 Openfire 節點做叢集。他們對 Openfire 做了很多改造，比如 XMPP 協議互動複雜，要簡化；XMPP 協議文本臃腫，則轉換為二進位。叢集方面，則完全是自己重新開發的。他們最多單點負載 30 萬使用者。 還有另外二個其實相對好一點的選擇： ejabberd, tigase。ejabberd 是用 Erlang語言實現的，懂 Erlang 的使用者很少，所以一般不會選。我們當時初步的聊天伺服器端選擇是 tigase (Java實現的)。 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情境裡，開源方案不是個可用好用的方案。後來我們自己完全重新架構了整套系統。