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. 其他思路

如果以上都解決不了，最後建議去看各個廠商的官方介紹，可能會找到一些思路，

oppo的faq:
vivo的faq:

3. 推送Android裝置但是推到了iOS裝置

現象：發現部分手機上本來需要推送到Android裝置的消息，推送到了iOS裝置。

分析：服務端是通過最後一次綁定來判斷最後推送的裝置，說明使用者在Android裝置上一直沒有觸發綁定，導緻服務端存儲的是iOS的登入記錄。

原因：使用者Android手機登入使用的是指紋登入，客戶在指紋登入的場景下沒有觸發綁定，導緻服務端一直存儲的是iOS的綁定記錄