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 開發容易。
固然，開發者仍是要作些事情，好比維護個服務器什麼的。可是複雜度無疑下降不少了。

Android 的推送
Apps 掛後臺一直是 Android 引覺得豪的特性（雖然我真的不知道是好處多仍是壞處多。。）。。。你們掛後臺等待推送就成爲技術選擇。

固然， Google 過後也提供相似蘋果的推送方式了。倒也談不上抄襲，畢竟蘋果的整個技術實現也沒有什麼特別創新之處。

用戶的電池？

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

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

最後的話
強制和封閉，有時候並不是壞事。他意味着作出這個決定的人，要爲此負責。

因此，若是說蘋果的推送方案有何創新？

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

我的相信，擔負起這些「額外」的責任，是值得的。。。

只要是爲了用戶。

PS
敢於承擔責任的公司也更像個可靠的成年人，而不是一個隨意胡鬧的孩子。