iOS推送完整链路：数据从哪来，到哪去，怎么流

上篇讲了挂起态存储有读者说链路那张图一带而过想看清楚每个环节到底传了什么、数据往哪流。这篇就专门干这一件事把整条链路拆成一个个节点标清楚每一段传的是什么数据、朝哪个方向流。先认清链路上的四个角色整条推送链从头到尾只有四方参与。先把这四方认清楚谁是谁、各自管什么┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 你的App │ │ 你的服务器 │ │ APNs │ │ iPhone系统 │ │ (Provider前端)│ │ (Provider后端)│ │ (苹果推送网关)│ │ 你的App │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘角色大白话职责你的App收信的那家申请收推送、上报门牌号、最终展示/处理消息你的服务器寄信的人保管门牌号、决定推什么、把信交给邮局APNs苹果总邮局唯一的推送网关所有推送都从这过iPhone系统小区收发室维护那唯一一条连接接信、投递、代管关键认知这四方之间数据不是单向一路走到底的而是分成两个大阶段方向还相反。整条链路分两个阶段方向相反很多人搞不清楚就是因为把两个阶段混在一起看了。其实要分开阶段一【注册阶段】数据从设备流向你的服务器自下而上 目的让你的服务器拿到门牌号device token 阶段二【推送阶段】数据从你的服务器流回设备自上而下 目的把消息投递到设备上必须先有阶段一才可能有阶段二。没拿到门牌号你服务器根本不知道往哪推。下面分别把两个阶段的数据流画清楚。阶段一注册拿门牌号——数据自下而上流这个阶段的目标只有一个你的服务器最终要拿到一个 device token门牌号。数据从App出发绕一圈最后落到你的服务器。① 我想收推送 ┌─────────┐ ────────────────────────── ┌─────────┐ │ 你的App │ │iPhone系统│ │ │ ────────────────────────── │ │ └─────────┘ ② 用户点了同意 └─────────┘ │ │ │ │ ③ 去苹果注册 │ │ 这台设备这个App │ ▼ │ ┌─────────┐ │ │ APNs │ │ │(苹果邮局) │ │ ④ 生成门牌号(token) └─────────┘ │ 发回给系统 │ │ ───────────────────────────────────────┘ │ ⑤ 系统把token交给App │ │ ⑥ App把token上报给自己的服务器 ▼ ┌─────────┐ │ 你的服务器 │ ← token最终存在这里存进数据库 └─────────┘逐段说明数据流向和内容步骤数据从 → 到传的是什么①App → 系统“我想收推送”申请权限②系统 → 用户 → App弹窗用户点同意③系统 → APNs“这台设备这个App要注册”④⑤APNs → 系统 → Appdevice token门牌号⑥App → 你的服务器把token上报服务器存起来对应代码看数据在哪几个点落地// 【步骤①】App向系统申请UNUserNotificationCenter.current().requestAuthorization(options:[.alert,.badge,.sound]){同意了,_inif同意了{// 用户同意 → 触发系统去APNs注册步骤③UIApplication.shared.registerForRemoteNotifications()}}// 【步骤④⑤】APNs生成token系统通过这个回调交给Appfuncapplication(_application:UIApplication,didRegisterForRemoteNotificationsWithDeviceToken deviceToken:Data){// 这里第一次拿到门牌号lettokendeviceToken.map{String(format:%02x,$0)}.joined()// 【步骤⑥】关键把门牌号上报给【你自己的服务器】// 数据流的终点在这token存进你的数据库上报token给自己服务器(token)}阶段一的核心结论数据流向App → 系统 → APNs → 系统 → App → 你的服务器 最终落点device token 存在【你的服务器数据库】里 这个token 设备App的唯一门牌号 以后你想推送就靠它找到这台设备阶段二推送投递消息——数据自上而下流拿到门牌号后才能推。这个阶段方向反过来了数据从你的服务器出发经过苹果邮局投到设备上。┌─────────┐ │ 你的服务器 │ ① 组装消息内容 门牌号(token) └─────────┘ │ │ ② 建立连接把消息交给苹果邮局 │ 用之前存的token指明投给谁 ▼ ┌─────────┐ │ APNs │ ③ 苹果验证token合法吗App还装着吗 │(苹果邮局) │ 通过 → 投递 / 不通过 → 丢弃并反馈 └─────────┘ │ │ ④ 通过那唯一一条长连接投到设备 ▼ ┌─────────┐ │iPhone系统│ ⑤ 根据App当前状态决定怎么处理 └─────────┘ │ │ ⑥ 交给App或系统代为展示 ▼ ┌─────────┐ │ 你的App │ ← 消息最终到达 └─────────┘逐段说明步骤数据从 → 到传的是什么①你的服务器内部组装 payload消息内容 取出目标token②你的服务器 → APNspayload token用HTTP/2连接发出③APNs内部校验token有效性④APNs → 系统走那条唯一长连接投到设备⑤⑥系统 → App按App状态处理下面细讲你服务器发给APNs的数据长这样payload{aps:{alert:{title:你有一条新消息,body:点击查看详情},badge:1,sound:default},自定义字段:跳转到订单页}发的时候token放在请求路径里指明投给哪台设备POST https://api.push.apple.com/3/device/{这里放device_token} Body: 上面那段payload阶段二的最后一段进了系统后数据往哪流取决于App状态这是整条链路最容易忽略、也最关键的一段。消息到了iPhone系统步骤⑤接下来数据流向哪里完全看你的App此刻是什么状态。消息到达 iPhone系统 │ ├─ App在前台 │ → 系统直接把数据交给App的回调 │ 数据流系统 → AppwillPresent回调 │ ├─ App在后台/挂起普通推送 │ → 系统自己存进【通知数据库】显示在通知栏 │ 数据暂时【不流向App】App还在睡 │ 等用户点击 → 才流向AppdidReceive回调 │ └─ App挂起静默推送 content-available → 系统短暂唤醒App 数据流系统 → AppdidReceiveRemoteNotification回调三种情况的数据落点对应三个不同的回调// 情况1App在前台时消息数据流到这里funcuserNotificationCenter(_center:UNUserNotificationCenter,willPresent notification:UNNotification,...){// 数据直接到达App醒着立即能处理let数据notification.request.content.userInfo}// 情况2App在后台/挂起用户【点击通知】后数据流到这里funcuserNotificationCenter(_center:UNUserNotificationCenter,didReceive response:UNNotificationResponse,...){// 消息之前一直躺在【系统通知数据库】里// 用户点击 → 系统唤醒App → 现在才把数据交还let数据response.notification.request.content.userInfo}// 情况3静默推送App被短暂唤醒数据流到这里funcapplication(_application:UIApplication,didReceiveRemoteNotification userInfo:[AnyHashable:Any],...){// App被摇醒几秒数据直接到达趁机处理let数据userInfo}这就是上篇挂起态存储的链路视角普通推送在挂起时数据流没有到达App而是停在了系统的通知数据库里等用户点击才继续往App流。完整链路一张图从头到尾把两个阶段拼起来标清所有数据流向═══════════ 阶段一注册拿门牌号自下而上═══════════ App ─①想收推送─ 系统 ─③注册─ APNs │ ④生成token │ App ─⑤交还token─ 系统 ──────────┘ │ └─⑥上报─ 你的服务器 【token存这里】 ═══════════ 阶段二推送投消息自上而下═══════════ 你的服务器 【取出token组装消息】 │ │ ②发送(payload token) ▼ APNs ③校验token │ │ ④走唯一长连接投递 ▼ iPhone系统 ⑤按App状态分流 │ ├─前台── App(willPresent回调) ├─挂起(普通)── 系统通知库暂存 ──用户点击── App(didReceive回调) └─挂起(静默)── 唤醒 ── App(didReceiveRemoteNotification回调)数据流的三个关键点记住就不乱了1. token的流向是绕一圈回到你手里token从APNs生成 → 经系统 → 给App → App上报 → 存到你的服务器很多人卡在这token不是苹果直接给你服务器的是先到AppApp再交给你服务器。你服务器和APNs之间注册阶段没有直接往来。2. 推送阶段你服务器和App之间【没有直接连接】你的服务器 ✗直接✗ 你的App 你的服务器 → APNs → 系统 → App 必须绕苹果邮局你永远不能直接把消息推给App必须经过APNs这个唯一网关。这是苹果的强制规定也是为啥推送这么省电全设备就一条连接。3. 最后一段的数据流向是条件分支不是直线到了系统这数据不一定马上流到App 前台→直达App / 挂起普通→先停系统库 / 挂起静默→唤醒后达App理解这一点就理解了为啥App睡着还能收推送——因为最后那段数据流系统能替App接管。用一句话概括整条链路的数据流动注册时门牌号token从设备一路上报、最终存进你的服务器推送时消息从你的服务器出发必经苹果邮局APNs投到系统再由系统按App状态决定是直接交给App、还是先替它代管。两个阶段、方向相反、APNs是唯一枢纽——抓住这三点整条链路的数据流动就彻底清楚了。