iOS设备重启后未能接收到静默推送通知

Question

iOS设备重启后未能接收到静默推送通知

iosapple-push-notificationsios13silent-notification

4

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

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

- francybiga

我遇到了与静默推送通知相同的问题，在设备重新启动后它不会到达，但是我能够接收带有通知部分的普通推送通知。 - Omar Hassan

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- francybiga · Accepted Answer

简而言之：

您的通知可能被系统延迟了一段时间后才会传递。您可以使用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秒钟。

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

在跟踪日志流程后，我注意到系统一直在多次评估此ThunderingHerdPolicy，并且在300秒后，静默通知已成功传递到我的应用程序！✌

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

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