前言

國內的Android推送就是個悲劇

國內Android缺少Google的生態，如Google的Paly Store，Google Mobile Services（GMS）等，導致衍生出很多畸形的產業，比如五花八門的APP市場，光怪陸離的推送平臺，這里要說的是推送平臺。Google本身的GMS服務是包含一套推送在里面的，跟iOS系統的推送類似，它保證每臺手機維護一個推送通道就能收到各方推送，但由于Google沒法進入中國市場，國產Android基本上算被閹割了一個核心部件，由此衍生的種種弊端數不勝數，首當其沖的就是推送。

國內的手機廠商基本都有自家的推送服務，來替代GMS的缺失，性能、用法參差不齊。在離線場景下（APP死亡），如果想要收到推送，就必須接入對應廠家的推送服務，否則壓根收不到。所以Android APP在誕生之初基本就要集成華為push、小米push、魅族push、oppo push、Vivo push等，相對GMS，復雜且沒有增益，就好比用江南七怪代替了黃老邪，難用的一B。然而，你別無選擇。不過國內各種廠商倒是樂此不疲，他們多了一個觸達用戶及統計的渠道，并且還能不受Google挾制，對于開發者而言，就要麻煩很多，工作量平白翻了很多倍；有的聊天APP為了走自家的推送SDK，還要琢磨各種黑科技：包活，APP相互喚起等，惡之花開的漫山遍野。更有意思的是，為了解決這種問題，制定規范，還促生個各種機構，像推送聯盟，綠色聯盟等，但并沒什么卵用，成立3年，亂象依舊，很多說Android很垃圾，那推送的這個問題要負一大半責任。

吐槽完，你仍然要接。

推送概念

為什么一定要接廠商的推送SDK呢？不接入收不到推送嗎？想要弄清這個東西，就要對推送有個簡單的了解，推送：它的點在推（push上，與其對應的是拉（Pull），核心就是客戶端跟服務器建立一個長鏈接，服務器會將信息分發到各個客戶端，簡化示意如下：

對于手機端APP來說，推送分APP在線推送還是離線推送，其實就是APP是否存活，APP存活情況下，有多種選擇，如果APP通過Socket跟自家服務器建立了鏈接，則可以由自家服務器直接推送到APP端，也可以通過后端推送到第三方推送服務，借由第三方推送給APP端，也就是在線情況下，可以不用接入第三方SDK。但是在APP死亡的情況，只有一種方式：借由第三方推送服務，推送給手機端，這種場景，APP必須接入第三方廠商SDK，拿華為平臺為例，其推送模型如下：

與兩者對應也有兩種消息的概念：透傳消息與通知欄消息：

• 透傳消息：APP存活情況下，由推送服務直接把消息發送給APP應用，由APP自己選擇如何處理，注意透傳的前提是APP存活 ，透傳消息可以不用接入第三方SDK。

• 通知欄消息：在設備接收到消息之后，由系統彈出標準安卓通知，用戶點擊通知欄才激活應用，這種場景，APP無需存活（活著也不受影響），離線場景下，只有通知欄消息這一條路。

透傳消息每個APP自己維護一條通道，離線消息只要一條系統通道，簡單看下兩者對比，示意如下：

對于在線透傳消息，由于是在APP存活的情況下收到的，APP端可以統計到所有必要信息，無論是推送達時間、推送內容還是通知的點擊都能統計到；但是離線推送就沒那么幸運，很多信息APP自己是拿不到的，但是，業務方通常非常關心到達率、點擊率這些數據，必須有一個有效的解決方案。

推送統計問題 （離線推送）

如何到達率

這里不考慮在線推送，只考慮離線（APP死亡），那么離線推送APP能統計到達嗎？

答案是 不能，原因其實很簡單，APP進程都死了，怎么統計。這種情況下，通知的展示屬于系統行為，APP壓根無法感知，更無從統計。不過，各三方推送服務平臺扔提供了推送到達統計的能力，即采用三方推送平臺的回執，以上面的華為推送模型為例：

可以看到，離線推送的情況下，華為設備在展示完通知欄消息后，會給華為Push服務一個回執，而華為Push服務會把這個回執頭傳給開發者服務器，如此，APP服務端就能判斷推送是否到達。

如何統計點擊率

同樣，在離線推送的場景下，能統計到點擊事件嗎？關于這個場景，不同的廠商ROM及SDK真是亂七八糟，有的支持，有的不行，簡單整理下如下：

ROM小米華為魅族oppovivo

App是否可以統計到離線點擊事件	是	否	是	否	是

因此，各方平臺給的方式并沒太多參考意義，必須通過其他方式來統計點擊，離線推送基本都是通過scheme方式來處理，可以通過加參數來搞定，后續詳述。

推送送達率=本次推送真正送達的設備數/所覆蓋的所有設備數（按理說，是應該清理掉無效設備）

哪些因素影響送達率

• 留存率。已經卸載了APP，肯定收不到，但是有些三方平臺可能會歸結到分母中，需要自家后臺根據回執手動清理regID。
• 消息有效期，基本所有第三方PUSH平臺都支持設置有效期，有效期越短，觸達設備就越少，送達率會下降，可以適當選擇有效時間。
• 聯網情況， 在有效期內，設備沒聯網，也無法送達，但會被計入分母
• 目標人群設備的選取，活躍人群設備送達率肯定要高于全量推送

因此為了能精準的計算送達率，APP服務端要定期清理無效regID（推送token），否則統計的送達率也會偏低

各離線推送平臺接入事項

很多大公司都有自家的推送SDK來處理透傳消息，小公司一般不具備這個能力，所以在接入Push的時候也分兩種情況，

• 1：有自己加的PushSDK，
• 2：沒有自家PushSDK

如果APP有自己的PushSDK，那只要接入第三方離線推送能力就好了，一些關于透傳的處理配置可以完全不用關心，用自己PushSDK那套就可以。如果沒有自家PushSDK，那就需要選擇一個SDK進行透傳處理，當然，仍要接入第三方離線推送能力。不過即使如此，各家ROM的接入規則也個不相同，比如小米有個奇葩的權限叫：“后臺彈出界面權限 ”，如果后端服務Push姿勢不對，可能會引入奇葩問題：比如，手機能收到PUSH，但是拉不起界面，坑爹。

簡單看下各ROM計入注意事項，只看離線能力，不考慮透傳：

小米

關于MIPUSH的接入，直接看官方文檔即可，沒太多問題，需要注意的是，小米有個奇葩的權限設置：后臺彈出界面權限 ，該權限默認是關閉，這個選項可能會影響推送通知的點擊行為，小米有兩大類點擊行為：

完全自定義點擊行為

在這種行為下，開發者可以攔截通知點擊事件，自定義如何處理后續事件，點擊后，MiPushMessage通過PushMessageReceiver繼承類的onNotificationMessageClicked方法傳到APP進程，開發者可自行處理，如果想要啟動界面，只需要在其中調用context.startActivity方法即可，但是，這種自定義的行為會受到后臺彈出界面權限的影響，尤其是高版本的MIUI ROM中。

你會發現，在這些手機上，此方式壓根沒法拉起APP，除非通過先啟動一個Service，然后在Service中拉起，非常像小米的一個BUG，并且，即使通過此下策能拉起，你會發現，拉起速度非常慢，可能是過多AMS交互通信導致的，所以這種策略可以斃了。

預定義點擊行為

預定義點擊行為不用用戶在onNotificationMessageClicked中處理，系統會直接拉起目標頁面，小米支持三種預定義點擊行為：

• (1) 打開當前的Launcher Activity
• (2) 打開當前app內的任意一個Activity
• (3) 打開網頁。

APP一般會采用第二種行為，打開APP任意一個Activity，其實最終會選擇一個DeepLink Activity，由其路由到其他界面。服務端調用Message.Builder類的extra(String key, String value)方法，將key設置為Constants.EXTRA_PARAM_NOTIFY_EFFECT，value設置為Constants.NOTIFY_ACTIVITY便可以達到該效果，用戶點擊了客戶端彈出的通知消息后，封裝消息的MiPushMessage對象通過Intent傳到客戶端，客戶端可在Activity中解析，并自行處理后續流程。離線推送情況下，推送服務端核心字段如下：

采用離線非透傳消息，并利用extra自定義Click行為，最后推送給小米的消息格式簡化如下：

{title=通知標題, description=通知內容, restrictedPackageNames=[com.test.example], notifyType=1, notifyId=1249808047, <!--打開任意Activity配置-->extra.intent_uri=yanxuan://re?opOrderId=crm_a1d05c1d3d1743e192a08b461a376785_20200715,extra.notify_effect=2 }

extra.intent_uri的值就是APP端定義的私有scheme，點擊通知會直接拉起相應的DeepLink Activity，從而喚起應用，至于DeepLink Activity最終路由到哪個界面，可以從extra.intent_uri中解析出來。對于上文層說過的click事件不易統計的問題，可以通過在scheme家參數的方式解決，如下：

extra.intent_uri= yanxuan://re?opOrderId=0200715,

轉為

extra.intent_uri= yanxuan://re?opOrderId=0200715&platform=xiaomi

之后在路由Activity中可以解析出platform參數，從而標記click事件及來源平臺。預定義行為系統會幫我們處理好喚起，在APP中，不需要在onNotificationMessageClicked再次響應click事件了，避免重復處理。后面其余各方SDK的能力基本都跟小米類似，大同小異，沒多少花樣。

華為

流程同小米類似，按文檔即可，預定義行為有如下四種:

• 1：用戶定義Uri，打開目標界面
• 2：點擊后打開特定網頁
• 3：點擊后打開應用
• 4：點擊后打開富媒體信息

一般選擇自定義Uri行為，所有數據通過intent uri傳輸給APP，依舊是私有scheme的DeepLink實現方式。對應參數意義如下：

基本上，選擇type=1 同 intent uri配合，uri生成格式如下：

Intent intent = new Intent(Intent.ACTION_VIEW); intent.setData(Uri.parse("pushscheme://com.huawei.codelabpush/deeplink?name=abc&age=180")); String intentUri = intent.toUri(Intent.URI_INTENT_SCHEME);

最終通過API發送給華為push平臺數據格式簡化如下：

"msg":{"action":{"param":{"intent":"intent://member?url=http%3A%2F%2Fm.you.163.com%2Fmembership%2Findex&_yanxuan_hwpush=1&_mid=a397314518947995648#Intent;scheme=yanxuan;launchFlags=0x4000000;end"},"type":1},"body":{"title":"huawei免郵券禮包","content":"快來領取你的每月專屬免運費券，立即領取>>"} }

同小米類似，如果需要添加額外參數，放到scheme中，不再敖述。

魅族

接入類似，支持四種預定義行為：

• 打開應用主頁
• 打開應用內頁面
• 打開URI頁面
• 客戶端自定義

同樣選擇預定義Uri頁面，具體參數如下

最終發送數據格式簡化如下：

{noticeBarType = 0,title = 'meizu明天之后?恢復原價', content = '店慶爆款返場！乳膠床墊直降500，拉桿箱僅7折！😱每滿150減25消費券全品類通用，最后1天>>',clickType = 2, url = 'yanxuan://yxwebview?url=https%3A%2F%2Fact.you.163.com%2Fact%2Fpub%2FDisjY2u1n9p4SB3.html%3Fanchor%3DSeen3xcj%26opOrderId%3Dcrm_task_20200414160053263_1'}

clickType = 2 配合Uri scheme來實現，預定義拉起對應界面，如果需要添加額外參數，同上。

oppo

接入類似，oppo無法感知click事件，支持五種預定義行為（有冗余）：

• 0，啟動應用；
• 1，打開應用內頁（activity的intent action）
• 2，打開網頁；
• 4，打開應用內頁（利用activity全名）
• 5, Intent scheme URL

處理類似，選click_action_type選擇5，通過私有scheme拉起APP，具體數據格式如下

{"notification":{"app_message_id":"a467798011733344256","channel_id":"NotificationChannel","click_action_url":"yanxuan://yxwebview?url=https%3A%2F%2Fact.you.163.com%2Fact%2Fpub%2FDisjY2u1n9p4SB3.html%3Fanchor%3DSeen3xcj%26opOrderId%3Dcrm_task_20200414160053263_1","click_action_type":5,"content":"明天之后恢復原價","title":"明天之后恢復原價"},"target_type":2,"target_value":"CN_04f112241e183f6309611df2a95d6237" }

click_action_type= 5 配合 scheme拉起APP，，如果需要添加額外參數，同上。

vivo

vivo跟oppo很類似，不過它也可以收到click事件（并沒什么卵用），因此支持完全自定義（然而不用），支持五種Click行為

• 1：打開APP首頁
• 2：打開鏈接
• 3：自定義
• 4：打開app內指定頁面

同樣，為了防止禁止后臺啟動，不采用自定義的方式，而直接打開打開app內指定頁面， “skipType”:4,

{"classification":1,"content":"adssdsr345436","notifyType":1,"pushMode":1,"regId":"15905547110541891320627","requestId":"a467798011733344256","skipContent":"yanxuan://yxwebview?url=https%3A%2F%2Fact.you.163.com%2Fact%2Fpub%2FDisjY2u1n9p4SB3.html%3Fanchor%3DSeen3xcj%26opOrderId%3Dcrm_task_20200414160053263_1","skipType":4,"title":"adssdsr345436" }

skipType:4配合 scheme拉起APP，，如果需要添加額外參數，同上。

各ROM接入事項小結

以上是幾種離線推送的接入方式，整體總結就是：

• 盡量選擇預定義Uri scheme方式，不要采用自定義的方式
• 可以在scheme中填加參數，統一鑒別click事件
• 在預定義的方式下，不要在click回調中重復處理事件
• 如果只要離線推送功能，沒必要處理透傳配置（比如什么Receiver Service之類的配置）

總結

• 不得不接入第三方SDK是為了離線推送
• 各家離線推送大同小異，為了統一建議統一采用預定義Uri方式，配合私有scheme拉起APP
• 額外追蹤參數可以通過添加scheme字段解決
• 不同ROM可能有自己的額外限制，比如小米，盡量避免受其限制

最后，Android的推送困境依舊是個悲劇…

作者：看書的小蝸牛
原文鏈接:Android推送的群魔亂舞

總結

以上是生活随笔為你收集整理的Android推送的群魔乱舞的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。