內(nèi)部爆料，推送服務的那些“坑”
隨著移動互聯(lián)網(wǎng)行業(yè)發(fā)展越來越成熟，各種各樣的開發(fā)工具與標準化的解決方案，正在急速降低互聯(lián)網(wǎng)產(chǎn)品的開發(fā)成本。推送服務儼然已成為移動開發(fā)中的標配服務。作為業(yè)務唯一能夠主動touch用戶的手段，推送服務對于app拉新、拉活、引流、?；疃加兄潜葘こ５囊饬x。
然鵝，作為一個多年奮戰(zhàn)在“技術(shù)客服”一線的產(chǎn)品經(jīng)理，我想說對于推送服務——多的是，你不知道的事~~
接下來我就以小米推送為例，跟各位開發(fā)者(產(chǎn)品/運營同學)簡單講講在和形形色色的開發(fā)者對接過程中，我所見過的最隱蔽、最難躲的坑。
文章分別從四個方面總結(jié)了關(guān)于推送服務過程中隱蔽的坑，會通過兩期的內(nèi)容分別呈現(xiàn)給大家，希望可以給大家一些警示。
本期，我們先從注冊和注銷兩方面來進行探討~
1 、一切的開始：設(shè)備注冊
所有的推送服務使用的第一步，都是注冊設(shè)備。其實原因和目的都是顯而易見的，因為推送本身是一個點對點的行為，每臺設(shè)備的客戶端都需要與服務端建立一個獨立的長連接用于收發(fā)消息。因此，推送服務需要對每個設(shè)備進行標示。
各家推送服務的注冊接口叫法都不同，但有兩點是一樣的：
1)這一接口均為客戶端接口
2) 通過調(diào)用接口后均會生成一個per app&per 設(shè)備的唯一標示
以小米推送為例，客戶端注冊推送的接口叫做registerPush，注冊成功后，會生成一個regID，regID在推送系統(tǒng)中是全局唯一的，mipush通過一套復雜的加密算法，保證每個app在每臺設(shè)備上都不一樣。
介紹完背景知識，我們來講講在注冊設(shè)備這個看似最簡單最基礎(chǔ)的動作中隱藏的坑：設(shè)備注冊的時機。
由于pushSDK需要有客戶端工程師手動集成到app之中，registerPush的方法也需要客戶端自行調(diào)用才能完成注冊行為。因此，注冊行為的時機就非常重要。
那么從產(chǎn)品層面，怎樣設(shè)計注冊推送的時機呢?
由于不同的產(chǎn)品之間，業(yè)務形態(tài)千差萬別。所以很難總結(jié)一條明確的規(guī)定來指導使用者去注冊推送。但每位產(chǎn)品經(jīng)理在設(shè)計推送的使用邏輯時，一定要將這一點想到前邊，了解app注冊推送的時機，結(jié)合業(yè)務邏輯去決策注冊推送的時機。以免為以后推送的使用埋下“神坑”。
舉個簡單的例子來說明一下吧：
某直播app，產(chǎn)品邏輯中有這樣一條限制：只有登陸之后才能看到內(nèi)容。即登錄是強制動作。
這時候注冊應該在什么時機呢?是在登錄前還是登錄后呢?
其實這個問題沒有標準答案，要通過業(yè)務邏輯來進行設(shè)計。如果推送體系是基于賬號設(shè)計的，只有登錄完成之后，才能有賬號，那么在登陸后注冊推送聽上去比較合理，沒有登錄的用戶不作為自己的推送目標;如果推送不基于賬號，而是基于設(shè)備，及時未登錄的設(shè)備，也希望能夠接受推送消息。那么注冊時機應該在用戶登錄之前。即app被用戶打開即可喚起推送。
2 、不要隨便注銷
一般的推送服務都會提供注冊(registerPush)和注銷(unregisterPush)兩種接口，這兩種接口都是客戶端能力。用于開啟和關(guān)閉推送功能。需要注意的是：調(diào)用注銷接口后，之前注冊的設(shè)備ID(regID)就失效了，無法繼續(xù)使用。即使重新注冊，也會生成新的設(shè)備ID。
所以注冊行為是一種不可逆的行為，僅適用于需要完全終止推送服務的場景。
如果一直頻繁的調(diào)用注冊和注銷接口，會有什么風險呢?
我們再舉一個栗子：
還是拿剛才的直播app舉例，需求是如果用戶登出，則不再向該設(shè)備推送消息。客戶端邏輯為：用戶登陸后，調(diào)用registerPush接口;用戶注銷后，調(diào)用unregisterPush接口。按照以上行為，每次用戶進行登錄和登出操作，均會生成新的regID。這種行為直接導致無效的regID會越來越多。推送ID體系變得臃腫復雜。
因此，如果只是希望暫時停止推送或關(guān)閉推送能力。應當使用別的方式，而不是直接注銷推送。各家基本都提供了暫停推送的接口。
以mipush為例：
小米推送客戶端SDK中提供了兩種方式可以控制推送的使用或恢復使用。
1)設(shè)置推送接受時間(setAcceptTime)：這種方式可以自由控制設(shè)備每天(00:00-23:59)允許接收推送的時間，達到停止/恢復推送的目的。
詳情如截圖：
舉個栗子：夜間不希望用戶收到推送/用戶可自主選擇接受推送的時間
2) 關(guān)閉/打開推送(enable/disablePush)：與上邊的方式不同，設(shè)置acceptTime后，長連接并未斷開。但設(shè)置disablepush之后，該設(shè)備的長連接也將斷開，只保留regID的有效性。
詳情如截圖：
舉個栗子：某些情況下處于為設(shè)備省電省流的考慮，希望長連接斷開，但保留推送能力，則可使用這一方法。
3、正確認識送達率
送達率是每個使用推送的開發(fā)者最關(guān)心的數(shù)據(jù)指標之一，也是衡量一個推送服務靠不靠譜的關(guān)鍵指標。
然鵝，怎樣才算送達率的正確打開方式?我以小米推送為例來解釋一下這個問題~
首先需要說明的是推送服務送達率的計算方式：
分子比較容易理解，就是本次推送真正送達的設(shè)備數(shù)。
分母則是本次推送請求所覆蓋的有效的設(shè)備數(shù)：如果目標對象的選取是所有用戶，那分母就是歷史上所有激活過推送服務的有效設(shè)備數(shù);如果是按照標簽選取的，那分母是歷史上所有訂閱過這個標簽的有效設(shè)備數(shù);如果是按照別名或者regID來選取，那么分母就是所請求的所有合法的別名或regID。其中，設(shè)備的有效性是通過如下規(guī)則來判斷的：如果應用有以下幾種行為：
1)調(diào)用unregisterPush，
2) 用戶主動卸載，
3)超過3個月都沒有和小米服務器建立過長連接，則會判定設(shè)備失效。
4)設(shè)置alias失敗等
按照這種計算方式，會有如下幾個影響送達率的因素：
① 應用的留存率。
已經(jīng)卸載了app的設(shè)備，肯定是推送不到的，但按照目前的計算方式，不少卸載設(shè)備(尤其是)都會被計入分母(計劃推送數(shù))當中。
②應用所在設(shè)備的聯(lián)網(wǎng)情況。
如果在消息有效期內(nèi)，設(shè)備一直不聯(lián)網(wǎng)，那消息也是不能送達的，但也會被計入分母當中。
③消息的有效期。
有效期越短，在有效期內(nèi)聯(lián)網(wǎng)的設(shè)備數(shù)勢必就越少，因此送達率會隨之下降。
④目標設(shè)備的選取。
如果選取的是全量用戶，那其送達率肯定會比按照用戶聯(lián)網(wǎng)情況精準提取目標設(shè)備(如選取7天內(nèi)有過打開應用行為的用戶)要低。
4 APNs服務的“神坑”
作為一個有追求、有態(tài)度的推送服務，支持全平臺是基本的專業(yè)能力?？墒敲鎸μO果這個神一樣的廠商，再牛叉的平臺都得俯首帖耳，遵從人家的規(guī)定。
市面上提供推送服務的公司在面對蘋果時候，基本都會采取相同的做法：
集成APNs(Apple Push Notification service)
APNs是蘋果官方提供的推送服務，由于蘋果閉源的生態(tài)，所有開發(fā)者都只能使用這種方式來實現(xiàn)推送能力，強如微信也不例外。同時，無論是Android和iOS(包括WinPhone)，推送服務的服務端接口的定義和使用方法保持一致，在結(jié)合業(yè)務邏輯使用的過程當中，客戶端的差異可以透明化。
今天在這里并不想展開講APNs，只想吐槽一下偉大的蘋果……
但凡搞過iOS開發(fā)的同學，基本都面對過同一個難題：無法獲取設(shè)備的唯一標示。唯一用于標識設(shè)備的DeviceToken也會經(jīng)常發(fā)生變化。
這一點其實也很好解釋：如果開發(fā)者能唯一標示設(shè)備，對用戶而言將會有很大的隱私風險。
開發(fā)者可能感觸不深，然鵝對于推送服務而言，這幾乎是令人抓狂的：無法拿到設(shè)備的唯一標示，該怎么做推送呢!
Mipush在這方面做了非常多的努力和嘗試，包括使用iOS的key chain能力去存儲設(shè)備標識……
然鵝，最近我看到了這樣的一條新聞【截圖來自MrPeak雜貨鋪】：
簡而言之，獲取唯一標示這件事情基本已經(jīng)被蘋果趕盡殺絕了……
無論怎樣，路還得走，產(chǎn)品還要不斷發(fā)展，相信我們后面會有更好的解決辦法，幫助廣大開發(fā)者解決這些難題~
以上就是我做推送的一點心得，希望能為你提供一點點幫助~
【本文是51CTO專欄“小米開放平臺”原創(chuàng)文章，“小米開放平臺”微信公眾號xiaomideveloper】
