无声推送未在iOS 11上传送到应用程序

Question

我注意到在iOS 11 beta 2上,application:didReceiveRemoteNotification:fetchCompletionHandler无论应用程序的状态如何(背景/前景),都不会传递静默通知.

我实现了该UIApplicationDelegete方法,application:didReceiveRemoteNotification:fetchCompletionHandler并发送以下静默推送

{  
  "aps": {  
    "content-available": 1  
  },  
  "mydata": {  
    "foo": "bar"  
  }  
} 

但是在iOS 11上没有调用委托方法.

它在其他版本的iOS上工作正常,文档部分配置静默通知没有提到应该做的任何其他事情.

这是iOS 11中的错误还是我错过了iOS 11中的新功能？

请注意,我不是在讨论或使用UserNotification发送静默推送所不需要的框架.

这是一个说明问题的示例项目(您必须设置自己的包ID)

当您在示例项目中进行午餐并将上述有效负载发送到应用程序时,您可以使用macOS控制台查看推送是否已正确传递到设备,而不是应用程序.

更新10.08

看来行为是随机的.有时在重新启动设备后,有效负载会正确传送,但一段时间后它会停止工作.

正如您在下面的屏幕截图中看到的那样,标记为1的推送仅对设备进行了延迟,并且推送2(设备重启后)也会传送到应用程序.

更新14.08 - iOS 11 Beta 6

还是一样的行为.应该起作用的另一件事但不是以下.当应用程序的方案设置为"等待可执行文件启动"时,静音推送应该唤醒应用程序并在后台启动它.

更新21.08 - iOS 11 Beta 7

在错误报告中仍然是Apple的相同行为而不是更新.

更新29.08 - iOS 11 Beta 8

仍然是同样的问题.我现在使用的重现步骤如下:

• 在Xcode项目方案中,选择"等待可执行文件启动"
• 在中添加断点 didReceiveRemoteNotification: fetchCompletionHandler
• 在设备上启动应用
• 发送上面的静音推送

预期:应用程序从暂停状态进入后台并被didReceiveRemoteNotification: fetchCompletionHandler调用

实际:没有任何反应

更新06.09 - iOS 11 Beta 10

我仍然有同样的马车行为.来自Apple的门票更新了以下答案:

Apple Developer Relations 2017年9月6日,下午10:42关于此问题,Engineering提供了以下反馈:

我们能够运行示例应用程序并测试行为.当我们按照描述进行测试时,我们没有看到任何问题.

当应用程序在后台运行时,不保证推送到应用程序,这里的日志表明我们不相信应用程序的使用足以启动它.

我们确实看到我们在条件良好时不时提供推动.

我们相信这是正确的行为.

更新11.09

我的Apple错误报告已关闭,并标记为重复33278611仍然打开

更新13.09 - iOS 11 GM

感谢kam800的评论(见下文),我做了更多测试并得出了这些观察结果:

iOS 11 dasd DuetActivitySchedulerDaemon中似乎有一个新的守护进程要么完全丢弃数据推送,要么延迟数据推送:

交货推迟

控制台日志

default 13:11:47.177547 +0200   dasd    DuetActivitySchedulerDaemon CANCELED: com.apple.pushLaunch.net.tequilaapps.daylight:C03A65 <private>!   lifecycle   com.apple.duetactivityscheduler
default 13:11:47.178186 +0200   dasd    DuetActivitySchedulerDaemon Removing a launch request for application <private> by activity <private>   default com.apple.duetactivityscheduler
default 12:49:04.426256 +0200   dasd    DuetActivitySchedulerDaemon Advancing start date for <private> by 6.5 minutes to Wed Sep 13 12:55:31 2017   default com.apple.duetactivityscheduler
default 13:21:40.593012 +0200   dasd    DuetActivitySchedulerDaemon Activity <private>: Optimal Score 0.6144 at <private> (Valid Until: <private>)  scoring com.apple.duetactivityscheduler
default 13:21:40.594528 +0200   dasd    DuetActivitySchedulerDaemon Setting timer (isWaking=1, activityRequiresWaking=0) between <private> and <private> for <private>  default com.apple.duetactivityscheduler

推迟交货问题

• 当数据推送传递被推迟并且应用程序启动时,仅在达到交付日期时才传递数据推送,该日期可能是将来的几分钟.这完全违背了使用数据推送来保持新应用内容为下次发布做好准备的目的.我再次在这里引用Apple的文档:

"无声通知可以帮助您保持应用程序的最新状态,即使它没有运行,也能改善用户体验."

• 当两个数据推送发送到暂停的应用程序时,它们会被iOS 11推迟,而不是直接唤醒应用程序.达到交货时间时,仅交付最后一次数据推送!之前的推送丢失,并且未通过委托方法传递,从而导致数据丢失.

交货已取消

控制台日志

default 13:35:05.347078 +0200   dasd    DuetActivitySchedulerDaemon com.apple.pushLaunch.net.tequilaapps.daylight:C03A65:[
    {name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Must Not Proceed, Score: 0.00}}
 ], FinalDecision: Must Not Proceed}    scoring com.apple.duetactivityscheduler

取消交货问题

那么在这种情况下,数据推送完全丢失,并且在iOS 11上正确传送时从未在iOS 11上传送.

更新19.09 - iOS 11 GM

我还注意到,当应用程序在前台并且通知未发送到应用程序时,我在控制台中看到以下日志:

default 08:28:49.354824 +0200   apsd    apsd    <private>: Received message for enabled topic '<private>' onInterface: NonCellular with payload '<private>' with priority 10 for device token: NO   courier-oversized   com.apple.apsd

fault   08:33:18.128209 +0200   dasd    Foundation  <NSXPCConnection: 0x151eee460> connection from pid 55: Exception caught during decoding of received message, dropping incoming message.
Exception: Exception while decoding argument 0 (#2 of invocation):
Exception: value for key 'NS.objects' was of unexpected class 'NSNull'. Allowed classes are '{(
    NSArray,
    NSData,
    NSString,
    NSNumber,
    NSDictionary,
    NSUUID,
    _DASActivity,
    NSSet,
    _DASFileProtection,
    NSDate,
    NWParameters,
    NWEndpoint
)}'.    general com.apple.foundation.xpc

Answer 1

所以iOS 11.1 beta 1的发行说明说

iOS 11.1 beta 1刚刚发布,他们提到:"通知已解​​决的问题•更频繁地处理静默推送通知.(33278611)

我做了一些测试,似乎确实修复了:

暂停国

当我以挂起模式启动应用程序并发送静默推送时,应用程序将返回到后台并didReceiveRemoteNotification:fetchCompletionHandler调用代理.

前景状态

同样,当应用程序处于前台并发送静默推送时,代理似乎按预期调用.这在以前的iOS 11版本中随机无效,因此我将在更多测试后确认这一点.

Answer 2

我只想在这里加上我的2美分,因为我也受到了这个问题的打击而且我注意到苹果公司在这个问题上已经关闭了几个雷达表示他们无法重现.我发现一个有趣的事情是,如果应用程序在连接到调试器的同时进行后台处理,则会推送推送.

如果我杀了调试器,请拔掉我的手机,启动应用程序,然后发送静音推送有效负载,我看到应用程序没有被唤醒.我确实在控制台日志中看到系统取消了将负载传送到我的应用程序.

我已经提交了一个带有小样本应用程序的雷达,可以重现问题.我还在雷达中明确指出,在我的机票上工作的人不得运行连接到调试器的应用程序来重现问题.这是链接:https://bugreport.apple.com/web/ ?problemID = 34461063

希望这将在这个问题上取得一些进展.

Answer 3

看起来像iOS 11的新行为.iOS 11 beta 10提供了有关此问题的一些描述性日志:

default 23:18:51.806011 +0200   dasd    com.apple.pushLaunch.com.acme.Acme:F7E7D0:[
    {name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Can Proceed, Score: 0.50}}
    {name: BatteryLevelPolicy, policyWeight: 1.000, response: {Decision: Can Proceed, Score: 0.87, Rationale: [{batteryLevel == 62}]}}
    {name: DeviceActivityPolicy, policyWeight: 5.000, response: {Decision: Can Proceed, Score: 0.20}}
 ] sumScores:52.279483, denominator:81.410000, FinalDecision: Can Proceed FinalScore: 0.642175}
default 23:18:51.806386 +0200   dasd    'com.apple.pushLaunch.com.acme.Acme:F7E7D0' has compatibility score of 1.000000 with 'com.apple.CFNetwork-cc-111-79:E7272D'. Relaxing scores.
default 23:18:51.806855 +0200   dasd    'com.apple.pushLaunch.com.acme.Acme:F7E7D0' CurrentScore: 0.642175, ThresholdScore: 0.738454 DecisionToRun:0

看起来每个静音推送都会传送到iOS,但是dasd守护程序使用几个策略来决定是否应该向应用程序传送静音推送(例如电池电量).昨天晚上我设法接受了一次静音推送,但当时我的iPhone已连接到充电器 - 可能是BatteryLevelPolicy得分高到足以接受那个静音推送.

Apple没有提供有关此iOS端行为的官方信息,只有关于服务器端限制的信息:

静音通知并不意味着让您的应用程序在后台保持清醒,也不是用于高优先级更新.APN将无声通知视为低优先级,如果总数过多,可能会完全限制其传递.实际限制是动态的,可以根据条件进行更改,但尝试不要每小时发送多个通知.

我保持手指交叉他们改变了这种行为,因为这会修复我的应用程序:)另一方面,这种变化很好 - 许多事情之一使iPhone电池持续时间比Android手机更长.

Answer 4

iOS 11.1 beta版发行说明包括:通知已解决的问题更频繁地处理无提示推送通知.(33278611)

Answer 5

iOS 11.1 Beta 2也包含

Notifications
Resolved Issues
• Silent push notifications are processed more frequently. (33278611)

在发行说明中 - 将立即测试它.

更新 - 11.10.2017 - iOS 11.1 Beta 2

在"真实场景"中使用我们的应用程序2天后,看起来这个版本的iOS有了真正的改进.我小心翼翼地开始相信这是固定的.

Answer 6

Apple Developer Relations刚刚在我的雷达上添加了评论:

我们相信此问题已在最新的iOS 11.2测试版中得到解决.

请使用最新的iOS测试版进行测试.如果您仍有问题,请使用可帮助我们调查的任何相关日志或信息更新您的错误报告.

https://developer.apple.com/download/

目前正在安装iOS 11.2 beta - 将测试静默推送行为

Answer 7

所以这确实是 iOS 11 中的一个错误，现在已在 iOS 11 beta 3 中修复。现在，application:didReceiveRemoteNotification:fetchCompletionHandler当在前台或后台收到静默推送时，现在可以正确调用。

更新

不，它尚未修复，并且在 iOS beta 3 和 4 中仍然发生