在 android 上，因為 google 自己實現的 android 標配的 gcm (google cloud messaging，原來叫 c2dm) 在國內基本不可用，所以，對於開發者來說，如果需要 push功能，怎麼樣選擇成為了乙個問題。
到目前為止，國內尚沒有完全向開發者免費、開放的 push 服務可用。國外有幾家第三方推送服務，但一般都要收費。所以一般來說，國內的開發者不得不考慮自己來搭建 push服務。
自己構建 push服務時，乙個比較自然的選擇就是，基於開源的現在方案來做。
上面文章提及的方案裡，基本上都提及了乙個開源的 android push實現: androidpn。
androidpn 它本質上伺服器端基於 openfire，客戶端基於 asmack，這二者都最 xmpp im 開源實現裡的二個基本元件，應該說 androidpn 只是把二者更多地結合起來用於做 push的場景。
先說伺服器端選擇。openfire 是乙個 xmpp 最古老的開源 im server，幾乎所有做 im 的都應該有研究過。但是，它也是最不合適運用到生產的 im server，因為：單機併發很有限，集群方案不成熟，**古老而缺乏及時更新。舉個具體的例子：openfire 的集群元件叫connection manager，但是，你在openfire官方**可以看到，最近乙個版本是 2009 年 2 月份發布的。可見，基於 openfire 實現的 androidpn 的根基是不夠穩的。
還有另外二個其實相對好一點的選擇： ejabberd, tigase。ejabberd 是用 erlang語言實現的，懂 erlang 的使用者很少，所以一般不會選。我們當時初步的聊天伺服器端選擇是 tigase。
tigase 作者維護很活躍，集群測試結果能夠支撐比較大的容量，這是吸引我們的地方。但經過實際生產運營情況來看，由於其集群方案實現的複雜性，以及單節點容量的有限，我們對支撐到 50 萬使用者在集群節點上沒有信心，所以在到達 50 萬使用者之前，趕快自己開發了替代方案。
再來說 xmpp 協議與客戶端的問題：對於移動客戶端來說，原始的 xmpp 有些複雜而且流量消耗大。xmpp 本質上協議體都在字串的 xml 結構上，每個協議都量一堆的字串，xml裡還有很多無意義的結構。另外，xmpp為了其靈活性，就登入這個事情都需要有 n 個來回。對於手機客戶端很在乎流量與電量來說，xmpp 比較笨重。
我們的作法是：協議格式上改為二進位制，協議內容上簡化互動，但保留對原始 xmpp的相容。
androidpn 是開源的 push 實現，是基於 xmpp 開源元件整合的，它沒有為手機應用場景做必要的優化。另外，xmpp 本質上雙向 im 協議，而直接基於 xmpp 來實現 push 功能，也是沒有特別地為 push 的特點優化的，比如客戶端網路連線的策略等。
總結一下以 androidpn 為典型的開源 android push 方案會存在的問題：
１）容量大了開源伺服器實現頂不住，還是需要自己去改進開源實現，或者完全重新用新方案，開發投入與高成本是不可避免的。
２）協議與實現上如流量消耗、網路連線策略等，不是專門為移動 push 優化過的，是不經濟的。
極光推送專門為移動場景下的實時 push 來研發，我們想要去解決國內 android 開發者沒有可用好用的 push方案的問題，是免費的，完全向普通開發者開放。如果你也有這個 android push 的需求，不妨到極光推送官方**進一步地了解。
開源BOOT方案 U Boot
uboot 是由開源專案 ppcboot 發展起來的，armboot 併入了ppcboot 和其他一些 arch 的loader 合稱u boot 2002年12 月17日第乙個版本 u boot 0.2.0 發布，同時 ppcboot 和armboot 停止維護。u boot 支援的處理器構架包括...
適合c c 的http開源方案
版本 作者日期 備註0.1 loon 2019.2.13 初稿0.2 loon 2019.4.1 修復部分勘誤 在嵌入式開發過程中，我們有的時候需要移植或開發web服務，http協議是繞不開的，這個時候結合開源方案，可以加快我們的開發進度，減少工作量。以下排名不分先後順序。名稱位址 說明libcur...
AndroMDA 3 0 開源的MDA方案
2005年01月31日 13 11 00 第2版 2005.6.22 修改優缺點比較部分 因為有些ide不支援，一直沒有完整留意uml的擴充套件機制，所以也就以為uml不很適合做mda。比如生成hibernate的hbm檔案,一些屬性的輔助屬性比如lazy load，應該放在class圖的 呢?最近...