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