Android 发送Firebase主题消息时是否存在预期的延迟带？当主题的订户数量较多时，延迟带是否会恶化？

我们目前正在使用Firebase消息向React本机应用程序（iOS和Android）中特定屏幕上的所有活动用户发送主题数据消息。在登台环境中测试行为时，我们没有太多明显的延迟，甚至在生产环境中的一些流量较低的区域使用这种延迟，延迟可以接受（通常<1秒，但不会超过几秒）。现在，我们正尝试在流量更大的用例（几千个并发活动用户）中使用相同的功能，并且发现在发送消息和最终用户实际接收消息之间存在相当大的延迟（至少十几秒，有时甚至超过一分钟）

我知道Firebase主题消息“针对吞吐量而不是延迟进行了优化”（），但我认为（可能是错误的）我们在流量较低的用例中看到的几秒钟延迟是典型的，而不是随着活动用户的增加而增加。是否有任何文档描述Firebase主题消息的预期延迟范围？我们试图避免跟踪所有用户向自己发送直接消息所需的开销，这就是为什么我们将消息发送到主题

关于这个用例，还有几件事：

• 用户设备上的应用程序处于活动状态，因此这与应用程序处于后台/非活动状态或作为通知接收消息无关
• 发送的消息不需要任何类型的安全性，因此我们使用主题时不必担心这一点

---

如果服务拥挤（不取决于项目），FCM可能会从几乎瞬间变化到最多一小时或更长时间。一些人已经找到了适合在时间关键型应用程序中使用近即时消息的替代方案

---

一个流行的例子是：

啊，这是一个巨大的麻烦，是这个用例的一个破坏者。您知道成批直接设备id消息是否具有相同的弱点，或者延迟严格来说是一个主题消息问题吗？此外，您知道Firebase网站上是否记录了该响应时间？我找不到比“优化吞吐量而不是延迟”更重要的东西了。这是一个到处都是的问题，因为有几个因素在起作用——本机限制、主题限制等，再加上平均15分钟间隔的设备轮询时间。如果用户在您想要发送消息时打开了应用程序，您只需使用一个更快的数据库侦听器即可。总之，FCM尝试在3分钟的窗口内发送消息，但情况并非总是如此，这很少见，但在最坏的情况下，FCM上更可能会有30分钟的窗口。