在今天的文章開始之前，有個忙想請大家幫一下，希望在京東、淘寶、噹噹、亞馬遜購買了我的書的朋友們，幫忙去網店上給個簡短的評價，舉手之勞，還是多謝大家啦~~

    OK 下面就是今天的文章，中秋三天，加急寫出來的，算是對現在接手的推送功能的一個總結吧。

推送

    推送簡直就是一種輕量級的騷擾方式

    自從有了推送，各個公司基本上都在使用推送，這確實是一個比較好的提醒方式，Android較iOS強的一個部分，也就是在於Android的Notification。Google教育我們利用好Android的通知模組，做更多友好的互動，可這句話，翻譯成中文，不知不覺，就變成了在Notification中推送各種廣告，而且僅僅就是一些廣告，Notification各種牛逼的功能，完全不需要，這也違背了Google設計Notification的初衷。

    更關鍵的是，現在隨便找一款App，沒有推送的真是鳳毛麟角，更可惡的是，做外賣的App給我推送奧運新聞，一條新聞十幾個App推送，以至於現在很多使用者都非常反感各種推送廣告，就我本人而言，基本上會禁用所有廣告類的App的推送。

本人非常反感推送，借用王思聰的一句話，XXX App天天給我推送各種廣告，還TM是自己做的推送，真是絕了。

推送方案

輪詢

    輪詢是最簡單的與伺服器保持通訊的方式，即迴圈向伺服器通訊。這個方案的特點就是通訊由客戶端主動發起，你需要自己實現輪詢訊息佇列、頻率等等引數，在功耗和效果間做權衡，類似於TCP的短連線。

SMS

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

長連線

    長連線和前面提到的短連線，都是基於Socket連線的方式，他們的區別在與，短連線是每次資料傳輸完畢後就斷開連線，而長連線不會。所以，基於輪詢的方式，每次都要進行鏈路的連線，效能消耗更大，基於長連線的方式，就是對這點的改進。應用一旦與伺服器連線成功，並不會主動斷開連線，後面的通訊都基於這個通道。目前大部分的推送服務都是基於長連線的推送，在後臺維護一個Service，維持應用與服務端之間的TCP長連線。

推送方案

iOS

    iOS這邊使用系統統一的APNs，所有推送訊息都由蘋果的伺服器進行下發，同時，也由系統進行統一展示和處理。

GCM

    與iOS一樣，Android同樣有一套內建的推送方案，但很可惜的是，Google的服務在中國大陸無法使用，草了個蛋。

第三方推送服務

專業的第三方推送

• 極光

• 個推

• 友盟推送

手機ROM廠商推送

• 華為推送

• 小米推送

BAT級別的全家桶

• 阿里推送

• 信鴿推送

• 百度推送
  

    關於第三方推送服務在各個App中的使用率，大家可以參考賈吉鑫的那篇文章，微信沒辦法貼連結。。。麻煩大家自己搜一下。

第三方推送注意

    這些推送服務大同小異，基本上一家使用了一個新功能，另外幾家，也會很快推出這個功能，就例如之前比較火的，『共享推送通道進行App喚醒』這個技術，友盟、個推推出後，很快其它推送服務商就支援了，所以開發者並不需要擔心哪一家推送功能比較強。

    這裡還需要說下現在的『推送喚醒』這樣一個功能，簡單的說，就是所有安裝了A推送的App，只要有一個還活著，就可以把其它安裝了A推送的App拉起來，從而提高推送的到達率。有些阿里系、百度系的App，被大家稱作『全家桶』，實際上就是因為這個原因，這個方式，確實能在一定程度上提高推送到達率，但另一方面，也破壞了Android生態，增加了功耗，打亂了系統的清理策略。

    另外，小米推送、華為推送，大家接入的原因可能很簡單，就是他們的手機市場佔有率比較高，接入他們自家的推送，可以在一定程度上提高到達率，但需要注意的是，推送分為透傳和非透傳兩種方式，透傳即我們自己App處理推送訊息，而非透傳，則是交給相應的PushSDK處理，對於小米推送、華為推送來說，只有採用非透傳訊息，到達率採用保證，而透傳訊息，與其它推送並沒有什麼區別，換句話說，小米手機、華為手機，只對非透傳的推送訊息做了可靠性保證，但非透傳訊息的展示格式非常固定、簡單，且不能自定義，這是一個很大的問題，這點應該是很多開發者的誤區。

    最後，很多推送服務都需要在Application中進行初始化，同時，各種被喚醒策略，又會拉起Application，導致推送程序的重複，所以，這裡經常需要對程序名進行過濾，非主程序，不進行初始化。

自建推送服務

    基本都是基於AndroidPN、MQTT、XMPP、長連線這些方式去實現的，自己搭建Push平臺服務，一個最大的問題就是服務端的架構設計，不僅成本高，而且效果不一定好，建議中小企業不要輕易嘗試。

推送名詞解釋

RegistrationID\ClientID

    一般來說，類似這類ID都是用於唯一標識應用\使用者的，每個App在每臺手機上都會生成一個唯一ID。

RegistrationID\ClientID生成規則

    Android平臺上因為國記憶體在大量山寨裝置，所以很多裝置的IMEI、Mac地址、AndroidID 都有可能為空或者錯誤，所以不能單獨作為唯一標識，需要將這些進行組合起來使用。

    對於應用解除安裝後RegistrationID的問題，很多PushSDK的策略是，生成一個DeviceID儲存到本地儲存，應用被解除安裝後如果被重新安裝，如果檢測到儲存裡的DeviceID還在的話，就判定是同一個裝置，不重新生成RegistrationID。

AppKey\AppID

    這些Key基本都是用於驗證App的，每個包名對應一個加密的Key。

透傳\非透傳

    非透傳訊息是指推送訊息被PushSDK獲取並處理，透傳訊息是指推送訊息被PushSDK交給宿主應用處理，非透傳訊息通常只能設定一些固定的樣式，比較簡單，而透傳訊息，可以由App自定義處理，比較靈活。

推送資料基礎

累計註冊

    通過應用使用的appid統計使用者註冊總量。

日線上使用者

    通過應用使用的appid統計當天的線上使用者數。

活躍使用者

    通過應用使用的appid統計當天在推送平臺啟用過的使用者總數。

線上下發率

    線上訊息下發數/總下發數。

回執率

    訊息回執數（去重）/訊息線上下發數。

到達率

    到達數/實際下發數。

百日內聯網使用者數（可推送使用者數）

    是指最近三個月內有登入過（裝置與推送服務端建立長連結）的裝置總數，即有效可下發的使用者數。一般的推送服務端認為，裝置在100天內沒有登入請求，認為該裝置已經失效，所以無需再次傳送。

實際下發數

    實際可推送裝置數（在訊息有效期內，有聯網並推送程序正常的裝置，即訊息有效期內的線上下發數。訊息有效期就是設定的離線時間）。

到達數

    客戶端SDK接收到訊息的裝置數（通過統計客戶端SDK接收到訊息後的回執獲得）。

展示數

    用自定義非透傳訊息在使用者手機展示過的裝置數。

點選數

    點選通知欄訊息的裝置數。

推送資料分析

    那麼關於推送，大家實際上最關係的，就是『到達率』。那麼這個到達率究竟怎麼計算呢？

    首先我們舉個例子來說明上面的這些資料背後的實際意義，例如，我們有一款App，有100w的下載量，每個App啟動後，都將上報給伺服器一個唯一ID，所以，累計註冊量就是100w，也稱傳送總量。

    那麼在服務端準備傳送推送的時候，當前手機端推送程序還活著的，也就是說推送的長連線還健在的，就是線上裝置，如果按天算，那麼就叫日線上裝置數，我們假設這個數字是60w。

    OK，推送發出去後，客戶端收到推送訊息，併產生回執，代表完成了一次推送，假設這些完成推送的裝置是55w，這個就是送達裝置數。一般來說，只要裝置線上，基本都能送達，所以這個數字和線上裝置數非常接近，不接近的話，這個推送基本就有問題了，其中可能送不達的原因就在於網路切換等導致長連線斷掉這類因素。

    那麼到這裡，一般的推送服務商會使用送達裝置數/線上裝置數的方式來計算到達率，當然，前面我們也說了，這個比例一定是很高的，如果保持長連線的裝置都不能收到推送，那一定是有問題了。

    而一般的到達率，應該是送達裝置數/可送達裝置數，也就是百日內活躍的裝置數，這樣一除，這個比例一下子就小了很多，因為誰也不知道，這一百天內曾經活躍的使用者，第二天是不是就已經把你解除安裝了。所以說，Android下統計推送的到達率一般都很低，而推送服務商宣傳的到達率都很高，這其實就是一個偷換概念的問題，我們說的是一般的到達率，而服務商宣傳的是線上到達率。

    而且，這個到達率與iOS完全沒有可比性，因為iOS統一通過APNs來進行推送，且無法獲取到達回執，所以，iOS基本不存在到達率這一說法，如果有，幾乎也是100%，完全沒有意義，所以，如果哪一天有產品或者運營跟你說，為什麼Android的到達率比iOS的到達率差這麼多，請毫不客氣的砸它一斤蘋果。

Tag\Alias

Tag

    Tag，或者叫標籤，是使用者的一種屬性，在給某些使用者設定某類標籤後就可以針對推送。比如給喜歡『程式設計』的人打上『程式設計』的標籤，就可以只給他們精準推送。

    通常情況下，一個裝置（在一個App裡）可以設定多個標籤。標籤與別名類似，其對應關係也是儲存在推送伺服器側的。

Alias

    Alias，或者叫別名，是對已經安裝某應用的使用者取個別名進行標識，在對該使用者訊息推送時，就可以用此別名來進行推送。設定了別名後，推送時伺服器端指定別名即可。推送伺服器端來把別名轉化到裝置ID來找到裝置。

    Tag和Alias他們的共同點在於，提供對使用者的精確推送。

推送原理

    目前大部分的第三方推送服務，都是基於長連線的推送方案，下面將對這個方式進行詳細講解。

NAT

    首先，我們需要了解下一個網路基本知識——NAT，即網路地址轉換（Network Address Translation，NAT），這是因為IP地址是有限的，手機無論是通過路由器還是資料網路，都有一個內網IP地址，同時，路由器上會維護一個外網IP地址，從而形成一個NAT路由表，即內網IP地址:埠，以及對應的外網IP地址:埠。這樣通過一層層封裝與解封裝，就達到了內網與外網交換通訊的方式。

NAT超時

    由於NAT路由表的大小有效，所以一般路由都有NAT有效期，WIFI下，這個NAT有效期可能會比較長，而在資料流量下，運營商一般都會盡快更新NAT路由表，淘汰無效的裝置，所以，在使用資料流量時，長連線經常容易斷。

    那麼除了NAT路由表主動淘汰過期的裝置之外，切換網路環境和DHCP伺服器租期到期，這些情況都有可能導致NAT路由表改變，從而造成長連線中斷。

心跳包

    前面我們說了，現在的推送服務一般採用的是長連線的通訊方式，而長連線會因為NAT路由表的更新而中斷，所以，客戶端會定時向服務端傳送一個心跳包，來定期告知NAT路由表，我還活著，別殺我！這就是心跳包的作用——防止NAT路由表超時，同時檢測連線是否被斷開。

心跳包的心跳時間

    既然心跳包的作用是防止NAT超時，那麼就需要將心跳包的傳送頻率設定為小余NAT超時的檢測頻率，而WIFI和資料流量下，對於NAT路由表的超時時間又是不一樣的，而且不同的網路運營商的超時時間，甚至都不一樣，所以，一個比較好的方法就是根據裝置當前網路環境，來動態的設定心跳時間。

注意，心跳包與輪詢是不一樣的，心跳包建立在長連線上，只要傳送資料即可，而輪詢每次都是一個完整的TCP連線。

心跳包誰來發

    既然需要定時任務，那麼就需要使用AlarmManager來作定時喚醒了，原因我之前的文章有講過，是關於處理器喚醒的原因，這裡就不贅述了，大家可以參考我之前的文章：

程序保活

    所謂程序保活，是指App希望儘可能的保證自己的App的推送程序能夠存活在後臺，以保證可以收到服務端的推送訊息，因此，才出現了一大批關於程序保活的方式，例如NDK層的檔案鎖，fork子程序、前臺服務、程序優先順序等等方式，然而，這些東西，實際上，都不能完全保證手機的程序管理策略放過你，特別是Android 5.0以後的系統，Android對程序的管理更加嚴格，還有國內的這些ROM層的修改，ROM想要殺你這個程序，你怎麼做也沒有辦法，哦，除了白名單。所以，不要再花心思去找什麼程序保活的黑科技了，好好做好應用，提供使用者的使用黏性，才是最佳的保活，而對於一些產品、運營所謂的『為什麼微信、QQ都可以保活』這樣的問題，我建議你回答它：『如果你能把產品做到微信、QQ那樣的數量級，我也能讓你活！』

推送整合方案

    介於各種第三方推送與ROM推送的特點，我們目前採用的推送方案，名為『UniversalPushSDK』，即整合了多個不同的推送渠道，通過模板設計模式來進行整合，並向外暴露統一的介面，這種方式的好處在於UniversalPushSDK利用的各個不同推送特點，提高推送到達率，但是壞處在於，包的體積會大一些。例如，我們現在整合了『小米推送、極光推送、華為推送』，在系統啟動的時候，判斷當前系統，如果是小米系統，則啟用『小米推送』，如果是華為手機，則啟用『華為推送』，其它的Android裝置，則啟用『極光推送』，通過這種方式來設計我們自己的推送SDK，可以在一定程度上，利用好各個推送平臺的特性。

    那麼如果利用這種方式來設計SDK給到不同的App接入，就需要能夠將應用的推送Key做到動態配置，這也是我們遇到的最大的一個問題，解決方法大家可以參考我之前寫的一篇文章：

雖然我極力反對這種方案，我堅持認為，做好App，提升使用者使用黏性，才是提升推送到達率的關鍵

最後，上海的開發者注意啦，9月24日，滬江會舉辦一次Android技術沙龍，具體內容大家可以看這篇文章：

歡迎各位前來圍觀~

———— 感謝醫生白忙之中還寫出這麼好的文章，在此收藏了，以備後續學習。