在iOS 11上，静默推送没有传送到应用程序

Question

我注意到，在iOS 11 beta 2上，无论应用程序的状态如何（后台/前台），静默通知都不会传递到 。

null

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

但在iOS 11上不调用delegate方法。

null

这是iOS 11的bug还是我错过了iOS 11的新东西？

请注意，我不是在谈论或使用 框架，它不应该用于发送静默推送。

下面是一个示例项目，说明了这个问题（您必须设置自己的bundle id）

当您使用示例项目并向应用程序发送上述有效负载时，您可以使用macOS控制台查看推送是否正确地传递到设备，而不是应用程序。

这种行为似乎是随机的。有时在重新启动设备后，有效载荷被正确地传送，但它在一段时间后停止工作。

null

null

仍然是相同的行为，而不是苹果在错误报告中的更新。

还是同样的问题。我现在使用的复制步骤如下:

• 在Xcode项目方案中，选择“等待可执行文件启动/li>
• 在 ionhandler ode="" i=""> 中添加断点

应为:将应用程序从挂起状态带到后台，并调用

实际:什么都没有发生

我还是有同样的行为。来自苹果的罚单更新，答案如下:

苹果开发者关系部2017年9月6日10:42 PM工程部门就此问题提供了以下反馈:

我们能够运行示例应用程序并测试其行为。当我们按照描述进行html" target="_blank">测试时，我们没有发现任何问题。

当应用程序在后台运行时，推送不能保证到达应用程序，并且这里的日志表明我们不相信应用程序正在被使用到足以启动它。

我们确实看到我们不时地在条件好的时候提供推送。

我们认为这是正确的行为。

我的Apple bug报告已关闭，并标记为 的重复版本，该版本仍处于打开状态

感谢KAM800的评论（见下文），我做了更多的测试，得出了这些观察结果:

iOS 11中似乎有一个新的守护进程 ，它要么完全丢弃数据推送，要么延迟数据推送传递:

控制台日志

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

延期交付问题

“静默通知可以帮助您保持应用程序的最新状态，即使它没有运行，也能改善用户体验。”

控制台日志

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 10上它是正确交付的。

我还注意到，当应用程序在前台，通知没有传递到应用程序时，我在控制台中看到以下日志:

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

null

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端行为的官方信息，只有关于服务器端节流的信息:

静默通知并不是为了让你的应用程序在后台保持清醒，也不是为了高优先级的更新。APNs将静默通知视为低优先级，如果总数过多，则可能完全阻止其传递。实际的限制是动态的，可以根据条件变化，但尽量不要每小时发送多于几个通知。

我祈祷他们改变了这一行为，因为这将修复我的应用程序:）另一方面，这个改变是一个很好的改变，它使iPhone的电池续航时间比安卓手机更长。

Answer 2

我只是想在这里加上我的2美分，因为我也受到了这个问题的打击，我注意到苹果关闭了几个雷达在这个问题上，说他们不能复制。我发现的一个有趣的事情是，如果应用程序是后台的，而它连接到调试器，推送将被交付。

如果我关闭调试器，拔掉我的手机，启动应用程序，并发送静默推送有效负载，我会看到应用程序没有被唤醒。我确实在控制台日志中看到系统取消了对我的应用程序的有效负载的交付。

我已经提交了一个雷达和一个小的样例应用程序，重现了这个问题。我还在雷达中明确指出，处理我的票证的人不能运行连接到调试器的应用程序来重现问题。以下是链接:https://bugreport.apple.com/web/？problemid=34461063

希望这将导致在这个问题上取得一些进展。

Answer 3

所以iOS 11.1 beta 1的发布说明中说

iOS 11.1 beta 1刚刚发布，其中提到:“通知解决问题•静默推送通知处理频率更高。（33278611）

我做了一些测试，看起来确实修复了:

当我以挂起模式启动应用程序并发送静默推送时，应用程序将返回后台并调用 委托。

同样，当应用程序处于前台并且发送了静默推送时，委托似乎会像预期的那样被调用。这在之前的iOS11版本中是随机不起作用的，所以我将在更多的测试后确认这一点。