推送
推送簡(jiǎn)直就是一種輕量級(jí)的騷擾方式
自從有了推送，各個(gè)公司基本上都在使用推送，這確實(shí)是一個(gè)比較好的提醒方式，Android較iOS強(qiáng)的一個(gè)部分，也就是在于Android的Notification。Google教育我們利用好Android的通知模塊，做更多友好的交互，可這句話，翻譯成中文，不知不覺，就變成了在Notification中推送各種廣告，而且僅僅就是一些廣告，Notification各種牛逼的功能，完全不需要，這也違背了Google設(shè)計(jì)Notification的初衷。
更關(guān)鍵的是，現(xiàn)在隨便找一款A(yù)pp，沒有推送的真是鳳毛麟角，更可惡的是，做外賣的App給我推送奧運(yùn)新聞，一條新聞十幾個(gè)App推送，以至于現(xiàn)在很多用戶都非常反感各種推送廣告，就我本人而言，基本上會(huì)禁用所有廣告類的App的推送。
本人非常反感推送，借用王思聰?shù)囊痪湓挘琗XX App天天給我推送各種廣告，還TM是自己做的推送，真是絕了。
推送方案
輪詢
輪詢是最簡(jiǎn)單的與服務(wù)器保持通信的方式，即循環(huán)向服務(wù)器通信。這個(gè)方案的特點(diǎn)就是通信由客戶端主動(dòng)發(fā)起，你需要自己實(shí)現(xiàn)輪詢消息隊(duì)列、頻率等等參數(shù)，在功耗和效果間做權(quán)衡，類似于TCP的短連接。
SMS
這個(gè)其實(shí)就是借助短信來實(shí)現(xiàn)信息的展示，只不過把短信內(nèi)容展示到了Notification中，這個(gè)方案，到達(dá)率確實(shí)高，畢竟短信是比較可靠、穩(wěn)定的，但劣勢(shì)也很明顯，就是成本很高，而且在Android平臺(tái)上，短信的權(quán)限比較開放，容易被劫持。
長(zhǎng)連接
長(zhǎng)連接和前面提到的短連接，都是基于Socket連接的方式，他們的區(qū)別在與，短連接是每次數(shù)據(jù)傳輸完畢后就斷開連接，而長(zhǎng)連接不會(huì)。所以，基于輪詢的方式，每次都要進(jìn)行鏈路的連接，性能消耗更大，基于長(zhǎng)連接的方式，就是對(duì)這點(diǎn)的改進(jìn)。應(yīng)用一旦與服務(wù)器連接成功，并不會(huì)主動(dòng)斷開連接，后面的通信都基于這個(gè)通道。目前大部分的推送服務(wù)都是基于長(zhǎng)連接的推送，在后臺(tái)維護(hù)一個(gè)Service，維持應(yīng)用與服務(wù)端之間的TCP長(zhǎng)連接。
推送方案
iOS
iOS這邊使用系統(tǒng)統(tǒng)一的APNs，所有推送消息都由蘋果的服務(wù)器進(jìn)行下發(fā)，同時(shí)，也由系統(tǒng)進(jìn)行統(tǒng)一展示和處理。
GCM
與iOS一樣，Android同樣有一套內(nèi)置的推送方案，但很可惜的是，Google的服務(wù)在中國(guó)大陸無法使用，草了個(gè)蛋。
第三方推送服務(wù)
專業(yè)的第三方推送
- 極光
- 個(gè)推
- 友盟推送
手機(jī)ROM廠商推送
- 華為推送
- 小米推送
BAT級(jí)別的全家桶
- 阿里推送
- 信鴿推送
- 百度推送
關(guān)于第三方推送服務(wù)在各個(gè)App中的使用率，大家可以參考賈吉鑫的這篇文章：
https://mp.weixin.qq.com/s?__biz=MzA5OTMxMjQzMw==&mid=2648112527&idx=1&sn=b23c1b5f3e32e343ad96d705bd4d63ff
第三方推送注意
這些推送服務(wù)大同小異，基本上一家使用了一個(gè)新功能，另外幾家，也會(huì)很快推出這個(gè)功能，就例如之前比較火的，『共享推送通道進(jìn)行App喚醒』這個(gè)技術(shù)，友盟、個(gè)推推出后，很快其它推送服務(wù)商就支持了，所以開發(fā)者并不需要擔(dān)心哪一家推送功能比較強(qiáng)。
這里還需要說下現(xiàn)在的『推送喚醒』這樣一個(gè)功能，簡(jiǎn)單的說，就是所有安裝了A推送的App，只要有一個(gè)還活著，就可以把其它安裝了A推送的App拉起來，從而提高推送的到達(dá)率。有些阿里系、百度系的App，被大家稱作『全家桶』，實(shí)際上就是因?yàn)檫@個(gè)原因，這個(gè)方式，確實(shí)能在一定程度上提高推送到達(dá)率，但另一方面，也破壞了Android生態(tài)，增加了功耗，打亂了系統(tǒng)的清理策略。
另外，小米推送、華為推送，大家接入的原因可能很簡(jiǎn)單，就是他們的手機(jī)市場(chǎng)占有率比較高，接入他們自家的推送，可以在一定程度上提高到達(dá)率，但需要注意的是，推送分為透?jìng)骱头峭競(jìng)鲀煞N方式，透?jìng)骷次覀冏约篈pp處理推送消息，而非透?jìng)?，則是交給相應(yīng)的PushSDK處理，對(duì)于小米推送、華為推送來說，只有采用非透?jìng)飨?，到達(dá)率采用保證，而透?jìng)飨?，與其它推送并沒有什么區(qū)別，換句話說，小米手機(jī)、華為手機(jī)，只對(duì)非透?jìng)鞯耐扑拖⒆隽丝煽啃员ＷC，但非透?jìng)飨⒌恼故靖袷椒浅９潭?、?jiǎn)單，且不能自定義，這是一個(gè)很大的問題，這點(diǎn)應(yīng)該是很多開發(fā)者的誤區(qū)。
最后，很多推送服務(wù)都需要在Application中進(jìn)行初始化，同時(shí)，各種被喚醒策略，又會(huì)拉起Application，導(dǎo)致推送進(jìn)程的重復(fù)，所以，這里經(jīng)常需要對(duì)進(jìn)程名進(jìn)行過濾，非主進(jìn)程，不進(jìn)行初始化。
自建推送服務(wù)
基本都是基于AndroidPN、MQTT、XMPP、長(zhǎng)連接這些方式去實(shí)現(xiàn)的，自己搭建Push平臺(tái)服務(wù)，一個(gè)最大的問題就是服務(wù)端的架構(gòu)設(shè)計(jì)，不僅成本高，而且效果不一定好，建議中小企業(yè)不要輕易嘗試。
推送名詞解釋
RegistrationID\ClientID
一般來說，類似這類ID都是用于唯一標(biāo)識(shí)應(yīng)用\用戶的，每個(gè)App在每臺(tái)手機(jī)上都會(huì)生成一個(gè)唯一ID。
RegistrationID\ClientID生成規(guī)則
Android平臺(tái)上因?yàn)閲?guó)內(nèi)存在大量山寨設(shè)備，所以很多設(shè)備的IMEI、Mac地址、AndroidID 都有可能為空或者錯(cuò)誤，所以不能單獨(dú)作為唯一標(biāo)識(shí)，需要將這些進(jìn)行組合起來使用。
對(duì)于應(yīng)用卸載后RegistrationID的問題，很多PushSDK的策略是，生成一個(gè)DeviceID保存到本地存儲(chǔ)，應(yīng)用被卸載后如果被重新安裝，如果檢測(cè)到存儲(chǔ)里的DeviceID還在的話，就判定是同一個(gè)設(shè)備，不重新生成RegistrationID。
AppKey\AppID
這些Key基本都是用于驗(yàn)證App的，每個(gè)包名對(duì)應(yīng)一個(gè)加密的Key。
透?jìng)鱘非透?jìng)?/h3>
非透?jìng)飨⑹侵竿扑拖⒈籔ushSDK獲取并處理，透?jìng)飨⑹侵竿扑拖⒈籔ushSDK交給宿主應(yīng)用處理，非透?jìng)飨⑼ǔＶ荒茉O(shè)置一些固定的樣式，比較簡(jiǎn)單，而透?jìng)飨?，可以由App自定義處理，比較靈活。
推送數(shù)據(jù)基礎(chǔ)
累計(jì)注冊(cè)
通過應(yīng)用使用的appid統(tǒng)計(jì)用戶注冊(cè)總量。
日在線用戶
通過應(yīng)用使用的appid統(tǒng)計(jì)當(dāng)天的在線用戶數(shù)。
活躍用戶
通過應(yīng)用使用的appid統(tǒng)計(jì)當(dāng)天在推送平臺(tái)激活過的用戶總數(shù)。
在線下發(fā)率
在線消息下發(fā)數(shù)/總下發(fā)數(shù)。
回執(zhí)率
消息回執(zhí)數(shù)（去重）/消息在線下發(fā)數(shù)。
到達(dá)率
到達(dá)數(shù)/實(shí)際下發(fā)數(shù)。
百日內(nèi)聯(lián)網(wǎng)用戶數(shù)（可推送用戶數(shù)）
是指最近三個(gè)月內(nèi)有登錄過（設(shè)備與推送服務(wù)端建立長(zhǎng)鏈接）的設(shè)備總數(shù)，即有效可下發(fā)的用戶數(shù)。一般的推送服務(wù)端認(rèn)為，設(shè)備在100天內(nèi)沒有登錄請(qǐng)求，認(rèn)為該設(shè)備已經(jīng)失效，所以無需再次發(fā)送。
實(shí)際下發(fā)數(shù)
實(shí)際可推送設(shè)備數(shù)（在消息有效期內(nèi)，有聯(lián)網(wǎng)并推送進(jìn)程正常的設(shè)備，即消息有效期內(nèi)的在線下發(fā)數(shù)。消息有效期就是設(shè)置的離線時(shí)間）。
到達(dá)數(shù)
客戶端SDK接收到消息的設(shè)備數(shù)（通過統(tǒng)計(jì)客戶端SDK接收到消息后的回執(zhí)獲得）。
展示數(shù)
用自定義非透?jìng)飨⒃谟脩羰謾C(jī)展示過的設(shè)備數(shù)。
點(diǎn)擊數(shù)
點(diǎn)擊通知欄消息的設(shè)備數(shù)。
推送數(shù)據(jù)分析
那么關(guān)于推送，大家實(shí)際上最關(guān)系的，就是『到達(dá)率』。那么這個(gè)到達(dá)率究竟怎么計(jì)算呢？
首先我們舉個(gè)例子來說明上面的這些數(shù)據(jù)背后的實(shí)際意義，例如，我們有一款A(yù)pp，有100w的下載量，每個(gè)App啟動(dòng)后，都將上報(bào)給服務(wù)器一個(gè)唯一ID，所以，累計(jì)注冊(cè)量就是100w，也稱發(fā)送總量。
那么在服務(wù)端準(zhǔn)備發(fā)送推送的時(shí)候，當(dāng)前手機(jī)端推送進(jìn)程還活著的，也就是說推送的長(zhǎng)連接還健在的，就是在線設(shè)備，如果按天算，那么就叫日在線設(shè)備數(shù)，我們假設(shè)這個(gè)數(shù)字是60w。
OK，推送發(fā)出去后，客戶端收到推送消息，并產(chǎn)生回執(zhí)，代表完成了一次推送，假設(shè)這些完成推送的設(shè)備是55w，這個(gè)就是送達(dá)設(shè)備數(shù)。一般來說，只要設(shè)備在線，基本都能送達(dá)，所以這個(gè)數(shù)字和在線設(shè)備數(shù)非常接近，不接近的話，這個(gè)推送基本就有問題了，其中可能送不達(dá)的原因就在于網(wǎng)絡(luò)切換等導(dǎo)致長(zhǎng)連接斷掉這類因素。
那么到這里，一般的推送服務(wù)商會(huì)使用送達(dá)設(shè)備數(shù)/在線設(shè)備數(shù)的方式來計(jì)算到達(dá)率，當(dāng)然，前面我們也說了，這個(gè)比例一定是很高的，如果保持長(zhǎng)連接的設(shè)備都不能收到推送，那一定是有問題了。
而一般的到達(dá)率，應(yīng)該是送達(dá)設(shè)備數(shù)/可送達(dá)設(shè)備數(shù)，也就是百日內(nèi)活躍的設(shè)備數(shù)，這樣一除，這個(gè)比例一下子就小了很多，因?yàn)檎l也不知道，這一百天內(nèi)曾經(jīng)活躍的用戶，第二天是不是就已經(jīng)把你卸載了。所以說，Android下統(tǒng)計(jì)推送的到達(dá)率一般都很低，而推送服務(wù)商宣傳的到達(dá)率都很高，這其實(shí)就是一個(gè)偷換概念的問題，我們說的是一般的到達(dá)率，而服務(wù)商宣傳的是在線到達(dá)率。
而且，這個(gè)到達(dá)率與iOS完全沒有可比性，因?yàn)閕OS統(tǒng)一通過APNs來進(jìn)行推送，且無法獲取到達(dá)回執(zhí)，所以，iOS基本不存在到達(dá)率這一說法，如果有，幾乎也是100%，完全沒有意義，所以，如果哪一天有產(chǎn)品或者運(yùn)營(yíng)跟你說，為什么Android的到達(dá)率比iOS的到達(dá)率差這么多，請(qǐng)毫不客氣的砸它一斤蘋果。
Tag\Alias
Tag
Tag，或者叫標(biāo)簽，是用戶的一種屬性，在給某些用戶設(shè)置某類標(biāo)簽后就可以針對(duì)推送。比如給喜歡『編程』的人打上『編程』的標(biāo)簽，就可以只給他們精準(zhǔn)推送。
通常情況下，一個(gè)設(shè)備（在一個(gè)App里）可以設(shè)置多個(gè)標(biāo)簽。標(biāo)簽與別名類似，其對(duì)應(yīng)關(guān)系也是保存在推送服務(wù)器側(cè)的。
Alias
Alias，或者叫別名，是對(duì)已經(jīng)安裝某應(yīng)用的用戶取個(gè)別名進(jìn)行標(biāo)識(shí)，在對(duì)該用戶消息推送時(shí)，就可以用此別名來進(jìn)行推送。設(shè)置了別名后，推送時(shí)服務(wù)器端指定別名即可。推送服務(wù)器端來把別名轉(zhuǎn)化到設(shè)備ID來找到設(shè)備。
Tag和Alias他們的共同點(diǎn)在于，提供對(duì)用戶的精確推送。
推送原理
目前大部分的第三方推送服務(wù)，都是基于長(zhǎng)連接的推送方案，下面將對(duì)這個(gè)方式進(jìn)行詳細(xì)講解。
NAT
首先，我們需要了解下一個(gè)網(wǎng)絡(luò)基本知識(shí)——NAT，即網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT），這是因?yàn)镮P地址是有限的，手機(jī)無論是通過路由器還是數(shù)據(jù)網(wǎng)絡(luò)，都有一個(gè)內(nèi)網(wǎng)IP地址，同時(shí)，路由器上會(huì)維護(hù)一個(gè)外網(wǎng)IP地址，從而形成一個(gè)NAT路由表，即內(nèi)網(wǎng)IP地址:端口，以及對(duì)應(yīng)的外網(wǎng)IP地址:端口。這樣通過一層層封裝與解封裝，就達(dá)到了內(nèi)網(wǎng)與外網(wǎng)交換通信的方式。
NAT超時(shí)
由于NAT路由表的大小有效，所以一般路由都有NAT有效期，WIFI下，這個(gè)NAT有效期可能會(huì)比較長(zhǎng)，而在數(shù)據(jù)流量下，運(yùn)營(yíng)商一般都會(huì)盡快更新NAT路由表，淘汰無效的設(shè)備，所以，在使用數(shù)據(jù)流量時(shí)，長(zhǎng)連接經(jīng)常容易斷。
那么除了NAT路由表主動(dòng)淘汰過期的設(shè)備之外，切換網(wǎng)絡(luò)環(huán)境和DHCP服務(wù)器租期到期，這些情況都有可能導(dǎo)致NAT路由表改變，從而造成長(zhǎng)連接中斷。
心跳包
前面我們說了，現(xiàn)在的推送服務(wù)一般采用的是長(zhǎng)連接的通信方式，而長(zhǎng)連接會(huì)因?yàn)镹AT路由表的更新而中斷，所以，客戶端會(huì)定時(shí)向服務(wù)端發(fā)送一個(gè)心跳包，來定期告知NAT路由表，我還活著，別殺我！這就是心跳包的作用——防止NAT路由表超時(shí)，同時(shí)檢測(cè)連接是否被斷開。
心跳包的心跳時(shí)間
既然心跳包的作用是防止NAT超時(shí)，那么就需要將心跳包的發(fā)送頻率設(shè)置為小余NAT超時(shí)的檢測(cè)頻率，而WIFI和數(shù)據(jù)流量下，對(duì)于NAT路由表的超時(shí)時(shí)間又是不一樣的，而且不同的網(wǎng)絡(luò)運(yùn)營(yíng)商的超時(shí)時(shí)間，甚至都不一樣，所以，一個(gè)比較好的方法就是根據(jù)設(shè)備當(dāng)前網(wǎng)絡(luò)環(huán)境，來動(dòng)態(tài)的設(shè)置心跳時(shí)間。
注意，心跳包與輪詢是不一樣的，心跳包建立在長(zhǎng)連接上，只要發(fā)送數(shù)據(jù)即可，而輪詢每次都是一個(gè)完整的TCP連接。
心跳包誰來發(fā)
既然需要定時(shí)任務(wù)，那么就需要使用AlarmManager來作定時(shí)喚醒了，原因我之前的文章有講過，是關(guān)于處理器喚醒的原因，這里就不贅述了，大家可以參考我之前的文章：
進(jìn)程?；?/h3>
所謂進(jìn)程保活，是指App希望盡可能的保證自己的App的推送進(jìn)程能夠存活在后臺(tái)，以保證可以收到服務(wù)端的推送消息，因此，才出現(xiàn)了一大批關(guān)于進(jìn)程?；畹姆绞?，例如NDK層的文件鎖，fork子進(jìn)程、前臺(tái)服務(wù)、進(jìn)程優(yōu)先級(jí)等等方式，然而，這些東西，實(shí)際上，都不能完全保證手機(jī)的進(jìn)程管理策略放過你，特別是Android 5.0以后的系統(tǒng)，Android對(duì)進(jìn)程的管理更加嚴(yán)格，還有國(guó)內(nèi)的這些ROM層的修改，ROM想要?dú)⒛氵@個(gè)進(jìn)程，你怎么做也沒有辦法，哦，除了白名單。所以，不要再花心思去找什么進(jìn)程?；畹暮诳萍剂?，好好做好應(yīng)用，提供用戶的使用黏性，才是最佳的?；?，而對(duì)于一些產(chǎn)品、運(yùn)營(yíng)所謂的『為什么微信、QQ都可以?；睢贿@樣的問題，我建議你回答它：『如果你能把產(chǎn)品做到微信、QQ那樣的數(shù)量級(jí)，我也能讓你活！』
推送整合方案
介于各種第三方推送與ROM推送的特點(diǎn)，我們目前采用的推送方案，名為『UniversalPushSDK』，即整合了多個(gè)不同的推送渠道，通過模板設(shè)計(jì)模式來進(jìn)行整合，并向外暴露統(tǒng)一的接口，這種方式的好處在于UniversalPushSDK利用的各個(gè)不同推送特點(diǎn)，提高推送到達(dá)率，但是壞處在于，包的體積會(huì)大一些。例如，我們現(xiàn)在整合了『小米推送、極光推送、華為推送』，在系統(tǒng)啟動(dòng)的時(shí)候，判斷當(dāng)前系統(tǒng)，如果是小米系統(tǒng)，則啟用『小米推送』，如果是華為手機(jī)，則啟用『華為推送』，其它的Android設(shè)備，則啟用『極光推送』，通過這種方式來設(shè)計(jì)我們自己的推送SDK，可以在一定程度上，利用好各個(gè)推送平臺(tái)的特性。
那么如果利用這種方式來設(shè)計(jì)SDK給到不同的App接入，就需要能夠?qū)?yīng)用的推送Key做到動(dòng)態(tài)配置，這也是我們遇到的最大的一個(gè)問題，解決方法大家可以參考我之前寫的一篇文章：
http://blog.csdn.net/eclipsexys/article/details/51283232
雖然我極力反對(duì)這種方案，我堅(jiān)持認(rèn)為，做好App，提升用戶使用黏性，才是提升推送到達(dá)率的關(guān)鍵
