上篇文章介紹了iOS 遠(yuǎn)程推送的相關(guān)知識(shí)诺擅，這次來(lái)講講Android 的遠(yuǎn)程推送。
Android 遠(yuǎn)程推送幾種常用的實(shí)現(xiàn)方法
- 輪詢(Pull)：APP 定時(shí)向服務(wù)器發(fā)出請(qǐng)求看是否有新的推送消息
- SMS(Push)：通過(guò)攔截SMS消息獲得推送消息
- 持久連接(Push)：Android 設(shè)備和服務(wù)器建立持久連接，服務(wù)器把消息推送到設(shè)備
輪詢
這個(gè)方式不足的地方還是挺多的，概括有以下幾點(diǎn)：
- 定時(shí)請(qǐng)求，對(duì)性能和電量耗費(fèi)比較大
- 請(qǐng)求的頻率编检，頻率太低可能導(dǎo)致某些消息的延遲，如果太高扰才，則會(huì)大量消耗流量和電量
- 必須自己實(shí)現(xiàn)與服務(wù)器之間的通信允懂，例如消息排隊(duì)等
輪詢最主要就是定時(shí)請(qǐng)求，一般就是啟動(dòng)一個(gè)系統(tǒng)進(jìn)程執(zhí)行定時(shí)器隔一段時(shí)間向服務(wù)器發(fā)送請(qǐng)求衩匣，想想如果每一個(gè)APP 都這么干的話蕾总，對(duì)性能和電量耗費(fèi)還是比較大的。而且當(dāng)內(nèi)存不足時(shí)琅捏，Android 操作系統(tǒng)會(huì)殺掉部分系統(tǒng)服務(wù)生百，所以很難保證自己的定時(shí)系統(tǒng)進(jìn)程不被殺死，所以這也是需要考慮的問(wèn)題柄延。
使用 AlarmManager 對(duì)輪詢進(jìn)行優(yōu)化
AlarmManager 是 Android 系統(tǒng)封裝的用于管理 RTC 的模塊蚀浆，RTC (Real Time Clock) 是一個(gè)獨(dú)立的硬件時(shí)鐘，可以在 CPU 休眠時(shí)正常運(yùn)行搜吧，在預(yù)設(shè)的時(shí)間到達(dá)時(shí)市俊，通過(guò)中斷喚醒 CPU。我們可以為自己的APP 設(shè)定一個(gè)在未來(lái)某個(gè)時(shí)間喚醒的功能滤奈，當(dāng)鬧鐘響起秕衙，實(shí)際上是系統(tǒng)發(fā)出了為這個(gè)鬧鐘注冊(cè)的廣播，會(huì)自動(dòng)開(kāi)啟目標(biāo) APP僵刮。這意味著据忘，如果我們用 AlarmManager 來(lái)定時(shí)執(zhí)行任務(wù)，CPU 可以正常的休眠搞糕，只有在需要運(yùn)行任務(wù)時(shí)醒來(lái)一段很短的時(shí)間勇吊，執(zhí)行一下我們的請(qǐng)求，然后就可以繼續(xù)休眠了窍仰，從而大大降低了性能和電量的消耗汉规。
SMS
通過(guò)截取SMS 內(nèi)容達(dá)到遠(yuǎn)程推送提醒的目的，因?yàn)镾MS 是實(shí)時(shí)的驹吮，所以這個(gè)方法從時(shí)效性上來(lái)說(shuō)是很好的针史。但是！看到SMS 碟狞，腦海中第一反應(yīng)就是錢(qián)啄枕！然后就是移動(dòng)、聯(lián)通族沃、電信這些運(yùn)營(yíng)商了频祝，畢竟國(guó)內(nèi)想使用免費(fèi)的SMS 不是一件容易的事，所以這個(gè)方法也不是很好脆淹。
持久連接
這個(gè)和iOS 的遠(yuǎn)程推送比較像常空，不過(guò)iOS 是每臺(tái)設(shè)備和APNs 之間只有一個(gè)可靠的長(zhǎng)連接，所有的APP 共同使用盖溺，所以性能上消耗并不是很大漓糙，這點(diǎn)蘋(píng)果做的確實(shí)不錯(cuò)。其實(shí)Google 自家也有類(lèi)似的服務(wù) C2DM烘嘱，不過(guò)國(guó)內(nèi)的情況大家都懂昆禽，所以知道有這么個(gè)事就可以了。
Android 中的持久連接基本都是使用開(kāi)源的 androidpn 實(shí)現(xiàn)的拙友。androidpn 是一個(gè)基于XMPP協(xié)議的java開(kāi)源Android push notification實(shí)現(xiàn)为狸，它本質(zhì)上服務(wù)器端基于 Openfire，客戶端基于 asmack遗契，這二者都最 XMPP IM 開(kāi)源實(shí)現(xiàn)里的二個(gè)基本組件辐棒，應(yīng)該說(shuō) androidpn 只是把二者更多地結(jié)合起來(lái)用于做 Push的場(chǎng)景。XMPP牍蜂、IM 這些大家都知道更多的是用在即時(shí)通信方面的漾根，XMPP 的協(xié)議都是在xml 上實(shí)現(xiàn)的，xml 相對(duì)于客戶端二進(jìn)制流和JSON 來(lái)說(shuō)有點(diǎn)臃腫鲫竞、靈活性比較差辐怕，這樣會(huì)導(dǎo)致客戶端的耗費(fèi)更多的流量和電量，這個(gè)肯定是用戶不愿意看到的从绘。另外就是單機(jī)并發(fā)很有限寄疏，集群方案不成熟是牢，代碼古老而缺乏及時(shí)更新。
總結(jié)一下以 androidpn 為典型的開(kāi)源 Android Push 方案會(huì)存在的問(wèn)題：
- 容量大了開(kāi)源服務(wù)器實(shí)現(xiàn)頂不住陕截，還是需要自己去改進(jìn)開(kāi)源實(shí)現(xiàn)驳棱，或者完全重新用新方案，開(kāi)發(fā)投入與高成本是不可避免的农曲。
- 協(xié)議與實(shí)現(xiàn)上如流量消耗社搅、網(wǎng)絡(luò)連接策略等，不是專門(mén)為移動(dòng) Push 優(yōu)化過(guò)的乳规，是不經(jīng)濟(jì)的形葬。
其他的選擇：第三方推送
目前第三方的推送比較成熟了，極光暮的、百度云推送笙以、個(gè)推等等。如果不是特別的需求青扔，使用第三方推送服務(wù)是一個(gè)比較好的選擇源织，可以省去很多功夫。
