【轉】推送怎麼玩

推送和移動互聯的關係，已經密不可分。天天你收到的推送是各大app的強有力的吸引用戶黏住用戶的工具。

那咱們來具體瞭解下推送吧。目前的兩大平臺ios和安卓的推送的實現是有很大差別的。如下分開描述。

 

IOS&android簡要對比

IOS推送即APNS - Apple Push Notification Service，依託一個或幾個系統常駐進程，是全局的（接管全部應用的消息推送）的獨立於應用以外，是設備和蘋果服務器之間的通信，而非應用的提供商服務器。

好比，網易雲課堂的服務器（Provider）給蘋果公司對應的服務器（APNS）發出通知，而後再中轉傳送到設備（Devices）上。當你接收到通知，打開應用，纔開始從雲課堂服務器接收數據。

而android的推送是各應用有各自的單獨後臺進程和各自的服務器通信，交換數據，來達到推送的目的。好比雲課堂有本身單獨的推送進程：com.netease.edu.study.enterprise:pushservice。

 
    當該進程被kill掉以後，則沒法收到推送。IOS則不存在相似問題。 另外其實 Android 也有相似 APNS 的 GCM（Google Cloud Message），屬於開發者可選，非強制。而 Google 不強制的結果就是：沒人真正爲用戶的電池負責。也由於整個技術方案非強制， Android 的 Apps 在接收到推送後的表現更爲靈活。

 

因此iOS 的消息推送機制使得應用自己不能有常駐的後臺進程，系統的開銷少，內存使用更少，而 Android 則開銷更大。

 

推送的通常技術原理

要理解推送的實現原理，首先要了解device_token。

UDID - iOS Unique Device ID，是每一個iphone的標識符，能夠經過鏈接XCode查看到，以下圖中的identifier就是該設備的UDID。

 

 

 

Bundle ID(Bundle Identifier)：一款iOS應用的惟一標識，應用與Bundle ID之間是惟一對應關係。應用新建成功後，Bundle ID將不可修改，如必須修改只能建立一個新的應用，屆時App ID、App Key和App Secret也將從新分配，舊版用戶將沒法收到針對新Bundle ID的推送。

蘋果服務器根據咱們這一臺設備的UDID和app的bundleID混編而成的deviceToken,咱們須要將這個deviceToken傳送給咱們的服務器端,或者登錄用戶的時候做爲參數傳給服務器.這樣一個用戶對象就綁定了一個deviceToken.當須要給這個用戶推送消息的時候,咱們本身的後臺服務器,就會找這個用戶對應的deviceToken和要發送的推送內容,直接發送到蘋果的apns服務器,而後由蘋果的apns服務器將消息推送到該deviceToekn對應的手機上。

 

deviceToken是ios設備在APNS上的標識（蘋果服務器根據咱們這一臺設備的UDID和app的bundleID混編而成的deviceToken）用於推送服務。每一個設備上的每一個app有兩個deviceToken，一個用於開發測試，一個用於生產環境。應用須要每次啓動的時候都去註冊遠程通知，註冊成功， APNs 會返回一個設備的標識符即deviceToken 給 App，一個用戶對象就綁定了一個deviceToken.當須要給這個用戶推送消息的時候,咱們本身的後臺服務器,就會找這個用戶對應的deviceToken和要發送的推送內容,直接發送到蘋果的apns服務器,而後由蘋果的apns服務器將消息推送到該deviceToekn對應的手機上。

 

 

在須要發送push時，咱們的服務端就會取出要發送的設備的device token，而後如下圖所示的結構，組成字符串，而後將其發送到的APNs 

 

 

第一個部分是命令標示符，第二個部分是咱們的deviceToken的長度，第三部分是咱們的deviceToken字符串，第四部分是推送消息體（Payload）的長度，最後一部分也就是真正的消息內容了，裏面包含了推送消息的基本信息，好比消息內容，應用Icon右上角顯示多少數字以及推送消息到達時所播放的聲音等。

 

 

整個過程是這樣：

首先，設備安裝了具備推送功能的應用， iOS設備在有網絡的狀況下會鏈接APNs推送服務器，鏈接過程當中，APNS 服務器會驗證device_token，鏈接成功後維持一個基於TCP 的長鏈接；Provider(咱們本身的應用服務器)收到須要被推送的消息並結合被推送的 iOS設備的device_token一塊兒打包發送給APNS服務器；APNS服務器將推送信息推送給指定device_token的iOS設備，iOS設備收到推送消息後通知咱們的應用程序並顯示和提示用戶（聲音、彈出框）。

 

 

安卓推送

GCM 

Google Cloud Messaging是 Google 本身的一套推送服務，也是系統級別的，可是衆所周知，Google 的服務在國內根本無法使用，只能放棄。

輪詢

輪詢是最簡單的與服務器保持通訊的方式，即循環向服務器通訊。這個方案的特色就是通訊由客戶端主動發起，你須要本身實現輪詢消息隊列、頻率等等參數，在功耗和效果間作權衡，相似於TCP的短鏈接。

SMS

這個其實就是藉助短信來實現信息的展現，只不過把短信內容展現到了Notification中，這個方案，到達率確實高，畢竟短信是比較可靠、穩定的，但劣勢也很明顯，就是成本很高，並且在Android平臺上，短信的權限比較開放，容易被劫持。

長鏈接

長鏈接和前面提到的短鏈接，都是基於Socket鏈接的方式，他們的區別在與，短鏈接是每次數據傳輸完畢後就斷開鏈接，而長鏈接不會。因此，基於輪詢的方式，每次都要進行鏈路的鏈接，性能消耗更大，基於長鏈接的方式，就是對這點的改進。應用一旦與服務器鏈接成功，並不會主動斷開鏈接，後面的通訊都基於這個通道。目前大部分的推送服務都是基於長鏈接的推送，在後臺維護一個Service，維持應用與服務端之間的TCP長鏈接。目前基本上是最多選擇的方案。

可是目前基於成本上的考慮，大多數中小型公司都會選擇使用第三方推送服務。

 

第三方推送服務

目前來講作的比較好的推送服務大概有小米推送、騰訊信鴿推送、百度推送、極光推送、友盟推送等。這些推送服務大都有如下特色：

免費

固然部分公司也有收費的，號稱更穩定、推送到達率更高，但大部分都仍是用的免費版。

服務會被殺死

因爲 Android 系統的機制，後臺推送 Service 會被各類主動的或是被動的行爲給殺死，而服務一旦被殺死，意味着就接收不到推送消息。

多個 app 共用一條推送通道

什麼意思呢？就是若是有多個 app 都使用了同一家推送服務，那麼這些 app 共用一條消息通道，即便你家的 app 推送服務被殺死了，那麼只要用戶打開了其餘集成該推送服務的 app ，你家的推送就能接受到消息。好比雲課堂企業版如今使用的小米推送服務，雲課堂企業版被殺死了，可是手機上只要其它也使用小米推送的app的進程還在，雲課堂企業版仍是能接收到推送消息。

 

每家的推送服務都號稱推送到達率很高，號稱本身家的推送服務更不容易被殺死，號稱本身的推送更穩定更有保證，然而我要說的是，各家都差很少，技術上你能實現的，別家同樣能實現，到達率也都差很少，據我觀察平均推送到達率能達到 70% 左右都算不錯的了，那麼到底該怎麼選擇呢？

 

有一點比較特殊的是有些推送服務有本身家品牌的手機，好比小米有本身的手機，而在 MIUI 系統上小米推送是做爲系統級的服務，不會被殺死，畢竟一家人，總不至於傻到把本身家的服務給幹掉吧？因此這就是一個巨大的優點了。相似的華爲推送服務在本身家的手機系統上也不會被殺死。

 

各大手機廠商都宣傳本身家的手機市場份額第一，然而我要說的是現在市場上的 Android 手機只分小米手機跟其餘手機，什麼意思？就是小米手機是目前市場份額第一，並且遠遠領先其餘手機，這個在咱們本身家 app 的數據上看就是這樣，而這裏有一份友盟發佈的 Android 設備活躍的排名數據，地址在這裏：http://www.umindex.com

以小米手機的市場份額，加上小米推送在 MIUI 上不被殺死這一大特性，導致選擇小米推送是第一選擇。目前雲課堂企業版安卓也選擇了小米推送服務（哈哈）。

因此，你能夠選擇直接集成某個第三方推送，若是你想要把推送更優化下，那麼能夠集成多個推送服務，針對不一樣的渠道用不一樣的推送，好比小米渠道用小米推送，華爲渠道用華爲推送，其餘渠道用信鴿推送等，可是這種也比較麻煩，具體怎麼作看本身利弊權衡。