Android 推送技術解析

Android 推送技術解析

 

　　當今信息爆炸的時代，人們對於充斥在身邊的各類信息幾乎有些麻木了。大量無關的信息不斷騷擾人們的神經，所以個性化、社交化的應用也是大行其道。好比一些新聞客戶端，會根據用戶的使用習慣或訂閱要求向用戶發送指定的新聞內容；再好比經常使用的一些即時通信軟件如微信、GTalk、個信等，都是能夠實時地將私密信息送到用戶的終端。這背後用到的技術就是消息的推送。
　　本文討論的消息推送特指從服務器端向移動終端設備進行特定格式信息流傳遞的過程。 與傳統服務器端到服務器端通信最大的區別就在於移動終端的不肯定性。舉個生活中的例子，服務器端比如是北京的"水立方"游泳館，聞名遐邇，有明確並且固定的地址（IP或域名），你們要遊覽（訪問）"水立方"能夠很方便的找到她。可是反過來，"水立方"要想找到某個具體的"遊客"就很難了，由於每一個"遊客"沒有肯定的地址（每次登陸網絡均可能變動IP）。
　　怎樣才能隨時找到散落各處的"遊客"呢？移動運營服務商提供了一個有效的途徑-SMS。經過移動終端的惟一標識（手機號碼），隨時隨地找到某個終端用戶。但是有兩座大山擋在了開發者面前。其一，號碼資源做爲運營商的壟斷資本不會輕易開放出來，事實上在android手機上要想繞開運營商得到手機號碼毫不容易；其二，短信內容的攔截、解析與匹配自己技術門檻較高，對於開發者來講實在不是一種合適的選擇。
　　有沒有其餘便捷的選擇呢？答案是確定的，既然服務器端找到客戶端不容易，而客戶端找到服務器端很容易，那麼就可讓消息推送的過程反轉過來。首先由客戶端來定時訪問服務器端，創建某種聯繫（一般爲http請求）。以後，服務器端就能夠輕鬆地將信息經過這種聯繫通道發給客戶端了。這就是一般說的輪詢模式。這種模式具體到移動終端設備上，卻存在致命缺陷：高頻的輪詢致使流量和電量消耗極高，低頻的輪詢又會致使消息的及時性不好。
　　有沒有更好一些的實現方式呢？的確是有的，並且蘋果已經很好地實現了這種方式-持久化鏈接。蘋果信息推送服務（Apple Push Notification Service）提供了蘋果移動終端與服務器端的長鏈接。一樣地，在android系統上也能夠實現相似蘋果APNS的推送機制。目前主流的實現協議包括：C2DM、XMPP和XQTT等。同時，一些技術公司也看準了android信息推送的廣闊市場，將這些協議進行封裝、改造，造成了各具特點的android推送解決方案。
　　國內的推送技術解決方案有個推，聽說新浪微博android上的推送也是他們作的，併發量達到5000tps（每秒鐘能夠處理5000個事務），日分發消息聽說超過1億條，消息到達率在96%以上，延時小於250ms，換句話說消息會在1/4秒內到達。同時對於消息都有詳細的報表數據，能夠用於作數據分析挖掘和用戶體驗的改善，整體來講是開發成本最低的。
　　  個推平臺有兩種接入模式：
　　    羣發模式
　　  提供羣發管理後臺，知足消息羣發需求
　　  無需設備部署，當天開通帳號，客戶端集成SDK發佈便可使用
　　    業務整合模式
　　若是但願推送與業務深度結合，還可使用其提供的業務整合模式。
　　提供服務端API接口，能夠與客戶已有業務系統深度整合
　　客戶通常通過1-2周開發改造便可實現新功能的上線
　　第三方推送接入相對最簡單，開發也比較容易。不管是從消息的到達率、集成開發成本、併發量仍是統計報表的完善程度，個推都表現的很是出色。