在我的应用程序过程中，我在推送通知方面遇到了各种困难，这些困难似乎可以通过卸载来修复。我相信我已经将其缩小到过期的设备令牌。
阅读Apple的推送通知文档，我发现：
注册成功，但未收到通知
。
你的应用可能向你的提供程序发送了不正确的设备令牌。 你的应用应始终通过注册 每次启动时的推送服务。不存储设备令牌 并尝试重复使用它，因为令牌可能会更改。你 然后，提供程序应将相同的令牌传递给推送服务。
他们建议每次启动应用程序时注册。他们还建议推送通知的最佳实践是不要这样做，因为用户不喜欢在看到您的应用程序之前就被访问请求轰炸。因此，仅将注册调用放入应用委托并不是最佳选择。但是，我没有看到有关设备令牌何时过期或如何查看它是否已过期的更多信息。
我能找到的最接近的是关于UIApplication的实例方法isRegisteredForRemoteNotifications的文档：
返回值 YES，如果应用已注册远程通知，则返回值 YES，并且 收到其设备令牌或否(如果未进行注册)，已收到 失败，或已被用户拒绝。
我的理解是，这是调用以检查用户是否启用了推送通知服务的方法。我知道特定通知类型的权限都可以关闭，如果用户允许推送通知，这仍然可能是正确的。但措辞看起来需要应用程序注册到当前 deviceToken。 这是否意味着我可以打电话
[[UIApplication currentApplication] isRegisteredForRemoteNotifications]
在 appDelegate 中，如果为 true，请注册远程通知以更新我的服务器上的 deviceToken 并确保我的推送通知不会过期？或者，这个函数是否会遇到与我目前相同的情况，最终 deviceToken 将过期，并且即使用户允许推送通知，此方法也将开始返回 false 而不是 true？
tl;dr - Apple表示，deviceTokens最终会因推送通知而过期。他们建议每次应用程序启动时注册。我不想用该警报轰炸新用户。如何确保只有已接受推送通知的用户才能重新注册？
警报只会显示一次。
如果用户以前允许通知，则代码将获取新令牌，而无需用户进行任何交互(或向用户发出 UI 通知)。
好的，最佳实践如下，我们遵循这些实践而不会失败
-
始终使用以下代码注册应用启动时推送，或在适当的 AppDelegate 生命周期方法中注册推送
[[UIApplication sharedApplication] registerUserNotificationSettings: [UIUserNotificationSettings settingsForTypes:(UIUserNotificationTypeAlert | UIUserNotificationTypeBadge | UIUserNotificationTypeSound) categories:nil]]; [[UIApplication sharedApplication] registerForRemoteNotifications]; -
如果推送成功注册，则推送的委托将使用 deviceToken 调用
- (void)application:(UIApplication*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken如果设备令牌始终发生变化，则上面的委托将被调用。因此，每当您获得设备令牌时，都会在服务器中更新它。
-
在服务器中，如果您在沙盒或生产模式下运行，请确保点击正确的模式，丢弃模拟器中的值，它们通常会失败并阻止服务一段时间。
您可以随时使用您的 pem 文件和设备令牌检查推送是否适用于此在线服务。
希望对您有所帮助。
干杯。