第三方推送已死

國內第三方推送的起源

2010 年左右，Android 手機在國內迅速發展，Google 的原生推送（C2DM，如今的 GCM）因爲種種緣由不能正常使用，當時的 Android 開發者使用各類辦法來解決這個問題，其中就包括 Android 手機廠商開發出本身的推送方案。

對於大部分開發者來講，除了作一個 App，還要獨立開發一套推送系統是件異常困難的事情。哪怕是用戶數量很大的 App ，這也不是一件容易的事情。因而在 2011 年末，我產生了作獨立第三方推送服務的想法，也就有了後來的極光推送。

推送消息能送達的關鍵

這幾年常常有業內的朋友探討推送可否送達的關鍵因素。其實最重要的是 SDK 可否保活。

具體地說，有如下兩方面：

SDK 若是不能及時地發起心跳，運營商網絡的長鏈接會被斷開。

SDK 的任務若是被殺掉了，不能被拉起，消息就徹底沒有機會下發。

參考以前的文章：《推送技術原理》 http://zhang.hu/mobile-push/

若是 SDK 端不能有效地保活，那麼不管服務器端怎麼優化，都不能保證消息及時地送達。

對 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 廠商推送通道現狀

目前國內幾個主要的 Android 廠商中，小米、華爲 都有提供官方的推送服務。通過咱們團隊的驗證，他們的推送服務在本身品牌的手機上，有相對穩定的送達率。目前表現最好的是小米，華爲的推送延遲有時比較大，也不太穩定。

而另外的幾家 OPPO、VIVO、金立 都沒有官方的推送服務。

雲巴近期推出了一鍵集成 小米、華爲 推送的功能，方便開發者快速集成廠商的推送服務。可是對於沒有提供推送服務的廠商，目前尚未特別好的辦法。咱們期待各主流手機廠商爲了 App 有更好的體驗，都能提供解決這個問題的方案。

文章做者：@Tiger_張虎 ，雲巴 (yunba.io) 創始人，yunba.io 雲端實時消息服務。 JPush 創始人，原CTO。 Oracle VM 創始團隊成員