還記得上次我們做過的試驗么？
我們在 iOS 設備殺掉進程后能收到推送，而 Android 設備卻不行。這個問題可困惑了小樹很長時間，這天趁着工作清閑，又跑到小黑工位上請教了。
小黑喝了口茶便開始說，我們現在所有推送消息都是通過第三方推送推出去的。所以了解一下第三方推送是如何實現的非常重要。
當我們的 App 啟動的時候，同時會啟動我們App中附帶的第三方廠商的推送服務，這時候 App 進程中就有一個 Socket 長連接一直與第三方廠商的推送服務器保持着。當我們有消息需要推送到用戶設備上時，我們通過調用第三方廠商的推送接口，傳入對應的別名就可以了。
小樹聽到別名感覺有點困惑，什么是別名啊？
其實別名就是第三方廠商用來標記唯一用戶的一個標識。
當我們的 App 啟動的時候，廠商要求 App 方在合適的時候將別名和該設別的 DeviceToken 這兩個參數傳給廠商，從而建立起綁定關系。
所以從本質上來說，第三方廠商最后還是通過 DeviceToken 去識別要推送到哪個設備的哪個 App 的。
而這個別名，一般情況下也是要能唯一標識一個用戶。所以很多時候我們都用用戶ID來作為別名，將其和 DeviceToken 綁定在一起。
小樹聽完之后 發覺可以畫一個流程圖來梳理一下整個流程了。
App啟動 -> 啟動第三方推送服務 -> 注冊別名和DeviceToken -> 等待推送消息
畫得很不錯，非常清晰地表達了第三方推送的流程，小黑說道。
而對於后台開發小哥來說，如果要發送一條推送給用戶，只需要將別名和推送內容作為參數調用第三方廠商的接口即可。
但這貌似還沒回答之前的問題呢，為什么 iOS 設備在 App 進程被殺掉時能收到推送，而 Android 設備卻不行呢？
小伙子果然窮追不舍，我這不是還沒講完嘛，別着急啊。小黑淡定地說。
文章首發於【博客園-陳樹義】，點擊跳轉到原文《官方老爹之痛：為什么蘋果能收到推送，而安卓不行？》
我們上面說的這種情況，只在 App 進程還未被殺掉時適用。但當我們的 App 進程被殺掉時，第三方服務廠商的進程也會跟着被清除。
此時，如果我們還是通過設備與第三方廠商建立的 Socket 長連接進行推送消息接收，顯然是無法正常進行的。所以，安卓設備就無法收到推送了。
而 iOS 設備能夠在 App 進程死亡之后還接收到推送，那是因為第三方廠商在檢測到自己與 iOS 設備的連接斷開后，自動調用蘋果官方的 APNS 服務進行消息推送。
而 iOS 設備的官方推送服務只要設備開機，則是永遠存在的。所以我們的 iOS 設備就能夠做到即使 App 進程被殺掉也能收到推送。雖然這推送推送功能很有限，但是能送達用戶總比沒送達好吧。
而 Android 設備不能在 App 進程死亡后收到推送，那是因為其沒有官方推送的支持。
但現在也有一些情況下能夠實現 Android 設備在 App 還未開啟的時候，也可以接收到推送。
小樹一聽到還有這么一招，急忙問到底是什么方式啊？
這功能能否實現，這就依賴於第三方廠商的服務是否強大了。
假設我們手機上有兩個 App，分別是「珍愛網」和「知乎」，它們都使用同一個推送廠商的推送服務。
當我們把兩個 App 都啟動，這時候進程上就會有兩個關於推送的服務進程，一個歸屬於「珍愛網」App，一個歸屬於「知乎」這個 App。
當我們把「珍愛網」App 殺掉之后，珍愛網 App 對應的推送進程也就完蛋了。但是這時候不是有 知乎 App 里這個推送么。有些廠商就是利用了這一點，通過某些技術手段，使用「知乎」App的推送服務去喚醒「珍愛網」App 的推送服務，從而使得 珍愛網 App 的用戶也能收到推送。
原來這還能這么玩啊，果然是自己的服務就可以有無限的想象空間啊。小樹感慨道。如果我也能實現自己的一個推送服務就好了，這樣我們就不用依賴第三方廠商，能夠做更多定制化服務了。
自建推送服務雖然看似美好，但是開發成本和維護成本卻是非常高的。如果公司業務規模不大，還是使用第三方推送服務比較靠譜。
不過我們公司規模其實也不小了，有將近上億的用戶，每天進行業務推送的量級也達到了百萬級別。公司前陣子組織了開發團隊里的開發精英，埋頭干了2個月，終於搞出一個能用的推送服務了。
小樹聽到異常欣喜，覺得又有東西可以學習了。
不過今天還是不說那么多了吧，怕你學太多吸收不了。有機會我們下次來講講如何從零開始去設計一個推送系統，再如何一步步將其實現。
你所看到是推送系列文章中的一篇，更多關於推送的文章：