遠(yuǎn)程推送(一): iOS 的遠(yuǎn)程推送

說在前面

iOS中的推送分為:Local Notification(本地消息通知)和Remote Notification(遠(yuǎn)程消息推送)。本文重點(diǎn)介紹一下Remote Notification,主要講理論知識(shí),沒有具體的代碼實(shí)現(xiàn),望各位見諒。

Apple Push Notification Service

蘋果官方的Programming Guide中是這么描述的:

Apple Push Notification service (APNs) is the centerpiece of the remote notifications feature. It is a robust and highly efficient service for propagating information to iOS (and, indirectly, watchOS), tvOS, and OS X devices. Each device establishes an accredited and encrypted IP connection with APNs and receives notifications over this persistent connection. If a notification for an app arrives when that app is not running, the device alerts the user that the app has data waiting for it.

You provide your own server to generate the remote notifications for your users. This server, known as the provider, gathers data for your users and decides when a notification needs to be sent. For each notification, the provider generates the notification payload and attaches that payload to an HTTP/2 request, which it then sends to APNs using a persistent and secure channel using the HTTP/2 multiplex protocol. Upon receipt of your request, APNs handles the delivery of your notification payload to your app on the user’s device.

For information about the format of the requests that you send to APNs, and the responses and errors you can receive, see APNs Provider API. For information about how to implement notification support in your app, see Registering, Scheduling, and Handling User Notifications.

大概的意思就是:
Apple Push Notification service (以下簡(jiǎn)稱:APNs)即蘋果推送通知服務(wù)是蘋果遠(yuǎn)程通知功能的核心,支持蘋果的所有的設(shè)備(包括WatchOS、TVOS、OS X)。每臺(tái)設(shè)備和APNs之間會(huì)建立一個(gè)網(wǎng)絡(luò)長(zhǎng)連接接收通知。無論應(yīng)用程序是否正在運(yùn)行,Apple設(shè)備都可以接收到通知并且對(duì)用戶進(jìn)行提示。
我們需要?jiǎng)?chuàng)建自己的服務(wù)器(以下稱為:Provider)在需要的時(shí)候生成遠(yuǎn)程通知。再由Provider通過HTTP 2.0協(xié)議向APNs發(fā)送請(qǐng)求,APNs在接收到請(qǐng)求后,會(huì)對(duì)遠(yuǎn)程消息進(jìn)行處理并推送到你的應(yīng)用程序所在的設(shè)備。

上面這么一大段話,我們可以簡(jiǎn)單的用下圖來概括:


一條遠(yuǎn)程通知發(fā)送的過程

通過上面這些內(nèi)容,我們大概可以知道以下幾點(diǎn):

  1. Provider,發(fā)送遠(yuǎn)程推送的時(shí)候,首先要有一個(gè)自己的服務(wù)器,用來生成遠(yuǎn)程通知的內(nèi)容并按照蘋果官方的API發(fā)送遠(yuǎn)程通知請(qǐng)求。這個(gè)請(qǐng)求是通過HTTP2.0協(xié)議完成的,也就是https
  2. APNs,蘋果的遠(yuǎn)程推送服務(wù)器,Provider發(fā)出的請(qǐng)求并不是直接發(fā)送到設(shè)備,而是發(fā)給APNs(強(qiáng)制的),然后再由 APNs 發(fā)送給應(yīng)用程序所在的設(shè)備
  3. APNs 是通過和設(shè)備之間的一個(gè)可信任、加密、長(zhǎng)久的網(wǎng)絡(luò)連接將遠(yuǎn)程通知發(fā)送到設(shè)備上的

** APNs 的儲(chǔ)存機(jī)制**
當(dāng)蘋果設(shè)備處于無網(wǎng)絡(luò)連接時(shí),遠(yuǎn)程推送消息是沒有辦法發(fā)送到設(shè)備的,這時(shí)APNs會(huì)把這條消息存起來,當(dāng)然,只是一段時(shí)間內(nèi),并且只可以存一條,也就是說一旦你的設(shè)備無網(wǎng)絡(luò)連接的時(shí)間過長(zhǎng),或者有一條新的推送消息的話,都會(huì)導(dǎo)致之前存的消息消失。個(gè)人認(rèn)為這勉強(qiáng)可以算是蘋果對(duì)于推送消息在網(wǎng)絡(luò)方面小小的解決方案吧,畢竟想做到大數(shù)據(jù)量的存儲(chǔ)不是容易的事,而且你也不想在IPhone重新連接網(wǎng)絡(luò)的時(shí)候會(huì)有N條推送出現(xiàn)吧,小心臟壓力不會(huì)小……

The device token

The device token 是蘋果設(shè)備的唯一認(rèn)證碼。當(dāng)你設(shè)備中的APP需要發(fā)送推送消息的時(shí)候,APNs 只能通過 device token 才能定位到你的設(shè)備。APP 在使用遠(yuǎn)程推送功能之前需要注冊(cè) device token ,通過Device 向 APNs 發(fā)送注冊(cè)請(qǐng)求,并將從 APNs 獲得的 device token 發(fā)給 Provider 進(jìn)行保存,以便將來發(fā)送推送消息時(shí), Provider 向 APNs 發(fā)送請(qǐng)求時(shí)使用。
注意:

  1. device token 是Device (也就是設(shè)備)向 APNs 注冊(cè)然后分享給 APP 使用的,雖然注冊(cè)的代碼是寫在 APP 當(dāng)中,但是主角還是 Device
  2. device token 并不是永遠(yuǎn)不變的,當(dāng)升級(jí)操作系統(tǒng)后會(huì)生成新的 device token ,所以我們需要在APP 啟動(dòng)的時(shí)就將新的 device token 發(fā)送到Provider 并進(jìn)行保存,這樣才能確保推送消息能夠準(zhǔn)確的發(fā)送到設(shè)備上
  3. device token 雖然是可修改的,但是千萬不要試圖修改他們,否則小心無法以正確的姿勢(shì)發(fā)送推送消息啊

下面兩圖,分別展示了 device token 注冊(cè)和遠(yuǎn)程推送過時(shí)的過程

向 APNs 注冊(cè)device token 的過程

Device 把 device token 分享給 APP 的過程

Provider 和 APNs 之間的連接

Provider 和APNs 之間會(huì)創(chuàng)建一個(gè)TLS連接,Provider首先會(huì)接收到APNs發(fā)過來的服務(wù)器證書,然后把自己的證書發(fā)給APNs(也就是p12文件),APNs驗(yàn)證通過后,完成TLS連接創(chuàng)建。如果你的證書配置的不正確,也就是沒有開通推送權(quán)限的話,APNs 會(huì)拒絕Provider的https請(qǐng)求。
Provider 除了需要向 APNs 發(fā)送證書以外,還需要發(fā)送 PayLoad (消息載體),包括了JSON字典格式的消息內(nèi)容、消息展示的形式(比如:Alert)、badge 顯示的消息數(shù)目以及sound提示聲。


Provider 和APNs 通信過程

APNs 和 Device 之間的連接

每個(gè) Device 都有自己的設(shè)備證書和私鑰,在設(shè)備激活的時(shí)候存儲(chǔ)在了 Keychain 中。Device 會(huì)啟動(dòng)一個(gè) TLS 連接APNs,APNs 會(huì)把服務(wù)器證書發(fā)給 Device 進(jìn)行驗(yàn)證,通過后 Device 會(huì)把設(shè)備證書發(fā)送給 APNs 進(jìn)行驗(yàn)證,一旦雙方都驗(yàn)證通過,這個(gè)連接就會(huì)創(chuàng)建成功,并且長(zhǎng)時(shí)間的保持,當(dāng)然,這個(gè)過程中我們是什么都不需要做的,蘋果會(huì)自動(dòng)幫我們完成。
注意:APNs 和 Device 的長(zhǎng)連接優(yōu)先使用的移動(dòng)網(wǎng)絡(luò),只有已經(jīng)連接wifi時(shí)才會(huì)走wifi,這也就是為什么好多人wifi上不了網(wǎng),但是卻能收到推送消息的原因。

APNs 和 Device 通信過程

總結(jié)

iOS 遠(yuǎn)程推送的相關(guān)知識(shí)大概就是這些了,總結(jié)一下有以下幾點(diǎn):

  1. 具有遠(yuǎn)程推送權(quán)限的證書,如果沒有,也就不能通過APNs的驗(yàn)證,當(dāng)然也就沒有辦法進(jìn)行消息推送了
  2. 向 APNs 進(jìn)行注冊(cè)獲得 device token,并進(jìn)行存儲(chǔ),要保證 device token 的正確性和實(shí)時(shí)性,否則也是無法消息推送的
  3. Provider 向 APNs 請(qǐng)求時(shí),使用的HTTP 2.0 也就是https協(xié)議,普通的 http 是會(huì)被拒絕訪問的
  4. APNs 和 Device 之間的長(zhǎng)連接也是 HTTP 2.0 協(xié)議,優(yōu)先走的移動(dòng)網(wǎng)絡(luò),若連 wifi 才會(huì)走 wifi 網(wǎng)絡(luò),所以只要保證有其中一樣的網(wǎng)絡(luò)連接是可用的,那么就可以正確的姿勢(shì)收到推送消息了

參考

  1. 蘋果自家開發(fā)文檔:Local and Remote Notification Programming Guide
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

推薦閱讀更多精彩內(nèi)容