iOS 設備重啟后未發送靜默推送通知

Question

在測試向我的應用程序發送靜默通知（在有效負載中具有“內容可用”：1 的通知）時，我注意到，在設備重新啟動后不會發送通知。 如果應用程序在后台或前台運行，則發送相同的有效負載是有效的，但是在設備重新啟動后，我沒有在AppDelegate中收到didReceiveRemoteNotification:回調。

這發生在 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 ，在這種情況下，在發生神秘的“ThunderingHerd”事件后至少需要 300 秒

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

之后，按照日志流，我注意到系統會多次評估此ThunderingHerdPolicy ， 300 秒后，靜默通知有效地傳遞到我的應用程序！ ✌

因此，如果您正在測試靜默通知的傳遞，請記住在某些情況下它可能會被系統延遲（正如 Apple 在文檔中所說）。 在設備重新啟動后發生這種情況。

請注意，此行為沒有正式記錄，並且在 iOS 的未來版本中可能會發生變化。 您不應依賴它，而僅將其用於調試目的。