我正处于开发在智能手机（Android 或 iOS）上使用的新应用程序的概念阶段，所有实际工作都在服务器上进行。如果部署为智能手机应用程序，它将在 MAUI 中完成，否则它只是一个浏览器应用程序。决定因素是推送通知。应用程序需要近乎实时地将推送通知传送到目标设备（可以容忍长达 1 分钟的延迟，但理想情况下不超过几秒）。无论设备上的应用程序状态如何，通知传递都必须发生，即应用程序不必处于前台/活动/运行状态，如果作为浏览器应用程序实现，则浏览器不必运行。
我熟悉（并且已经实现）使用 WNS 的 Windows Phone 解决方案，因此对（现已过时的）单一供应商生态系统中的需求和可能性有很好的了解，但现在正在考虑混合世界中的当前平台。我知道 Azure 通知中心，并且看到过 Firebase 的提及，但我没有找到任何明确的“操作方法”路径，没有看到提及任何其他选项，也没有看到任何关于可用之间权衡的讨论选项。
无论浏览器状态如何，纯粹基于浏览器的应用程序都可以接收推送通知吗？即所有现代智能手机浏览器都支持“后台”推送通知吗？如果是这样，我在哪里可以找到有关设备如何注册接收通知以及服务器如何向目标设备发送通知的相关文档？
如果现代浏览器在非活动状态下不支持推送通知，我的问题就转向 MAUI...Firebase 和 Azure Hub 是唯一可行的选择吗？对于每一个，MAUI 应用程序如何注册通知以及服务器如何发送通知？
我应该注意，消息接收者只能是移动设备，而不是桌面设备。
这里严格从 Android/iOS 的角度进行讨论，但您会发现您所提出的要求存在一些固有的问题。
应用程序需要向目标发送推送通知 设备近乎实时（可以容忍长达 1 分钟的延迟，但 最好不超过几秒钟）
Android 和 iOS 都不保证推送通知的发送，他们在 TOS 中声明了这一点。 Android 特别存在这样的问题：不同的设备制造商会破坏推送通知，因为它们试图推动过于激进的电池优化，因此只能在前台收到推送通知。如果您发送的消息过多，Android（也可能是 iOS）也会限制您的消息，并且每天可以发送的数量以及发送的通知类型都有上限。
严格来说Firebase对于Web有一些限制，浏览器需要Push API支持。在 iOS 上，需要将网页添加到主屏幕，并且根据兼容性矩阵，通知始终保持静音（即无噪音/振动）。您可以检查版本兼容性这里
我不熟悉 Azure 通知中心，但它的工作方式可能与 Firebase 类似，因为它们都需要使用内部系统 API 来推送通知才能在移动设备上工作。
您可以在此处
找到 Firebase 文档