iOS推送原理

1.由App向iOS设备发送一个注册通知，用户需要同意系统发送推送。
2.iOS向APNs远程推送服务器发送App的Bundle Id和设备的UDID。
3.APNs根据设备的UDID和App的Bundle Id生成deviceToken再发回给App。
4.App再将deviceToken发送给远程推送服务器(自己的服务器), 由服务器保存在数据库中。
5.当自己的服务器想发送推送时, 在远程推送服务器中输入要发送的消息并选择发给哪些用户的deviceToken，由远程推送服务器发送给APNs。
6.APNs根据deviceToken发送给对应的用户。
· APNs 服务器就是苹果专门做远程推送的服务器。
·deviceToken是由APNs生成的一个专门找到你某个手机上的App的一个标识码。
· deviceToken 可能会变,如果你更改了你项目的bundle Identifier或者APNs服务器更新了可能会变。

APNs推送中的问题

问题一：当应用从设备卸载后，推送的消息改如何处理？

我们知道当应用从设备卸载后，是收不到推送消息的。但是，如何让APNs和Provider知道不再向这台卸载了应用的设备推送消息呢？

针对这个问题苹果也已经帮我们解决了（那就是Feedback Service）。它是APNS的一部分，APNs会持续的更新Feedback service的列表，当我们的Provider将信息发给APNs服务器，APNs推送信息到我们的设备时，如果这时设备无法将消息推送到指定的应用（应用已经删除），就会向APNs服务器发送一个反馈信息，而这个信息就记录在Feedback service中。按照这种方式，Provider应该定时的去检测Feedback service的列表，然后删除在自己数据库中记录的存在于反馈列表中的deviceToken，从而不再向这些设备发送推送信息。连接Feedback service的过程同样使用长连接的方式，连接上后，直接接收由APNs传输给我们的反馈列表，传输完成后断开连接，然后我们根据这个最新的反馈列表在更新我们自己的数据库，删除那些不再需要推送信息的设备的deviceToken。

image.png

结构中包含三个部分

• 第一部分是一个时间戳，记录的是设备失效后的时间信息
• 第二个部分是deviceToken的长度
• 第三部分就是失效的deviceToken，我们所要获取的就是第三部分，跟我们的数据库进行对比后，删除对应的deviceToken，下次不再向这些设备发送推送信息

问题二：iOS 重复推送之谜

当自己公司后端保存了多个device token(指向同一设备的)的时候，并且后端没有针对同一账号只调用一条device token记录进行设备推送的限制，导致了同一设备重复收到同一条推送。

问题三：收不到 APNs 推送怎么办？

• 首先要知道服务器推送成功，并不代表设备就能收到推送。服务器推送成功只是将消息交给了苹果服务器而已，苹果服务器还需要设备在线才能推送的。

• 其次 deviceToken 可能会在 APP 卸载重装后发生变化，客户端对此需要制定相应的汇报策略，以便服务器及时更新存储的 deviceToken 。
  客户端只要能上报正确的 deviceToken 就可以说明客户端实现没问题了。否则检查客户端是否开启了远程推送通知服务，Bundle Identifier 是否与申请的推送证书匹配。

• 检查服务器内存缓存的 deviceToken 或者数据库存储的 deviceToken 是否与客户端汇报的一致。
  排查服务器配置的证书是否过期，是否与客户端的 Bundle Identifier 匹配，或者是否勿用了其他类型的推送证书。
  采用抓包工具（如 Wireshark ）抓包分析，看看服务器是否将消息交给苹果服务器，客户端是否收到了相应的推送通知。