在《測試妹子的吶喊：為什么總是收不到推送？》這篇文章中，小樹解決了測試妹子收不到推送的反饋后，小樹對推送就異常感興趣，把項目里面所有有關推送的代碼都閱讀了一遍。
但細心的小樹發現這里面並沒有請求蘋果 APNS 接口的代碼，只有一些類似於極光推送，友盟推送，騰訊信鴿等推送的注釋。
帶着這些疑惑，小樹又找到了小黑，希望能再次得到大神的指導。
極光推送、友盟推送、騰訊信鴿這些其實都是第三方推送服務商，小黑說道。
誒，有了官方推送那為什么還要用第三方推送呢，小樹困惑地問道。
你這個問題倒是問對了，但要清楚地解釋這個問題，就必須跟你講一講推送的歷史了。小黑補充說。
蘋果的遠見：APNS誕生
其實互聯網崛起也就在 2010 年左右，在這之前是沒有推送這個概念的。而在互聯網時代，最常用的幾大平台就是：iOS、Android、Windows Phone。
在 iOS 平台上，蘋果有其官方推送平台 APNS（Apple Push Notification service），開發者可以直接使用該推送服務，但是提供的功能非常有限。
說起官方推送服務，蘋果可以說是很有自己的遠見的。在 iOS 系統一推出的時候就推出了 APNS 服務，所有推送給用戶的通知必須要通過 APNS 服務才可以送達。
「不就是一個服務嘛，這么大的公司應該沒啥問題吧」，小樹不屑地說。
可能一般人覺得這沒啥啊，不就一個服務嘛。但對於一個提供硬件廠商的公司來說，讓其來做一個軟件服務提供商，還是有些難度的，並且還是一個高並發量、海量用戶的一個服務。如果服務發生了異常，那么這個鍋可就是要蘋果背的。
安卓的短視：混亂的推送
文章首發於【博客園-陳樹義】，點擊跳轉到原文《開發小哥的困惑：為何要用第三方推送？》
你看，安卓平台可就做出了不一樣的選擇了。安卓平台在一開始推出的時候並沒有考慮到統一推送平台的問題，所以在安卓平台上是沒有一個統一的推送解決方案的。雖然后面安卓平台也推出了自己的 GCM (Google Cloud Messaging）推送平台，但開發者都習慣使用了自己的第三方推送服務，想改也很難了。再之，因為 Google 服務長期在國內處於不可用狀態，所以開發者也就懶得改了。
因為以上許多原因，你可以看到蘋果和安卓系統在設計推送系統上的不同。這其實直接就導致了用戶在使用時的體驗。對於蘋果系統來說，因為 iOS 對推送做了嚴格的規范，所以在 iOS 系統上的推送代碼都比較規范，不敢造次。而在安卓平台上，因為沒有了具體的規范，所以經常會出現彈窗通知一大堆的情況，過度打擾了用戶。
除了用戶體驗問題，與推送相關的還有另一個手機電量的問題。因為 iOS 對推送服務做了統一，所以在 iOS 手機上一般情況下就只會有一個「官方推送服務」的系統服務一直運行。而對於 Android 平台來說，因為每個 App 提供商都有自己喜好的第三方服務提供商，所以經常會出現一個 Android 設備上運行着數十個推送服務。這毋庸置疑就直接導致了 Android 設備的耗電量急劇上升，而 iOS 設備則因為良好的規范設計避免了這個問題。
說了這么多東西，覺得懂了挺多東西的，但發現並沒有解決一開始提出的問題。
為什么用第三方推送？
那到底為什么要用第三方推送而不是用官方推送呢？小樹繼續問。
其實這個問題只問對了一半，並不完全正確。
因為 Android 平台上的官方推送服務經常處於不可用的狀態。所以如果我們使用 Android 平台的官方推送的話，就會使得我們的推送服務非常不安全。因為這個原因，我們只能拋棄 Android 平台的官方服務。那現在只有兩條路可以走，一個是自建推送服務，另一個是使用第三方推送服務。
前面說到自建推送服務的難度是很高的，不僅要求開發人員有豐富的開發經驗，還要求其對網絡編程方面的知識有深入的了解。此外，對於運維人員也有很高的要求，其必須保證服務能長時間零差錯地運行。
這樣的要求對於中小型公司來收，成本是非常高的。所以很多時候，許多公司會選擇第三方推送服務，就像我們公司一樣。
小樹這下終於明白了使用第三方推送的原因了。雖然饒了許多彎子，但知其然才能知其所依然嘛。了解多一些歷史背景和原因，才能更好地理解現在所使用的技術。
這就是許多公司為什么選擇第三方推送的原因了。而因為 Android 使用了第三方推送，一般情況下都會要求 iOS 端也使用第三方推送，這是為了保持移動端實現的統一。你想一想，如果 Android 用第三方推送，而 iOS 端使用官方推送，那后台代碼豈不是要寫兩次實現？
對！保持一定的規范性是非常必要的。小樹興奮地說道。
第三方推送的優勢
除了技術實現難度低、統一移動端的推送之外，第三方推送平台的有點之一是能實現更多復雜的功能。
對於 APNS 官方推送服務來說，它只允許我們推送一個系統通知，用戶點擊之后跳轉到 App 里的某個頁面。但第三方推送服務則可以實現更多復雜的操作，比如用戶點擊通知后直接播放。
所以我們使用第三方推送的原因就是：
- Android 官方推送的缺陷，我們只能使用第三方推送服務。
- 使用第三方推送實現難度低，可以節省成本。
- 使用第三方推送能實現更多的復雜功能。
你的總結能力可真不錯啊，小黑豎起了大拇指。
蘋果與安卓的推送差異
但你還沒解釋為什么我那個問題只問對了一半呢。（為什么要用第三方推送而不是用官方推送呢？）
你不僅總結能力不差，記性還很厲害嘛。
在回答你這個問題之前，我先問題幾個問題。
在 iOS 設備上，我們的 App 使用了第三方推送。我們把 App 進程殺掉后，給該用戶發送一條推送消息，你猜該 iOS 設備能否收到？
小樹摸摸腦袋想，我們使用第三方推送服務，那這個推送服務必然是跟隨我們的 App 進程的。既然 App 進程都被殺掉了，那應該是接收不到推送的了。
就在小樹思考的那幾分鍾，小黑打開了一個小項目，模擬了一次簡單的推送。接着小黑運行了一個 JUnit 測試用例，向旁邊的測試機發送了一條推送。過了沒幾秒手機就響起了「叮叮」的推送提示聲。
小樹這下子可是丈二和尚摸不着頭腦，但是小黑卻不急着回答小樹的問題。繼續問第二個問題。
在 Android 設備上，我們的 App 使用了第三方推送。我們把 App 進程殺掉后，給該用戶發送一條推送消息，你猜該 Android 設備能否收到？
小黑還是用原先的方式發送了一條測試推送，這次旁邊的 Android 測試機卻一點動靜都沒有。
小樹這下可真的完全不知道所以然了，為什么 iOS 設備殺掉進程后能收到推送，而 Android 設備卻不行？
小樹急的像熱鍋上的螞蟻，但小黑卻悠然自得地拿起旁邊的咖啡喝了起來。
今天還有緊急需求要做，下次我再給你講講這個問題，你先回去想一想吧。小黑這次賣了個關子。
你所看到是推送系列文章中的一篇，更多關於推送的文章：