iOS的静默通知有多可靠？

Question

4

我需要通过推送通知来扩展我的应用功能。期望的结果是发送静默通知，这会触发本地通知的创建。

我了解到这些静默通知似乎非常不可靠。

首先，根据此文献： “如果某些内容强制退出或停止运行应用程序，则系统将丢弃保留的通知。” https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app 静默通知可能会被丢弃。从我理解的角度看，强制退出是指您双击主屏幕按钮并向上滑动应用程序，对吗？
其次，根据此文献 https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app ，苹果公司不建议每小时发送超过3-4个的静默通知。您有没有这方面的经验？如果您在一个小时内发送15个通知，您收到了多少个？

如果我上面所说的是正确的，那么我有哪些替代静默通知的选择？

我相信远程通知（例如警报类型）不会受到上述两点的影响，即使您强制退出应用程序，仍然会收到通知。

我知道有些stackoverflow问题涵盖了这些主题的部分内容，但它们相当旧。

- Claudiu

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rafael Veronezi · Accepted Answer

我知道静默通知和远程通知是不同的东西。静默通知只是一种常规推送通知，不会向用户生成任何警报，它直接进入通知中心，但仍然有一个隐藏的通知。请注意，文档中没有提到“静默”。

现在，远程通知才是您需要的真正解决方案。这种通知不会向最终用户产生任何警报，它只是传递到您的AppDelegate方法中的有效负载，这样您就可以生成异步调用以通知应用程序发生了某些外部事件，并采取一些行动，例如更新本地数据库。

问题在于，远程通知依赖于相同的APNS基础架构，而苹果不保证通知的传递。尽管现在故障率往往非常低，但您应该意识到不能依赖通知进行严肃的业务逻辑。后台更新更多地是一种使您的本地状态与用户打开应用程序时立即可用的手段，但这并不能使您免于在打开应用程序时手动触发同步逻辑。

所以关于具体的要点：

问题在于，iOS 管理接收到的通知并优化将其传递给您的应用程序。通知可以在您的应用程序处于后台或停止状态时接收到。如果您向用户发送了通知，并且 iOS 在您的应用程序处于后台时将其缓存，然后用户强制关闭了您的应用程序，则此通知将丢失。这可能是一个非常罕见的情况，但确实可能发生。
我个人没有关于通知吞吐量的经验。我相信这可能与以下事实有关：当通知被发送且您的应用程序处于后台时，iOS 将在后台运行它以传递通知并让您有机会处理它。根据通知的数量，操作系统可能会对后台处理施加限制，以保留电池或其他系统资源。

因此，我不知道您的功能要求，但我认为远程通知基础设施对于本地状态的小型更新而言并不可靠。