一 背景
金融級移動開發平臺 mPaaS（Mobile PaaS）為 App 開發、測試、運營及運維提供雲到端的一站式解決方案，能有效降低技術門檻、減少研發成本、提升開發效率，協助企業快速搭建穩定高質量的移動應用。其中消息推送服務（Message Push Service，簡稱 MPS）為開發者提供了專業的移動消息推送方案，針對不同的場景推出多種推送類型，滿足個性化推送需求。為了提升推送的到達率，mPaaS 集成了華為、小米等廠商的推送功能，從而有效地提高用戶留存率，提升用戶體驗。在我們日常運維過程中，發現少部分設備在廠商push下無法push，在此分享下相關案例的排查過程，方便後續同類問題借鑑。
二 push相關背景
1. push整體架構
以接觸最多的國內Android設備為例，整體結構如下，官網已經給出詳細介紹（鏈接），這裡不在贅述。
2. 廠商push和自建push
廠商push通道：優點是通過各個OS廠商維護的長鏈接進行推送，在App被系統殺掉後也可以進行推送，推送到達率高於自建push。支持華為，小米，oppo，vivo等廠商。缺點是，目前廠商的push基本都只支持通知欄消息的推送，在用戶點擊通知前，不啟動應用，對紅點, 圖片等消息格式支持有限。
自建push通道：通過App啟動後和自建服務端的長連接通道實現推送，缺點也很明顯，App被殺掉後，就無法收到信息。主要用於不支持廠商渠道場景下的push。
三 問題排查舉例
通過上面的介紹，可以看出三方廠商push是否成功，主要取決於三個鏈路，分別為：
1.三方token正確生成上報
2.服務端正常轉發到廠商服務器
3.下發到客戶端消息可以正常顯示
1. 測試準備
為了快速驗證問題，我們需要準備一個推送程序，可以快速推送信息到App上。MPS提供了推送的Http接口供外部調用，我們可以通過初始化一個簡單的java程序實現推送信息的發送，方便聯調。使用鏈接：鏈接
2. 三方token生成階段
目前mPaas對三方廠商push的token生成分為以下步驟。
2.1 設備在三方push的廠商列表裡
以華為設備為例，判斷是否是華為設備的標準是，檢測當前手機是否是emui, 如果是才走華為PUSH SDK。在我們日常運維的case中，發現過部分設備由於刷機或者其他操作，在華為手機上安裝的不是emui，類似這種設備是走不了華為push的，只能走自建push。
以vivo設備為例，低版本手機只有在vivo公佈的白名單設備內才支持推送。白名單見：鏈接
2.2 生成三方token
在調用push sdk生成token的過程中，由於push sdk的生成也依賴當前手機的room版本，以華為為例，就強依賴華為手機內置的HMS Core版本。針對這種場景下的問題，在獲取三方token失敗的時候，會在回調裡返回對應錯誤碼。如下圖所示，搜索push的關鍵字mPush14, 然後過濾，可以獲取token返回錯誤碼2。
我們查看華為定義的錯誤碼（鏈接），發現2表示SERVICE_VERSION_UPDATE_REQUIRED，需要升級當前的HMS版本。
升級HMS版本的方案有兩個
方案1: 主動升級,調用更新服務接口,升級更新效果如下所示：
在啟動階段調用如下服務，安裝更新華為推送服務
if (HuaweiApiAvailability.getInstance().isHuaweiMobileNoticeAvailable(context) == ConnectionResult.SERVICE_VERSION_UPDATE_REQUIRED) {
// 需要升級
HuaweiApiAvailability.getInstance().resolveError(activity, ConnectionResult.SERVICE_VERSION_UPDATE_REQUIRED, 1);
}
方案2: 引導用戶去華為設置裡去升級
https://consumer.huawei.com/cn/support/content/zh-cn04461342/
2.3 三方token正常上報
生成token後會通過RPC接口上報到MPS服務端，需要檢查RPC接口是否有異常，上報接口是：alipay.client.yunpushcore.device.report
2.4 token過期
以oppo為例，是在應用第一次啟動時註冊生效，後在刷機、還原手機(設置-其他設置-還原手機)、卸載應用時會失效，需要重新註冊才能推送。
3. 服務端投送階段
3.1 消息包含了紅點，靜默，群發
目前如果消息設置了紅點或者靜默，因為廠商push不支持，MPS會自動走自建push。
3.2 三方服務端報錯
這種主要用作mPaas服務端推送到三方服務端後，三方返回異常。這種需要去MPS拉取服務端報錯日誌，然後核對廠商文檔解決，比如華為服務端報錯文檔鏈接如下：鏈接。
3.3 三方服務端限流
以vivo為例，默認推送走的是運營消息，每天只能對同一個用戶推送5次。只有改成系統push類型才能沒有這個限制，參考：鏈接
4. 設備顯示階段
4.1 設備必須打開通知權限才能顯示
比如oppo的通知權限默認是關閉的，需要打開通知權限，或者引導用戶打開後才能顯示。
4.2 應用包名和註冊oppo配置保持一致
應用的包名要和註冊oppo平臺填寫的包名要一致，不然不會顯示
四 其他常見問題
1. 常用日誌舉例
1.1 tag：mPush14
主要是mPaas上層應用層日誌打印，打印push註冊token相以及自建通道push相關信息
1.2 tag: mcssdk
mcssdk 是oppo push sdk的日誌tag, 可以查看廠商的一些日誌信息，比如查看三方token
2. 其他思路
如果以上都解決不了，最後建議去看各個廠商的官方介紹，可能會找到一些思路，
3. 推送Android設備但是推到了iOS設備
現象：發現部分手機上本來需要推送到Android設備的消息，推送到了iOS設備。
分析：服務端是通過最後一次綁定來判斷最後推送的設備，說明用戶在Android設備上一直沒有觸發綁定，導致服務端存儲的是iOS的登錄記錄。
原因：用戶Android手機登錄使用的是指紋登錄，客戶在指紋登錄的場景下沒有觸發綁定，導致服務端一直存儲的是iOS的綁定記錄