相信大家在使用iPhone版微信的時候都會有這樣的經歷,微信已經處于關閉狀態(tài)了(后臺進程運行一段時間就被系統(tǒng)殺掉),這時候我們收到了一個消息提醒,打開微信應用,微信顯示“連接中…”和“收取中…”,然后再次顯示一次剛才系統(tǒng)推送給我的消息通知。對這個現(xiàn)象比較好奇,于是去知乎上查一下資料,發(fā)現(xiàn)知乎上的熱心人還真多,看了大家的回答之后,總結如下: [之所以去知乎查看技術問題,因為我并非技術人員,而知乎上很多開發(fā)人員是會用通俗易懂的方式解釋好技術問題的,因為里面有不少大牛。] 先介紹一下兩個重要的消息推送服務: iOS 的推送:Apple 官方的 APNs (Apple Push Notification service)。 其實兩個推送服務的機制是比較接近的,以蘋果為例,用一個圖示表示如下: 采用 APNs 或者 GCM 進行消息推送,消息都會經由蘋果或者谷歌的服務器,然后再到用戶設備上,這樣做的好處主要有以下幾點: 1)省電 這個是最直觀的體驗。由于這兩套推送機制都是用戶設備和蘋果或谷歌的服務器保持一個長連接,而這個長連接是幾乎不會耗損多少電量的,采用統(tǒng)一的連接來接收手機上所有應用的通知消息,耗電量少是顯而易見的。 由于蘋果采用封閉的策略,因此所有第三方應用都必須采取這種推送方式,因此iPhone設備即使電池電量比Android少也更耐用。但由于國內眾所周知的原因,Google 服務的穩(wěn)定性大受考驗,而且 Google 對第三方應用推行 GCM 方式并不是強制性的,因此國內的應用開發(fā)者幾乎都單獨在后臺常駐一個進程,來專門處理消息推送。 2)開發(fā)簡單 這個是對應用開發(fā)者來說的,一般不使用上述的 APNs 或者 GCM 推送機制,就需要自己搭建一條推送服務,可以采用別人開發(fā)的成熟協(xié)議,或者自己單獨開發(fā)(如騰訊),這對于開發(fā)者來說還是有門檻的。 3)利于統(tǒng)一管理 采用統(tǒng)一的方式來處理就使得系統(tǒng)可以更高效,不會出現(xiàn)多應用同時處理消息卡頓的情況。 當然壞處的話,一個就是穩(wěn)定性和實效性依賴于蘋果或者谷歌的消息服務器,當然這種機制目前正常情況下都能做到5s以內的延遲。如果是第三方應用單獨放置一個常駐進程處理,延遲一般在1s內,可以忽略不計。 以上就是兩種常見的消息推送機制。但還有一個情況沒有解釋,為什么我們打開iPhone應用(如微信),應用還要再次和第三方服務器連接一次,再取回一次消息? 這個可以解釋為,當應用處于后臺關閉狀態(tài)時,由iOS系統(tǒng)推送一個消息通知給我們。當我們打開應用后,我們的設備就直接和第三方應用的消息服務器通信了,不需要再經由蘋果消息服務器傳遞。 但為了保證消息傳遞的完整性,剛才系統(tǒng)推送的消息并沒有在應用里面顯示,所以應用再與第三方服務器建立連接后,再重新把剛才那條消息取回來,這就造成了系統(tǒng)通知一次消息,應用打開后再顯示一次消息。當然這種做法可能在使用體驗上有些許瑕疵(也許強迫癥患者會這么認為吧),但消息的完整性是必須要保證的。 蘋果設備統(tǒng)一采用 APNs 推送機制,至少很省電,而安卓設備幾乎每個應用都單獨設置一個常駐進程來收發(fā)消息,造成的情況是,安卓設備將會非常耗電(即使你不使用,后臺卻同時開著那么多進程),一方面是由于谷歌服務不穩(wěn)定造成的,但更重要的是,國內開發(fā)者都是自私的,只管自己的應用功能正常,而不會顧用戶的手機電池會不會耐用。蘋果的推送機制別無選擇,但安卓系統(tǒng)在國內是存在穩(wěn)定的推送服務提供商的,一旦采用也能達到iOS設備的效果,但幾乎很少開發(fā)者會采用。 另外要穿插一個小插曲就是,微信曾經出現(xiàn)過大范圍的宕機情況,消息收發(fā)出現(xiàn)嚴重延遲,實際上是網絡服務提供方(如移動、聯(lián)通、電信)在網絡上搗鬼,導致消息傳遞出現(xiàn)大范圍延遲。身處國內,即使強大如騰訊,也要對三大運營商忌憚三分??!當時明明對運營商暗中使壞切齒痛恨,但仍然咬牙向外部宣稱“這是由我們的技術故障造成的……”,當時好像還找了個特別無厘頭的解釋——施工被挖斷光纜。好吧,QQ都活了15年,容災備份機制會沒有,怎么可能出現(xiàn)那么嚴重的事故呢?!
原文地址:http:///20140221/789 |
|