Question

在测试向我的应用程序发送静默通知（在有效负载中具有“内容可用”的消息：1）时，我注意到在重新启动设备后，通知没有传递。如果应用程序在后台或前景中运行，则发送相同的有效负载是可行的，但是在设备重启后，我在didReceiveRemoteNotification:中没有收到AppDelegate回调。

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

Answer 1

简而言之：

您的通知可能已被系统延迟，将在几分钟后发送。您可以使用Console.app来过滤系统日志，并尝试找出场景中正在发生的事情。

更多详细信息：

经过几次尝试，我对操作系统的交付机制有了一些了解，可以帮助您了解场景中正在发生的事情。

通过在macOS上使用 Console.app ，选择您所连接的设备，并过滤名为“ dasd” 的进程的日志，该进程包含捆绑软件标识符（输入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秒后，静默通知已有效地传递到我的应用程序！? ✌?

因此，如果您正在测试静默通知的传递，请记住在某些情况下它可能会被系统延迟（如Apple在docs中所说）。重启设备后，情况确实如此。

请注意，此行为尚未正式记录，并且在将来的iOS版本中可能会更改。您不应该依赖于此，而只能将其用于调试目的。

设备重启后未传递iOS静音推送通知

1 个答案:

简而言之：

更多详细信息：