从后台唤醒应用程序时 voip 推送和常规推送之间的区别答案

【问题标题】：Difference between voip push and regular push when waking app from background从后台唤醒应用程序时 voip 推送和常规推送之间的区别
【发布时间】：2017-12-14 01:19:43
【问题描述】：

我有一个用于定期推送通知的消息服务。例如，当一个用户发送消息时，另一个用户会收到带有该消息的推送通知。我注意到如果手机在 wifi 和 3g / 4g 上，并且应用程序被杀死（并且屏幕被锁定），则会收到通知。如果设备仅在wifi上并且应用被杀死（并且屏幕被锁定），则不会收到通知。

我的假设是，为了节省电池，设备会在一段时间后断开与 wifi 的连接，这就是为什么没有收到推送通知的原因。

但是当我使用 VOIP 推送通知时，情况就不同了。即使应用程序被杀死并且设备在 wifi 上（并且屏幕被锁定），也会收到通知。那么这是什么意思？如果手机与 wifi 断开连接，手机如何收到此通知？

我在这里错过了什么？

【问题讨论】：

当您的 iOS 设备进入睡眠模式时，我认为 wifi 不会完全断开连接。 iOS 上的 Wifi 芯片可能会遵循 Wake on Wireless LAN 等。总是提供 Voip Push 的原因是因为 VOIP 保证是实时的！所有其他非 voip 推送（包括静音通知）都不可靠，iOS 可能会选择性地丢弃它们以在睡眠模式下节省电池电量。

标签： ios apple-push-notifications voip

【解决方案1】：

此外，添加到 Sivajee Battina 的答案中，您可以在 guidelines 中阅读：

使用 PushKit 接收 VoIP 推送有很多优点：

只有在 VoIP 推送发生时才会唤醒设备，从而节省能源。

与标准推送通知不同，用户必须先回复您的应用程序可以执行操作，VoIP 推送直接进入您的应用程序进行处理。

VoIP 推送被视为高优先级通知并及时送达。

VoIP 推送可以包含比标准推送通知提供的更多的数据。

如果您的应用在收到 VoIP 推送时未运行，则会自动重新启动。

您的应用程序有运行时间来处理推送，即使您的应用正在后台运行。

因此，第三点确认您的标准推送通知在某些情况下可能会延迟，而 VoIP 推送通知将始终即时传递。

另外，请查看question，了解标准推送通知延迟或丢弃的原因。

【讨论】：

来自文档：“与 UserNotifications 框架支持的用户通知不同，PushKit 通知永远不会呈现给用户——它们不会呈现徽章、警报或声音。”
因此，可以安全地假设正常的推送通知是无用的，因为您的应用程序有可能处于屏幕锁定的终止阶段，并且推送通知不会唤醒设备。而 VOIP 始终是最好的，但如果将 VOIP 用作推送，苹果会拒绝该应用程序。现在该怎么办？
@Shubham1164 VoIP 推送应该只用于报告来电，普通推送通知应该用于其他一切。要使用 VoIP 推送，您的应用程序必须符合条件（例如：带有 VoIP 呼叫的消息应用程序），因此苹果将拒绝使用它但没有资格这样做的应用程序。此外，iOS 13 对 VoIP 推送带来了新的限制，使其无法报告非来电的内容。

【解决方案2】：

您在这方面几乎是正确的 - 这就是 VoIP 的工作原理。摘自Apple Docs：

过去，VoIP 应用必须维护一个持久的网络与服务器连接以接收来电和其他数据。这意味着编写复杂的代码来发送周期性的消息，并且在应用程序和服务器之间来回保持连接，即使当应用程序未使用时。这种技术导致频繁的设备唤醒浪费的能量。这也意味着如果用户退出 VoIP 应用程序，无法再接收来自服务器的调用。

开发者应该使用 PushKit 而不是持久连接框架——允许应用程序接收推送（通知）的 API 当数据可用时）来自远程服务器。每当推收到后，该应用程序将被调用。例如，一个 VoIP 应用程序可以接到电话时显示警报，并提供一个选项接听或拒绝来电。它甚至可以开始采取前期措施在用户决定接受的情况下发起呼叫。

【讨论】：

因此，可以安全地假设正常的推送通知是无用的，因为您的应用程序有可能在屏幕锁定的情况下处于终止阶段，并且推送通知不会唤醒设备。而 VOIP 总是最好的，但如果使用 VOIP 作为推送，苹果会拒绝该应用程序。现在该怎么办？