? ? ? 相信大家對推送這項技術并不陌生。如果沒聽說過，那么作為一個充滿好奇心的孩子，你一定想過這個問題：睡覺前我明明關閉了淘寶、網(wǎng)易新聞等app，為什么第二天他們又自動出現(xiàn)在我手機的通知欄上呢？這其實就是推送系統(tǒng)干的好事：在你睡覺的時候，服務器悄悄的向你的手機推送了一個消息，然后喚醒了你已經(jīng)關閉的app。事實上，無論你愿意與否，現(xiàn)在大多數(shù)‘有節(jié)操’的app，都已經(jīng)內(nèi)置了推送系統(tǒng)，并時刻準備著登上你的通知欄的‘頭條’。

? ? ? 傳統(tǒng)的app架構里，通常是app主動向服務器請求數(shù)據(jù)，服務器被動的提供數(shù)據(jù)。以新聞客戶端app為例：app被用戶打開的時候，會通過網(wǎng)絡(無論3g、4g還是wifi)連接到服務器上，向服務器請求最新的新聞。服務器收到請求，從自己的數(shù)據(jù)庫里查詢最新的新聞，返回給app。app收到服務器返回的數(shù)據(jù)，經(jīng)過一系列的解析處理操作，最終把最新的新聞呈現(xiàn)給用戶。一次通信就完成了。然而如果此時服務器上又有了新的新聞，無論多么重要，在用戶沒有主動刷新的情況下，是沒有辦法讓用戶看到的。推送就是為了解決這樣的困境的，它給了服務器一個展示自我的機會，主動連接上所有的app，告訴他們我有新的新聞了，你們再來請求一次吧，于是收到推送的app（即時此時已經(jīng)被用戶關閉了）又去服務器請求最新的新聞，這樣用戶就能看到最新的新聞了。

? ? ? 從技術上來講，實現(xiàn)一個推送系統(tǒng)需要服務器端和終端的配合。一種方法是輪詢，也就是不停的向服務器發(fā)起請求。這其實很好理解，作為app，我既然不知道什么時候會發(fā)生新的新聞，那我一遍一遍的問好了，而且我知道這樣一定會成功的。顯而易見，這種方法app端費時費力不說，電量流量也扛不住啊，服務器要處理如此量大的請求，必然也是非常頭疼的。另一種方法是服務器和app建立一個長時間連接的通道，通過這個通道，不僅app可以向服務器請求數(shù)據(jù)，服務器也可以向app發(fā)送數(shù)據(jù)，看起來非常完美，但是如果app被用戶關閉的話，通道就斷掉了。好在android系統(tǒng)給app提供了一個這樣的環(huán)境，app可以啟動一個后臺服務來維持這個通道，即使app被關掉了，服務依然可以運行，通道依然還在工作（ios后面會講）?；氐角懊娴睦樱阍谒X前關掉了淘寶，但是并沒有關閉淘寶的后臺服務，淘寶依然可以接收服務器推送來的指令，把自己的喚醒。

? ? ? 那么如何維持這樣的一條長時間連接的通道呢？就好比兩個人打電話，一開始聊的熱情有來有往，后來慢慢沉默下來了，幾分鐘之后，電話的另一頭沒有任何動靜，如何知道那邊的人還在呢？很簡單，只需要另一頭的人每隔幾分鐘說一個字就行。同樣的道理，app會每隔一段時間向服務器報告自己還活著，就像心跳一樣，服務器收到后，就知道這個通道是可以繼續(xù)使用的了。然而天下沒有免費的午餐，發(fā)送心跳是有代價的，一般手機鎖屏之后，為了省電CPU是出于休眠狀態(tài)的，然而發(fā)送心跳就會喚醒CPU，必然會增加電量的消耗。這還只是一個長連接通道的情況，如果手機里裝了2、30個帶有推送的app呢？先別急著抱怨，聰明的android工程師和ios工程師早就想到了這一點，他們分別設計了GCM和apns來解決多個app有多個長連接通道的問題。以apns為例，ios開通了一條系統(tǒng)級別的長連接通道，通道的一端是手機的所有app，另一端是蘋果的服務器。app的服務器如果有新的消息需要推送的話，先把消息發(fā)送到蘋果的服務器上，再利用蘋果的服務器通過長連接通道發(fā)送到用戶手機，然后通知具體的app。這樣就做到了即使手機安裝了100個app，也只需要向一條通道里發(fā)送心跳。

? ? ? 回到Android，系統(tǒng)提供的GCM只能在Android2.2以上才能使用，3.0以下必須要安裝Googleplay并登陸了Google賬號才能支持。而國內(nèi)發(fā)行的手機大多是閹割掉了google 服務的。因此，對于Android系統(tǒng)來說，各家app只能各顯神通，開發(fā)自己的專用長連接通道了。然而這時候他們遇到了app的天敵：管家和衛(wèi)士們。前文說了，app想要及時收到服務器推送的消息，關鍵在于自己與服務器的長連接通道不被關閉，也就是自己的后臺服務可以一直在后臺運行，而管家和衛(wèi)士們的一鍵清理功能就是專治這種“毒瘤”的。道高一尺魔高一丈，app在與管家和斗士們的長期斗爭中，總結了一系列躲避被清理掉的方法，什么定時自啟能力、什么相互喚醒、什么前臺進程等等，當然這就是另一個話題了,我們后面會講到。

? ? ?總結起來，app和后臺的連接方式有兩種。一種叫pull，也叫輪詢，就是定期的不斷向后臺請求，缺點是耗電，費流量，不環(huán)保。對于一名有追求的程序員，他應該會比較惡心這種方式的，你千萬不要對他說，我不管你怎么實現(xiàn)，我就要這種效果這種傻逼話了，凡事應該找到最優(yōu)路徑。另一種叫push，app和后臺一直維持了一條通信通道，兩端不定期的就會偷摸的約會，告訴對方“I‘m Here”，也能順帶把信息互相攜帶了。缺點是要維持一條長連接通道，這條通道容易被其他程序殺死，要多想復活辦法。