iOS Push Notifications官方故障排查指南

参考:https://developer.apple.com/library/archive/technotes/tn2265/_index.html

No Delegate Callbacks 木有回调

When the first push-capable app is installed, iOS or OS X attempts to establish a persistent network connection to the push service that will be shared by all push-capable apps on the system. If neither delegate callback application:didRegisterForRemoteNotificationsWithDeviceToken: nor application:didFailToRegisterForRemoteNotificationsWithError: is called, that means that this connection has not yet been established.
This is not necessarily an error condition. The system may not have Internet connectivity at all because it is out of range of any cell towers or Wi-Fi access points, or it may be in airplane mode. Instead of treating this as an error, your app should continue normally, disabling only that functionality that relies on push notifications.
Keep in mind that network availability can change frequently. Once the persistent connection to the push service succeeds, one of the previously-mentioned application delegate methods will be called.
On iOS, push notifications use the cellular data network whenever possible, even if the device is currently using Wi-Fi for other network activity such as web browsing or email. However, the push service will fall back to Wi-Fi if cellular data service isn't available.
If your iOS device is capable of using the cellular data network, check that it has an active cellular data plan. Turn off Wi-Fi in Settings and see if you can still browse the web with Safari, for example. On the other hand, if the push service is using Wi-Fi, any firewalls between your device or computer and the Internet must allow TCP traffic to and from port 5223.
Note: There is a separate persistent connection to the push service for each environment. The operating system establishes a persistent connection to the sandbox environment for development builds, while ad hoc and distribution builds connect to the production environment.

iOS或OS X会试图与push service建立一个持久的网络连接,如果delegate没有回调application:didRegisterForRemoteNotificationsWithDeviceTokenapplication:didRegisterForRemoteNotificationsWithDeviceToken,意味着连接未建立。应用会继续运行,而不是将其当作一个错误,只是禁用通知相关的功能。
(作者按:所以有时拿不到token时不走didRegisterForRemoteNotificationsWithDeviceToken方法,因为连接还未建立。)
这个问题与网络状况有关,比如没联网啥的,请记住,网络可用性可能经常变化,一旦push服务的持久连接成功,前面提到的应用程序委托方法之一将被调用。
在iOS上,推送通知会尽可能使用手机数据网络,即使设备目前正在使用Wi-Fi。不过,如果无法提供蜂窝数据服务,推送服务将回落到Wi-Fi。
如果你的iOS设备能够使用移动数据网络,检查是否能正常浏览网页。另一方面,如果推送服务使用Wi-Fi,那么您的设备与互联网之间的任何防火墙都必须允许往来于5223端口的TCP通信。
注意:每个环境都有一个到推送服务的独立持久连接。操作系统为Development包建立到沙箱环境的持久连接,而Ad-Hoc和distribution包连接到生产环境。

Some Notifications Received, but Not All 只收到一部分推送

If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one.
Here's why. The device or computer acknowledges receipt of each notification. Until the push service receives that acknowledgment, it can only assume that the device or computer has gone off-line for some reason and stores the notification in the quality of service (QoS) queue for future redelivery. The round-trip network latency here is of course a major factor.
As described in the Local and Remote Notification Programming Guide, the QoS queue holds a single notification per app per device or computer. If the service receives another notification before the one in the queue is sent, the new notification overwrites the previous one.
If your notification payload contains the content-available key, your app will receive the notification if iOS or OS X determines it is energy-efficient to do so. If the energy or data budget for the device has been exceeded, your app will not receive any more notifications with the content-available key until the budget has been reset. This occurs once a day and cannot be changed by user or developer action. This throttle is disabled if the app is run from Xcode, so be sure to test your app by running it from the device to have the same user experience your customers will have.
All of this points out that the intent is that a notification indicates to an app that something of interest has changed on the provider, and the app should check in with the provider to get the details. Notifications should not contain data which isn't also available elsewhere, and they should also not be stateful.
Any push notification that isn't delivered immediately was queued for future redelivery because your device was not connected to the service. "Immediately" of course needs to take latency for your connection into account. Outlying cases would be beyond 60 seconds as APNs will time out at that point.

如果你在短时间内向同一设备或计算机发送多个通知,推送服务将只发送最后一个通知。
在推送服务收到确认之前,它只能假设设备或计算机出于某种原因离线,并将通知存储在服务质量(QoS)队列中以备将来重新发送。这里的往返网络延迟当然是一个主要因素。
正如在本地和远程通知编程指南中描述的那样,QoS队列为每个应用程序、每个设备或计算机保存单个通知。如果服务在发送队列中的通知之前收到另一个通知,新的通知将覆盖前一个通知。
任何没有立即发送的推送通知都将排队等待将来的重新发送,因为你的设备没有连接到服务。“立即”当然需要考虑连接的延迟。久的情况将超过60秒,因为此时apn将超时。

IP Address Range Used by the Push Service 推服务使用的IP地址范围

Push providers, iOS devices, and Mac computers are often behind firewalls. To send notifications, you will need to allow inbound and outbound TCP packets over port 443 for the HTTP/2 provider API or port 2195 for the binary provider API.
To reach the feedback service, you will need to allow inbound and outbound TCP packets over port 2196.
Devices and computers connecting to the push service over Wi-Fi will need to allow inbound and outbound TCP packets over port 5223, or port 443 for a fallback when devices can’t reach APNs on port 5223.
OS X systems will also need to allow inbound and outbound TCP traffic over port 80.
The IP address range for the push service is subject to change; the expectation is that providers will connect by hostname rather than IP address. The push service uses a load balancing scheme that yields a different IP address for the same hostname. However, the entire 17.0.0.0/8 address block is assigned to Apple, so you can specify that range in your firewall rules.

总结下:需要允许443、2195、5233端口。OS X还要允许80。

Resetting the Push Notifications Permissions Alert on iOS 重置iOS上的推送通知权限alert

The first time a push-enabled app registers for push notifications, iOS asks the user if they wish to receive notifications for that app. Once the user has responded to this alert it is not presented again unless the device is restored or the app has been uninstalled for at least a day.
If you want to simulate a first-time run of your app, you can leave the app uninstalled for a day. You can achieve the latter without actually waiting a day by following these steps:
1.Delete your app from the device.
2.Turn the device off completely and turn it back on.
3.Go to Settings > General > Date & Time and set the date ahead a day or more.
4.Turn the device off completely again and turn it back on.

应用首次注册推送通知时,询问用户是否希望接收通知,一旦用户回应这个alert不会再提出,除非设备恢复或应用程序卸载了至少一天。
如果你想模拟第一次运行你的应用,你可以把应用卸载一天。也可以通过以下步骤不用等一天就能实现:
1.从设备上删除你的应用程序。
2.完全关闭设备,然后再开机。
3.进入设置 > 通用 > 日期和时间,并将日期提前一天或更久。
4.再次完全关闭设备,然后再开机。

你可能感兴趣的:(iOS Push Notifications官方故障排查指南)