设备重新启动后未发送iOS静默推送通知

Question

在测试向我的应用程序发送静默通知(有效负载中有"内容可用"的通知：1)时，我注意到，在设备重新启动后，不会发送通知。如果应用程序在后台或前台运行，则发送相同的有效载荷是有效的，但在设备重新启动后，我不会在AppDelegate中收到didReceiveRemoteNotification:回调。

这种情况在iOS 13和iOS 12 上都会发生

Answer 1

简而言之：

您的通知可能被系统延迟，将在几分钟后送达。您可以使用Console.app来过滤系统日志，并尝试弄清楚场景下发生了什么。

更多详细信息：

经过几次尝试，我对操作系统的交付机制有了一些了解，这有助于理解场景下发生的事情。

通过在macOS上使用Console.app，选择连接的设备并过滤名为"的进程的日志；CCD_ 3">包含您的捆绑包标识符(类型process:dasd any:YOUR_BUNDLE_ID)我发现系统实际上收到了远程静默通知，但取消了唤醒我的应用程序的尝试。

default    15:37:29.955974+0200    dasd    Submitted Activity: com.apple.pushLaunch.YOUR_BUNDLE_ID:7BAB0E at priority 5 <private>
default    15:37:29.958436+0200    dasd    Adding a launch request (<private>) for application <private> by activity <private>
default    15:37:29.958611+0200    dasd    Launch requests for <private>: (null)
default    15:37:29.972714+0200    dasd    com.apple.pushLaunch.YOUR_BUNDLE_ID:7BAB0E:[
{name: ThunderingHerdPolicy, policyWeight: 1.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{timeSinceThunderingHerdTriggerEvent < 300}]}}
], FinalDecision: Must Not Proceed}
default    15:37:33.505325+0200    dasd    Submitted Activity: com.apple.pushLaunch.YOUR_BUNDLE_ID:B3D6C8 at priority 5 <private>
default    15:37:33.509388+0200    dasd    Adding a launch request (<private>) for application <private> by activity <private>
default    15:37:33.509515+0200    dasd    Launch requests for <private>: <private>
default    15:37:33.509778+0200    dasd    Daemon Canceling Activities: {(
com.apple.pushLaunch.YOUR_BUNDLE_ID:7BAB0E
)}
default    15:37:33.510334+0200    dasd    CANCELED: com.apple.pushLaunch.YOUR_BUNDLE_ID:7BAB0E at priority 5 <private>!
default    15:37:33.510514+0200    dasd    Removing a launch request for application <private> by activity <private>
default    15:37:33.510693+0200    dasd    Don't have <private> for type 0
default    15:37:33.510865+0200    dasd    Don't have <private> for type 1
error    15:37:33.511162+0200    dasd    Activity <private> not tracked as being started, ignoring it

更确切地说，我发现有两个策略是由操作系统强制执行的：

• 一个BootTimePolicy，它在引导后至少需要120秒才能传递通知

{name: BootTimePolicy, policyWeight: 0.010, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[Minimum seconds after boot]: Required:120.00, Observed:103.62},]}}

• ThunderingHerdPolicy，在这种情况下，在错误的"时间"之后需要经过至少300秒；ThunderingHerd"；事件

{name: ThunderingHerdPolicy, policyWeight: 1.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{timeSinceThunderingHerdTriggerEvent < 300}]}}], FinalDecision: Must Not Proceed}

之后，根据日志流，我注意到系统不断评估此ThunderingHerdPolicy好几次，300秒后，无声通知有效地传递到了我的应用程序✌

因此，如果您正在测试静默通知的交付，请记住在某些情况下，系统可能会延迟(正如苹果在文档中所说)。设备重新启动后，情况恰好如此。

请注意，这种行为没有正式记录，这可能会在iOS的未来版本中发生变化。您不应该依赖它，而应该仅将它用于调试目的。