Android Push 開源方案解析

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

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

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

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

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

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

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

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

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

更新:與一個基於 Openfire 作聊天App的朋友交流,他們的用戶量比較大,有多個 Openfire 節點作集羣。他們對 Openfire 作了不少改造,好比 XMPP 協議交互複雜,要簡化;XMPP 協議文本臃腫,則轉換爲二進制。集羣方面,則徹底是本身從新開發的。他們最多單點負載 30 萬用戶。 優化

還有另外二個其實相對好一點的選擇: ejabberdtigaseejabberd 是用 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 方案會存在的問題:

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

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

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

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

相關文章
相關標籤/搜索