一句话结论

签名分发的 App 能不能收到推送，很多时候不是推送服务没配好，而是它压根走在了另一条通道上。APNs（Apple Push Notification service，苹果推送通知服务）分测试通道和正式通道两条，走错一条，消息发出去就像石沉大海。

两条通道是怎么分的

苹果把推送环境切成两半：一条给开发调试阶段用，业内习惯叫沙盒（Sandbox，测试环境）通道；另一条给正式对外分发的 App 用，叫生产（Production，正式环境）通道。两条通道的服务器地址不同、证书不同、设备令牌（device token，系统给每台设备上的每个 App 发的一串标识）也不同。

关键在这里：同一个 App，用不同的方式签出来，拿到的设备令牌属于不同的通道。用开发证书签的包拿到的令牌，只能在沙盒通道上被找到；用企业证书或 Ad Hoc（定向分发）方式签的包，拿到的是正式通道的令牌。

为什么到了签名这步容易错

问题通常出在「同一个包在不同人手里签过」。

• 研发在自己电脑上用开发证书调试，一切正常，推送秒到。
• 包交给签名商用企业证书重新签，包名没变、功能没变，但签名身份变了。
• 这时候研发再拿原来的调试环境去推，服务端还在往沙盒通道发，而用户手里的包已经只认正式通道了。

于是就出现一种很典型的现象：研发说「我这边测试明明能收到」，用户说「我一条都没收到」——两个人说的都是真的，只是不在同一条通道上。

怎么判断自己卡在哪一条

按顺序做三件事就能定位。

• 第一，看签名方式。企业签名、超级签这类对外分发的包，走的都是正式通道；只有连着 Xcode（苹果官方开发工具）调试、或者用开发描述文件签的包才走沙盒。
• 第二，让服务端把推送结果记下来。往沙盒通道推一个只存在于正式通道的令牌，服务端会收到明确的错误返回，这个返回值就是最直接的证据。
• 第三，换个网络环境复测。公司网络里某些端口被拦，也会表现为「推送时有时无」，这种情况换手机流量一测就能区分开。

几个常见误区

误区一：以为推送跟签名没关系。有关系，而且关系在证书这一层，不在代码那一层。

误区二：把两条通道的令牌混着存在一个表里。用户换过签名方式之后，旧令牌就作废了，服务端如果还拿着旧的去推，会一直失败。

误区三：重签一次就能好。如果服务端指向的通道没改，重签多少次都一样。

小结

推送不通先别急着改代码，先确认三件事：这个包现在是用什么证书签的、服务端往哪条通道发、用户手里的令牌是哪一次安装时生成的。这三者的对上了，推送自然就通了。

---

我是本期作者小思，想解决苹果企业签名、超级签名、TF签名问题？可以在微信公众号对话框找到我哦~（QQ：822404920　微信：A-mk5888）