419
iOS 和 Android 的後台推送工作原理各是如何？有什麼區別？
iOS 的推送iOS 在係統級別有一個推送服務程序使用 5223 端口。使用這個端口的協議源於 Jabber 後來發展為 XMPP ，被用於 Gtalk 等 IM 軟件中。
所以， iOS 的推送，可以不嚴謹的理解為：
蘋果服務器朝手機後台掛的一個 IM 服務程序發送的消息。
然後，係統根據該 IM 消息識別告訴哪個 Apps 具體發生了什麼事。
然後，係統分別通知這些 Apps 。
這個消息的內容是這樣的：
應該說，蘋果這種方式在技術上沒有什麼創新。但是，整個架構是很了不起的。 因為：
1
使用久經考驗的協議，技術風險小。
2
蘋果勇於承擔責任：
他需要維護一個代價不小的服務器集群，而且要為服務器的 down 機負責。
選擇低風險的技術方案 Bug 更少，減輕了用戶的痛苦，這是構架師的功勞。
蘋果承擔責任，盡可能的減少了不可控的意外，保證了用戶體驗。
這，隻能說是公司決策者的功勞。
（從側麵說明有個懂技術的 VP 是多重要。。。而 Scott 走人了。。）
他們帶給用戶的好處也是實實在在的。
1 安全。
隻有登錄過的開發者可以通過蘋果的服務器推送。
2 快速，穩定，可靠。
蘋果掌控推送服務器和 OS 。
3 更省電。
4 讓整個係統的體驗更統一和簡單。
不會出現殺後台這種腦殘事。（不用大量 Apps / Apps 的服務為了推送掛後台）。
也不會出現 Apps 被殺就收不到推送這種腦殘事（早一點的新浪微博 Android 版仍然如此）。
5 開發容易。
當然，開發者還是要做些事情，比如維護個服務器什麼的： https://www.ifanr.com/3979。但是複雜度無疑降低很多了。
Android 的推送
Apps 掛後台一直是 Android 引以為豪的特性（雖然我真的不知道是好處多還是壞處多。。）。。。大家掛後台等待推送就成為技術選擇。
當然， Google 事後也提供類似蘋果的推送方式了。倒也談不上抄襲，畢竟蘋果的整個技術實現也沒有什麼特別創新之處。
用戶的電池？
Apps 的開發者不會站在係統層麵考慮的。他會假設其他 Apps 沒有那麼“不自覺”。而 Google 不強製的結果就是：沒人真正為用戶的電池負責。
但是， Google 的方案也並非全是悲劇：
也因為整個技術方案非強製， Android 的 Apps 在接收到推送後的表現更為靈活。
像 Line 的 Android 版本可以在推送通知的 Popup 上直接回複， iOS 就需要越獄才能做到了。
最後的話
強製和封閉，有時候並非壞事。他意味著做出這個決定的人，要為此負責。
所以，如果說蘋果的推送方案有何創新？
我以為是超越技術，不惜讓公司承擔更多風險和責任的解決方案。（類似的還有 BB 的專用網絡， Kindle 的全球 3G ）
個人相信，擔負起這些“額外”的責任，是值得的。。。
隻要是為了用戶。
PS
勇於承擔責任的公司也更像個可靠的成年人，而不是一個隨意胡鬧的孩子。
OS 係統的推送（APNS，即
Apple Push Notification Service）依托一個或幾個係統常駐進程運作，是全局的（接管所有應用的消息推送），所以可看作是獨立於應用之外，而且是設備和蘋果服務器之間的通訊，而非應用的提供商服務器。你的例子裏麵，騰訊 QQ 的服務器（Provider）會給蘋果公司對應的服務器（APNs）發出通知，然後再中轉傳送到你的設備（Devices）之上。當你接收到通知，打開應用，才開始從騰訊服務器接收數據，跟你之前看到通知裏內容一樣，但卻是經由兩個不同的通道而來。
而 Android，就不同，更像是傳統桌麵電腦係統做法。每個需要後台推送的應用有各自的單獨後台進程，才能和各自的服務器通訊，交換數據。另外其實 Android 也有類似 APNS 的 GCM（Google Cloud Message），屬於開發者可選，非強製。（更多請看本回答評論區裏麵 @Bill
Cheng 的補充）
所以你大概看出來區別，iOS 的消息推送機製麵世之時是一種全新的解決方案（堪稱平台中的平台），應用本身不能有常駐的後台進程，係統的開銷少，內存使用更少，電量也更少（把更多的運算和資源開銷放在雲端，非設備端）。而 Android 的特點，雖然開銷大，優點是更穩定快速，但不明顯。
來自：https://www.zhihu.com/question/20667886
最後更新：2017-04-04 07:03:14