前言
iOS和Android上的實(shí)時(shí)消息推送差異很大，往小了說是技術(shù)實(shí)現(xiàn)的差異，往大了說是系統(tǒng)實(shí)現(xiàn)理念的不同。實(shí)時(shí)消息推送在移動端互聯(lián)網(wǎng)時(shí)代很平常，也很重要，它的存在讓智能終端真正成為全時(shí)信息傳播的工具。本文將從原理上談?wù)剝蓚€(gè)平臺上實(shí)時(shí)消息推送的區(qū)別。
簡要對比
1iOS的實(shí)時(shí)消息推送
iOS 系統(tǒng)的推送（APNS，即 Apple Push Notification Service）依托一個(gè)或幾個(gè)系統(tǒng)常駐進(jìn)程運(yùn)作，是全局的（接管所有應(yīng)用的消息推送），所以可看作是獨(dú)立于應(yīng)用之外，而且是設(shè)備和蘋果服務(wù)器之間的通訊，而非應(yīng)用的提供商服務(wù)器。你的例子里面，騰訊 QQ 的服務(wù)器（Provider）會給蘋果公司對應(yīng)的服務(wù)器（APNs）發(fā)出通知，然后再中轉(zhuǎn)傳送到你的設(shè)備（Devices）之上。當(dāng)你接收到通知，打開應(yīng)用，才開始從騰訊服務(wù)器接收數(shù)據(jù)，跟你之前看到通知里內(nèi)容一樣，但卻是經(jīng)由兩個(gè)不同的通道而來。
2Android的實(shí)時(shí)消息推送
而 Android，就不同，更像是傳統(tǒng)桌面電腦系統(tǒng)做法。每個(gè)需要后臺推送的應(yīng)用有各自的單獨(dú)后臺進(jìn)程，才能和各自的服務(wù)器通訊，交換數(shù)據(jù)。另外其實(shí) Android 也有類似 APNS 的 GCM（Google Cloud Message），屬于開發(fā)者可選，非強(qiáng)制。
（更多請參見以下文章：《
移動端IM實(shí)踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》、《
Android端做消息推送有沒有比較好的方案？》、《
為何微信、QQ這樣的IM工具不使用GCM服務(wù)推送消息？》
，以及即時(shí)通訊網(wǎng)精選的《
推送技術(shù)好文專輯》
）3小結(jié)
所以你大概看出來區(qū)別，iOS 的消息推送機(jī)制面世之時(shí)是一種全新的解決方案（堪稱平臺中的平臺），應(yīng)用本身不能有常駐的后臺進(jìn)程，系統(tǒng)的開銷少，內(nèi)存使用更少，電量也更少（把更多的運(yùn)算和資源開銷放在云端，非設(shè)備端）。而 Android 的特點(diǎn)，雖然開銷大，優(yōu)點(diǎn)是更穩(wěn)定快速，但不明顯。
技術(shù)原理
1基本原理
首先講解下服務(wù)器如何先找到設(shè)備、再找到app的問題。
每一個(gè)設(shè)備都有一個(gè)自己的設(shè)備號，而設(shè)備中的app又都有一個(gè)唯一的包名。所以服務(wù)器只需要找到設(shè)備號與包名就可以定位到某個(gè)設(shè)備的某個(gè)應(yīng)用，而這設(shè)備號與包名會一起構(gòu)成一個(gè)標(biāo)識符，叫做device_token，因此問題就簡化為把device_token與消息內(nèi)容等信息交給服務(wù)器，服務(wù)器把內(nèi)容發(fā)到唯一的device_token上。這就好像你在上海要通過順豐寄送一個(gè)快件兒給某某小區(qū)的某某房間，那么快件兒首先會郵遞到順豐公司在北京的總站點(diǎn)，之后再根據(jù)小區(qū)的地址投遞/路由到某某房間，這樣一個(gè)寄件過程就算完成了。
在這里，你要寄送的快件兒就是你要發(fā)的“消息”，送達(dá)房間相當(dāng)于最終“接收消息的App”，順豐公司在北京的總站點(diǎn)相當(dāng)于這里提到的“設(shè)備”，送達(dá)房間的房間號就相當(dāng)于這個(gè)環(huán)節(jié)里面提到的“包名”。
2iOS實(shí)時(shí)消息推送
iOS的推送是通過蘋果自己的APNs服務(wù)進(jìn)行的，用戶需要將device_token以及消息內(nèi)容等推送信息交給APNs服務(wù)器，剩下的均由蘋果自己來完成。iOS應(yīng)用的推送大部分情況下都要依賴蘋果生態(tài)提供的APNs（Apple Push Notification Service）服務(wù)。
首先作為設(shè)備標(biāo)識的device-token是由APNs頒發(fā)的，App開發(fā)者或者第三方推送平臺(圖中的Provider)做的工作是收集這個(gè)device-token，APNs的推送是要求基于APNs頒發(fā)的device-token來推送的。只有正確的device-token會被APNs接受，如果是一個(gè)錯誤的、或者無效的device-token(比如App已經(jīng)卸載了)，APNs就不會接受。
接著開發(fā)者使用第三方推送平臺（圖中的Provider）在將推送內(nèi)容與范圍選定之后進(jìn)行推送，第三方推送平臺將信息提交給APNs，剩下的操作全部都由APNs來進(jìn)行完成，整個(gè)過程第三方推送平臺就不能控制了。但是如果提供的device_token是失效的（app被卸載、系統(tǒng)版本升級導(dǎo)致device_token變化等情況）那么推送過程就會被中斷，頻繁的斷線重連甚至?xí)籄PNs認(rèn)為是一直DoS攻擊。（詳情可以參考
為什么蘋果的推送，兩次推送之間間隔比較久的話，第二次推送會很慢？）
3Android實(shí)時(shí)消息推送
Android平臺在不使用GCM的情況下就需要將自己的服務(wù)器或是第三方推送服務(wù)提供商的服務(wù)器與設(shè)備建立一條長連接，通過長連接進(jìn)行推送。但是不建議自己設(shè)置服務(wù)器實(shí)現(xiàn)推送功能，一是因?yàn)槌杀咎撸ㄩ_發(fā)成本、維護(hù)成本），自己搭建的服務(wù)器無論是穩(wěn)定性還是速度上都比不了第三方推送服務(wù)提供商的效果。另一個(gè)是因?yàn)樽约旱臄?shù)據(jù)量較小，使用第三方推送服務(wù)提供商可以用他們的維度進(jìn)行推送，實(shí)現(xiàn)精準(zhǔn)推送。友盟推送就是做的比較好的，可以根據(jù)用戶分群、地區(qū)、語言等多維度進(jìn)行推送，最大程度減少對于用戶的干擾，僅把消息推送給相關(guān)用戶。
下圖是Android平臺消息推送的簡單示意圖：開發(fā)者通過第三方推送服務(wù)提供商將信息直接下發(fā)給需要的設(shè)備，第三方推送服務(wù)提供商與設(shè)備建立一條長連接通道，并且將消息路由到APP中（圖中的設(shè)備1與設(shè)備2），對于像設(shè)備3這種無網(wǎng)絡(luò)連接或是沒有成功建立長連接通道的設(shè)備，會在設(shè)備3連網(wǎng)且推送消息沒有過期的情況下自動收到由第三方推送服務(wù)提供商推送過來的消息，保證消息不會丟失。
實(shí)現(xiàn)上的差異所帶來的直觀感受
1iOS的實(shí)時(shí)消息推送
iOS 在系統(tǒng)級別有一個(gè)推送服務(wù)程序使用 5223 端口。使用這個(gè)端口的協(xié)議源于 Jabber 后來發(fā)展為 XMPP ，被用于 Gtalk 等 IM 軟件中。
所以， iOS 的推送，可以不嚴(yán)謹(jǐn)?shù)睦斫鉃椋?/strong>
- 蘋果服務(wù)器朝手機(jī)后臺掛的一個(gè) IM 服務(wù)程序發(fā)送的消息。
- 然后，系統(tǒng)根據(jù)該 IM 消息識別告訴哪個(gè) Apps 具體發(fā)生了什么事。
- 然后，系統(tǒng)分別通知這些 Apps 。
他們帶給用戶的好處是實(shí)實(shí)在在的：
- 安全：
只有登錄過的開發(fā)者可以通過蘋果的服務(wù)器推送。 - 快速、穩(wěn)定、可靠：
蘋果掌控推送服務(wù)器和 OS 。 - 更省電。
- 讓整個(gè)系統(tǒng)的體驗(yàn)更統(tǒng)一和簡單：
不會出現(xiàn)殺后臺這種腦殘事。（不用大量 Apps / Apps 的服務(wù)為了推送掛后臺）。也不會出現(xiàn) Apps 被殺就收不到推送這種腦殘事（早一點(diǎn)的新浪微博 Android 版仍然如此）。 - 開發(fā)容易：
當(dāng)然，開發(fā)者還是要做些事情，比如維護(hù)個(gè)服務(wù)器什么的。但是復(fù)雜度無疑降低很多了。
2Android的實(shí)時(shí)消息推送
Apps 掛后臺一直是 Android 引以為豪的特性（雖然我真的不知道是好處多還是壞處多。。），大家掛后臺等待推送就成為技術(shù)選擇。當(dāng)然， Google 事后也提供類似蘋果的推送方式了。倒也談不上抄襲，畢竟蘋果的整個(gè)技術(shù)實(shí)現(xiàn)也沒有什么特別創(chuàng)新之處。
用戶的電池？ Apps 的開發(fā)者不會站在系統(tǒng)層面考慮的。他會假設(shè)其他 Apps 沒有那么“不自覺”。而 Google 不強(qiáng)制的結(jié)果就是：沒人真正為用戶的電池負(fù)責(zé)。
但是， Google 的方案也并非全是悲?。阂惨?yàn)檎麄€(gè)技術(shù)方案非強(qiáng)制， Android 的 Apps 在接收到推送后的表現(xiàn)更為靈活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回復(fù)， iOS 就需要越獄才能做到了。
結(jié)語
強(qiáng)制和封閉，有時(shí)候并非壞事。他意味著做出這個(gè)決定的人，要為此負(fù)責(zé)。所以，如果說蘋果的推送方案有何創(chuàng)新？
我以為是超越技術(shù)，不惜讓公司承擔(dān)更多風(fēng)險(xiǎn)和責(zé)任的解決方案。（類似的還有 BB 的專用網(wǎng)絡(luò)， Kindle 的全球 3G ）。
個(gè)人相信，擔(dān)負(fù)起這些“額外”的責(zé)任，是值得的。只要是為了用戶！ 
