ios / android的推送原理

本文內容基原本自知乎：https://www.zhihu.com/question/20667886

ios:

iOS 系統的推送（APNS，即 Apple Push Notification Service）依託一個或幾個系統常駐進程運做，是全局的（接管全部應用的消息推送），因此可看做是獨立於應用以外，並且是設備和蘋果服務器之間的通信，而非應用的提供商服務器。

因此， iOS 的推送，能夠不嚴謹的理解爲：蘋果服務器朝手機後臺掛的一個 IM 服務程序發送的消息。

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

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

 

android:

而 Android每一個須要後臺推送的應用有各自的單獨後臺進程，才能和各自的服務器通信，交換數據。

其實 Android 也有相似 APNS 的 GCM（Google Cloud Message）的服務，若是一個應用的推送採用這種模式的話，就和iOS推送一個樣了。

GCM相關的程序應該是集成在所謂的Gapps中，但國內的 Android 手機上 GCM 處於基本不可用的狀態，並且Android 由於後臺能夠長駐，因此，App們各顯神通。

聊天類應用的話，大多數直接借用 XMPP 規範裏的一些成果。少許如微信有IM底子的，本身開發協議。這些在實現原理上與 APNs / GCM 沒有本質的區別，但有必定的技術門檻。

而大多數廣泛應用，要使用推送的話，則使用輪詢的方式簡單實現，就是定時去服務器上查詢數據，也叫Polling，還有一種手機跟服務器之間維護一個 TCP 長鏈接，當服務器有數據時，實時推送到客戶端，也就是咱們說的 Push。

輪詢的方式不論怎麼優化都比較費電費流量，長鏈接的方式在網絡不穩定的狀況下，Socket比較容易斷開推送數據失敗。