本文為原創，如需轉載請標明出處，侵權必究。
不可不說的前言
去年筆者寫了一篇 《安卓推送這件小事》 ，現在回過頭來再看，不少地方已有些過時，趁著春節，重新思考和整理下推送這件事，這篇文章的目標受眾不僅是對客戶端推送實踐感興趣的工程師，還包括對推送的使用者體驗現狀不滿的使用者。
重新看推送需求
推送分推送需求和推送技術，推送技術由工程師實現，推送需求來自使用者，這裡的使用者包括如下幾個角色：
- 產品經理使用者
- 工程師使用者
- 普通使用者
不同角色對推送的需求不同，或者說對推送的度量的容忍度不同。主要有以下度量維度：
- 推送的到達率（到沒到）
- 推送的實時性（什麼時候到）
- 推送的表現形式（以什麼樣的 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 ）
相信我，當你真的發生問題的時候，直接聯絡相關人員，遠比自己除錯程式碼來得容易。
總結
說到這裡，是不是理解了筆者之前說的，推送這件事，本質是專案管理而不僅僅是開發呢，其實其他事情也一樣，明白了根源在哪裡，解決問題的思路就會很不同，不會糾結於具體的技術細節，而是先確保大方向的正確性。
上面這些我全做到了，但使用者仍然不滿意
上面這些只是不斷迭代實踐得來的經驗，推送這件事任重而道遠，去年如火如荼的**“安卓統一推送聯盟”**，正是為了解決這一問題而來，但由於歷史原因和各方利益的博弈，到最終解決問題還是有不少路要走。
可能使用者最不滿意的還是前面提到的：該推的不推，不該推的瞎推。
這也是筆者寫這篇文章的目的之一，通過背後的這些思考告訴使用者，不是看不見你們的不滿，我們在努力讓推送這件事變得美好，而你們現在馬上可以做的，就是去自己關注的主題下，明確自己的推送需求，把不需要的全部關掉就好，其他事情由我們來解決。