移動端消息推送 xmpp 和 mqtt 哪個更費電？

01-25

在網上看到關於移動端消息推送方式的比較，說xmpp比mqtt費電，有人做過測試嗎？
原文：
本文主旨在於，對目前Android平台上最主流的幾種消息推送方案進行分析和對比，比較客觀地反映出這些推送方案的優缺點，幫助大家選擇最合適的實施方案。

方案1、使用GCM服務（Google Cloud Messaging）
簡介：Google推出的雲消息服務，即第二代的G2DM。
優點：Google提供的服務、原生、簡單，無需實現和部署服務端。
缺點：Android版本限制（必須大於2.2版本），該服務在國內不夠穩定、需要用戶綁定Google帳號，受限於Google。

方案2、使用XMPP協議（Openfire + Spark + Smack）
簡介：基於XML協議的通訊協議，前身是Jabber，目前已由IETF國際標準化組織完成了標準化工作。
優點：協議成熟、強大、可擴展性強、目前主要應用於許多聊天系統中，且已有開源的Java版的開發實例androidpn。
缺點：協議較複雜、冗餘（基於XML）、費流量、費電，部署硬體成本高。
方案3、使用MQTT協議（更多信息見：MQTT: MQ Telemetry Transport）

簡介：輕量級的、基於代理的「發布/訂閱」模式的消息傳輸協議。
優點：協議簡潔、小巧、可擴展性強、省流量、省電，目前已經應用到企業領域（參考：Software - runtimes, APIs and libraries for MQTT），且已有C++版的服務端組件rsmb。
缺點：不夠成熟、實現較複雜、服務端組件rsmb不開源，部署硬體成本較高。
方案4、使用HTTP輪循方式
簡介：定時向HTTP服務端介面（Web Service API）獲取最新消息。

優點：實現簡單、可控性強，部署硬體成本低。
缺點：實時性差。

MQTT 當然更好，協議比 XMPP 輕很多。

我們產品就是基於 MQTT 的，可以嘗試下：http://yunba.io

其實對於push notification來講，使用XMPP協議就有點用大炮打蚊子的意思了。XMPP早期採用XML格式也是一個硬傷，當時是為了PC上的IM設計的，不管是用來做推送還是聊天，對移動設備來講都不合適。

推送還是首選 mqtt ，簡單，輕量級。

I"M 就首選 XMPP ，然後慢慢改進。問題不少，比如國內的2G，地鐵，電梯等，這樣的環境下，XMPP 數據就需要優化。

20150820更新:

我們選了mqtt+emqttd(國產)伺服器

對比過MQTT和XMPP，可以確認MQTT更省電，網上也有這樣的文章比較，因為MQTT消息更短小，網路傳輸時間更短。 XMPP是XML格式的，冗餘很大。同樣的信息兩者的數據差好幾倍。肯定是MQTT更省電。

對於推送消息來說，XMPP顯然是大材小用，或者說殺雞焉用牛到。XMPP過於龐大，唯一的好處就是其可擴展性強，其他的對於推送機制來說實在是過了，我一直在公司寫Android即時通訊系統，寫到各種吐，估計要換mqtt了，正在考察中。

單純的推送，從底層看，當然mqtt好了

但是要涉及到上層業務，設計到用戶分群分組，用戶層次關係的維護，xmpp已經為你做了很多很多，後期的開發會很省心。

所以，個人感覺這是一個開發效率和傳送效率二者不可兼得的問題，看公司業務以及產品後期的規划去取捨？

mqtt更適合做推送

GCM

xmpp費電

MQTT代碼量也比XMPP小很多，傳輸速度非常快。使用容易，不知道安全性如何

MQTT協議簡單，甚至可以結合業務去定製協議繼續優化

客戶端和服務端實現都比較簡單

Nexus 5上用Whats App，聯通和電信寬頻WIFI下，GCM推送基本沒延時。

P.S: 萬惡的微信，官方下載版本都不支持GCM，不知道用什麼方式推送消息。