Ios 并非每次推送通知都会调用DidReceiveEmoteNotification

似乎如果我同时向同一设备发送多个推送通知，则不会为发送的每个通知调用

didReceiveMemotentification

。假设我发送了6个通知，

didReceiveMemotentification

平均只被调用3次。如果应用程序当前正在运行。但是，如果我在应用程序之外并发送了6个推送通知，则所有推送通知都将发送到通知中心/锁定屏幕。这是预期行为吗？

这是预期行为：

Apple推送通知服务包括默认的服务质量 （QoS）执行存储转发功能的组件

如果APNs试图发送通知，但设备处于脱机状态， 通知将存储一段有限的时间，然后发送 当设备可用时，发送到设备

仅存储特定应用程序的一个最近通知。 如果在设备脱机时发送多个通知，每个 新通知会导致放弃以前的通知。这 仅保留最新通知的行为称为 合并通知

如果设备长时间处于脱机状态，则任何通知 因为它被丢弃而被存储

在您的情况下，设备处于联机状态，但需要注意的是，APN仅为您的应用程序为每个设备存储一个通知。假设您一次发送3个通知。当第二条消息到达时，APN服务器正在向设备发送第一条消息。它存储第二条消息。然后第三条消息在第一条消息仍在传递时到达，因此第三条消息覆盖第二条消息，而第二条消息永远不会被传递

下面是另一句你可能会觉得更令人信服的话：

已收到部分通知，但并非全部

如果要向同一设备发送多个通知，或 计算机在短时间内，推送服务将发送 只有最后一个

原因如下。设备或计算机确认收到了每个 通知。在推送服务收到该确认之前，它将 只能假设设备或计算机已脱机一段时间 推理并将通知存储在服务质量（QoS）中 排队等待将来的重新交付。这里的往返网络延迟是 课程是一个主要因素

如《本地和推送通知编程指南》中所述 QoS队列为每个设备或计算机的每个应用程序保存一个通知。 如果服务在中的通知之前收到另一个通知 发送队列时，新通知将覆盖上一个通知

所有这些都表明，其目的是通知 向应用程序指示计算机上感兴趣的内容已更改 提供商，应用程序应与提供商签入以获取 细节。通知不应包含不同时存在的数据 在别处可用，它们也不应该是有状态的

任何未立即传递的推送通知都已排队等待 由于您的设备未连接到服务器，因此将来将重新交付 服务“立即”当然需要为您的 连接考虑在内。边远地区的病例将超过60秒 APN将在该点超时

---

Hmmm…这似乎与“设备离线时”有关。在我的场景中，设备是在线的，因此我不太相信这是预期的behavior@MobileMon请参阅我的最新答案。即使在设备处于活动状态时也会出现这种行为，假设您发送消息的速度比APN服务器发送消息的速度快。