ios - iOS 静默通知有多可靠？
问题描述
我需要通过推送通知扩展我的应用程序功能。期望的结果是发送静默通知，这将触发本地通知的创建。
我读到了这个无声通知，它们似乎非常不可靠。
- 首先根据这个：“如果有东西强制退出或杀死应用程序，系统会丢弃持有的通知。”。 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 个通知，您收到了多少？
如果我上面写的是真的，那么我有什么替代静音通知的方法？
我相信远程通知（例如警报类型）不受我上述两点的影响，对吧？即使您强行杀死该应用程序，您仍然会得到它们。
我知道有一些堆栈溢出问题涵盖了这个主题的一部分，但它们已经很老了。
解决方案
我知道静默通知和远程通知是不同的东西。静音只是一个普通的推送通知，它不会向用户生成任何类型的警报，它直接进入通知中心，但在某个地方仍然有一个隐藏的通知。请注意，文档在任何地方都没有提到静默。
现在，远程通知是真正满足您需求的交易。这种通知不会向最终用户产生任何类型的警报，它只是传递给您的AppDelegate方法的有效负载，这样您就可以对您的应用程序生成异步调用以通知发生了一些外部事件，并采取一些措施关于它，例如更新本地数据库。
问题是，远程通知依赖于相同的 APNS 基础设施，Apple 不保证通知的传递。尽管现在失败率往往非常低，但您应该意识到您不能依赖通知来处理严重的业务逻辑。后台更新更多是一种让您的本地状态同步并在用户打开应用程序时立即可用的方法，但它并不能让您在打开应用程序时不必手动触发同步逻辑。
那么关于具体的项目符号：
问题是，iOS 管理收到的通知并优化向您的应用程序的传递。当您的应用程序处于后台或停止状态时，可以接收通知。如果您已向用户发送通知，并且 iOS 在您的应用程序处于后台时将其缓存，然后用户强行杀死您的应用程序，则此通知将丢失。这可能是一种非常罕见的情况，但可能会发生。
我个人对这种通知吞吐量的东西没有经验。我相信这可能与这样一个事实有关，即当发送通知并且您的应用程序处于后台时，iOS 将在后台运行它以传递通知并让您有机会处理它。根据通知的数量，操作系统可能会对后台处理施加限制以节省电池或其他系统资源。
因此，我不知道您的功能要求，但我认为远程通知基础架构对于本地状态的小更新而言并不可靠。