上篇講了掛起態(tài)存儲有讀者說鏈路那張圖一帶而過想看清楚每個環(huán)節(jié)到底傳了什么、數(shù)據(jù)往哪流。這篇就專門干這一件事把整條鏈路拆成一個個節(jié)點(diǎn)標(biāo)清楚每一段傳的是什么數(shù)據(jù)、朝哪個方向流。先認(rèn)清鏈路上的四個角色整條推送鏈從頭到尾只有四方參與。先把這四方認(rèn)清楚誰是誰、各自管什么┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 你的App │ │ 你的服務(wù)器 │ │ APNs │ │ iPhone系統(tǒng) │ │ (Provider前端)│ │ (Provider后端)│ │ (蘋果推送網(wǎng)關(guān))│ │ 你的App │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘角色大白話職責(zé)你的App收信的那家申請收推送、上報門牌號、最終展示/處理消息你的服務(wù)器寄信的人保管門牌號、決定推什么、把信交給郵局APNs蘋果總郵局唯一的推送網(wǎng)關(guān)所有推送都從這過iPhone系統(tǒng)小區(qū)收發(fā)室維護(hù)那唯一一條連接接信、投遞、代管關(guān)鍵認(rèn)知這四方之間數(shù)據(jù)不是單向一路走到底的而是分成兩個大階段方向還相反。整條鏈路分兩個階段方向相反很多人搞不清楚就是因?yàn)榘褍蓚€階段混在一起看了。其實(shí)要分開階段一【注冊階段】數(shù)據(jù)從設(shè)備流向你的服務(wù)器自下而上 目的讓你的服務(wù)器拿到門牌號device token 階段二【推送階段】數(shù)據(jù)從你的服務(wù)器流回設(shè)備自上而下 目的把消息投遞到設(shè)備上必須先有階段一才可能有階段二。沒拿到門牌號你服務(wù)器根本不知道往哪推。下面分別把兩個階段的數(shù)據(jù)流畫清楚。階段一注冊拿門牌號——數(shù)據(jù)自下而上流這個階段的目標(biāo)只有一個你的服務(wù)器最終要拿到一個 device token門牌號。數(shù)據(jù)從App出發(fā)繞一圈最后落到你的服務(wù)器。① 我想收推送 ┌─────────┐ ────────────────────────── ┌─────────┐ │ 你的App │ │iPhone系統(tǒng)│ │ │ ────────────────────────── │ │ └─────────┘ ② 用戶點(diǎn)了同意 └─────────┘ │ │ │ │ ③ 去蘋果注冊 │ │ 這臺設(shè)備這個App │ ▼ │ ┌─────────┐ │ │ APNs │ │ │(蘋果郵局) │ │ ④ 生成門牌號(token) └─────────┘ │ 發(fā)回給系統(tǒng) │ │ ───────────────────────────────────────┘ │ ⑤ 系統(tǒng)把token交給App │ │ ⑥ App把token上報給自己的服務(wù)器 ▼ ┌─────────┐ │ 你的服務(wù)器 │ ← token最終存在這里存進(jìn)數(shù)據(jù)庫 └─────────┘逐段說明數(shù)據(jù)流向和內(nèi)容步驟數(shù)據(jù)從 → 到傳的是什么①App → 系統(tǒng)“我想收推送”申請權(quán)限②系統(tǒng) → 用戶 → App彈窗用戶點(diǎn)同意③系統(tǒng) → APNs“這臺設(shè)備這個App要注冊”④⑤APNs → 系統(tǒng) → Appdevice token門牌號⑥App → 你的服務(wù)器把token上報服務(wù)器存起來對應(yīng)代碼看數(shù)據(jù)在哪幾個點(diǎn)落地// 【步驟①】App向系統(tǒng)申請UNUserNotificationCenter.current().requestAuthorization(options:[.alert,.badge,.sound]){同意了,_inif同意了{(lán)// 用戶同意 → 觸發(fā)系統(tǒng)去APNs注冊步驟③UIApplication.shared.registerForRemoteNotifications()}}// 【步驟④⑤】APNs生成token系統(tǒng)通過這個回調(diào)交給Appfuncapplication(_application:UIApplication,didRegisterForRemoteNotificationsWithDeviceToken deviceToken:Data){// 這里第一次拿到門牌號lettokendeviceToken.map{String(format:%02x,$0)}.joined()// 【步驟⑥】關(guān)鍵把門牌號上報給【你自己的服務(wù)器】// 數(shù)據(jù)流的終點(diǎn)在這token存進(jìn)你的數(shù)據(jù)庫上報token給自己服務(wù)器(token)}階段一的核心結(jié)論數(shù)據(jù)流向App → 系統(tǒng) → APNs → 系統(tǒng) → App → 你的服務(wù)器 最終落點(diǎn)device token 存在【你的服務(wù)器數(shù)據(jù)庫】里 這個token 設(shè)備App的唯一門牌號 以后你想推送就靠它找到這臺設(shè)備階段二推送投遞消息——數(shù)據(jù)自上而下流拿到門牌號后才能推。這個階段方向反過來了數(shù)據(jù)從你的服務(wù)器出發(fā)經(jīng)過蘋果郵局投到設(shè)備上。┌─────────┐ │ 你的服務(wù)器 │ ① 組裝消息內(nèi)容 門牌號(token) └─────────┘ │ │ ② 建立連接把消息交給蘋果郵局 │ 用之前存的token指明投給誰 ▼ ┌─────────┐ │ APNs │ ③ 蘋果驗(yàn)證token合法嗎App還裝著嗎 │(蘋果郵局) │ 通過 → 投遞 / 不通過 → 丟棄并反饋 └─────────┘ │ │ ④ 通過那唯一一條長連接投到設(shè)備 ▼ ┌─────────┐ │iPhone系統(tǒng)│ ⑤ 根據(jù)App當(dāng)前狀態(tài)決定怎么處理 └─────────┘ │ │ ⑥ 交給App或系統(tǒng)代為展示 ▼ ┌─────────┐ │ 你的App │ ← 消息最終到達(dá) └─────────┘逐段說明步驟數(shù)據(jù)從 → 到傳的是什么①你的服務(wù)器內(nèi)部組裝 payload消息內(nèi)容 取出目標(biāo)token②你的服務(wù)器 → APNspayload token用HTTP/2連接發(fā)出③APNs內(nèi)部校驗(yàn)token有效性④APNs → 系統(tǒng)走那條唯一長連接投到設(shè)備⑤⑥系統(tǒng) → App按App狀態(tài)處理下面細(xì)講你服務(wù)器發(fā)給APNs的數(shù)據(jù)長這樣payload{aps:{alert:{title:你有一條新消息,body:點(diǎn)擊查看詳情},badge:1,sound:default},自定義字段:跳轉(zhuǎn)到訂單頁}發(fā)的時候token放在請求路徑里指明投給哪臺設(shè)備POST https://api.push.apple.com/3/device/{這里放device_token} Body: 上面那段payload階段二的最后一段進(jìn)了系統(tǒng)后數(shù)據(jù)往哪流取決于App狀態(tài)這是整條鏈路最容易忽略、也最關(guān)鍵的一段。消息到了iPhone系統(tǒng)步驟⑤接下來數(shù)據(jù)流向哪里完全看你的App此刻是什么狀態(tài)。消息到達(dá) iPhone系統(tǒng) │ ├─ App在前臺 │ → 系統(tǒng)直接把數(shù)據(jù)交給App的回調(diào) │ 數(shù)據(jù)流系統(tǒng) → AppwillPresent回調(diào) │ ├─ App在后臺/掛起普通推送 │ → 系統(tǒng)自己存進(jìn)【通知數(shù)據(jù)庫】顯示在通知欄 │ 數(shù)據(jù)暫時【不流向App】App還在睡 │ 等用戶點(diǎn)擊 → 才流向AppdidReceive回調(diào) │ └─ App掛起靜默推送 content-available → 系統(tǒng)短暫喚醒App 數(shù)據(jù)流系統(tǒng) → AppdidReceiveRemoteNotification回調(diào)三種情況的數(shù)據(jù)落點(diǎn)對應(yīng)三個不同的回調(diào)// 情況1App在前臺時消息數(shù)據(jù)流到這里funcuserNotificationCenter(_center:UNUserNotificationCenter,willPresent notification:UNNotification,...){// 數(shù)據(jù)直接到達(dá)App醒著立即能處理let數(shù)據(jù)notification.request.content.userInfo}// 情況2App在后臺/掛起用戶【點(diǎn)擊通知】后數(shù)據(jù)流到這里funcuserNotificationCenter(_center:UNUserNotificationCenter,didReceive response:UNNotificationResponse,...){// 消息之前一直躺在【系統(tǒng)通知數(shù)據(jù)庫】里// 用戶點(diǎn)擊 → 系統(tǒng)喚醒App → 現(xiàn)在才把數(shù)據(jù)交還let數(shù)據(jù)response.notification.request.content.userInfo}// 情況3靜默推送App被短暫喚醒數(shù)據(jù)流到這里funcapplication(_application:UIApplication,didReceiveRemoteNotification userInfo:[AnyHashable:Any],...){// App被搖醒幾秒數(shù)據(jù)直接到達(dá)趁機(jī)處理let數(shù)據(jù)userInfo}這就是上篇掛起態(tài)存儲的鏈路視角普通推送在掛起時數(shù)據(jù)流沒有到達(dá)App而是停在了系統(tǒng)的通知數(shù)據(jù)庫里等用戶點(diǎn)擊才繼續(xù)往App流。完整鏈路一張圖從頭到尾把兩個階段拼起來標(biāo)清所有數(shù)據(jù)流向═══════════ 階段一注冊拿門牌號自下而上═══════════ App ─①想收推送─ 系統(tǒng) ─③注冊─ APNs │ ④生成token │ App ─⑤交還token─ 系統(tǒng) ──────────┘ │ └─⑥上報─ 你的服務(wù)器 【token存這里】 ═══════════ 階段二推送投消息自上而下═══════════ 你的服務(wù)器 【取出token組裝消息】 │ │ ②發(fā)送(payload token) ▼ APNs ③校驗(yàn)token │ │ ④走唯一長連接投遞 ▼ iPhone系統(tǒng) ⑤按App狀態(tài)分流 │ ├─前臺── App(willPresent回調(diào)) ├─掛起(普通)── 系統(tǒng)通知庫暫存 ──用戶點(diǎn)擊── App(didReceive回調(diào)) └─掛起(靜默)── 喚醒 ── App(didReceiveRemoteNotification回調(diào))數(shù)據(jù)流的三個關(guān)鍵點(diǎn)記住就不亂了1. token的流向是繞一圈回到你手里token從APNs生成 → 經(jīng)系統(tǒng) → 給App → App上報 → 存到你的服務(wù)器很多人卡在這token不是蘋果直接給你服務(wù)器的是先到AppApp再交給你服務(wù)器。你服務(wù)器和APNs之間注冊階段沒有直接往來。2. 推送階段你服務(wù)器和App之間【沒有直接連接】你的服務(wù)器 ?直接? 你的App 你的服務(wù)器 → APNs → 系統(tǒng) → App 必須繞蘋果郵局你永遠(yuǎn)不能直接把消息推給App必須經(jīng)過APNs這個唯一網(wǎng)關(guān)。這是蘋果的強(qiáng)制規(guī)定也是為啥推送這么省電全設(shè)備就一條連接。3. 最后一段的數(shù)據(jù)流向是條件分支不是直線到了系統(tǒng)這數(shù)據(jù)不一定馬上流到App 前臺→直達(dá)App / 掛起普通→先停系統(tǒng)庫 / 掛起靜默→喚醒后達(dá)App理解這一點(diǎn)就理解了為啥App睡著還能收推送——因?yàn)樽詈竽嵌螖?shù)據(jù)流系統(tǒng)能替App接管。用一句話概括整條鏈路的數(shù)據(jù)流動注冊時門牌號token從設(shè)備一路上報、最終存進(jìn)你的服務(wù)器推送時消息從你的服務(wù)器出發(fā)必經(jīng)蘋果郵局APNs投到系統(tǒng)再由系統(tǒng)按App狀態(tài)決定是直接交給App、還是先替它代管。兩個階段、方向相反、APNs是唯一樞紐——抓住這三點(diǎn)整條鏈路的數(shù)據(jù)流動就徹底清楚了。