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