导语:
Apple Push Notification service (APNs),即苹果推送通知服务,是苹果为 APP 开发商提供「间接的」推送通知到指定设备的一种服务。
为什么会有 APNs ?
由于移动设备内存、CPU、电量的局限性,iOS 不允许 APP 的进程常驻后台(事实上可以申请后台运行一段时间,最长约 10 分钟),这样当用户主动杀掉 APP,或者 APP 进入后台超过约定时长时,就意味着该 APP 进程的结束。这在很大程度上保障了前台 APP 的流畅性,也延长了手机的使用时长,获得了较好的用户体验。但是这也意味着,服务器无法主动和用户交互(如推送实时消息等)。为了解决这个限制,苹果推出了 APNs,允许设备和服务器分别与苹果的推送通知服务器保持长连接状态。
APNs 到底是什么?
iOS 的通知分为本地通知和远程通知。本地通知是由本地应用触发的,一般是基于时间的一种通知形式,如闹钟、待办事件等的提醒。远程通知是由开发商通过自己的服务器推送的一种通知形式,而 APNs 就是远程通知功能的核心。
关于远程推送,记住以下两点就够了:
- 客户端:
客户端发送自身设备的 UDID 和 Bundle Identifier 给 APNs 服务器,经苹果服务器加密后生成 deviceToken,随后只需将用户的 deviceToken 发送服务器保存。 - 服务器:
服务器在需要给某个用户推送消息时,需要将消息内容和 deviceToken 一起发送给 APNs 服务器,苹果服务器对 deviceToken 解密后可以找到具体的设备,然后将消息推送给该用户。
这里就很清楚了,其实 APNs 的本质就是服务器和客户端之间的中介。当服务器需要给客户端推送消息时,先将消息发送给苹果服务器,再由苹果服务器找到对应设备推送下去。
那为什么还要走中介,不直接发送呢?因为这样做一个设备(即所有 APP )只需要和苹果的服务器建立一条长连接,而不需要每个 APP 都和服务器建立一条长连接。
APNs 的意义在哪里?
可能有些人还是不太明白 APNs 的意义,觉得也只是将多个长连接变成了统一的一个长连接而已,有必要那么做吗?
很有必要!
我们来看下 Android 的推送现状就明白了。
Android 事实上也有类似于 APNs 的一套用于推送的服务,简称 GCM,即 Google Cloud Messaging。但由于 GCM 需要谷歌服务器的支持,在国内由于「墙」的原因基本不能使用。这下就热闹了,国内出现了一大堆第三方推送服务商,如华为推送、小米推送、极光推送等。APP 通过集成这些推送服务来实现推送功能,而这些推送服务为了保持自己的长连接不被杀死,采用了各种保活、唤醒手段,这也是 Android 手机使用不流畅的真凶。之前也有看到「工信部要求国内安卓统一消息推送标准」的新闻,工信部都这么重视,可见统一推送的意义非凡。
APNs 新旧协议的对比
基于二进制的旧协议 | 基于 HTTP/2 的新协议 | |
---|---|---|
长连接情况 | 无法维持,空闲会被断开 | 可以通过“PING”心跳包检测维持 |
推送结果反馈 | 成功时无响应,失败时断开连接 | 成功失败均有明确响应 |
推送长度 | iOS 8 及以上 2 Kb,以下 256 字节 | 统一 4096 字节(4 Kb) |
证书类型 | 不同类型的推送,需要配置不同的推送证书 | 只需要配置一种推送证书(Universal Push Notification Client SSL) |
想要了解具体区别,可以参考这篇文章 「国内 90%以上的 iOS 开发者,对 APNs 的认识都是错的」。
不言而喻,当然是尽早升级 HTTP/2 协议了。
收不到 APNs 推送怎么办?
- 首先要知道服务器推送成功,并不代表设备就能收到推送。服务器推送成功只是将消息交给了苹果服务器而已,苹果服务器还需要设备在线才能推送的。
- 其次 deviceToken 可能会在 APP 卸载重装后发生变化,客户端对此需要制定相应的汇报策略,以便服务器及时更新存储的 deviceToken 。
- 客户端只要能上报正确的 deviceToken 就可以说明客户端实现没问题了。否则检查客户端是否开启了远程推送通知服务,Bundle Identifier 是否与申请的推送证书匹配。
- 检查服务器内存缓存的 deviceToken 或者数据库存储的 deviceToken 是否与客户端汇报的一致。
- 排查服务器配置的证书是否过期,是否与客户端的 Bundle Identifier 匹配,或者是否勿用了其他类型的推送证书。
- 采用抓包工具(如 Wireshark )抓包分析,看看服务器是否将消息交给苹果服务器,客户端是否收到了相应的推送通知。
参考:
(完)
网友评论