淺談iOS和Android後臺實時訊息推送的原理和區別

前言

iOS和Android上的實時訊息推送差異很大，往小了說是技術實現的差異，往大了說是系統實現理念的不同。實時訊息推送在移動端網際網路時代很平常，也很重要，它的存在讓智慧終端真正成為全時資訊傳播的工具。本文將從原理上談談兩個平臺上實時訊息推送的區別。

簡要對比

1iOS的實時訊息推送

iOS 系統的推送（APNS，即 Apple Push Notification Service）依託一個或幾個系統常駐程式運作，是全域性的（接管所有應用的訊息推送），所以可看作是獨立於應用之外，而且是裝置和蘋果伺服器之間的通訊，而非應用的提供商伺服器。你的例子裡面，騰訊 QQ 的伺服器（Provider）會給蘋果公司對應的伺服器（APNs）發出通知，然後再中轉傳送到你的裝置（Devices）之上。當你接收到通知，開啟應用，才開始從騰訊伺服器接收資料，跟你之前看到通知裡內容一樣，但卻是經由兩個不同的通道而來。

公眾號推薦:

2Android的實時訊息推送

而 Android，就不同，更像是傳統桌面電腦系統做法。每個需要後臺推送的應用有各自的單獨後臺程式，才能和各自的伺服器通訊，交換資料。另外其實 Android 也有類似 APNS 的 GCM（Google Cloud Message），屬於開發者可選，非強制。

3小結

所以你大概看出來區別，iOS 的訊息推送機制面世之時是一種全新的解決方案（堪稱平臺中的平臺），應用本身不能有常駐的後臺程式，系統的開銷少，記憶體使用更少，電量也更少（把更多的運算和資源開銷放在雲端，非裝置端）。而 Android 的特點，雖然開銷大，優點是更穩定快速，但不明顯。

技術原理

在這裡，你要寄送的快件兒就是你要發的“訊息”，送達房間相當於最終“接收訊息的App”，順豐公司在北京的總站點相當於這裡提到的“裝置”，送達房間的房間號就相當於這個環節裡面提到的“包名”。

公眾號推薦:

2iOS實時訊息推送

iOS的推送是通過蘋果自己的APNs服務進行的，使用者需要將device_token以及訊息內容等推送資訊交給APNs伺服器，剩下的均由蘋果自己來完成。iOS應用的推送大部分情況下都要依賴蘋果生態提供的APNs（Apple Push Notification Service）服務。

首先作為裝置標識的device-token是由APNs頒發的，App開發者或者第三方推送平臺(圖中的Provider)做的工作是收集這個device-token，APNs的推送是要求基於APNs頒發的device-token來推送的。只有正確的device-token會被APNs接受，如果是一個錯誤的、或者無效的device-token(比如App已經解除安裝了)，APNs就不會接受。

接著開發者使用第三方推送平臺（圖中的Provider）在將推送內容與範圍選定之後進行推送，第三方推送平臺將資訊提交給APNs，剩下的操作全部都由APNs來進行完成，整個過程第三方推送平臺就不能控制了。但是如果提供的device_token是失效的（app被解除安裝、系統版本升級導致device_token變化等情況）那麼推送過程就會被中斷，頻繁的斷線重連甚至會被APNs認為是一直DoS攻擊。

下圖是Android平臺訊息推送的簡單示意圖：

開發者通過第三方推送服務提供商將資訊直接下發給需要的裝置，第三方推送服務提供商與裝置建立一條長連線通道，並且將訊息路由到APP中（圖中的裝置1與裝置2），對於像裝置3這種無網路連線或是沒有成功建立長連線通道的裝置，會在裝置3連網且推送訊息沒有過期的情況下自動收到由第三方推送服務提供商推送過來的訊息，保證訊息不會丟失。

實現上的差異所帶來的直觀感受

1iOS的實時訊息推送

iOS 在系統級別有一個推送服務程式使用 5223 埠。使用這個埠的協議源於 Jabber 後來發展為 XMPP ，被用於 Gtalk 等 IM 軟體中。

 

所以， iOS 的推送，可以不嚴謹的理解為：

• 蘋果伺服器朝手機後臺掛的一個 IM 服務程式傳送的訊息。

• 然後，系統根據該 IM 訊息識別告訴哪個 Apps 具體發生了什麼事。

• 然後，系統分別通知這些 Apps 。

2Android的實時訊息推送

Apps 掛後臺一直是 Android 引以為豪的特性（雖然我真的不知道是好處多還是壞處多。。），大家掛後臺等待推送就成為技術選擇。當然， Google 事後也提供類似蘋果的推送方式了。倒也談不上抄襲，畢竟蘋果的整個技術實現也沒有什麼特別創新之處。

使用者的電池？ Apps 的開發者不會站在系統層面考慮的。他會假設其他 Apps 沒有那麼“不自覺”。而 Google 不強制的結果就是：沒人真正為使用者的電池負責。

但是， Google 的方案也並非全是悲劇：也因為整個技術方案非強制， Android 的 Apps 在接收到推送後的表現更為靈活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回復， iOS 就需要越獄才能做到了。

結語

強制和封閉，有時候並非壞事。他意味著做出這個決定的人，要為此負責。所以，如果說蘋果的推送方案有何創新？

我以為是超越技術，不惜讓公司承擔更多風險和責任的解決方案。（類似的還有 BB 的專用網路， Kindle 的全球 3G ）。

個人相信，擔負起這些“額外”的責任，是值得的。只要是為了使用者！