Android Push開源方案解析
作者：佚名
在 Android 上，因為 Google 自己實現(xiàn)的 Android 標(biāo)配的 GCM (Google Cloud Messaging，原來叫 C2DM) 在國內(nèi)基本不可用，所以，對于開發(fā)者來說，如果需要 Push功能，怎么樣選擇成為了一個問題。
| 在 Android 上，因為 Google 自己實現(xiàn)的 Android 標(biāo)配的 GCM (Google Cloud Messaging，原來叫 C2DM) 在國內(nèi)基本不可用，所以，對于開發(fā)者來說，如果需要 Push功能，怎么樣選擇成為了一個問題。 到目前為止，國內(nèi)尚沒有完全向開發(fā)者免費、開放的 Push 服務(wù)可用。國外有幾家第三方推送服務(wù)，但一般都要收費。所以一般來說，國內(nèi)的開發(fā)者不得不考慮自己來搭建 Push服務(wù)。 自己構(gòu)建 Push服務(wù)時，一個比較自然的選擇就是，基于開源的現(xiàn)在方案來做。 使用 Google或者百度搜索 “Android Push 推送”等關(guān)鍵詞，表明已經(jīng)有不少人研究過。排在前邊的是這樣幾篇文章：
上面文章提及的方案里，基本上都提及了一個開源的 Android Push實現(xiàn): androidpn。 androidpn 它本質(zhì)上服務(wù)器端基于 Openfire，客戶端基于 asmack，這二者都最 XMPP IM 開源實現(xiàn)里的二個基本組件，應(yīng)該說 androidpn 只是把二者更多地結(jié)合起來用于做 Push的場景。 筆者做過聊天App，愿意在這里，把基于 XMPP開源系統(tǒng)做 IM 的實踐經(jīng)驗分享給大家。 我們做聊天類App，比較自然地，剛開始時也是從研究開源的 XMPP IM 系統(tǒng)入手。 先說服務(wù)器端選擇。Openfire 是一個 XMPP 最古老的開源 IM Server，幾乎所有做 IM 的都應(yīng)該有研究過。但是，它也是最不合適運用到生產(chǎn)的 IM Server，因為：單機(jī)并發(fā)很有限，集群方案不成熟，代碼古老而缺乏及時更新。舉個具體的例子：Openfire 的集群組件叫 Connection Manager，但是，你在 Openfire官方網(wǎng)站可以看到，最近一個版本是 2009 年 2 月份發(fā)布的。可見，基于Openfire 實現(xiàn)的 androidpn 的根基是不夠穩(wěn)的。 更新：與一個基于 Openfire 做聊天App的朋友交流，他們的用戶量比較大，有多個 Openfire 節(jié)點做集群。他們對 Openfire 做了很多改造，比如 XMPP 協(xié)議交互復(fù)雜，要簡化；XMPP 協(xié)議文本臃腫，則轉(zhuǎn)換為二進(jìn)制。集群方面，則完全是自己重新開發(fā)的。他們最多單點負(fù)載 30 萬用戶。 還有另外二個其實相對好一點的選擇： ejabberd, tigase。ejabberd 是用 Erlang語言實現(xiàn)的，懂 Erlang 的用戶很少，所以一般不會選。我們當(dāng)時初步的聊天服務(wù)器端選擇是 tigase (Java實現(xiàn)的)。 tigase 作者維護(hù)很活躍，集群測試結(jié)果能夠支撐比較大的容量，這是吸引我們的地方。但經(jīng)過實際生產(chǎn)運營情況來看，由于其集群方案實現(xiàn)的復(fù)雜性，以及單節(jié)點容量的有限，我們對支撐到 50 萬用戶在集群節(jié)點上沒有信心，所以在到達(dá) 50 萬用戶之前，趕快自己開發(fā)了替代方案。 再來說 XMPP 協(xié)議與客戶端的問題：對于移動客戶端來說，原始的 XMPP 有些復(fù)雜而且流量消耗大。XMPP 本質(zhì)上協(xié)議體都在字符串的 xml 結(jié)構(gòu)上，每個協(xié)議都量一堆的字符串，xml里還有很多無意義的結(jié)構(gòu)。另外，XMPP為了其靈活性，就登錄這個事情都需要有 N 個來回。對于手機(jī)客戶端很在乎流量與電量來說，XMPP 比較笨重。 我們的作法是：協(xié)議格式上改為二進(jìn)制，協(xié)議內(nèi)容上簡化交互，但保留對原始 XMPP的兼容。 androidpn 是開源的 Push 實現(xiàn)，是基于 XMPP 開源組件集成的，它沒有為手機(jī)應(yīng)用場景做必要的優(yōu)化。另外，XMPP 本質(zhì)上雙向 IM 協(xié)議，而直接基于 XMPP 來實現(xiàn) Push 功能，也是沒有特別地為 Push 的特點優(yōu)化的，比如客戶端網(wǎng)絡(luò)連接的策略等。 總結(jié)一下以 androidpn 為典型的開源 Android Push 方案會存在的問題： １）容量大了開源服務(wù)器實現(xiàn)頂不住，還是需要自己去改進(jìn)開源實現(xiàn)，或者完全重新用新方案，開發(fā)投入與高成本是不可避免的。 ２）協(xié)議與實現(xiàn)上如流量消耗、網(wǎng)絡(luò)連接策略等，不是專門為移動 Push 優(yōu)化過的，是不經(jīng)濟(jì)的。 基于我們團(tuán)隊基于 XMPP開源系統(tǒng)實現(xiàn)聊天App的實踐經(jīng)驗，我們得出的結(jié)論是，在移動端的 IM場景里，開源方案不是個可用好用的方案。后來我們自己完全重新架構(gòu)了整套系統(tǒng)。之后，正是基于這套全新架構(gòu)的 IM 系統(tǒng)，演變出來了極光推送。 極光推送專門為移動場景下的實時 Push 來研發(fā)，我們想要去解決國內(nèi) Android 開發(fā)者沒有可用、好用的 Push方案的問題，是免費的，完全向普通開發(fā)者開放。如果你也有這個 Android Push 的需求，不妨到極光推送官方網(wǎng)站進(jìn)一步地了解。 |
責(zé)任編輯：冰凝兒
