iOS 静默通知有多可靠？

Question

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

我读到了这种无声通知，它们似乎非常不可靠。

1. 首先按照这个： “如果有东西强制退出或杀死应用程序，系统会丢弃保留的通知。”。 https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app 可以丢弃静默通知。据我了解，强制退出意味着您双击主屏幕按钮并向上滑动应用程序，对吗？
2. 其次，根据这个https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app，苹果不建议每小时发送超过3-4个无声通知。你有这种行为的经验吗？如果您每小时发送 15 条通知，您收到了多少？

如果我上面写的是真的，那我有什么替代静默通知的方法？

我相信远程通知（例如警报类型）不受上述两点的影响，对吧？即使你强行杀死应用程序，你仍然会得到它们。

我知道有一些堆栈溢出问题涵盖了该主题的部分内容，但它们已经很老了。

Answer 1

我了解静默通知和远程通知是不同的东西。静音只是一个普通的推送通知，它不会向用户生成任何类型的警报，它直接进入通知中心，但在某个地方仍然有一个隐藏的通知。请注意，文档没有在任何地方提及 silent。

现在，远程通知可以真正满足您的需求。这种通知不会向最终用户产生任何类型的警报，它只是传递给您的 AppDelegate 方法的有效负载，这样您就可以生成对您的应用程序的异步调用以通知发生了一些外部事件，并且对此采取一些措施，例如更新您的本地数据库。

问题是，远程通知依赖于相同的 APNS 基础架构，Apple 不保证通知的传递。尽管现在失败率往往非常低，但您应该意识到您不能依赖通知来处理严重的业务逻辑。后台更新更多是一种让您的本地状态同步并在用户打开应用程序时立即可用的方法，但它并不能让您在打开应用程序时不必手动触发同步逻辑。

关于具体的项目符号：

1. 问题是，iOS 管理收到的通知并优化向您的应用程序的传递。当您的应用程序处于后台或停止状态时，可以接收通知。如果您已向用户发送通知，并且 iOS 在您的应用程序处于后台时将其缓存，然后用户强行杀死您的应用程序，则此通知将丢失。这应该是一种非常罕见的情况，但可能会发生。

2. 我个人对这种通知吞吐量的东西没有经验。我相信这可能与这样一个事实有关，即当发送通知并且您的应用程序处于后台时，iOS 将在后台运行它以传递通知并让您有机会处理它。根据通知的数量，操作系统可能会对后台处理施加限制以节省电池或其他系统资源。

所以，我不知道您的功能要求，但我认为远程通知基础架构对于本地状态的小更新而言并不可靠。