IOS和android作業系統推送的實現原理

標籤：

IOS使用的技術叫做：APNS（Apple Push Notification Service）

Android使用的官方技術叫做：GCM（Google Clouding Messaging）

但是Android的GCM是開發人員自己選的也可以自己實現，但是IOS就必須要走他的APNS才可以。

APNS和GCM本質上都是在系統中存在一個基於TCP協議的一個長串連，一直保持與伺服器的串連，

即使手機睡眠也會一直保持聯絡。

這樣你可能會產生一個疑問：這樣豈不是會很費電？

事實上不是這樣的，TCP長串連有個心跳時間（這個名字很有意思嘛，就像人的心臟一樣，我們會覺得

心臟一直跳啊跳不會衰老很快嗎？但是醫學研究表明：心臟的收縮與舒張的時間比在1:2左右，也就是說

心臟2/3的時間在訊息呢！），原因與這個類似，在長串連中，用戶端與伺服器在傳輸資料的時候傳輸資料

沒的說，但是在沒有資料傳送的時候，用戶端會每隔一段時間給伺服器一個訊息來告訴伺服器要一直保持

聯絡，在發送訊息的時候耗電，其他時候就不會了。這樣就大概解決了你的疑問。

TCP長串連的心跳時間，在國外可以很長比如30分鐘，在國內則因為網路環境複雜一般10分鐘。客戶

端發起的心跳，會短暫地消耗手機電能，但在這個心跳間隔期間，則消耗電能是很少的。當在心跳期間服

務器端有推送資訊過來時，用戶端可以收到並做處理。

ISO在設計之初考慮到使用者的體驗是不允許應用後台啟動並執行，有了這個限制，但是對於終端裝置，應用又

是有必要“通知”到達使用者的，隨時與使用者主動溝通起來的（典型的如聊天應用）。所以Apple公司就採用了

這個技術。所有應用，有必要（申請）並且被允許（使用者可以改設定）的話，可以通過 APNs 中轉到達

使用者。

至於Android的GCM，原理與之類似，但是不同的是這個幾乎是沒人用的，尤其是在大陸這個牆內的環境下，

就直接被Pass掉了。一般來說，應用大多數直接借用 XMPP 規範裡的一些成果。少量如有IM底子的，

自己開發協議。這些在實現原理上與APNs / GCM 沒有本質的區別，但有一定的技術門檻。而大多數普遍應

用，要使用推送的話，則使用輪詢的方式簡單實現。當然現在有好多的第三方的推送平台，比如極光推送，

百度的雲推送等等。這些都是一個服務可以多應用一起使用的，假如qq、等等應用都統一使用一個推

送平台，那麼Android的推送將達到IOS一樣的省電效果，咩哈哈。

題外話：如果你的手機是土豪蘋果，只要空間足夠，應用不用管他，多少都沒事。至於Android，如果覺得手機卡頓，能少裝應用就少裝啊。

IOS和android作業系統推送的實現原理