淺談推送服務的那些「坑」

淺談推送服務的那些「坑」

隨着移動互聯網行業發展愈來愈成熟，各類各樣的開發工具與標準化的解決方案，正在急速下降互聯網產品的開發成本。推送服務儼然已成爲移動開發中的標配服務。做爲業務惟一可以主動touch用戶的手段，推送服務對於app拉新、拉活、引流、保活都有着非比尋常的意義。

然鵝，做爲一個多年奮戰在「技術客服」一線的產品經理，我想說對於推送服務——多的是，你不知道的事~~

接下來我就以小米推送爲例，跟各位開發者（產品/運營同窗）簡單講講在和形形色色的開發者對接過程當中，我所見過的最隱蔽、最難躲的坑。

 

1 一切的開始：設備註冊

全部的推送服務使用的第一步，都是註冊設備。其實緣由和目的都是顯而易見的，由於推送自己是一個點對點的行爲，每臺設備的客戶端都須要與服務端創建一個獨立的長鏈接用於收發消息。所以，推送服務須要對每一個設備進行標示。

各家推送服務的註冊接口叫法都不一樣，但有兩點是同樣的：

1 這一接口均爲客戶端接口

2 經過調用接口後均會生成一個per app&per 設備的惟一標示

以小米推送爲例，客戶端註冊推送的接口叫作registerPush，註冊成功後，會生成一個regID，regID在推送系統中是全局惟一的，mipush經過一套複雜的加密算法，保證每一個app在每臺設備上都不同。

介紹完背景知識，咱們來說講在註冊設備這個看似最簡單最基礎的動做中隱藏的坑：設備註冊的時機。

因爲pushSDK須要有客戶端工程師手動集成到app之中，registerPush的方法也須要客戶端自行調用才能完成註冊行爲。所以，註冊行爲的時機就很是重要。

那麼從產品層面，怎樣設計註冊推送的時機呢？

因爲不一樣的產品之間，業務形態千差萬別。因此很難總結一條明確的規定來指導使用者去註冊推送。但每位產品經理在設計推送的使用邏輯時，必定要將這一點想到前邊，瞭解app註冊推送的時機，結合業務邏輯去決策註冊推送的時機。以避免爲之後推送的使用埋下「神坑」。

舉個簡單的例子來講明一下吧：

某直播app，產品邏輯中有這樣一條限制：只有登錄以後才能看到內容。即登陸是強制動做。

這時候註冊應該在什麼時機呢？是在登陸前仍是登陸後呢？

其實這個問題沒有標準答案，要經過業務邏輯來進行設計。若是推送體系是基於帳號設計的，只有登陸完成以後，纔能有帳號，那麼在登錄後註冊推送聽上去比較合理，沒有登陸的用戶不做爲本身的推送目標；若是推送不基於帳號，而是基於設備，及時未登陸的設備，也但願可以接受推送消息。那麼註冊時機應該在用戶登陸以前。即app被用戶打開便可喚起推送。

 

2不要隨便註銷！

通常的推送服務都會提供註冊（registerPush）和註銷（unregisterPush）兩種接口，這兩種接口都是客戶端能力。用於開啓和關閉推送功能。須要注意的是：調用註銷接口後，以前註冊的設備ID（regID）就失效了，沒法繼續使用。即便從新註冊，也會生成新的設備ID。

因此註冊行爲是一種不可逆的行爲，僅適用於須要徹底終止推送服務的場景。

若是一直頻繁的調用註冊和註銷接口，會有什麼風險呢？

咱們再舉一個栗子：

仍是拿剛纔的直播app舉例，需求是若是用戶登出，則再也不向該設備推送消息。客戶端邏輯爲：用戶登錄後，調用registerPush接口；用戶註銷後，調用unregisterPush接口。按照以上行爲，每次用戶進行登陸和登出操做，均會生成新的regID。這種行爲直接致使無效的regID會愈來愈多。推送ID體系變得臃腫複雜。

所以，若是隻是但願暫時中止推送或關閉推送能力。應當使用別的方式，而不是直接註銷推送。各家基本都提供了暫停推送的接口。

以mipush爲例：

小米推送客戶端SDK中提供了兩種方式能夠控制推送的使用或恢復使用。

1 設置推送接受時間（setAcceptTime）：這種方式能夠自由控制設備天天（00:00-23:59）容許接收推送的時間，達到中止/恢復推送的目的。詳情請點擊連接

舉個栗子：夜間不但願用戶收到推送/用戶可自主選擇接受推送的時間

2 關閉/打開推送（enable/disablePush）：與上邊的方式不一樣，設置acceptTime後，長鏈接並未斷開。但設置disablepush以後，該設備的長鏈接也將斷開，只保留regID的有效性。詳情請點擊連接

舉個栗子：某些狀況下處於爲設備省電省流的考慮，但願長鏈接斷開，但保留推送能力，則可以使用這一方法

 

3 正確認識送達率

送達率是每一個使用推送的開發者最關心的數據指標之一，也是衡量一個推送服務靠不靠譜的關鍵指標。

然鵝，怎樣纔算送達率的正確打開方式？我以小米推送爲例來解釋一下這個問題~

首先須要說明的是推送服務送達率的計算方式：

分子比較容易理解，就是本次推送真正送達的設備數。

分母則是本次推送請求所覆蓋的有效的設備數：若是目標對象的選取是全部用戶，那分母就是歷史上全部激活過推送服務的有效設備數；若是是按照標籤選取的，那分母是歷史上全部訂閱過這個標籤的有效設備數；若是是按照別名或者regID來選取，那麼分母就是所請求的全部合法的別名或regID。其中，設備的有效性是經過以下規則來判斷的：若是應用有如下幾種行爲：

1調用unregisterPush，

2 用戶主動卸載，

3 超過3個月都沒有和小米服務器創建過長鏈接，則會斷定設備失效。

4 設置alias失敗等

按照這種計算方式，會有以下幾個影響送達率的因素：

1.    應用的留存率。

已經卸載了app的設備，確定是推送不到的，但按照目前的計算方式，很多卸載設備（尤爲是）都會被計入分母（計劃推送數）當中。

2.    應用所在設備的聯網狀況。

若是在消息有效期內，設備一直不聯網，那消息也是不能送達的，但也會被計入分母當中。

3.    消息的有效期。

有效期越短，在有效期內聯網的設備數勢必就越少，所以送達率會隨之降低。

4.    目標設備的選取。

若是選取的是全量用戶，那其送達率確定會比按照用戶聯網狀況精準提取目標設備（如選取7天內有過打開應用行爲的用戶）要低。

 

4 APNs服務的「神坑」

做爲一個有追求、有態度的推送服務，支持全平臺是基本的專業能力。但是面對蘋果這個神同樣的廠商，再牛叉的平臺都得俯首帖耳，聽從人家的規定。

市面上提供推送服務的公司在面對蘋果時候，基本都會採起相同的作法：

集成APNs（Apple Push Notification service）

APNs是蘋果官方提供的推送服務，因爲蘋果閉源的生態，全部開發者都只能使用這種方式來實現推送能力，強如微信也不例外。同時，不管是Android和iOS（包括WinPhone），推送服務的服務端接口的定義和使用方法保持一致，在結合業務邏輯使用的過程中，客戶端的差別能夠透明化。

今天在這裏並不想展開講APNs，只想吐槽一下偉大的蘋果……

但凡搞過iOS開發的同窗，基本都面對過同一個難題：沒法獲取設備的惟一標示。惟一用於標識設備的DeviceToken也會常常發生變化。

這一點其實也很好解釋：若是開發者能惟一標示設備，對用戶而言將會有很大的隱私風險。

開發者可能感觸不深，然鵝對於推送服務而言，這幾乎是使人抓狂的：沒法拿到設備的惟一標示，該怎麼作推送呢！

Mipush在這方面作了很是多的努力和嘗試，包括使用iOS的key chain能力去存儲設備標識……然鵝，最近我看到了這樣的一條新聞：

http://mp.weixin.qq.com/s?__biz=MzI5MjEzNzA1MA==&mid=2650264371&idx=1&sn=d23e515528e5d894a8d79558a48f73d1&chksm=f4068206c3710b1089d87c6727915488cddc94c08e4a928bac7e9809d9857fc4493ba7a36ae0&mpshare=1&scene=1&srcid=0314yXPCqwzN26Z7kuKmOVIO#rd

（此處爲轉載內容）

簡而言之，獲取惟一標示這件事情基本已經被蘋果趕盡殺絕了……做爲一個有操守的推送服務，我仍是很是想罵人……

不管怎樣，路還得走，產品還要不斷髮展，相信咱們後面會有更好的解決辦法，幫助廣大開發者解決這些難題~

以上就是我作推送的一點心得，但願能爲你提供一點點幫助~

 

yubin