消息推送背後的思考

本文爲原創，如需轉載請標明出處，侵權必究。

不可不說的前言

去年筆者寫了一篇 《安卓推送這件小事》 ，如今回過頭來再看，很多地方已有些過期，趁着春節，從新思考和整理下推送這件事，這篇文章的目標受衆不只是對客戶端推送實踐感興趣的工程師，還包括對推送的用戶體驗現狀不滿的用戶。

從新看推送需求

推送分推送需求和推送技術，推送技術由工程師實現，推送需求來自用戶，這裏的用戶包括以下幾個角色：

• 產品經理用戶
• 工程師用戶
• 普通用戶

不一樣角色對推送的需求不一樣，或者說對推送的度量的容忍度不一樣。主要有如下度量維度：

• 推送的到達率（到沒到）
• 推送的實時性（何時到）
• 推送的表現形式（以什麼樣的 ui 展現）
• 推送的後臺耗電（後臺是用戶無感知，可是系統很敏感）
• 推送內容（該推的不推，不應推的瞎推）

而咱們最該關心的是普通用戶的需求，即推送的到達率和推送內容。若是不理清上面的需求分析，即便推送技術實現得再好，也沒法在實際場景得到成功。做爲工程師不能埋頭作技術，任何一項業務背後都有它的核心需求。

以上說明了作推送這個需求時的考慮問題的優先級，在不斷的迭代過程當中，仍是須要把各方面都作到盡善盡美的。

管好你的業務夥伴

在人力成本受限的狀況下，客戶端實現推送不可憑一己之力，整個推送的實現過程與其說是開發，不如說是項目管理。咱們來看看推送須要和哪些業務夥伴打交道：

• Android 的官方推送 FCM
• 第三方的推送實現（包括手機廠商自帶推送和第三方推送）
• 手機廠商的後臺策略（如電池優化）
• Android 自身的後臺策略
• 第三方 app 的後臺策略（如綠色守護的後臺純淨模式）
• 手機對通知的 ui 支持狀況
• Google Play 的隱私策略

那麼筆者是如何來看這個問題的呢，首先須要進行一次項目管理的需求轉換，上面幾個業務夥伴的分類不便管理，須要作一次從新分類，具體以下：

• 推送實現（ FCM、手機自帶推送、第三方推送、後臺純淨）
• 後臺策略（何時啓動、何時中止，到了後臺只有當前使用的推送在幹活，其餘都要幹掉）
• 通知形式（主要指透傳消息的展現形式，分爲系統默認和自定義）
• 隱私策略（隱私不注重，直接給你下架）

上面分類後是否是邏輯清楚了不少呢，可是還不夠，咱們只是進行了功能上的劃分，在時序上還要想明白：

• 後臺策略貫穿整個 app 的生命週期
• 推送和通知的依賴關係，老是先收到推送，而後纔有通知

需求抽象到這裏，那麼實現也就水到渠成了。

抽象後的推送實現

如今不少工程師 UML 圖都懶得畫，雖然 UML 不等於架構能力，可是確實是提高抽象和架構能力的一個很好的工具。

圖中的每個方法是對推送概念的一個抽象。

值得注意的細節

別忽視這些細節，關鍵時候可能會讓你的整個推送用起來不爽。

細節一：引入 sdk 的注意事項

在這裏提到的 sdk 是推送實現的 aar 或者 jar 。

• 儘可能不要依賴 aar ，而是依賴 jar 和本身搞定資源文件。
• 有些 sdk 分 Google Play 和國內版，打包的時候經過條件判斷引入不一樣的 sdk 。
• 關注 sdk 的方法數和大小，有些版本會忽然就大了好幾倍。
• 關注 sdk 的升級日誌，若是是修復空指針或者提升穩定性啥的，記得必定要升。

細節二：殺不掉的推送進程

咱們的推送平臺策略是服務端下發的，會根據下發的 vendor 來決定開啓指定平臺的推送，關閉其餘平臺的推送。但以前常常有用戶經過系統工具看到後臺跑了兩個推送進程，這是怎麼回事呢？原來，推送實現爲了知足不被殺掉的需求，會盡量地讓本身的推送進程活着，即便手動調用了 sdk 的 stop 方法也沒用。

這個時候只能上大殺器了，咱們在 stop 方法以後延時幾百毫秒調用 Process.killProcess() 方法。

細節三：發揮不穩定的 FCM

你們知道 FCM 推送是要知足必定條件的，而且即便知足條件，也不必定能夠收到推送，那麼就須要對條件的判斷有一個策略，這個策略還在迭代，等到穩定後再講。

解決技術問題，也不要忘記解決人的問題

任何涉及到業務夥伴的事情，若是隻關心技術文檔或者代碼，可能會事倍功半，由於代碼是人寫的，既然你引入了別人寫的 sdk ，那麼就要去創建一條溝通路徑，包括以下方式：

• 跟蹤 github 上該項目，保持和主要開發者的溝通
• 創建和國內第三方 sdk 的售前或者技術支持人員的溝通路徑（最好是微信或 qq ）

相信我，當你真的發生問題的時候，直接聯繫相關人員，遠比本身調試代碼來得容易。

總結

說到這裏，是否是理解了筆者以前說的，推送這件事，本質是項目管理而不只僅是開發呢，其實其餘事情也同樣，明白了根源在哪裏，解決問題的思路就會很不一樣，不會糾結於具體的技術細節，而是先確保大方向的正確性。

上面這些我全作到了，但用戶仍然不滿意

上面這些只是不斷迭代實踐得來的經驗，推送這件事任重而道遠，去年如火如荼的**「安卓統一推送聯盟」**，正是爲了解決這一問題而來，但因爲歷史緣由和各方利益的博弈，到最終解決問題仍是有很多路要走。

可能用戶最不滿意的仍是前面提到的：該推的不推，不應推的瞎推。

這也是筆者寫這篇文章的目的之一，經過背後的這些思考告訴用戶，不是看不見大家的不滿，咱們在努力讓推送這件事變得美好，而大家如今立刻能夠作的，就是去本身關注的主題下，明確本身的推送需求，把不須要的所有關掉就好，其餘事情由咱們來解決。