Silent Push-уведомление iOS не доставляется после перезагрузки устройства - PullRequest
Новая
       49

Silent Push-уведомление iOS не доставляется после перезагрузки устройства

0 голосов
/ 23 октября 2019

Во время тестирования доставки уведомлений в режиме без вывода сообщений (одно из которых имеет «content-available»: 1 в полезной нагрузке) в мое приложение, я заметил, что после перезагрузки устройства уведомления не доставляются. Отправка той же полезной нагрузки работает, если приложение работает в фоновом или переднем плане, но после перезагрузки устройства я не получаю ответный вызов didReceiveRemoteNotification: в AppDelegate.

Это происходит как на iOS 13, так и на iOS 12

1 Ответ

0 голосов
/ 23 октября 2019

Короче говоря:

Ваше уведомление, вероятно, было задержано системой и будет доставлено через несколько минут. Вы можете использовать Console.app для фильтрации системных журналов и попытаться выяснить, что происходит за кулисами.

Подробнее:

После нескольких попыток я получил некоторое представление о механизме доставкиоперационная система, которая может помочь понять, что происходит под сценой.

Используя Console.app в macOS, выбирая подключенное устройство и фильтруя журналы процесса с именем "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

Точнее я нашелиз-за того, что две политики применяются операционной системой:

  • a 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},]}}
  • a 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 говорит в * документы 1042 *). Это происходит после перезагрузки устройства.

Обратите внимание, что это поведение официально не задокументировано и может измениться в будущих выпусках iOS. Не следует полагаться на это, а использовать его только для целей отладки.

...