FCM 上游消息传递的可靠性如何？

Posted 2023-05-06

【中文标题】FCM 上游消息传递的可靠性如何？

【英文标题】：How reliable is FCM upstream message delivery?

【发布时间】：2017-01-27 15:26:37

【问题描述】：

Firebase Cloud Messaging 上游消息（从设备到服务器的消息）的文档描述了如果设备离线，消息如何排队等待传递。

android:

在设备离线或 FCM 服务无法将上游消息转发到您的服务器的情况下，Android 客户端应用实例最多可累积 20 条待处理消息。

ios:

FCM 客户端库将消息缓存在客户端应用程序上，并在客户端具有活动服务器连接时发送。

但是，如果应用程序在消息传递之前关闭怎么办？连接恢复后，Firebase 是否会尝试使用任何类型的后台服务来传递此类消息？或者它们是在等待下次打开应用程序之前排队，还是完全丢弃？

编辑：在我的实验中，至少有一个持久队列可以在应用重新启动时保存消息。但我仍然不确定（在每个操作系统上）什么情况会导致 Firebase 消息服务运行或不运行，尤其是当应用程序处于后台时。

【参考方案1】：

在您提到的 iOS 部分中，它明确指出：

FCM 客户端库缓存客户端应用上的消息，并在客户端具有活动的服务器连接时发送。

话虽如此，我认为 Android 也是如此。只要没有为客户端应用程序清除缓存，就可以肯定地说数据仍然存在。但是，记住@DanHulme 在answer 中提到的内容也很好：

缓存的后台进程

不要忘记，即使后台进程停止运行，Android 也会将它们保留在内存中，除非/直到另一个进程需要使用该内存。如果应用程序被“停止”，则它没有使用任何资源，即使 Android 将其保存在内存中也是如此。

所以我认为你最好在你的客户端应用程序中实现一个检查器，无论上游消息是否成功发送，并在以后重新发送它（当连接已经可用）如果没有。

【讨论】：

您引用的文档提到了缓存，但没有说明缓存是否是持久的。也就是说，在我的实验中证明是这样的。我仍然好奇的是，Firebase 消息传递服务在什么情况下会真正处于活动状态并尝试发送消息。 （另外，关于 TTL 的无关更正：当不包含 TTL 时，它默认为 0，这意味着消息要么立即发送，要么被丢弃。）

@ArthurDenture 话虽如此，我想问题应该更多地在于 Android（或 iOS，取决于设备）缓存持久性，而不是 FCM 上游消息传递。对于 TTL，可以肯定的是，here 表示 默认超时为 4 周，除非设置了 time_to_live 标志。

该链接描述了下游消息。对于上游消息，the default ttl value is 0.

@ArthurDenture 绝对是我这边关于上游 TTL 的错误。感谢您指出了这一点。 :) 尽管如此，我认为问题仍然在于设备的缓存持久性（我认为这在 Android 上可能会有所不同，具体取决于设备操作系统和型号）。