Android端外推送到底有多烦？(转载自一个1000万用户App的CTO的对推送的看法)
轉(zhuǎn)載自:https://zhuanlan.zhihu.com/p/22461795
說(shuō)Android端外推送比較煩，實(shí)際有兩層意思：首先是說(shuō)實(shí)現(xiàn)上比較麻煩，至今業(yè)界也沒(méi)有找到一種完美的解決方案，Android程序員通常需要同時(shí)集成多家推送平臺(tái)（如果有自己的端內(nèi)推送，還要考慮與端內(nèi)推送的配合）；其次是說(shuō)Android推送的市場(chǎng)現(xiàn)狀比較混亂，無(wú)論選擇哪一家，都讓人糾結(jié)萬(wàn)分，難免心情煩躁。無(wú)論是你花費(fèi)了多少功夫，做了多少優(yōu)化，仍然可能存在推送不到或推送延遲的情況。
網(wǎng)上已經(jīng)有很多關(guān)于Android推送的討論，但很少有站在App開發(fā)者（特別是開發(fā)App的創(chuàng)業(yè)團(tuán)隊(duì)）的角度來(lái)進(jìn)行介紹的文章。本文的目的，就是站在一個(gè)App開發(fā)團(tuán)隊(duì)的角度，集中討論兩方面的問(wèn)題：
- 如何對(duì)各家的推送平臺(tái)進(jìn)行技術(shù)選型；
- 在集成各家推送平臺(tái)的SDK的時(shí)候，應(yīng)該重點(diǎn)關(guān)注哪些問(wèn)題。
為什么本文只討論端外推送？
通常大廠的App都會(huì)區(qū)分端內(nèi)推送和端外推送（端指的是客戶端），具體說(shuō)來(lái)：
- 當(dāng)App在前臺(tái)運(yùn)行的時(shí)候，這時(shí)的推送稱為端內(nèi)推送。端內(nèi)推送一般是走App自己實(shí)現(xiàn)的一套推送系統(tǒng)：推送服務(wù)器是自己的，客戶端維護(hù)一條長(zhǎng)連接連到自己的推送服務(wù)器，不依賴任何第三方的推送系統(tǒng)。
- 當(dāng)App從前臺(tái)退到后臺(tái)，在短時(shí)間內(nèi)App未被殺死前，App自己的長(zhǎng)連接仍然有效。這時(shí)的推送可以仍然走App自己的推送系統(tǒng)。所謂的“Android進(jìn)程保活”，就是為了盡量延長(zhǎng)這段在后臺(tái)存活的時(shí)間。
- 當(dāng)App在后臺(tái)運(yùn)行足夠長(zhǎng)的時(shí)間后，App進(jìn)程由于被清理或者其它原因，App自己的長(zhǎng)連接斷開。這時(shí)的推送就稱為端外推送了，只能走某個(gè)第三方推送平臺(tái)了。
從這個(gè)過(guò)程來(lái)看，大廠的App的推送策略可以概括為：優(yōu)先使用自己的推送，實(shí)在不行再走第三方推送平臺(tái)。為什么這樣呢？因?yàn)樽约旱耐扑拖到y(tǒng)更快、更有保障：
- 更快，是因?yàn)槟憬唤o第三方推送平臺(tái)的推送消息要跟很多其它家App的消息一起排隊(duì)。如果某家App突然在短時(shí)間內(nèi)發(fā)送大量推送消息給推送平臺(tái)（推廣活動(dòng)，或者程序bug），那么這個(gè)推送平臺(tái)上的其它App就有可能受到牽連，推送延遲變得很大。這樣的情況是很可能會(huì)發(fā)生的。比如，在某個(gè)推送平臺(tái)的技術(shù)交流群里，不定期地就會(huì)看到有人在喊：“是不是推送又堵了啊......”
- 更有保障。大廠通常有專門的隊(duì)伍維護(hù)推送相關(guān)的服務(wù)，有問(wèn)題可以快速推進(jìn)優(yōu)化。
我們雖然算不上大廠，但我們維護(hù)的微愛(ài)App也是有自己獨(dú)立的端內(nèi)推送的，而端外采用另外幾家推送平臺(tái)，后面我們?cè)僭敿?xì)講。
那為什么本文只討論端外推送呢？因?yàn)橛懻摱藘?nèi)推送和討論端外推送是完全不同的兩個(gè)話題。討論端外推送，我們主要是在討論怎么對(duì)各家的推送平臺(tái)進(jìn)行選擇，以及集成各家SDK的時(shí)候我們應(yīng)該重點(diǎn)注意哪些問(wèn)題。這通常是很多初創(chuàng)團(tuán)隊(duì)更需要的。
而討論端內(nèi)推送，主要應(yīng)該討論一個(gè)推送系統(tǒng)的具體實(shí)現(xiàn)，這是一個(gè)比較復(fù)雜的問(wèn)題，并不是一篇文章就能討論清楚的。在這里，我們只是浮光掠影地瀏覽一下這個(gè)話題可能涉及到的內(nèi)容，但不做展開討論：
- 采用什么協(xié)議？XMPP還是MQTT還是自定義二進(jìn)制協(xié)議？是否像微信一樣，需要推送二進(jìn)制數(shù)據(jù)（比如短語(yǔ)音和縮略圖數(shù)據(jù)）？
- 如何保證后臺(tái)長(zhǎng)連接不死？涉及到“保活”的問(wèn)題。
- 如何做才能真正保證不丟數(shù)據(jù)？涉及到系統(tǒng)的方方面面，比如消息的確認(rèn)，客戶端和服務(wù)器的數(shù)據(jù)同步，客戶端的數(shù)據(jù)存儲(chǔ)的事務(wù)保證，后臺(tái)消息隊(duì)列如何設(shè)計(jì)保證不丟數(shù)據(jù)。如果是IM，離線數(shù)據(jù)如何處理？
- 長(zhǎng)連接的Keep Alive和連接狀態(tài)的檢測(cè)與維護(hù)。比如XMPP相當(dāng)于一個(gè)永遠(yuǎn)解析不完的XML流，使用一個(gè)空格作為Keep Alive消息。
- 長(zhǎng)連接的安全性。驗(yàn)證以及加密。
綜上，本文要討論的重點(diǎn)是端外推送。
有哪些推送平臺(tái)可以選擇？
端外推送我們必須依賴第三方的推送平臺(tái)了。
這個(gè)情況其實(shí)本來(lái)跟iOS上類似。在端內(nèi)推送系統(tǒng)的長(zhǎng)連接失效的時(shí)候，我們就只能通過(guò)其它的推送平臺(tái)來(lái)完成。在iOS上我們只用使用APNs就行了。
而在Android上，跟APNS對(duì)應(yīng)的服務(wù)是谷歌的GCM (Google Cloud Messaging)，但很可惜它在國(guó)內(nèi)的可用性不高（主要原因是手機(jī)廠商對(duì)Android系統(tǒng)的定制化，可能會(huì)將GCM服務(wù)裁減掉，以及國(guó)內(nèi)運(yùn)營(yíng)商的一些限制）。如果我們做的是一個(gè)海外的應(yīng)用，那么端外推送基本只用考慮GCM就可以了。
那國(guó)內(nèi)的Android推送平臺(tái)有哪些可以選擇呢？
根據(jù)我個(gè)人了解到的信息，我列出了下面這些（排名不分先后）：
- 小米推送（MiPush）
- 華為推送（華為Push）
- 友盟推送（U-Push）
- 個(gè)推
- 極光推送
- 阿里云移動(dòng)推送（Alibaba Cloud Channel Service）
- 騰訊信鴿推送
- 百度云推送
我們選的是哪家推送？選擇標(biāo)準(zhǔn)是什么？
上面提到的各推送平臺(tái)大體可以分為三大類：
- 大手機(jī)廠商的推送：小米推送、華為推送。
- 專業(yè)的第三方推送：友盟推送、個(gè)推、極光推送
- BAT大廠的平臺(tái)推送：阿里云移動(dòng)推送、騰訊信鴿推送、百度云推送。
要對(duì)這些推送平臺(tái)進(jìn)行選擇，我們首先要知道各類推送平臺(tái)的優(yōu)勢(shì)分別是什么。
首先，對(duì)于手機(jī)廠商的推送，他們的推送服務(wù)在他們自己生產(chǎn)的手機(jī)上屬于系統(tǒng)級(jí)別的服務(wù)，理論上來(lái)說(shuō)，手機(jī)系統(tǒng)對(duì)他們自家的推送限制最小。
比如，在小米手機(jī)上，不在系統(tǒng)自啟動(dòng)名單里的App，在手機(jī)重啟后，App聲明的后臺(tái)Service并不會(huì)自動(dòng)運(yùn)行。但是，小米推送作為手機(jī)系統(tǒng)級(jí)服務(wù)，仍然是可以收到推送的。
同樣，華為推送的技術(shù)團(tuán)隊(duì)也對(duì)外宣稱（原話）：
華為Push，在華為手機(jī)上是系統(tǒng)級(jí)別的服務(wù)，穩(wěn)定性等各方面肯定都會(huì)好些。
但是，即使是系統(tǒng)級(jí)別的推送服務(wù)，也不是百分百保證消息送達(dá)。這里比較奇葩的是華為推送，下面是他們技術(shù)支持給出的描述（原話）：
華為手機(jī)上：Emui3.0上，Push廣播有很大概率被限制，如： Mate7 3.0版本，榮耀6plus，P7 3.0版本，4X， 4A等。Emui3.1上，Push廣播基本不被限制，但個(gè)別型號(hào)機(jī)型存在問(wèn)題，如：榮耀5x等。Emui4.0及以上，Push廣播有較高概率被限制，不被限制的機(jī)型如：榮耀暢玩4C，榮耀暢玩4X，Mate S，P8 MAX等。如廣播被限制，需要將應(yīng)用設(shè)為開機(jī)啟動(dòng)項(xiàng)。所以對(duì)于及時(shí)性或到達(dá)率要求非常高的應(yīng)用，我們建議應(yīng)用要考慮替代方案。后續(xù)Push版本，華為將采用新的設(shè)計(jì)方案，解決被限制的問(wèn)題，但發(fā)布計(jì)劃待定。
另外，至于限制的問(wèn)題，其實(shí)華為sdk還是能接收到推送消息的，當(dāng)將消息通過(guò)廣播發(fā)送給應(yīng)用是，如果手機(jī)管家查到該應(yīng)用處于stop狀態(tài)，那么會(huì)攔截該廣播的。
看完之后的感覺(jué)：還真他媽復(fù)雜！
總之，華為手機(jī)上的推送，華為推送自己也不太完全能搞得定的。但是，我們考慮再三，似乎也沒(méi)有更好的選擇了。
再說(shuō)第二類：專業(yè)的第三方推送。他們的優(yōu)勢(shì)看什么呢？看他們“保活”和“互拉”的能力。舉個(gè)例子，假設(shè)你接入了友盟，而恰好今日頭條也接入了友盟。有一天你的App被殺死了，但是今日頭條的裝機(jī)量估計(jì)比你的要大啊，這時(shí)用戶啟動(dòng)了今日頭條，那么推送系統(tǒng)也就會(huì)通過(guò)共享的推送通道順便把你推送消息送達(dá)到手機(jī)上，然后還可能把你的進(jìn)程也喚醒（被“保活”了）。
這么說(shuō)來(lái)，選第三方推送平臺(tái)，這個(gè)推送平臺(tái)的規(guī)模效應(yīng)就很重要了。那如何得知他們的規(guī)模和市場(chǎng)份額呢？最好的辦法是問(wèn)內(nèi)部的朋友。否則，其實(shí)也沒(méi)什么好的辦法，每家肯定對(duì)外都說(shuō)自己最好啊。有一個(gè)不太精準(zhǔn)的方法，就是看他們的合作客戶里有哪些大的app，到他們官網(wǎng)上的合作案例里去看。這個(gè)信息總不能亂寫把。
而對(duì)于BAT大廠的推送呢？看起來(lái)并沒(méi)有什么優(yōu)勢(shì)。各家的“全家桶”采用的“保活”陣營(yíng)和推送通道，跟他們開放出來(lái)的是兩碼事。比如，你不要以為用了騰訊信鴿推送，就能占上微信的光。
這里需要單獨(dú)提一下的是阿里云的移動(dòng)推送。在他們官網(wǎng)上提到，手機(jī)淘寶就是用了阿里云的這個(gè)推送。不過(guò)仔細(xì)研究一下會(huì)發(fā)現(xiàn)，手機(jī)淘寶也在同時(shí)使用其它的第三方推送平臺(tái)啊（比如友盟推送）。兩個(gè)平臺(tái)到底誰(shuí)借誰(shuí)的力更多呢？不得而知啊。
綜合上面的分析，我們?cè)谖?ài)的Android客戶端里使用的推送方案基本如下所述：
- 端內(nèi)使用微愛(ài)自己的推送；
- 端外在小米手機(jī)上使用小米推送；
- 端外在華為手機(jī)上使用華為推送；
- 端外在其它手機(jī)上統(tǒng)一使用一種推送，也就是上面推送平臺(tái)列表中的某一個(gè)。具體是哪個(gè)就不說(shuō)了，本文中我們稱它為X-Push吧。
注意：小米推送在非小米手機(jī)上當(dāng)然也能工作，只不過(guò)就不是系統(tǒng)級(jí)別的服務(wù)了，受的限制就多一點(diǎn)。同理，華為手機(jī)也一樣。我們之所以這樣選擇，是為了讓不同的推送運(yùn)行在各自擅長(zhǎng)的環(huán)境里。
基本的架構(gòu)圖如下：
本來(lái)呢，對(duì)于推送平臺(tái)的選擇問(wèn)題，到這里就應(yīng)該結(jié)束了。但是，最近發(fā)生了一件事，讓我們覺(jué)得被X-Push這家坑了一把，這讓我們突然意識(shí)到了一個(gè)選擇陷阱。現(xiàn)在把它分享出來(lái)，好讓大家選擇的時(shí)候一定要擦亮眼睛。
事情大致經(jīng)過(guò)是這樣的：我們開始集成X-Push這家推送的時(shí)候，使用的是免費(fèi)版服務(wù)。但是，我們用了一段時(shí)間之后，他們的銷售找了過(guò)來(lái)。宣稱他們SDK里的“看護(hù)功能”，是付費(fèi)功能，如果不付費(fèi)，技術(shù)那邊就會(huì)通過(guò)一些操作關(guān)閉這一功能。這里他們提到的“看護(hù)功能”，大概就是本文前面提到的“保活”和“互拉”的能力。
這個(gè)事情的關(guān)鍵點(diǎn)在于什么呢？
如果把這件事的全部細(xì)節(jié)寫出來(lái)，恐怕還需要額外的5000字。由于本文的主要目的還是分享技術(shù)選型的經(jīng)驗(yàn)，所以這里點(diǎn)到為止，能把事情的大致經(jīng)過(guò)說(shuō)清楚就好了。等這件事塵埃落定以后，我們也許還有機(jī)會(huì)再重新拿出來(lái)講一講這個(gè)故事。
但是，這里你要記住的是，在你選擇一家推送平臺(tái)之前，一定要找人問(wèn)清楚對(duì)方收費(fèi)的模式，有沒(méi)有隱性的消費(fèi)陷阱。記住：沒(méi)有人主動(dòng)會(huì)告訴你喲。
大家也別問(wèn)這家X-Push到底是哪家了，大家自己去體會(huì)。這里能起到提醒的作用就夠了。
你是否需要自己的端內(nèi)推送？
對(duì)于小的創(chuàng)業(yè)團(tuán)隊(duì)來(lái)說(shuō)，自己實(shí)現(xiàn)端內(nèi)的長(zhǎng)連接推送系統(tǒng)，成本還是不小的。
其實(shí)呢，各個(gè)第三方推送平臺(tái)也是可以在端內(nèi)使用的。而且，他們一般也對(duì)iOS的APNs推送也有封裝。所以，在資源緊缺的情況下，小團(tuán)隊(duì)在初期也可以選擇某家第三方推送平臺(tái)做自己全部的推送服務(wù)，能快速地同時(shí)支持Android和iOS兩個(gè)平臺(tái)推送。等后邊人手充裕了，再考慮進(jìn)行優(yōu)化，或加入新的推送渠道。
具體怎樣選擇，還在于你自己權(quán)衡。
使用通知欄消息還是透?jìng)飨?#xff1f;
通常第三方推送平臺(tái)都支持兩種推送消息類型：通知欄消息和透?jìng)飨ⅰ?/p>
通知欄消息，在被送達(dá)用戶的設(shè)備后，直接以系統(tǒng)通知的形式展示給用戶。它不會(huì)繼續(xù)被傳遞到App。
而透?jìng)飨?#xff0c;在被送達(dá)用戶的設(shè)備后，還會(huì)繼續(xù)路由到App，通過(guò)回調(diào)App的某個(gè)BroadcastReceiver的形式將消息傳遞到App內(nèi)部。然后由App決定如何處理和顯示這個(gè)消息。
這兩類消息在送達(dá)率的保證上有所不同，當(dāng)然在提供的編程能力上也非常不同。
透?jìng)飨⒃谡麄€(gè)消息傳遞過(guò)程中比通知欄消息多了一步，因此就增加一些被系統(tǒng)限制的概率。所以說(shuō)，通知欄消息比透?jìng)飨?yīng)該能提供更好的送達(dá)率。
比如，小米推送的文檔中就這樣描述：
在一些 Android 系統(tǒng)(如 MIUI)中,受到系統(tǒng)自啟動(dòng)管理設(shè)置的限制,應(yīng)用不能在后臺(tái)自啟動(dòng)。在這類系統(tǒng)中,如果在發(fā)送消息的時(shí)候?qū)?yīng)的應(yīng)用沒(méi)有被啟動(dòng),透?jìng)黝愊⒉荒茼樌瓦_(dá)。因此,對(duì)于對(duì)送達(dá)率要求很高的消息,建議盡量采用通知欄提醒的方式推送消息
如果App有自己的端內(nèi)推送系統(tǒng)，那么這種通知欄推送消息就更合適一些。當(dāng)端內(nèi)推送的長(zhǎng)連接失效時(shí)，我們通過(guò)通知欄消息把提醒展示給用戶，由用戶喚起我們的App，然后真正的消息數(shù)據(jù)再經(jīng)由端內(nèi)推送達(dá)到客戶端。
實(shí)際上，我們就是采用通知欄消息這種推送方式的。
而透?jìng)飨?#xff0c;提供了對(duì)消息數(shù)據(jù)的更靈活的操縱能力。App如果僅僅通過(guò)通知欄消息，是無(wú)法接觸到消息數(shù)據(jù)本身的。
所以，如果App沒(méi)有自己的端內(nèi)推送系統(tǒng)，而是采用第三方推送作為端內(nèi)推送通道，那么就只能使用透?jìng)飨ⅰ?/p>
另外一個(gè)例子，如果App想自定義通知提醒的樣式，以及提示聲音，恐怕也只能通過(guò)透?jìng)飨?lái)自己實(shí)現(xiàn)。通知欄消息通常提供不了那么靈活的配置。
這里有一點(diǎn)需要說(shuō)明的是，當(dāng)透?jìng)飨⑺瓦_(dá)設(shè)備后，如果在試圖路由到App內(nèi)部的時(shí)候，發(fā)現(xiàn)App進(jìn)程不在，那么理想情況下它應(yīng)該“拉起”App進(jìn)程。所以，照此推測(cè)，如果前面提到的那家X-Push關(guān)閉了“看護(hù)功能”的話，那么透?jìng)飨?huì)受到多大的影響呢？結(jié)果可想而知。另外，X-Push那家的銷售說(shuō)了，關(guān)閉“看護(hù)功能”，對(duì)通知欄消息的“消息觸達(dá)效果”也是有影響的。無(wú)語(yǔ)......
推送的初始化和推送token的同步
我們使用第三方推送平臺(tái)，最關(guān)鍵的地方在于前兩個(gè)步驟：
- 在恰當(dāng)?shù)臅r(shí)機(jī)把推送SDK初始化起來(lái)。
- 初始化之后App會(huì)異步地收到一個(gè)推送token，那么接下來(lái)需要把這個(gè)推送token同步到App服務(wù)器。
這里的推送token，在不同的推送平臺(tái)上的叫法不太一樣，比如在小米推送中被稱為reg id，在華為推送中被稱為token，在個(gè)推中被稱為cid，在友盟推送被稱為Device Token。總之，它是推送平臺(tái)對(duì)設(shè)備的唯一標(biāo)識(shí)。我們這里統(tǒng)稱它為“推送token”是為了方便討論。
App的客戶端拿到它之后，必須要同步到自己的服務(wù)器，并與自己的用戶ID建立起對(duì)應(yīng)關(guān)系。這樣當(dāng)我們想推送消息給我們的某個(gè)用戶的時(shí)候，我們才能查到對(duì)應(yīng)的推送token。
前面說(shuō)的初始化和推送token同步這兩個(gè)步驟，看起來(lái)很簡(jiǎn)單，只是調(diào)用SDK的現(xiàn)成接口，再把它發(fā)送給服務(wù)器而已。但是，好的代碼不僅能在正常情況下工作，還應(yīng)該充分考慮失敗情況。有什么樣的失敗情況需要我們考慮呢？我們以小米推送為例來(lái)分析一下：
- 小米推送要求在Application對(duì)象的onCreate中執(zhí)行初始化操作。我們可以猜測(cè)一下，在這個(gè)初始化操作中小米推送的SDK可能需要在本地為我們修改配置，還可能需要聯(lián)系小米推送的服務(wù)器來(lái)申請(qǐng)reg id（即推送token）。這個(gè)初始化過(guò)程是可能失敗的，本地操作可能會(huì)受到系統(tǒng)的限制，網(wǎng)絡(luò)更是可能出錯(cuò)。試想，如果初始化出錯(cuò)了，我們還會(huì)收到推送token嗎？
- 假設(shè)我們成功收到了推送token（通常在一個(gè)BroadcastReceiver中），接下來(lái)把推送token發(fā)送到我們自己的服務(wù)器，這個(gè)工作需要我們自己來(lái)完成了。我們都知道在移動(dòng)環(huán)境下網(wǎng)絡(luò)很可能是弱網(wǎng)環(huán)境，這次同步如果失敗了，那么下次要等到什么機(jī)會(huì)才能再次進(jìn)行同步呢？
上述第一種初始化錯(cuò)誤，理應(yīng)由推送SDK來(lái)處理。如果失敗，它應(yīng)該會(huì)有重試機(jī)制，直到成功獲取了推送token，它再重新調(diào)用App把推送token傳過(guò)來(lái)。比如，小米推送平臺(tái)也是這么宣稱的，初始化可能出現(xiàn)的錯(cuò)誤，App開發(fā)者不用考慮。如果你充分信任推送平臺(tái)，那么這個(gè)錯(cuò)誤其實(shí)是可以不用去考慮的；否則，你可以在App里增加某些機(jī)會(huì)來(lái)檢測(cè)初始化是否已經(jīng)成功（可以通過(guò)檢測(cè)是否已經(jīng)拿到推送token來(lái)確定），然后在恰當(dāng)?shù)臅r(shí)機(jī)重新調(diào)用初始化代碼。當(dāng)然，在做這個(gè)事情之前，你最好與推送平臺(tái)溝通清楚，確保重復(fù)調(diào)用初始化代碼不會(huì)產(chǎn)生什么副作用。
上述第二種錯(cuò)誤，就必須靠App開發(fā)者自己處理了。這里我們實(shí)際上需要在App客戶端和服務(wù)器之間抽象出一條強(qiáng)的通信通道，我們把同步推送token的請(qǐng)求放進(jìn)去，這條通信通道能夠在失敗發(fā)生的時(shí)候自動(dòng)重試。
這里的代碼寫得是不是足夠健壯（robust），不同level的程序員就高下立判了。
我們可以說(shuō)，恰當(dāng)而全面地處理失敗情況才能真正體現(xiàn)工程師的意義，這也是工程和理論研究的不同點(diǎn)之一。
推送的送達(dá)率到底跟什么有關(guān)？
推送做得好不好，以及我們選擇推送平臺(tái)選的好不好，關(guān)鍵在于送達(dá)率高不高。送達(dá)率這個(gè)概念，一直是個(gè)很混亂的概念，有些平臺(tái)會(huì)宣稱送達(dá)率能達(dá)到98%以上，而又有一些人說(shuō)行業(yè)平均水平也就60%左右。
為什么說(shuō)法如此迥異呢？是因?yàn)榇蠹以谡f(shuō)的其實(shí)不是一個(gè)送達(dá)率。
友盟的消息推送業(yè)務(wù)線負(fù)責(zé)人陳漠沙曾專門寫過(guò)一篇文章，來(lái)澄清送達(dá)率概念的一些誤解，文章寫得相當(dāng)好，建議做推送業(yè)務(wù)的同學(xué)一定要讀一下：
關(guān)鍵是要分清此文中定義的“在線送達(dá)率”和“通用送達(dá)率”。
“在線送達(dá)率”，各個(gè)推送平臺(tái)優(yōu)化到最后，可能都差不多。估計(jì)都能達(dá)到98%以上。
而“通用送達(dá)率”才是真真正正把消息推送到你的App的最終的送達(dá)率，這個(gè)也才是用戶最終能感受到的送達(dá)率。App開發(fā)者需要真正關(guān)注的也是這個(gè)。
“通用送達(dá)率”大概來(lái)講，是最終到達(dá)App的消息數(shù)與開始發(fā)出的消息數(shù)的比率（在一定時(shí)間內(nèi)監(jiān)測(cè)）。跟這個(gè)比率直接有關(guān)的因素是兩個(gè)：
- 業(yè)務(wù)類型。比如你的App是個(gè)IM，那么可能通用送達(dá)率會(huì)比較高，因?yàn)镮M來(lái)的消息比較重要，且需要接收的人盡快去閱讀處理。而如果你的App只是來(lái)推送一些系統(tǒng)消息，那么很多人可能壓根不會(huì)打開你的App去看，這樣通用送達(dá)率自然就低。
- 推送的調(diào)用方式。這個(gè)和開發(fā)有關(guān)。比如，你的推送邏輯總給已經(jīng)卸載了App的用戶發(fā)送消息，那么對(duì)方肯定收不到了，造成通用送達(dá)率比較低。這種情況在群發(fā)的時(shí)候尤其顯著。
所以，這么說(shuō)起來(lái)，不同的App由于業(yè)務(wù)不同，推送調(diào)用方式也不同，那么他們的通用送達(dá)率就沒(méi)有實(shí)質(zhì)的可比性。
那假如我們推送做了某個(gè)優(yōu)化，或者某天換了一個(gè)更好的第三方推送平臺(tái)，我們?cè)趺粗肋@個(gè)改動(dòng)是好還是壞呢？答案是我們可以自己跟自己比。持續(xù)監(jiān)測(cè)通用送達(dá)率，比較改動(dòng)前后的變化。
擁抱變化
GitHub上有一個(gè)討論Android推送的帖子（由@Trinea創(chuàng)建）：
- Android 第三方 Push 推送方案使用調(diào)查
這個(gè)帖子從2015年5月份開始討論至今，仍然沒(méi)有人給出一個(gè)完美的解決方案。
隨著各個(gè)手機(jī)廠商的市場(chǎng)份額的變化，以及推送平臺(tái)市場(chǎng)的變化，Android推送也是一個(gè)不斷處于變化中的話題。今天的結(jié)論，換到明天，也許就未必再適用。
所以，推送服務(wù)的實(shí)現(xiàn)者們也當(dāng)然要擁抱變化。一定要確保你的推送架構(gòu)能夠很容易地切換某個(gè)第三方的推送渠道。
多年的創(chuàng)業(yè)經(jīng)驗(yàn)告訴我們，不只是推送服務(wù)，也包括眾多其它的云服務(wù)，僅僅依賴一家平臺(tái)的做法，都是極其愚蠢的。
由于國(guó)內(nèi)的各大手機(jī)廠商對(duì)于安卓系統(tǒng)做了各種不同的定制，增加了很多安全性的限制，導(dǎo)致推送成了一個(gè)很復(fù)雜的問(wèn)題。而這個(gè)市場(chǎng)中又沒(méi)有哪一家完美解決了所有手機(jī)設(shè)備的推送送達(dá)的問(wèn)題。同時(shí)，微信由于其先發(fā)優(yōu)勢(shì)和規(guī)模優(yōu)勢(shì)，進(jìn)入了各大廠商受保護(hù)的白名單，進(jìn)一步拉開了與其他App在推送送達(dá)率上的距離。
最后不由得感慨一句，如果谷歌一直在中國(guó)，還會(huì)有這種亂局出現(xiàn)嗎？
總結(jié)
以上是生活随笔為你收集整理的Android端外推送到底有多烦？(转载自一个1000万用户App的CTO的对推送的看法)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： python中星号怎么打出来_Pytho
- 下一篇： App应用双开技术，Android沙盒