1
雷鋒網按：本文作者@Tiger_張虎， 云巴 (yunba.io) 創始人，yunba.io 云端實時消息服務。 JPush 創始人，原CTO。 Oracle VM 創始團隊成員。雷鋒網已獲授權。
2010 年左右，Android 手機在國內迅速發展，Google 的原生推送（C2DM，現在的 GCM）由于種種原因不能正常使用，當時的 Android 開發者使用各種辦法來解決這個問題，其中就包括 Android 手機廠商開發出自己的推送方案。
對于大部分開發者來說，除了做一個 App，還要獨立開發一套推送系統是件異常困難的事情。哪怕是用戶數量很大的 App ，這也不是一件容易的事情。于是在 2011 年底，我產生了做獨立第三方推送服務的想法，也就有了后來的極光推送。
這幾年經常有業內的朋友探討推送能否送達的關鍵因素。其實最重要的是 SDK 能否保活。
具體地說，有以下兩方面：
1. SDK 如果不能及時地發起心跳，運營商網絡的長連接會被斷開。
2. SDK 的任務如果被殺掉了，不能被拉起，消息就完全沒有機會下發。
參考之前的文章：《推送技術原理：移動無線網絡長連接》
如果 SDK 端不能有效地保活，那么無論服務器端怎么優化，都不能保證消息及時地送達。
對 Android 手機廠商來說，這里有一個矛盾的問題。對于各個 App 的推送達到的效果來說是好事，但這樣做一定程度上破壞了Android系統的生態，增加了功耗，也違背了系統清理后臺設計的初衷。手機廠商都希望自己出產的手機能有盡量長的待機時間，但是 App 定時在后臺啟動、維持心跳的行為，會極大地影響手機待機時間。
因此，最近幾年，手機廠商為了控制后臺服務，持續地推出各種限制手段。比如之前的心跳對齊，也就是不允許 App 任意使用 RTC 后臺喚醒手機。還有更嚴厲的手段，就是定時清理所有后臺服務，并且不允許服務通過監聽廣播自動拉起。
正如前文所提到的，最近主流的 Android 手機都會清理后臺服務，禁止服務自動拉起，以前第三方推送服務商的各種 SDK 保活手段相繼失效，這個問題從根本上動搖了 Android 第三方推送服務的基礎，導致幾乎所有的 Android 第三方推送服務都不能保證送達。
面對這樣的問題，App 開發者該如何應對？
因為推送服務的特點，它最應該以系統原生服務的形態存在。在 iOS/Android 系統推出的早期，都考慮到了這個問題，iOS 有 APNs，Android 有 C2DM（GCM）。可惜的是，Android 的 GCM 在國內早已不能被有效使用，而 Android 方面沒有試圖解決這個問題，而把問題留給了手機廠商和 App 開發者。
考慮到推送服務的特點，我們自然而然就想到了通過廠商的推送通道來解決這個問題，就像在 iOS 上使用 APNs 一樣。使用 App 內的消息通道發消息給 App，再通過廠商的推送通道喚醒 App，App 被打開后，接受消息通道的離線消息。
從目前的實踐情況來看，這是解決后臺進程被清理的最有效辦法。
目前國內幾個主要的 Android 廠商中，小米、華為 都有提供官方的推送服務。經過我們團隊的驗證，他們的推送服務在自己品牌的手機上，有相對穩定的送達率。目前表現最好的是小米，華為的推送延遲有時比較大，也不太穩定。
而另外的幾家 OPPO、VIVO、金立 都沒有官方的推送服務。
云巴近期推出了一鍵集成 小米、華為 推送的功能，方便開發者快速集成廠商的推送服務。但是對于沒有提供推送服務的廠商，目前還沒有特別好的辦法。我們期待各主流手機廠商為了 App 有更好的體驗，都能提供解決這個問題的方案。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
