DNF每日簽到送豪
lol7月神秘商店
LOL黑市亂斗怎么
LOL英雄成就標志相關資訊
本類常用軟件
-
福建農村信用社手機銀行客戶端下載下載量：584212
-
Windows優化大師下載量：419723
-
90美女秀(視頻聊天軟件)下載量：366966
-
廣西農村信用社手機銀行客戶端下載下載量：365708
-
快播手機版下載量：325898
騎自行車的正確
在校大學生該如
微信朋友圈怎么
microsoft Yahei', Simsun; font-size: 14px; line-height: 21px; ">在 Android 上，因為 Google 自己實現的 Android 標配的 GCM (Google Cloud Messaging，原來叫 C2DM) 在國內基本不可用，所以，對于開發者來說，如果需要 Push功能，怎么樣選擇成為了一個問題。
到目前為止，國內尚沒有完全向開發者免費、開放的 Push 服務可用。國外有幾家第三方推送服務，但一般都要收費。所以一般來說，國內的開發者不得不考慮自己來搭建 Push服務。
自己構建 Push服務時，一個比較自然的選擇就是，基于開源的現在方案來做。
使用 Google或者百度搜索 “Android Push 推送”等關鍵詞，表明已經有不少人研究過。排在前邊的是這樣幾篇文章：
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場景里，開源方案不是個可用好用的方案。后來我們自己完全重新架構了整套系統。之后，正是基于這套全新架構的 IM 系統，演變出來了極光推送。
極光推送專門為移動場景下的實時 Push 來研發，我們想要去解決國內 Android 開發者沒有可用、好用的 Push方案的問題，是免費的，完全向普通開發者開放。如果你也有這個 Android Push 的需求，不妨到極光推送官方網站進一步地了解。
到目前為止，國內尚沒有完全向開發者免費、開放的 Push 服務可用。國外有幾家第三方推送服務，但一般都要收費。所以一般來說，國內的開發者不得不考慮自己來搭建 Push服務。
自己構建 Push服務時，一個比較自然的選擇就是，基于開源的現在方案來做。
使用 Google或者百度搜索 “Android Push 推送”等關鍵詞，表明已經有不少人研究過。排在前邊的是這樣幾篇文章：
- Android實現推送方式解決方案
- 用androidpn來實現推送
- Android上實現Push
- Android Push Notification實現信息推送使用
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場景里，開源方案不是個可用好用的方案。后來我們自己完全重新架構了整套系統。之后，正是基于這套全新架構的 IM 系統，演變出來了極光推送。
極光推送專門為移動場景下的實時 Push 來研發，我們想要去解決國內 Android 開發者沒有可用、好用的 Push方案的問題，是免費的，完全向普通開發者開放。如果你也有這個 Android Push 的需求，不妨到極光推送官方網站進一步地了解。
熱門評論
最新評論