如何看待小米推出 iOS 式的統一推送服務，競爭力如何？

12-28

本文作者系小米推送服務研發工程師 ：汪軒然

什麼是推送

很多移動應用需要將消息通過某種方式通知到用戶的手機設備（如新聞類應用的重大新聞、通訊類應用的即時消息、天氣類應用的重大災害預警等），而不管此時用戶是否正在使用此款應用。推送服務正是為了滿足這種需求而生。在幾大主流智能設備操作系統中，iOS提供了統一的消息推送服務，所有的消息都必須經由蘋果伺服器發起，推送給指定的設備。而谷歌也為其安卓系統開發了推送服務GCM（Google Cloud Messaging）,但由於其服務在國內不是很穩定，因此開發者普遍都開發了自己的安卓平台的推送服務或使用了第三方開發的推送服務，來滿足應用的推送需求。要實現上述實時推送的需求，一般需要在移動設備和伺服器之間建立一條TCP長連接，並通過發送心跳包來維持這條長連接。一旦有推送需求，可通過這條長連接，向設備推送消息內容。而設備在接收到推送消息後，通過彈窗、通知欄等方式，向用戶發起提醒。

什麼是小米推送服務（MiPush）

小米推送(MiPush)是小米公司為開發者提供的消息推送服務，通過在雲端和客戶端之間建立一條穩定、可靠的長連接，為開發者提供向客戶端應用推送實時消息的服務，幫助開發者有效地拉動用戶活躍。http://dev.xiaomi.com/doc/?page_id=1670

統一推送服務對用戶的好處

很多安卓用戶在抱怨手機很耗電，這和安卓上應用的推送需求有很大關係。如前文所述，推送需要應用在後台保持長連接，因此經常會喚醒設備去向伺服器發送心跳包，而由於每個應用喚醒的頻率和時間點不同，往往會導致設備一直處於被喚醒狀態，引起耗電量的增加。

如果所有的應用都採用統一的推送服務，則可統一每個應用的喚醒時間和頻率，同時可根據用戶使用行為採取一些智能的喚醒策略，讓安卓手機能夠有規律的喚醒-休眠，節省大量耗電。實踐證明，在使用統一的推送服務之後，手機設備的平均省電效果能達20-40%。

統一推送服務對開發者的好處

實現推送服務有如下幾個技術難點，首先是移動設備的網路環境複雜，網路切換頻繁，如何能保證在各種網路環境下，消息都能及時送達。其次是為了維持多個設備的長連接，需要大量的伺服器資源投入，開發和維護成本很大。最後由於用於維持長連接的心跳需要將手機喚醒，因此對於手機的電量是個不小的開銷，如何在盡量不影響手機待機的前提下，維護推送的長連接，也是不小的技術挑戰。

基於上述門檻，開發者要實現推送需求，成本較高，並且後期維護難度也很大，因此使用一些已經成熟的第三方SDK是一個性價比比較高的方式。

小米為什麼要做推送服務

如前文所說，省電，是手機的最核心競爭力之一，如果能夠統一小米手機上的推送服務，則小米手機便毫無爭議的成為最省電的安卓手機。這是小米做推送服務的初衷，也是最根本的出發點。同時作為一家互聯網公司，服務一直是小米的鐵人三項的很重要的一項，而開發者服務則是互聯網服務的重中之重，是企業的創建自己生態圈的重要根基。微軟、谷歌、蘋果的成功無不說明「得開發者得天下」這一事實。小米抱著同樣的開放心態，不惜投入大量的人力和伺服器資源，以推送服務為切入點，一步步完善整個小米生態圈。（完）

原文：什麼是小米推送服務

1）小米推送的背景和歷史

我們使用IOS刷微博的時候，接收到了一條微信，這個時候，系統會有通知，告訴你收到一條微信，但是此時，微信並沒有在後台啟動，當你決定打開微信時，這時候微信才會在你的後台啟動，但是當我們使用android刷微博的時候，這時候我們接收到了一條微信，這個時候，微信會自己啟動，將消息推送給你

這就是為什麼IOS比Android省電的原因，安卓的應用，都會獨立的啟動，來推送自己的消息，但是IOS的推送是通過Push來統一實現的，為了解決這一問題，MIUI V5就創立了對齊喚醒機制，這就是小米推送的歷史

MIUI 通過對喚醒機制的對齊，使得耗電量對於原聲安卓有了質的提升。

2）小米推送概述
小米推送(MiPush)是小米公司向開發者提供的消息推送服務，通過在雲端與客戶端之間建立一條穩定、可靠的長連接，為開發者提供向客戶端應用實時推送消息的服務。小米推送服務能有效地幫助開發者拉動用戶活躍度，改善產品體驗。

應用案例及場景
如何保證消息的實時性（以新聞類應用為例）

使用場景：在發生重大新聞事件時，新聞類應用希望將新聞信息以最快的速度傳遞給用戶，同時也希望這條新聞是有「保鮮期」的，用戶明天再聯網不應該看到昨天的新聞推送。

因此，推送服務在這樣的場景下需要保證消息的實時性，永遠給用戶最快最新的信息。

解決方法：小米推送採用長連接的方式，確保消息能實時推送到客戶端，只要用戶設備網路正常，消息就能快速送達。同時，開發者對於每條消息都可以單獨設置有效期，消息有效期內未聯網的用戶上線後不會收到過期的消息，保證了用戶收到的新聞推送永遠是最新的信息。

今日頭條此類新聞類應用正是通過這樣方式使用小米推送，保證了新聞推送的實時性。

如何精準推送，避免打擾（以O2O類應用為例）
使用場景：O2O類應用為用戶提供的信息很多情況下是本地化的信息，如果將A城的餐館打折信息推給B城用戶顯然是打擾B城用戶的無效信息。

因此需要推送服務提供精準推送的能力，讓消息可以精準地觸達目標用戶。

解決方法：小米推送提供了標籤的功能幫助開發者實現精準推送的目標。以上面的場景為例，開發者可以將A城的用戶統一打上「A城」的標籤，在需要推送A城的餐館打折信息時，使用基於標籤推送的功能，可以指定向擁有「A城」標籤的用戶進行推送。這樣該城的用戶就能及時收到這條消息，並且不會打擾其他區域的用戶。

大眾點評等擁有本地服務的O2O類應用都在以類似的方式使用小米推送。

3）小米推送服務作用

1.促進用戶活躍，增強用戶黏性

通過雲和端之間建立的長連接，開發者可以實時地將消息推送到用戶設備端。只要用戶設備網路暢通，就能隨時喚醒用戶，保持與用戶的溝通，大大提升用戶活躍度和留存率。

2.節約推送成本

小米承諾提供永久免費的推送基礎服務，開發者不需要投入大量時間、人力和伺服器資源來開發和維護到客戶端的長連接，免去了應用實現推送功能所增加的成本。

3.穩定安全的推送

依託強大的伺服器集群，以及多年在手機即時通訊領域的技術積累，小米在消息推送服務這一領域有著豐富的經驗和雄厚的實力。在保證推送消息的到達率及到達速度的同時，我們還設計了一套基於業界最高標準加密演算法的安全措施，讓應用消息的傳輸更加安全可靠。

4）小米推送服務的工作原理

如上圖所示，通過小米推送服務，應用可以從伺服器向它的用戶發送推送消息。推送服務負責把這些消息排隊和轉發給目的手機上的目的應用。
如果目的手機在線上，則推送服務會把這些消息直接下發給目的手機，否則會把它們存為離線消息保存一段時間，等到手機上線再下發給它。

典型例子

1 對1 的單點推送

小米推送服務支持手機應用伺服器向它的某一個用戶或者某幾個用戶發送消息。應用服
務器有2 種方式指定該用戶或者用戶列表：

1) 通過讓客戶端調用客戶端sdk 的setAlias()來設定一個客戶端與伺服器之間約定的別名（alias）。伺服器就可以用伺服器端sdk 的sendToAlias()方法向該別名對應的客戶
端發送消息。通常可以把別名設置為是手機應用的用戶在系統里的賬號名。

2) 當客戶端調用客戶端sdk 的initialize(),等推送初始化成功之後，客戶端sdk 的回調介面MiPushClientCallback 會被調用，其中一個返回結果是regID，註冊ID。伺服器
可以調用伺服器端sdk 的send()方法向該regID 對應的客戶端發送消息。這種方法能給應用伺服器更大的靈活性，性能和安全性也更高。但是，要求客戶端把註冊ID
上傳給應用伺服器，開發複雜度更高。

基於訂閱 /發布模式的廣播推送

小米推送服務支持手機應用伺服器向它的某個用戶群體發送消息。通過讓客戶端調用客戶端sdk 的 subscribe(topic),某個手機上的用戶可以指示伺服器他對一個特定的 topic 主
題做訂閱，即加入以主題為標示的用戶群體。以後應用伺服器就可以調用伺服器端 sdk的broadcast(topic)來向該用戶群體發布消息了。

5）小米推送服務的工作流程和安全機制

上圖描述了小米推送服務的工作流程和端到端如何保證數據安全。

1) 在使用推送服務之前，開發人員必須通過 1~3 步在小米開發者網站小米開發者站註冊自己的應用。如果註冊成功則獲得相應的 appid，app key和app
secret.利用這些信息應用伺服器就可以給自己的應用推送消息了。
2) 第4~6 步描述了推送通道的激活過程。這個過程由小米推送服務的 SDK 實現，對上層應用伺服器和應用客戶端都是透明的。大致流程是：小米手機會通過 https 安全
地激活本手機到雲端的推送服務。成功激活之後，手機就從推送服務獲得了 servicetoken（一個周期性被刷新的密鑰）。該 servicetoken 在隨後的通信過程中用於
加密和簽名。所以整個推送通道上的消息的傳輸是安全的。
3) 第7~10 步，是由手機應用調用客戶端 sdk 的 initialize()發起的。目的是讓雲端的推送服務能夠識別在某個手機上的某個應用（通過 regID）。整個通信過程如前所述是
加密的。
4) 第11 步，是手機應用客戶端通知自己的應用伺服器 regID 用於以後發送通知。如果應用採用基於別名的消息發送方式，則可以跳過本步驟。這是因為客戶端調用
客戶端sdk 的 setAlias()讓小米推送服務知道了如何把別名映射到對應的機器。
5) 第12~19 步，是手機應用伺服器如何單發一條消息，該消息又是如何基於 ACK 可靠傳輸給用戶某個手機上的應用。過程如前 2）所述是安全的。如果應用採用訂閱 /發
布模式，流程基本類似。
6) 第20 步，用戶可以隨時到管理後台去查看過去消息發送和到達等情況的統計信息。

6）小米推送功能簡析與特點
6.1.推送的消息類型
小米推送支持通知欄提醒和透傳消息兩種消息類型。
6.1.1.通知欄提醒
客戶端收到這類消息後，將直接在通知欄彈出一條通知。用戶點擊彈出通知後，客戶端SDK會將消息中攜帶的數據傳遞給應用，由應用決定下一步的動作。
通知欄內的展示如圖1 所示，展示的內容包括標題、摘要、應用的大圖標、小圖標和時間。其中標題、摘要、大圖標和小圖標可由開發者自定義 3。同時，針對每條消息，開發者也可以單獨定義是否響鈴、是否振動、是否點亮呼吸燈，並且可以選擇響鈴的聲音 4。

圖2 MIUI和原生Android上消息的展示
6.1.2.透傳消息
為了滿足不同應用對消息展示效果個性化的需求，小米推送支持以透傳的方式來發送消息。這種方式把消息直接推送給應用客戶端，由客戶端自定義如何呈現或者選擇不呈現。
使用透傳消息，開發者可自定義更多使用推送的方式和展現形式，更靈活地使用消息推送通道。
需要注意的是，在一些Android系統(如MIUI)中，受到系統自啟動管理設置的限制，應用不能在後台自啟動。在這類系統中，如果在發送消息的時候對應的應用沒有被啟動，透傳類消息將不能順利送達。因此，對於對送達率要求很高的消息，建議盡量採用通知欄提醒的方式推送消息5。

6.2.推送對象的選取
6.2.1.基於標籤的推送
這種方式允許應用基於不同的用戶類型，分別進行個性化的定向消息推送。在應用初始化時或運行過程中，開發者可結合自己的業務特徵，給用戶打上不同的標籤(topic)。在推送消息時，開發者可以結合每條消息的內容和目標用戶，選擇所對應的標籤，完成請求後，小米推送服務會向所有打上這一標籤的用戶發送該消息，從而滿足應用精準推送的需求。

6.2.2.基於RegID或別名的推送
當開發者需要給一個或多個具體的設備推送消息時，可以使用基於Reg ID(或為設備設定的別名)的推送，將個性化的信息推送給指定的設備。這種方式適用於需要為每個用戶訂製個性化推送的場景。
6.3.別名的含義與功能
RegID是一個設備在小米推送服務中的唯一標識。考慮到在實際推送的場景中，對開發者來說更自然的方式是：以應用自有的用戶唯一標識為對象來推送，因此我們提供了設置別名(Alias)的功能：應用可以將用戶在應用內的賬號或其它用戶唯一標識設定為用戶設備RegID的別名，在推送中可以直接基於別名進行推送。
小米推送提供別名的功能不僅方便開發者將推送與自有的賬號系統進行關聯，同時也避免了因需要保存設備RegID 與自有帳號的對應關係而額外帶來的開發和存儲成本。

6.4.其他個性化設置
· 消息有效期設置

開發者可以根據自己的業務需求設置每條推送消息的有效期，推送的目標用戶在消息有效期內上線就會收到消息。消息的最長有效期是14天。如果應用沒有單獨設置一條消息的有效期，小米推送的默認有效期也是14天。
· 靜默期設置

小米推送可以為每個客戶端設定接收推送的靜默期，用戶在靜默期內將不會收到推送的消息。此時發出的消息會被保留在服務端，當用戶具備接收條件且消息尚處於有效期內時，用戶將會收到被保留的消息。應用內設置免打擾時段的功能就可以使用靜默期設置的功能來實現。
· 通知分類設置

開發者如果需要應用的多條通知在通知欄內並存，可以使用通知分類來實現這個展示要求。

通知分類是用來控制多條通知在通知欄內的替換關係。同類通知之間新的將替換舊的，不同類通知之間並存而不替換。最多可以有5類通知並存。
因此，如果希望多條通知在通知欄內並存，開發者可以在發起推送時將這幾條通知設置為不同的分類。

7）統計
在小米開發者站內，開發者可以在應用的消息推送服務下查看推送的數據統計，也可以直接使用小米推送提供的數據API，與自身現有的統計系統結合。
小米推送提供的統計主要分為推送數據統計和用戶數據統計兩大類。

7.1.推送數據統計
推送數據統計里包含實時數據和歷史數據兩類。
統計指標：

· 已推送總量：是單發和群發的目標設備數之和

· 單發消息數：指按reg id或按別名推送的目標設備數

· 群發消息數：指按標籤推送的目標設備數

· 送達消息數：指已收到消息的設備數

· 通知點擊數：指通知欄內應用通知的點擊數 6

7.2.用戶數據統計用戶數據統計也是包含實時數據和歷史數據兩類，用戶數據需應用開發者主動啟用才進行統計展示。
統計定義

· 當前在線用戶數：指當前保持著推送長連接的設備數

· 最高在線：指當日同時在線最高時的在線設備數

· 新增用戶：指當日首次建立推送長連接的設備數

· 日活躍用戶：指當日曾經在線過的設備數

8）服務性能
為了保證服務質量，我們對小米推送服務的伺服器性能做了較為完善的壓力測試。在實驗室環境下，通過壓力測試，我們得出如下幾項主要性能數據:

同時在線：目前能支撐6000萬長連接同時在線，並可隨時根據業務需求水平擴展。

吞吐量：消息的最大吞吐量為每分鐘600萬條，也可通過增加伺服器隨時擴展。

及時性：99.8%以上的消息可以在300ms內發送完成。消息的平均送達延遲為118.74ms，最大消息延時為531ms。

由於中國安卓用戶缺少GCM服務，統一的消息推送在這一塊上確實是個空白，小米看到了這一點。不過小米並沒有取得國內安卓系統的話語權，也是相當費力不討好。

雷軍說的「省電省內存」，這些好處是針對用戶來說的，而且還可以做成像iOS那樣可以在屏鎖界面顯示各種消息，對用戶體驗無疑是提升的。

然而對於開發者本身並沒有什麼明顯的收益，有時甚至是額外的開銷。
要開發者使用這樣的第三方推送服務，首先一個易使用且穩定的介面是必要的保證。這還不夠，因為目前雖然MIUI在國內活躍用戶接近4000萬，但仍然不能算作國內的主流，這樣即使一個APP使用了小米推送服務，為了保證在每一個Android手機上能夠正常推送消息，依舊會構建一個屬於自己的推送服務。那麼很容易演變成「反正我們都要寫一個推送服務，小米推送還是算了吧」

我不認為跟BAT這樣的大公司「取得合作關係來推廣小米推送」是個困難的事，因為小米本身就擅長與各種互聯網公司合作，且有各種先例，相比之下，如何讓他們相信「我們的數據都經過你的伺服器而且你不會拿去做對我們不利的事」，或者讓他們打消「我們才不想被你知道我們的數據」這樣的想法才是更困難的事情，而貌似這個問題是無解的。

這樣一來，「小米推送」要爭取的對象很可能就變成了廣大中小企業或自由開發者，所以小米要開發者使用這個推送服務的話，要使這個介面的使用盡量接近「零成本」，且無需維護，才有可能使開發者認為不過是舉手之勞，就順便加上吧。甚至初期最好能夠「有所補貼」討好開發者來形成最初的規模和口碑。另外，作為一個平台型的服務，MIUI的及其衍生的客戶端（小米系統？）的鋪開量也是非常重要的基礎，這些小米一直在做，不過目前的數量恐怕還不能讓【小米推送客戶端】在國內Android機型上的存在成為常態。不過一旦有了規模、形成馬太效應後，就算有後來者，也根本不足為懼了。

一句話，小米任重而道遠，在短期內，我們還無法在Android機型上享受到iOS般的統一推送體驗。不過，就算沒有開發者支持「小米推送」服務，至少不會讓MIUI的體驗更加糟糕，至多是一切照舊而已。

至於省電，這是肯定的，這跟多核心CPU沒什麼關係，核心再多，只要有後台有一堆需要保持心跳的服務，CPU就會不斷被喚醒，根本睡不下來。iPhone的電池容量才多大？卻可以實現這樣的待機時間，這跟他不允許像安卓這樣的後台服務是很有關係的。

==========Update========

由於我的孤陋寡聞，不知道騰訊百度等公司已經在小米之前推出過推送服務了，這一點我真是OUT了，所以我在一開始說在這一塊上國內是空白，是不正確的。
不過由於他們也才剛開始做，說推送的服務在國內是空白也不是完全不對。
以騰訊的信鴿為例，說下我的理解和看法，有不對的請各位指正。

我去騰信信鴿的官網大致了解了一下，且看了 @平刀發的小米推送原理，發現我之前理解的他們所說的推送似乎有些出入。
我之前的理解是在手機上需要一個接收消息的客戶端程序，由它來統一接收APP的推送消息。
但實際上這些推送服務是無需在手機上有客戶端的存在的。也就是說可以支持到所有的Android手機甚至是iPhone。那麼我之前認為MiPush是要在MIUI及其衍生客戶端的基礎上運作就是不正確的了。

騰訊信鴿給開發者提供了一個可靠的使用推送服務的渠道，使他們不用再花力氣去建立自己的伺服器。由於在手機上並沒有安裝一個用來接收推送的客戶端，是使用他們的SDK並集成在APP里且不用的APP有他們各自的信鴿SDK，那麼集成了信鴿SKD的APP還是要在後台保持喚醒狀態，不同的APP喚醒的時間仍然無序的。
而小米的MiPush除了同樣給開發者提供一個推送服務的渠道之外，也無需一個接收消息的客戶端，這點和騰訊類似，但是更進一步的，MiPush可以在MIUI及其衍生客戶端上實現【統一】各個APP的消息推送心跳時間。
（我這麼理解他們的推送服務不知道正確否？）

基於這樣的理解：
1.由於騰訊百度已經推出這樣的業務，我想他們支持小米的MiPush基本沒有什麼可能性了。
2.以後APP的推送服務，要麼是開發者一方自己建立的，要麼是使用第三方的推送服務，而不會有兩者同時使用的情況。所以我之前所說的「順便加上」的情況也是不可能出現的。
3.需要使用推送但是又不想建立伺服器的APP，可以很方便的使用這樣的推送服務，這樣開發者面臨的問題就是，到底相信哪一家？是騰訊百度這樣的國內老IT巨頭，還是小米這樣的互聯網新兵？
在MIUI及其衍生客戶端上的推送給用戶的體驗可能更好，但是MIUI的數量級是否能夠吸引開發者倒向小米？小米麵臨的挑戰依然艱巨。

不只是小米做這推送服務，騰訊也在上個月推出了Android 消息推送服務，叫做「騰訊信鴿」，騰訊信鴿|免費專業移動推送，百度也有這樣的推送服務，叫「百度雲推送」，雲推送 - 百度開放雲平台。除了這幾家大公司，國內的「極光推送」，JPush極光推送也做得不錯。我盼望著越來越多的開發者使用這些推送服務，以造福廣大android 用戶。

關於MIUI V5 的對齊心跳技術，確實是一項很有用的技術。華為也有類似的技術，華為"智電"省電技術，其實就是統一減慢心跳。華為的"智電"省電技術里，可以單獨設置那些對消息實時性要求比較高的App程序，把它們排除在外"智電「外，這樣這些App依然可以以自己默認心率中跳，以便實時接收信息。

除此之外，高通公司針對自家晶元組推出一個App，叫」電池大師BatteryGuru，Snapdragon? BatteryGuru 。實現方法也是讓Apps 保持同步心跳，也減少耗電。

這些推送技術，對齊心跳，減慢心跳，到底對提高手機待機時間有多明顯呢？
我們先假設你手機中裝有以下這些軟體：新浪微博，QQ, 微信，陌陌，阿里旺旺，來往，Skype，WhatsApp, line連我，Viber，Tango，電子郵件（Exchange 連接），以及其他一些會用到網路，有常駐後台進程保持心跳的Apps。
以下分情況談論：
A), 在wifi連接下使用，我們暫且說它能提高待機時間2%（不是精確統計時間，只是為了和以下B、C、D情況作對比）

B), 在GPRS/EDGE/3G 下使用，能提高待機時間6% （不是精確統計時間，只是為直觀地和另外幾種情況作對比）

C), 在HSDPA/HSPA+ 下使用，能提高待機時間18% （不是精確統計時間，只是為直觀地和另外幾種情況作對比）以上。

D), LTE 下暫未作測試。

以上幾種情況中的百分之幾都是粗略估計，目的是想告訴大家，在3.5G，也就是HSDPA/HSPA+ 下的數據連接，不規律的心跳會消耗了非常多的電，並使手機發熱發燙。這電是基帶晶元和射頻晶元消耗掉的，特別是在數據連接喚醒的時候，射頻的瞬時功率非常大。

-------------

前兩天，在公司內網看到騰訊信鴿的介紹（信鴿主頁在騰訊信鴿|免費專業移動推送），跟發帖介紹信鴿的同事聊了幾句，就提到「如果小米也做類似的push，那麼信鴿有什麼優勢」，當時還不知道真的有mipush這樣一個產品，所以當時也是比較空泛的聊了一下，沒想到一語成讖了。

回到題主的問題上來，mipush競爭力如何，這樣看跟誰對比？
對比GCM，mipush的優勢就是在於GCM的不穩定，而mipush可以做到相對穩定。而且也可能得到zf的支持，例如出現緊急事件時，在移動領域，官方過去主要通過簡訊途徑去闢謠去宣傳，以後就可以利用mipush這條通道去傳達消息。這條基於互聯網的消息通道，在一些場景，可靠性大於簡訊。

對比GCM，mipush的劣勢可能在於走出國門可能比較難，也就是國際化很難。所以mipush的主要面向對象，應該僅限於大陸的開發者。

對比信鴿，mipush的優勢在於MIUI的普及和MIUI桌面的普及。這裡的MIUI不止是軟體部分，而是包括了整個小米目前良好的軟硬體生態圈。這點信鴿是沒法比擬的。用戶對小米和MIUI的接受和認可，是mipush被開發者接受並認可的前提。

對比信鴿，mipush的劣勢也很明顯，因為小米和MIUI畢竟沒有在Android市場上佔到絕對優勢比例。而微信、手Q，卻是裝機必備，這會導致信鴿SDK會隨著手Q、微信以及騰訊系其他App，早早進入用戶的手機。當信鴿的推送因為觸達用戶、曝光頻率到達一定數量級後，用戶接受了信鴿的推送方式後，廣大開發者可能不會抱著「一定要自己開發push通道」的想法，轉而去接受信鴿並使用信鴿去push消息。尤其信鴿還支持iOS，這點也是mipush目前無法實現的。挾用戶亦令開發者，這點上，mipush的"挾持"能力不如信鴿。

綜上，mipush與GCM相比，優勢明顯，但國際化難；信鴿相比，硬體優勢明顯，但綜合競爭能力不還需繼續改進。

我還特意去小米消息推送服務的頁面看了下，貌似說的很兇的樣子，還丟出一遭數據，但是小米到底有沒有實力做成這麼大一個東西，我還是存疑的。

其次是第三方的統一推送服務，其實小米肯定也不是第一家了，但是為什麼還是那麼多 Android 應用還是不用推送，還是在使用自己的模塊在那邊自己玩，因為使用他人服務的推送，開發多半就複雜一些。很多開發者就是懶。在 iOS 上是沒辦法，沒法常駐後台，要實現類似功能，只能走 APNS，門檻上去了，但Android 可以用個後台模塊常駐，不論是定時輪訓還是自己搞個長鏈接，相對就簡單很多了。而且調試方面，如果是後台模塊，所有部件都是自己控制的，可控。使用別家的推送服務，說不定你 debug 半天，結果是別人伺服器問題。。。

最後就是個信任問題了。推送，牽扯到太多的隱私，太多的數據，而畢竟這個東西只有做到絕大部分應用都統一才比較有意義，絕大多數的應用，絕大多數的推送數據，絕大多數的 Android 用戶，這需要何等的信任？小米，擔得起這個信任嗎？

省電省流量應該是能做到的。很多應用都不用後台喚醒了，也不用和各自的伺服器連接了。可以減少一些輸入輸出，減少CPU使用。應該能省點。
這個東西能做起來的話，應該能讓更多開發商和小米接觸。這有可能增強小米應用市場的影響力。

做這個事，小米還是有機會的。對小廠商來說，多了一個選擇，可以不用在BAT之間馬上站隊。對大廠商，小米手握MIUI，也還是有可能逼各家坐下來談一談的。
MIUI的一些功能，可以降低那些不和小米合作的廠商，他們應用的用戶體驗。比如，過一段時間殺死後台應用，增大對齊喚醒的時間間隔，都可以對用戶說是為了省電；但這兩個做法，同時也能讓其他應用無法即時收到推送信息。

想一想，在幾千萬MIUI用戶的手機上，支付寶的通知要幾分鐘之後才能收到。財付通是不是會考慮和小米合作，提高用戶體驗？
微信？來往？

BAT統一到一起，看起來不太可能。大家都往小米這裡統一？不知道，不是完全沒有可能。

首先我相信小米公司肯定能做到穩定推送
而且已經有App開始支持了，相比某公司的Smartbar都能發展到這樣，小米推送也差不成什麼樣，雷總的人脈，家族妥妥的，秒殺某公司

完全代收通知，不點擊通知就不喚醒APP了，APP完全不需介入，這才是IOS式統一推送！！！！！！你們那些盜版去死吧

iOS 和 Android 的後台推送原理各是什麼？有什麼區別？
李楠： Google 事後也提供類似蘋果的推送方式了

而GCM是將接受到的傳遞給它，怎麼傳遞呢，就是喚醒App啊，相當於中轉

小米消息推送服務
小米推送呢，有N種工作模式

在一定條件下，完美提供IOS式通知！！！是完美

在一定情況下，又提供GCM的通知能力

又在多數情況下提供，比如極光啊，信鴿那種開無數後台服務的推送，簡直呵呵

這個功能對於手機用戶來說是絕對利大於弊，不僅節省內存，更能節省電量。
對於開發者來說，開發成本低，需要考慮的就是信任問題。

我為什麼還用ios的很大原因就是因為ios的推送機制和撫如酥油般的觸控感。

Google不是已經有這個功能了么.......？
——————————————up——————————————————————————
感謝評論區的各位指出，其實這些整合了谷歌的消息推送的應用我都沒見過他們彈出通知，也不知道有沒有效（我手機裝了谷歌框架）......Orz...

其實我想表達的是人家Android不是沒有這功能，只是一來被牆了二來也沒哪個國產軟體願意用，這個功能不是小米的發明，也沒啥顛覆性，只是撿漏而已.....

-，=至於看待，我寧願多耗點電也不要小米/騰訊/數字/百度/金山/****等國產軟體來管理我的推送

看到了一堆程序員在說：「小米這個推送只是給我們增加負擔嘛都不能一次編譯到處是用到了小米上自動變成小米推送」，我覺得你們遲早都還得給他專門寫一份代碼。

這是老問題了，正好最近做一點這方面的工作，所以提供一點看法。
[1]android和iOS的消息推送的區別
iOS自帶消息接收器，強制要求所有的app的消息推送都必須通過apple的伺服器來發送，這樣iOS設備的接收器就可以很簡單的只從自家的伺服器上來收推送信息，於是其他的app就無需常駐內存造成耗電和網路資源的浪費（需要發送心跳包維持連接）。
對於android系統，則沒有這個限制，任何app都可以自己搞後台服務來保持連接和查詢推送，這造成了耗電和網路資源的浪費，google這個傻逼等到了差不多android 2.1版本以後才搞出來個和iOS差不多的Google Cloud Messaging(GCM)出來，然而由於a)GCM在牆外，b)國內絕大部分android機子都沒裝google 框架，導致GCM根本用不起來。
這就是國內現狀。

[2]小米push，極光push之類的原理
簡單說，這類第三方推送，在iOS上就是簡單使用iOS的中心控制消息接收器，所以不需要加任何東西，當然實際推送的時候，基本路線是 app消息--》自己的伺服器--》apple的推送伺服器--》相關的iOS設備上的app ;
但是再android系統上，就不一樣了，必須增加一個服務，也就是service，常駐在內存里，實時和推送伺服器聯繫（比如小米push），實際推送的時候，基本路線是（以小米push為例）：app消息--》自己的伺服器--》小米push伺服器--》相關android設備的小米push service--》對應app。
參考上面的路線圖，也就是說：
a)對於MIUI這樣的系統，直接就有了小米push service;
b)對於其他的非MIUI，必須另外安裝一個獨立的小米push service（已經集成到app中，在安裝這個app時就裝上了），但是這是以動態庫的形式來安裝的（.so)，所以如果有100個app用到小米的push，不需要安裝100個服務，同時就只有1個服務，這樣就極大的達到了省電省網路資源的目的;
c)相對於小米push，其他的第三方push服務由於沒有系統支持，因此都需要額外的添加自己的push service，所以推廣上可能沒什麼優勢;

[3]安全性如何
如果不是直接和小米之類的公司有不死不休的死仇，否則使用小米push不會有任何的安全性問題，參看上面[2]的推送路線圖，實際的消息推送是在自己app的伺服器上推送的，所以完全可以自己定義要推送的信息的內容，甚至完全沒有內容，只是提醒你有新內容，然後打開自己的app到自己的伺服器上去看實際的內容都可以，所以安全上是完全沒問題的，最大的風險無非是不給你發信息或者很長的延遲，不過講真的可能性真的不大。

沒什麼不好，只是BAT不買賬，又有什麼用呢，jobs說必須我推送和雷軍說必須我推送是一回事嗎。。。。
常常需要推送的軟體，大多是IM吧。比如新聞類軟體那種推送，一天2-3條？我全禁了，沒有具體數過。陌陌，飛信，易信等等，這些一個都不好伺候，到最後可能用MIUI推送的只有UC歪歪米聊等雷軍系軟體吧。雖然這是個好方向，但是不看好

又仔細看了下小米的文檔，感覺剛才的揣測還是不太正確的，重新回答下。
首先說一下系統有統一的推送絕對是好事情（像蘋果一樣），開發系統的公司有能力維持一個更好的長鏈接，第三方應用的所有消息都走這一個長連接無疑是效率最大化的，而且不需要佔用額外的後台資源。
android 系統是有自己的推送服務的（Google Cloud Messaging for Android），但由於在我大天朝google服務不穩定，各種rom很多又不集成google的相應服務，所以這個方案也已被判定成坑了，試想一下只有nexus才能收到的推送，有那個工程師願意花精力去開發呢？
小米的服務支持android全平台，在MIUI系統上會有所優化，憑這一點相對於其他android第三方推送平台還是有一些競爭力的，加上小米的口碑也相對更可靠些，但這件事要做好還是有點任重道遠。
1. iOS上app不需要額外的推送SDK，那在MIUI上也應該不需要吧，這樣客戶端會少做一些事（和小米伺服器打交道的事）
2. 市場佔有率，需要多個第三方app都使用同一個長鏈接，這個東西對用戶的價值才會體現出來，小米能不能說服開發者達成這樣的共識，這是個問題。
最終評價，android 系統統一推送，這是件好事，但也是件難事，其中沒什麼可取巧的，希望小米能做好。

沒用的，開發者們不會使用的。
在小米推送之前，國內又不是沒有統一的推送服務。用的人都寥寥可數。
就算是在能夠無縫連接到GCM的國外，也不是所有應用都使用了谷歌的服務。

從商業上來講，為我國用戶提供大多數互聯網服務的BAT三大廠商，就不可能使用小米的推送服務。
除非雷軍強制他們在MIUI上的只能使用他的推送。

實在搞不懂為什麼國內的廠商就沒一點自律
作為國內的巨頭，騰訊、阿里、新浪等就不能想想怎麼做行業的榜樣，都在挖空心思謀取最大的利益，真不想吐槽了，太噁心了
何時國內的軟體能真正讓國人自豪的用，放心的用，舒暢的用？？
目前來說，只要Play上有可代替的應用，我絕對不會選擇國內的，QQ也優先用國際版

大概看了一下，沒覺得相對於別家的推送例如百度推送有啥本質的區別，至於省電省內存省CPU，如果還有人不知道小米手機那一套多內存多核多像素多便宜等等多雷布斯,我只能呵呵了！
其實說到底，雷布斯想要拿到的還是用戶數據，即那個服務中的數據分析，這才是重點，用戶的行為隱私等全都掌握到手了！想我雷布斯千千萬小米手機在手，再加上通過米服務獲取到的信息，一統天下豈不指日可待，地球人你們顫抖吧！

Android早就有自己的GCM服務了，國際上大多數的通訊類App消息推送走的都是這個通道，你小米自己搞一個類GCM服務完全是多此一舉。
不過沒準在國內還真用得上，君不見國內的手機廠商把Android的原生系統糟蹋成什麼樣子了么，搞得廣大App開發者都不敢使用Google自己親生的服務了……

推送作為主動觸達用戶的通道，是app的剛需，因此不管是第三方做推送的公司，還是手機廠商，甚至bat 都會爭這塊市場。稍微有點量的廠商，都必然會做推送服務，小米華為三星這些大廠都有自己的推送服務。

另一個層面，推送saas 服務現在熱火朝天，友盟，個推，極光都靠推送服務獲取了大量客戶資源，小米也不會放棄這個市場。