2

Die Dokumentation für Firebase Cloud Messaging Upstream-Nachrichten (Nachrichten vom Gerät an den Server) beschreibt, wie Nachrichten in die Warteschlange gestellt werden, wenn das Gerät offline ist.Wie zuverlässig ist FCM Upstream-Nachrichtenübermittlung?

Android:

In Fällen, in denen das Gerät offline ist oder der FCM-Dienst ist nicht verfügbar Upstream-Nachrichten auf Ihren Server, Android Client App-Instanzen maximal 20 anstehende Nachrichten akkumulieren weiterleiten können.

iOS:

Die FCM-Client-Bibliothek speichert die Nachricht auf der Client-Anwendung und sendet sie, wenn der Client eine aktive Server-Verbindung hat.

Aber was ist, wenn die App geschlossen ist, bevor die Nachricht zugestellt werden kann? Wird Firebase nach der Wiederherstellung der Verbindung versuchen, einen beliebigen Hintergrunddienst zur Übermittlung solcher Nachrichten zu verwenden? Oder werden sie in die Warteschlange gestellt, bis die App als nächstes geöffnet wird, oder werden sie vollständig verworfen?

Edit: in meinen Experimenten gibt es mindestens eine persistente Warteschlange, die Nachrichten über App-Neustarts speichert. Aber ich bin immer noch nicht sicher (auf jedem Betriebssystem), unter welchen Umständen der Firebase-Messaging-Dienst ausgeführt wird oder nicht, insbesondere wenn die App im Hintergrund läuft.

Antwort

0

Im iOS Teil, die Sie erwähnt haben, heißt es ausdrücklich, dass:

Die FCM-Client-Bibliothek Caches die Nachricht auf dem Client-Anwendung und es sendet, wenn der Client eine aktive Server-Verbindung hat.

Mit dem gesagt, ich denke, es ist auch der gleiche Fall für Android. Solange der Cache für die Client-App nicht freigegeben ist, sollte es sicher sein, dass die Daten immer noch da sind. Es ist aber auch gut im Auge zu behalten, was in diesen answer von @DanHulme erwähnt wurde:

Cached Hintergrund verarbeitet

Vergessen Sie nicht, dass Android Hintergrundprozesse im Speicher hält, auch wenn sie‘ Ich habe aufgehört zu laufen, außer/bis ein anderer Prozess diesen Speicher benutzen muss. Wenn die App "gestoppt" ist, werden keine Ressourcen verwendet, selbst wenn Android sie im Speicher hält.

Also ich denke, es wäre am besten für Sie einen Kontrolleur in der Client-Anwendung zu implementieren, ob die Upstream-Nachricht erfolgreich gesendet wurde, und um es zu einem späteren Zeitpunkt (erneut zu senden, wenn die Verbindung bereits verfügbar) wenn nicht.

+0

Die von Ihnen zitierte Dokumentation erwähnt einen Cache, aber es wird nicht angegeben, ob der Cache persistent ist. Das hat sich in meinen Experimenten als erwiesen erwiesen. Was mich interessiert, ist, unter welchen Umständen der Firebase-Messaging-Dienst tatsächlich aktiv ist und versucht, Nachrichten zu senden. (Auch eine nicht verwandte Korrektur über TTL: Wenn die TTL nicht enthalten ist, ist sie standardmäßig 0, was bedeutet, dass die Nachricht entweder sofort gesendet oder verworfen wird.) – ArthurDenture

+0

@ArthurDenture Ich denke, damit sollte die Frage mehr auf Android (oder iOS je nach Gerät) Cache-Persistenz und nicht mit der FCM Upstream-Nachricht Lieferung sein. Für die TTL ist ziemlich sicher, dass es [hier] (https://firebase.google.com/docs/cloud-messaging/concept-options) sagt, dass das * Das Standard-Timeout beträgt vier Wochen, es sei denn, das Flag 'time_to_live' ist gesetzt *. –

+1

Dieser Link beschreibt Downstream-Nachrichten. Bei Upstream-Nachrichten ist [der Standard-TTL-Wert 0] (https://firebase.google.com/docs/reference/android/com/google/firebase/messaging/RemoteMessage.Builder.html#setTtl (int)). – ArthurDenture

Verwandte Themen