首页手记测试妹子的呐喊：为什么总是收不到推送？

测试妹子的呐喊：为什么总是收不到推送？

标签：

Java iOS

小树最近在开发公司 App 的一个新的功能，需要在用户上线的时候，给关注了她的用户发送一条推送消息。小树很快就完成了开发，但测试人员却反馈说无法正常接收到推送。这可让小树着急死了，但小树调用的是原来的推送接口，对推送的相关业务并不熟悉。于是小树准备寻求资深工程师小黑的帮助。

苹果推送的沙盒环境

小树描述了以下问题，经验丰富的小黑立刻看出了端倪所在，问小树：是不是忘记设置推送类型为沙箱模式了？

此时的小树一脸茫然，赶紧问：什么是沙箱环境啊？

沙箱环境其实就是测试环境的意思，这是苹果系统习惯性的称呼。为了方便描述，我们下面还是用测试环境来替代沙箱环境吧。

小树听完连忙点头，之后又继续发问：那就是说推送系统也有测试环境和正式环境之分？

小黑不急不忙地跟小树说：那是肯定的啊。如果没有区分测试环境和线上环境，那我们在测试新功能的时候岂不是会干扰到线上用户的正常使用。

小黑接着说道：所以你提供给测试人员测试时，需要提供测试环境的推送，这样测试人员测试的时候才能正常收到推送。而当我们功能开发完成，需要发布到线上时，我们需要使用线上环境的推送。

小树听完之后赶紧将推送类型改为测试模式，之后让测试妹子再次测试。果不其然，这次果然能收到推送提醒了。

什么是苹果推送服务

虽然问题解决了，但小树还是感觉有什么东西没搞懂，于是坐在座位上冥思苦想，想了解一下推送的整个流程。

在一旁的小黑看到了小树皱着眉头，于是拿起纸和笔画起了图跟小树讲解起来。

对于苹果的 iOS 系统来说，它有自建的官方推送服务 APNS（Apple Push Notification service）。当我们的手机处于开机状态时，iOS 系统内置的一个推送服务便会一直处于运行的状态，并与 APNS 服务器保持长连接，随时准备接收APNS服务器的推送消息。

当我们向 APNS 服务器发送一条推送消息时，APNS 服务器就会将消息推送给对应的设备。而对应的 iOS 设备接收到推送消息后，又会将消息传递给对应的 APP 处理。

什么是DeviceToken

小树接着问：这个世界上的 iOS 设备那么多，APNS 服务器怎么知道这条消息是要推送给哪个设备的呢？

小树问的问题真是问到点子上了，小黑高兴地夸奖道。

要解答你这个问题，那就必须提一下DeviceToken这个东西。只要有 DeviceToken，那么APNS 服务器就知道将消息推送到哪台 iOS 设备上。

小树接着问：那也就是说 DeviceToken 是跟设备绑定的咯？

其实你只答对了一半。

其实 DeviceToken 是跟设备和App绑定在一起的。不同设备的同一应用，它们的 DeviceToken 是不同的。同一设备的不同应用，它们的 DeviceToken 也是不同的。

还记得我们每次新装一个应用的时候都会弹出一个「是否允许XXX给你发送系统消息」的提示吗？

当你点击「允许」之后，你的手机便会向 APNS 服务器请求生成一个 DeviceToken，此时 APNS 服务器便将这个 DeviceToken 和这个 iOS 联系起来了。除非你将应用卸载，否则这个 DeviceToken 就一直跟你的这个设备和这个应用绑定在一起了。

当我们需要发送推送消息时，APNS 服务器便会根据我们传递的 DeviceToken 参数寻找到对应的长连接，再将要发送的数据通过长连接推送到对应的设备上。

小树听完连连称赞，没想到一个简单的推送还有这么多学问。

苹果推送的流程

小黑看着小树似懂非懂的样子，于是让小树试着描述一下整个苹果推送的流程，借此看看小树是否真的掌握了。

小树听到了跃跃欲试，开始滔滔不绝地讲起来。

第一步，当我们启动应用后 App 弹出是否允许「系统通知」的请求，我们点击允许后，iOS 设备向 APNS 服务器请求一个 DeviceToken。此时，APNS 服务器将这个 DeviceToken 与该 iOS 设备绑定起来。
第二步，当我们需要发送推送消息时，我们请求我们的后台服务器，告诉它我们要发一条推送消息给某个 DeviceToken。后台服务器接收到消息后转而请求APNS 服务器的沙箱环境接口或线上环境接口。
第三步，当 APNS 服务器接收到请求后，它根据 DeviceToken 取出之前已经建立的与该 iOS 建立的长连接，最后将需要发送的内容输出到该长连接中。

第四步，与 APNS 服务器建立长连接的 iOS 设备接收到消息后，分析这个 DeviceToken 属于哪个 App，并将其分发给对应的 App 进行处理。

整个流程大概像下面这张图描述的这样：