標籤:開機 也會 梳理 apns ice 表達 第三方服務 www shu
文章首發於【部落格園-陳樹義】,點擊跳轉到原文《官方老爹之痛:為什麼蘋果能收到推送,而安卓不行?》
還記得上次我們做過的實驗嗎?
我們在 iOS 裝置殺掉進程後能收到推送,而 Android 裝置卻不行。這個問題可困惑了小樹很長時間,這天趁著工作清閑,又跑到小黑工位上請教了。
小黑喝了口茶便開始說,我們現在所有推送訊息都是通過第三方推送推出去的。所以瞭解一下第三方推送是如何?的非常重要。
當我們的 App 啟動的時候,同時會啟動我們App中附帶的第三方廠商的推送服務,這時候 App 進程中就有一個 Socket 長串連一直與第三方廠商的推送伺服器保持著。當我們有訊息需要推送到使用者裝置上時,我們通過調用第三方廠商的推送介面,傳入對應的別名就可以了。
小樹聽到別名感覺有點困惑,什麼是別名啊?
其實別名就是第三方廠商用來標記唯一使用者的一個標識。
當我們的 App 啟動的時候,廠商要求 App 方在合適的時候將別名和該設別的 DeviceToken 這兩個參數傳給廠商,從而建立起綁定關係。
所以從本質上來說,第三方廠商最後還是通過 DeviceToken 去識別要推送到哪個裝置的哪個 App 的。
而這個別名,一般情況下也是要能唯一標識一個使用者。所以很多時候我們都用使用者ID來作為別名,將其和 DeviceToken 綁定在一起。
小樹聽完之後 發覺可以畫一個流程圖來梳理一下整個流程了。
App啟動 -> 啟動第三方推送服務 -> 註冊別名和DeviceToken -> 等待推送訊息
畫得很不錯,非常清晰地表達了第三方推送的流程,小黑說道。
而對於後台開發小哥來說,如果要發送一條推送給使用者,只需要將別名和推送內容作為參數調用第三方廠商的介面即可。
但這貌似還沒回答之前的問題呢,為什麼 iOS 裝置在 App 進程被殺掉時能收到推送,而 Android 裝置卻不行呢?
小夥子果然窮追不捨,我這不是還沒講完嘛,別著急啊。小黑淡定地說。
我們上面說的這種情況,只在 App 進程還未被殺掉時適用。但當我們的 App 進程被殺掉時,第三方服務廠商的進程也會跟著被清除。
此時,如果我們還是通過裝置與第三方廠商建立的 Socket 長串連進行推送訊息接收,顯然是無法正常進行的。所以,安卓裝置就無法收到推送了。
而 iOS 裝置能夠在 App 進程死亡之後還接收到推送,那是因為第三方廠商在檢測到自己與 iOS 裝置的串連斷開後,自動調用蘋果官方的 APNS 服務進行訊息推送。
而 iOS 裝置的官方推送服務只要裝置開機,則是永遠存在的。所以我們的 iOS 裝置就能夠做到即使 App 進程被殺掉也能收到推送。雖然這推送推送功能很有限,但是能送達使用者總比沒送達好吧。
而 Android 裝置不能在 App 進程死亡後收到推送,那是因為其沒有官方推送的支援。
但現在也有一些情況下能夠實現 Android 裝置在 App 還未開啟的時候,也可以接收到推送。
小樹一聽到還有這麼一招,急忙問到底是什麼方式啊?
這功能能否實現,這就依賴於第三方廠商的服務是否強大了。
假設我們手機上有兩個 App,分別是「珍愛網」和「知乎」,它們都使用同一個推送廠商的推送服務。
當我們把兩個 App 都啟動,這時候進程上就會有兩個關於推送的服務進程,一個歸屬於「珍愛網」App,一個歸屬於「知乎」這個 App。
當我們把「珍愛網」App 殺掉之後,珍愛網 App 對應的推送進程也就完蛋了。但是這時候不是有 知乎 App 裡這個推送麼。有些廠商就是利用了這一點,通過某些技術手段,使用「知乎」App的推送服務去喚醒「珍愛網」App 的推送服務,從而使得 珍愛網 App 的使用者也能收到推送。
原來這還能這麼玩啊,果然是自己的服務就可以有無限的想象空間啊。小樹感慨道。如果我也能實現自己的一個推送服務就好了,這樣我們就不用依賴第三方廠商,能夠做更多定製化服務了。
自建推送服務雖然看似美好,但是開發成本和維護成本卻是非常高的。如果公司業務規模不大,還是使用第三方推送服務比較靠譜。
不過我們公司規模其實也不小了,有將近上億的使用者,每天進行業務推送的量級也達到了百萬層級。公司前陣子組織了Team Dev裡的開發精英,埋頭幹了2個月,終於搞出一個能用的推送服務了。
小樹聽到異常欣喜,覺得又有東西可以學習了。
不過今天還是不說那麼多了吧,怕你學太多吸收不了。有機會我們下次來講講如何從零開始去設計一個推送系統,再如何一步步將其實現。
文章首發於【部落格園-陳樹義】,點擊跳轉到原文《官方老爹之痛:為什麼蘋果能收到推送,而安卓不行?》
官方老爹之痛:為什麼蘋果能收到推送,而安卓不行?