在测试向我的应用程序传递静默通知(有效负载中具有“content-available”:1的通知)时,我注意到在设备重新启动后通知不会被传递。如果应用程序在后台或前台运行,则发送相同的有效负载有效,但是在设备重新启动后,我没有在AppDelegate
中收到didReceiveRemoteNotification:
回调。
这种情况在iOS 13和iOS 12上都发生。
在测试向我的应用程序传递静默通知(有效负载中具有“content-available”:1的通知)时,我注意到在设备重新启动后通知不会被传递。如果应用程序在后台或前台运行,则发送相同的有效负载有效,但是在设备重新启动后,我没有在AppDelegate
中收到didReceiveRemoteNotification:
回调。
这种情况在iOS 13和iOS 12上都发生。
您的通知可能被系统延迟了一段时间后才会传递。您可以使用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秒后,静默通知已成功传递到我的应用程序!✌