編輯:關於Android編程
推送並不是什麼新技術,這種技術在互聯網時代就已經很流行了。只是隨著進入移動互聯網時代,推送技術顯得更加重要。因為在智能手機中,推送從某種程度上,可以取代使用多年的短信,而且與短信相比,還可以向用戶展示更多的信息(如圖像、表格、聲音等)。
推送技術的實現通常會使用服務端向客戶端推送消息的方式。也就是說客戶端通過用戶名、Key等ID注冊到服務端後,在服務端就可以將消息向所有活動的客戶端發送。
實際上,在很多移動操作系統中,官方都為其提供了推送方案,例如,Google的雲推送、IOS、Windows Phone7/8也都提供了類似的推送方案。不過這些推送方案的服務器都在國外,有一些推送服務(如Google的雲推送)在國內由於某些原因不太穩定,所以國內近幾年湧現出了很多專門為國人打造的推送服務。
本文將從各種流行移動操作系統入手介紹推送技術的各種實現方式。當然,我們的主要目的是討論Android的推送技術。
一、iOS的推送技術
Apple為IOS提供了很完美的推送方案,其基本原理是Apple提供了自己的推送服務器,叫APNS(Apple Push Notification Service,蘋果推送通知服務器)。而客戶端設備(IPhone、IPad等)直接與APNS建立長連接。不過向客戶端設備發送的消息並不是由APNS產生的,而是在需要發送消息的用戶自己提供的服務器(稱為Provider)中產生的,然後Provider將消息傳送給APNS,最後由APNS將消息傳送給客戶端設備。也就是說,消息最開始由Provider產生,然後Provider將消息傳送給APNS,最後再由APNS傳送給客戶端設備。消息傳遞的過程如圖1所示。
在發送消息到客戶端設備接收到消息的過程中,始終伴隨這一個令牌的傳送(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的描述就會對這一過程更加了解了。每一個流程描述前面的數字表示發送的時間先後順序。
二、Windows Phone的推送技術
微軟為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將消息傳送給應用程序(⑤、⑥和③)。
三、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個步驟。
除了使用官方的推送方案外,現在國內湧現出多個第三方的推送方案,例如,極光推送(JPush)、百度推送等。讀者也可以用一下,這些同時通常是免費的(可能推送多媒體數據需要收費)。
Android 側滑菜單的實現,參考網上的代碼,實現側滑菜單。最重要的是這個動畫類UgcAnimations,如何使用動畫類來側滑的封裝FlipperLayout。&nb
Android表情功能處理方案概述1.原理和實現思路2.表情圖片顯示3.表情面板4.表情的輸入框插入和刪除5.表情添加腳本Android中表情功能,一般都不是用Image
一、前言之前介紹了Android直播視頻中一種視頻源數據采集:攝像頭Camera視頻數據采集分析中介紹了利用Camera的回調機制,獲取攝像頭的每一幀數據,然後進行二次處
本文是我的《Android音頻開發》系列的第七篇文章,上一篇文章總整體上介紹了 Android OpenSL ES API 的基本概況,告訴了大家這個框架有什麼特性,可以