无声推送没有传递到iOS 11上的应用程序
我注意到在iOS 11 beta 2中，无论应用程序的状态（背景/前景）如何，静默通知都不会传递到application:didReceiveRemoteNotification:fetchCompletionHandler 。
我实现了UIApplicationDelegete方法的application:didReceiveRemoteNotification:fetchCompletionHandler和我发送下面的沉默推
{ "aps": { "content-available": 1 }, "mydata": { "foo": "bar" } }
但在iOS 11上不调用委托方法。
它在其他版本的iOS上工作正常，文档部分configuration无提示通知没有提到应该做什么。
这是在iOS 11中的错误还是我错过了iOS 11中的新东西？
请注意，我不是在谈论或使用UserNotification框架，不应该需要发送无声推送。
这里是一个示例项目 ，说明了这个问题（你必须设置你自己的包ID）
当您午餐示例项目，并发送一个以上的有效载荷的应用程序，您可以使用macOS控制台，看到推送正确传递到设备，而不是应用程序。
更新10.08
看来，这种行为是随机的。 有时在重新启动设备后，有效负载会正确传送，但一段时间后会停止工作。
正如您在下面的屏幕截图中所看到的，标记为1的推送仅针对设备，推送2（设备重新启动后）也会发送到应用程序。
更新14.08 – iOS 11 Beta 6
还是一样的行为。 另一件应该工作，但不是以下。 当应用程序的scheme设置为“等待可执行文件被启动”时，无声推送应该唤醒应用程序并在后台启动。
更新21.08 – iOS 11 Beta 7
还是一样的行为，而不是在bug报告中从苹果更新。
更新29.08 – iOS 11 Beta 8
仍然是同样的问题。 我现在使用的重现步骤如下：
- 在Xcode项目scheme中，select“等待可执行文件启动”
- 在
didReceiveRemoteNotification: fetchCompletionHandler添加一个断点 - 在设备上启动应用程序
- 发送上面的沉默推
预期 ：该应用程序从暂停状态进入后台， didReceiveRemoteNotification: fetchCompletionHandler被调用
实际 ：没有任何反应
更新06.09 – iOS 11 Beta 10
我仍然有相同的错误行为。 苹果机票更新了以下答案：
Apple开发者关系2017年9月6日，10:42 PM工程部门就此问题提供了以下反馈意见：
我们能够运行示例应用程序并testing行为。 我们没有看到任何问题，当我们testing如上所述。
在后台运行时，推送不能保证到达应用程序，这里的日志表明我们不相信该应用程序正在使用足够的时间来启动它。
当条件好的时候，我们确实看到我们不时地推挤。
我们相信这是正确的行为。
11.09更新
我的苹果缺陷报告已经closures，并且标记为33278611重复，仍然是开放的
更新13.09 – iOS 11 GM
感谢kam800的评论（见下文），我做了更多的testing，并提出了这些意见：
在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
延期交货问题
- 当数据推送递送推迟并且应用程序启动时，数据推送仅在达到可以在未来几分钟的递送date时递送。 这完全失败了使用数据推送的目的，以保持新的应用程序的内容准备下一次发射。 我在这里再次引用苹果的文档：
“无声通知可帮助您保持应用程序的最新状态，即使在未运行时也能改善用户体验。”
- 当两个数据推送到一个暂停的应用程序，他们被推迟了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 10上正确传送时，从未在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
所以iOS 11.1 beta 1发布说明
iOS 11.1 beta 1刚刚发布，他们提到：“通知已解决的问题•无声推送通知处理更频繁（33278611）
我做了一些testing，似乎确实是固定的：
暂停状态
当我以暂停模式启动应用程序并发送无声推送时，应用程序将返回到后台，并调用didReceiveRemoteNotification:fetchCompletionHandler委托。
前景状态
以同样的方式，当应用程序在前台，并发送一个无声的推，委托似乎被调用的预期。 这是以前的iOS 11版本随机不工作，所以我会在更多的testing后证实这一点。
只是想在这里增加我的2美分，因为我也受到这个问题的影响，我注意到苹果已经closures了这个问题上的几个雷达，说他们不能复制。 我发现一个有趣的事情是，如果应用程序连接到debugging器后台，推送将被传递。
如果我杀了debugging器，拔下手机，启动应用程序，并发送静默推送有效载荷我看到应用程序不醒来。 我在控制台日志中看到系统取消了将有效载荷传送到我的应用程序。
我已经提交了一个小样本的应用程序，再现了这个问题的雷达。 我也在雷达中明确指出，在我的票上工作的人不得运行附加到debugging器的应用程序来重现此问题。 以下是链接： https ： //bugreport.apple.com/web/ ?problemID = 34461063
希望这会在这个问题上取得一些进展。
看起来像是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得分高到足以接受一个沉默的推动。
苹果没有提供关于这个iOS端行为的官方信息，只有关于服务器端调节的信息：
无声通知并不意味着让您的应用在后台保持清醒状态，也不意味着高优先级更新。 APN将无声通知视为低优先级，如果总数过多，APN可能会将其交付完全限制在一定程度上。 实际限制是dynamic的，可以根据条件进行更改，但不要每小时发送一次以上的通知。
我保持我的手指交叉他们改变了这种行为，因为这将修复我的应用程序:)另一方面，这种变化是很好的 – 使iPhone电池持续时间长的Android手机的许多事情之一。
苹果开发者关系刚刚给我的雷达添加了一条评论：
我们相信这个问题已经在最新的iOS 11.2 beta中解决了。
请使用最新的iOStesting版进行testing。 如果您仍然有问题，请使用任何可能帮助我们调查的相关日志或信息来更新错误报告。
目前正在安装iOS 11.2 beta – 将testing静默推送行为
iOS 11.1 beta版本说明包括：已解决的通知无声推送通知处理更频繁。 （33278611）
iOS 11.1 Beta 2也包含
Notifications Resolved Issues • Silent push notifications are processed more frequently. (33278611)
在发行说明 – 将现在testing它。
更新 – 11.10.2017 – iOS 11.1 Beta 2
在“真实世界的场景”中使用我们的应用程序2天后，看起来这个版本的iOS有一个真正的改进。 我谨慎地开始相信这是固定的。
苹果刚刚发布了官方（万圣节版）的iOS11.1
所以这确实是iOS 11中的一个错误，现在已经在iOS 11 beta 3中修复了。当在前台或后台接收到无声推送时， application:didReceiveRemoteNotification:fetchCompletionHandler现在可以正确调用。
UPDATE
不，它不是固定的，现在还在iOS beta 3和4中发生
作为一种解决方法我们正在添加一个“通知”键和一个空string作为值的“标题”。 这是唤醒appDelegate中的didReceivecallback。
我有我的应用程序类似的问题，直到iOS 10我得到推送通知和application:didReceiveRemoteNotification:fetchCompletionHandler得到正确调用。但更新到iOS 11推送通知停止工作。
我的代码问题是，即使我在推送通知有效内容中使用content-available：1和mutable-content：1，后台提取选项未打开。 但是直到iOS 10才完美运行。
在打开背景获取function后，它正在工作
