推送並非什麼新技術，這種技術在互聯網時代就已經很流行了。只是隨着進入移動互聯網時代，推送技術顯得更加劇要。由於在智能手機中，推送從某種程度上，能夠取代使用多年的短信，並且與短信相比，還能夠向用戶展現更多的信息（如圖像、表格、聲音等）。服務器
推送技術的實現一般會使用服務端向客戶端推送消息的方式。也就是說客戶端經過用戶名、Key等ID註冊到服務端後，在服務端就能夠將消息向全部活動的客戶端發送。網絡
實際上，在不少移動操做系統中，官方都爲其提供了推送方案，例如，Google的雲推送、IOS、Windows Phone7/8也都提供了相似的推送方案。不過這些推送方案的服務器都在國外，有一些推送服務（如Google的雲推送）在國內因爲某些緣由不太穩定，因此國內近幾年涌現出了不少專門爲國人打造的推送服務。ide
本文將從各類流行移動操做系統入手介紹推送技術的各類實現方式。固然，咱們的主要目的是討論Android的推送技術。性能
1、iOS的推送技術spa
Apple爲IOS提供了很完美的推送方案，其基本原理是Apple提供了本身的推送服務器，叫APNS（Apple Push Notification Service，蘋果推送通知服務器）。而客戶端設備（IPhone、IPad等）直接與APNS創建長鏈接。不過向客戶端設備發送的消息並非由APNS產生的，而是在須要發送消息的用戶本身提供的服務器（稱爲Provider）中產生的，而後Provider將消息傳送給APNS，最後由APNS將消息傳送給客戶端設備。也就是說，消息最開始由Provider產生，而後Provider將消息傳送給APNS，最後再由APNS傳送給客戶端設備。消息傳遞的過程如圖1所示。操作系統
圖1
.net
在發送消息到客戶端設備接收到消息的過程當中，始終伴隨這一個令牌的傳送（device token）。要想使用APNS提供消息服務，應用程序須要先向IOS註冊須要提供的一個必要的信息就是與當前設備有關的device token，IOS在接收到devicetoken後，會向APNS查詢這個device token是否在APNS上註冊了（全部的IOS設備在第一次使用時都須要向蘋果服務器註冊一個帳號，不然沒法從AppleStore下載應用，固然更沒法使用推送服務了），若是已經註冊，APNS會直接嚮應用程序返回這個devicetoken。應用程序得到這個devicetoken後，表示APNS已經容許向本身推送消息了，接着還須要將該device token發送給推送服務器（Provider）。到這裏應用程序已經成功將本身註冊到APNS中了。如今就能夠經過Provider產生要推送的消息，而後Provider會將消息發送給APNS服務器，最後APNS服務器會直接嚮應用程序發送消息。這個過程比較複雜，不過看一下圖2的描述就會對這一過程更加了解了。每個流程描述前面的數字表示發送的時間前後順序。orm
圖2blog
2、Windows Phone的推送技術token
微軟爲Window Phone提供的推送方案與IOS相似，也須要本身準備推送服務器（能夠稱爲Cloud Service）。只是表示設備的ID變成了Uri。在Window Phone中有一個Push Client Service（PCS）。全部須要推送服務的應用程序都須要與Push Client Service通訊。下面是Window Phone推送的基本步驟，讀者能夠與圖3對照來看這一過程。
第1步：應用程序會向Push Client Service請求一個Push Notification URI（①）。
第2步：若是當前Window Phone設備已經在微軟服務器註冊了，Push Client Service會從MPNS（Microsoft Push Notification Service ，微軟推送通知服務）獲取Push Notification URI，並返回給應用程序，表示推送服務可用（②和③）。
第3步：應用程序須要將Push Notification URI發送給本身的推送服務器（Cloud Service）（④）。
第4步：若是須要推送消息，Cloud Service會將消息發送到MPNS，而後MPNS會將消息發送給Push Client Service，最後由Push Client Service將消息傳送給應用程序（⑤、⑥和③）。
圖3
3、Android的推送方案
Android的推送方案就比較多了，也比較亂。例如，有Google官方提供的C2DM（Android Cloud to Device Messaging）；第三方的推送服務（如極光推送）；還有經過各類協議實現的推送服務端程序（如AndroidPN），用戶經過這些服務端程序能夠搭建本身的推送服務器。這些推送技術會在本節後面的部分詳細介紹，本節先來介紹一下Android中常用的各類推送技術。固然，這些推送技術也能用於其它的移動設備，但因爲Android的官方推送服務（C2DM）在國內使用上有一些問題，因此基於Android的第三方推送服務較其它系統多，所以這裏主要針對Android來介紹。
一般推送技術會使用以下兩種方式實現。
1. 輪詢（Pull）方式
2. 持久鏈接方式（服務端Push方式）
輪詢方式就是客戶端以必定的時間間隔不斷查詢服務端是否有新的消息。這種方式必須本身實現與服務器之間的通訊機制，例如消息隊列等。並且還要考慮輪詢的頻率，若是太慢可能致使某些消息的延遲，若是太快，則會大量消耗網絡帶寬和電池。因此大多數推送服務都不會使用輪詢方式。
持久鏈接方式也就是Push方式，對於客戶端來講，是一種被動的方式，而主動權在服務端，當有消息時，服務端會向全部註冊到推送服務器的客戶端推送消息。這種推送方式的好處是能夠保證明時性，並且客戶端實現簡單。固然，也會有不足，例如，若是大量的客戶端與服務端保持長鏈接時，會消耗服務器的資源。不過在未推送消息時，這些長鏈接就成了空閒鏈接，一般這種鏈接主要消耗的是內存資源。例如，200萬用戶可能會消耗數十GB的內存。所以搭建這種推送機制時要使用性能好的服務器。
持久鏈接的實現有不少方式，例如，可使用XMPP做爲通訊協議。XMPP的主要優點是協議成熟、強大，可擴展性強。XMPP更多地用於IM系統中，後面要介紹的AndroidPN也是用了XMPP協議。
XMPP也有明顯的缺點，例如，協議很複雜，若是吃透XMPP協議可能須要很長時間，還有就是因爲XMPP是基於XML的，從而形成了數據冗餘、這樣會形成移動設備費流量、耗電等弊病。
除了XMPP，還可使用MQTT協議，這種協議的主要優點是簡潔、小巧、可擴展性強，從而帶來了省流量、省電等優勢，並且有C++版的服務端組件rsmb。缺點是協議不夠成熟，並且實現較複雜，並且rsmb不開源，部署硬件的成本較高。
儘管C2DM服務在國內可能不太穩定或有一些地區不可用，但仍是有必要介紹一下C2DM的原理。不過對於在國內使用的應用最好使用第三方的推送服務，或本身假設推送服務器。
C2DM和IOS的APNS以及Window Phone的MPNS大同小異。還須要本身準備一臺推送服務器，並經過以下步驟實現消息的推送。
第1步：移動設備上的C2DM服務須要與Google官方的C2DM服務器交互，驗證當前設備是否在C2DM服務器上註冊了，若是已經註冊，C2DM服務器會返回一個註冊ID給客戶端的C2DM服務。（①和②）
第2步：客戶端的C2DM服務會與本身的推送服務器交互，將帳號和C2DM服務器返回的註冊ID傳給推送服務器。（③）
第3步：若是要推送消息，推送服務器會將註冊ID和要推送的消息先發送到C2DM服務器，而後C2DM服務器會直接將消息推送給客戶端（手機、平板電腦的設備）（④和⑤）。
讀者能夠對照圖4來理解這3個步驟。
圖4
除了使用官方的推送方案外，如今國內涌現出多個第三方的推送方案，例如，極光推送（JPush）、百度推送等。讀者也能夠用一下，這些同時一般是免費的（可能推送多媒體數據須要收費）。
