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 開發容易。
當然，開發者還是要做些事情，比如維護個服務器什么的： http://www.ifanr.com/3979。但是復雜度無疑降低很多了。
Android 的推送
Apps 掛后台一直是 Android 引以為豪的特性（雖然我真的不知道是好處多還是壞處多。。）。。。大家掛后台等待推送就成為技術選擇。
當然， Google 事后也提供類似蘋果的推送方式了。倒也談不上抄襲，畢竟蘋果的整個技術實現也沒有什么特別創新之處。
用戶的電池？
Apps 的開發者不會站在系統層面考慮的。他會假設其他 Apps 沒有那么“不自覺”。而 Google 不強制的結果就是：沒人真正為用戶的電池負責。
但是， Google 的方案也並非全是悲劇：
也因為整個技術方案非強制， Android 的 Apps 在接收到推送后的表現更為靈活。
像 Line 的 Android 版本可以在推送通知的 Popup 上直接回復， iOS 就需要越獄才能做到了。
最后的話
強制和封閉，有時候並非壞事。他意味着做出這個決定的人，要為此負責。
所以，如果說蘋果的推送方案有何創新？
我以為是超越技術，不惜讓公司承擔更多風險和責任的解決方案。（類似的還有 BB 的專用網絡， Kindle 的全球 3G ）
個人相信，擔負起這些“額外”的責任，是值得的。。。
只要是為了用戶。
清澈Saup——來自知乎