Android各應用自主推送的機制到底會比iOS由蘋果統一的推送機制多費多少電？

01-03

各應用自己的推送是不保證在後台運行的，系統在內存緊張的時候會把他們回收掉，什麼時候重啟推送服務也不保證，所以各種推送服務會關聯各種系統事件啟動自己。但是一個推送服務是一個VM進程，有一定內存空間，那麼各種服務都啟動自己在低配的機器上就會頻繁造成內存緊張，引發系統回收資源和響應卡頓，也會加劇耗電。為什麼Android旗艦是2G以上內存，就是因為1G下各種佔據在後台的服務使得系統的可用內存所剩無幾。

手機待機耗電主要是消耗在設備的無線電發射接收上。無線電的工作狀態有三種，工作，預備和休眠，從預備轉入休眠消耗的時間會比較長。如果應用自己實現各種推送，則推送會佔據十分零碎的時間，可能導致無線電晶元反覆在工作-預備狀態下花去更多的時間。而統一推送可以讓晶元的工作時間更集中。

補充一點：推送框架比如GCM和Apple的推送服務的載荷都是有限制的，推送也會比較統一而減少總體的推送頻率，降低無線電工作時長。而Android應用各自實現的推送在頻率和載荷上都是沒有第三方限制的，所以無線電處於工作的時間是非常高的。不過現在iOS8也有後台的主動數據刷新，具體的耗電我也不是太清楚了。但是在iOS限制應用後台刷新的情況下或者Android採用GCM推送時，是肯定比Android各應用自己實現的推送要節約電能的。而具體的耗電差距沒有測過，就不清楚了。

iOS 的推送由iOS系統提供，消息推送過來，系統只做提示而不會啟動程序。

Android 的推送由各個App自己實現，消息推送過來，軟體可以做任何處理。

對於現在很多ROM都有喚醒對齊機制來說，就推送這一塊兒其實沒什麼差別。

主要問題在於推送消息到達手機後，App能幹什麼。

iOS：App什麼也幹不了，也就導致了後台收到個微信消息，重新打開微信的時候，消息是重新刷新得到的。

Android：呵呵，你懂的。

@於宙 report: iOS現在放開了一點，可以通過推送讓app做些一般性事務，但是有時間限制，而且時間不固定，系統覺得你差不多了就把你掐了，十分任性。

其實這個問題要分成兩面來看：

1. 技術方面

樓上各位解釋得很清楚了，Android 除了 GCM 之外沒有很好的推送通知機制，或者說有了咱也用不了…所以大傢伙也都開個後台 service 就完事。

這種大家各自實現的方式就導致 service 本身的質量參差不齊，出個 bug 說不定就給你跑電跑流量了…

2. 其他層面

因為大家不是要開 service 才可收到推送的通知嗎？那太棒了，我的 service 除了接受消息的功能之外還有紀錄位置，推送廣告，說不定再上傳個聯繫人等等諸如此類的實（keng）用（die）功能，所以大家都想在 service 裡面多塞點東西進去。

也就是說，信息推送給了 App 開發商在你機器上跑個後台 service 的理由。

想禁用 service？沒問題，你收不到推送就是了。這個概念其實 iOS 上也有。一個 App 如果天天除了廣告別的啥都不推送，用戶關你通知許可權分分鐘沒商量，如果一半是有用的信息一半是廣告呢？用戶說不定就從了哦～想像一下如果假設 iOS 端微信每天推送兩條廣告，其餘全是正常的和其他人的通信，你會關微信的推送許可權嗎？

於是乎…service 就越變越猥瑣了…

但凡風吹草動，全家生龍活虎.......某些安卓app

Android比較費電不是因為推送，而是因為Android可以有若干個不同應用的服務在後台跑，即使你Kill掉這些服務，它們還能在幾十秒後重新又把服務啟動起來；而IOS當你退出一個應用，過段時間這個應用就被系統幹掉了並且不能自啟動。

不管是Android還是IOS，推送費的電基本可以忽略。

對於推送的概念我感覺樓主沒有描述的很清晰。

但是起到決定作用的還是後台可運行進程過多，可操作的資源過多所造成的。包括後台存儲的io，網路的io。。。相對來說，蘋果就安靜的多了。

要搞一個gcm代替品，做在rom里

安卓推送的這個事情，已經是一個很重要的業務，很多公司在做這個，而IOS的推送，主要是一個功能。

iOS只有系統一個，而安卓（中國）有無數應用內置著各種推送模塊，各推送模塊技術實現不一樣，質量也不一樣。

iOS只推送消息（文字），安卓（中國）各種推送APK、圖片、文字，包括靜默下載等等（不僅消耗電量，還消耗流量），能耗肯定遠大於iOS上得輕量級文字推送。

當然，如果僅考慮文字推送，如果技術實現恰當，根據我的實驗，推送功能所需電量、流量消耗，幾乎可以忽視。