Firebase Cloud Messaging (FCM) bietet eine breite Palette von Messaging-Optionen und -Funktionen. Die Informationen auf dieser Seite sollen Ihnen helfen, die verschiedenen Arten von FCM-Nachrichten und deren Möglichkeiten besser zu verstehen.
Mitteilungstypen
Mit FCM können Sie zwei Arten von Nachrichten an Clients senden:
- Benachrichtigungen, die manchmal als „Angezeigte Nachrichten“ bezeichnet werden. Sie werden automatisch vom FCM SDK verarbeitet.
- Datennachrichten, die von der Client-App verarbeitet werden.
Benachrichtigungen enthalten vordefinierte Schlüssel, die für den Nutzer sichtbar sind. Datennachrichten enthalten dagegen nur Ihre benutzerdefinierten Schlüssel/Wert-Paare. Benachrichtigungen können eine optionale Datennutzlast enthalten. Die maximale Nutzlast für beide Nachrichtentypen beträgt 4.096 Byte, es sei denn, wenn Nachrichten über die Firebase Console gesendet werden, für die eine Beschränkung von 1.000 Zeichen erzwungen wird.
| Anwendungsszenario | Senden | |
|---|---|---|
| Benachrichtigung | Das FCM SDK zeigt die Nachricht für Endnutzergeräte im Namen der Client-App an, wenn sie im Hintergrund ausgeführt wird. Wenn die App beim Empfang der Benachrichtigung im Vordergrund ausgeführt wird, bestimmt der Code der App das Verhalten. Benachrichtigungen bestehen aus einem vordefinierten Satz von für den Nutzer sichtbaren Schlüsseln und einer optionalen Datennutzlast mit benutzerdefinierten Schlüssel/Wert-Paaren. |
|
| Datennachricht | Die Client-App ist für die Verarbeitung von Datennachrichten verantwortlich. Datennachrichten haben nur benutzerdefinierte Schlüssel/Wert-Paare ohne reservierte Schlüsselnamen (siehe unten). | Verwenden Sie in einer vertrauenswürdigen Umgebung wie
Cloud Functions oder auf Ihrem Anwendungsserver das Admin SDK oder die FCM-Serverprotokolle. Legen Sie in der Sendeanfrage den Schlüssel data fest.
|
Verwenden Sie Benachrichtigungen, wenn das FCM SDK automatisch eine Benachrichtigung anzeigen soll, wenn Ihre App im Hintergrund ausgeführt wird. Verwenden Sie Datennachrichten, wenn Sie die Nachrichten mit Ihrem eigenen Client-Anwendungscode verarbeiten möchten.
FCM kann eine Benachrichtigung mit einer optionalen Datennutzlast senden. In solchen Fällen verarbeitet FCM die Anzeige der Nutzlast der Benachrichtigung und die Clientanwendung die Datennutzlast.
Benachrichtigungen
Zu Testzwecken oder für Marketingzwecke und erneute Nutzerinteraktionen können Sie Benachrichtigungen über die Firebase Console senden. Die Firebase Console bietet analysebasierte A/B-Tests, mit denen Sie Ihre Werbebotschaften optimieren und verbessern können.
Wenn Sie Benachrichtigungen programmatisch über das Admin SDK oder die FCM-Protokolle senden möchten, legen Sie den Schlüssel notification auf die erforderlichen vordefinierten Schlüssel/Wert-Optionen für den für den Nutzer sichtbaren Teil der Benachrichtigung fest. Hier sehen Sie als Beispiel eine Benachrichtigungsnachricht im JSON-Format in einer IM-App. Der Nutzer sieht auf dem Gerät eine Nachricht mit dem Titel „Portugal vs. Dänemark“ und dem Text „Großartige Übereinstimmung!“:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}
Benachrichtigungen werden an die Benachrichtigungsleiste gesendet, wenn die App im Hintergrund ausgeführt wird. Bei Apps im Vordergrund werden Nachrichten von einer Callback-Funktion verarbeitet.
Eine vollständige Liste der vordefinierten Schlüssel zum Erstellen von Benachrichtigungsnachrichten finden Sie in der Referenzdokumentation zu HTTP v1-Protokollbenachrichtigungsobjekten.
Datennachrichten
Legen Sie den entsprechenden Schlüssel mit Ihren benutzerdefinierten Schlüssel/Wert-Paaren fest, um eine Datennutzlast an die Clientanwendung zu senden.
Hier sehen Sie beispielsweise eine JSON-formatierte Nachricht in derselben IM-Anwendung wie oben, bei der die Informationen im gemeinsamen Schlüssel data gekapselt werden und die Clientanwendung den Inhalt interpretieren soll:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
}
Im obigen Beispiel wird das allgemeine oder allgemeine Feld data verwendet, das von Clients auf allen Plattformen interpretiert wird, die die Nachricht empfangen.
Auf jeder Plattform empfängt die Client-App die Datennutzlast in einer Callback-Funktion.
Verschlüsselung von Datennachrichten
Die Android Transport Layer (siehe FCM-Architektur) verwendet die Punkt-zu-Punkt-Verschlüsselung. Abhängig von Ihren Anforderungen können Sie Datennachrichten mit Ende-zu-Ende-Verschlüsselung ergänzen. FCM bietet keine End-to-End-Lösung. Es gibt jedoch auch externe Lösungen wie Capillary oder DTLS.
Benachrichtigungen mit optionaler Datennutzlast
Sowohl programmatisch als auch über die Firebase Console können Sie Benachrichtigungen senden, die eine optionale Nutzlast von benutzerdefinierten Schlüssel/Wert-Paaren enthalten. Verwenden Sie in Benachrichtigungen-Composer unter Erweiterte Optionen die Felder Benutzerdefinierte Daten.
Das Verhalten einer App beim Empfangen von Nachrichten, die sowohl Benachrichtigungen als auch Datennutzlasten enthalten, hängt davon ab, ob die App im Hintergrund oder im Vordergrund ausgeführt wird – im Grunde davon, ob sie zum Zeitpunkt des Empfangs aktiv ist oder nicht.
- Wenn sie im Hintergrund ausgeführt wird, empfangen Apps die Nutzlast der Benachrichtigung in der Benachrichtigungsleiste und verarbeiten die Datennutzlast nur, wenn der Nutzer auf die Benachrichtigung tippt.
- Im Vordergrund empfängt die App ein Nachrichtenobjekt, in dem beide Nutzlasten verfügbar sind.
Hier sehen Sie eine Nachricht im JSON-Format, die sowohl den Schlüssel notification als auch den Schlüssel data enthält:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}
Mitteilungen plattformübergreifend anpassen
Sowohl mit dem Firebase Admin SDK als auch mit dem FCM v1-HTTP-Protokoll können bei Nachrichtenanfragen alle im Objekt message verfügbaren Felder festgelegt werden. Dazu zählen:
- einen gemeinsamen Satz von Feldern, der von allen Anwendungsinstanzen interpretiert werden soll, die die Nachricht empfangen.
- plattformspezifische Gruppen von Feldern wie
AndroidConfigundWebpushConfig, die nur von Anwendungsinstanzen interpretiert werden, die auf der angegebenen Plattform ausgeführt werden.
Mit plattformspezifischen Blöcken können Sie Nachrichten flexibel für verschiedene Plattformen anpassen, um sicherzustellen, dass sie beim Empfang korrekt verarbeitet werden. Das FCM-Back-End berücksichtigt alle angegebenen Parameter und passt die Nachricht für jede Plattform an.
Wann Sie allgemeine Felder verwenden sollten
Verwenden Sie allgemeine Felder, wenn Sie:
- Targeting auf App-Instanzen auf allen Plattformen: Apple, Android und das Web
- Nachrichten an Themen senden
Alle Anwendungsinstanzen können unabhängig von der Plattform die folgenden allgemeinen Felder interpretieren:
Wann sollten plattformspezifische Felder verwendet werden?
Sie können plattformspezifische Felder verwenden, wenn Sie:
- Felder nur an bestimmte Plattformen senden
- Plattformspezifische Felder zusätzlich zu den allgemeinen Feldern senden
Wenn Sie Werte nur an bestimmte Plattformen senden möchten, verwenden Sie keine allgemeinen Felder, sondern plattformspezifische Felder. Wenn Sie eine Benachrichtigung beispielsweise nur an Apple-Plattformen und das Web, aber nicht an Android senden möchten, müssen Sie zwei separate Feldsätze verwenden: eine für Apple und eine für das Web.
Wenn Sie Nachrichten mit bestimmten Zustellungsoptionen senden, verwenden Sie plattformspezifische Felder, um diese festzulegen. Wenn Sie möchten, können Sie für jede Plattform unterschiedliche Werte angeben. Aber auch wenn Sie im Wesentlichen auf allen Plattformen denselben Wert festlegen möchten, müssen Sie plattformspezifische Felder verwenden. Das liegt daran, dass jede Plattform den Wert leicht unterschiedlich interpretieren kann. Beispielsweise wird die Gültigkeitsdauer unter Android als Ablaufzeit in Sekunden und in Apple als Ablaufdatum festgelegt.
Beispiel: Benachrichtigung mit plattformspezifischen Zustellungsoptionen
Mit der folgenden V1-Sendeanfrage werden ein gemeinsamer Benachrichtigungstitel und -inhalt an alle Plattformen gesendet, aber auch einige plattformspezifische Überschreibungen. Konkret geht es um den Antrag:
- legt eine lange Lebensdauer für Android- und Webplattformen fest, während die Priorität von APNs-Nachrichten (Apple-Plattformen) niedrig eingestellt wird
- legt die entsprechenden Tasten fest, um das Ergebnis zu definieren, wenn ein Nutzer auf die Benachrichtigung unter Android und Apple getippt hat –
click_actionbzw.category.
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Match update",
"body":"Arsenal goal in added time, score is now 3-0"
},
"android":{
"ttl":"86400s",
"notification"{
"click_action":"OPEN_ACTIVITY_1"
}
},
"apns": {
"headers": {
"apns-priority": "5",
},
"payload": {
"aps": {
"category": "NEW_MESSAGE_CATEGORY"
}
}
},
"webpush":{
"headers":{
"TTL":"86400"
}
}
}
}
Ausführliche Informationen zu den Schlüsseln, die in plattformspezifischen Blöcken im Nachrichtentext verfügbar sind, finden Sie in der Referenzdokumentation zu HTTP v1. Weitere Informationen zum Erstellen von Sendeanfragen mit Nachrichtentext finden Sie unter Sendeanfragen erstellen.
Lieferoptionen
FCM bietet einen bestimmten Satz von Zustellungsoptionen für Nachrichten, die an Android-Geräte gesendet werden, und ermöglicht ähnliche Optionen auf Apple-Plattformen und im Web. So wird das Nachrichtenverhalten „minimierbar“ beispielsweise unter Android über collapse_key von FCM, auf Apple über apns-collapse-id und auf JavaScript/Web über Topic unterstützt. Weitere Informationen finden Sie in den Beschreibungen in diesem Abschnitt und in der zugehörigen Referenzdokumentation.
Nicht minimierbare und minimierbare Nachrichten
Eine nicht minimierbare Nachricht bedeutet, dass jede einzelne Nachricht an das Gerät zugestellt wird. Eine nicht minimierbare Nachricht liefert einige nützliche Inhalte im Gegensatz zu einer minimierbaren Nachricht wie einem inhaltsfreien Ping an die mobile App, um den Server zum Abrufen von Daten zu kontaktieren.
Typische Anwendungsfälle für nicht minimierbare Nachrichten sind Chatnachrichten oder kritische Nachrichten. In einer IM-Anwendung sollten Sie beispielsweise jede Nachricht zustellen, da jede Nachricht einen anderen Inhalt hat.
Für Android gibt es ein Limit von 100 Nachrichten, die ohne Minimierung gespeichert werden können. Wenn das Limit erreicht ist, werden alle gespeicherten Nachrichten verworfen. Wenn das Gerät wieder online ist, wird es in einer speziellen Nachricht darüber informiert, dass das Limit erreicht wurde. Die App kann dann die Situation ordnungsgemäß verarbeiten, indem sie in der Regel eine vollständige Synchronisierung vom Anwendungsserver anfordert.
Eine minimierbare Nachricht ist eine Nachricht, die durch eine neue Nachricht ersetzt wird, wenn sie dem Gerät noch nicht zugestellt wurde.
Ein häufiger Anwendungsfall für minimierbare Nachrichten sind Nachrichten, die eine mobile App anweisen, Daten vom Server zu synchronisieren. Ein Beispiel wäre eine Sport-App, die Nutzer mit dem aktuellen Spielstand aktualisiert. Nur die neueste Nachricht ist relevant.
Wenn Sie eine Nachricht unter Android als minimierbar markieren möchten, fügen Sie den Parameter collapse_key in die Nachrichtennutzlast ein. Der Minimierungsschlüssel ist standardmäßig der Name des App-Pakets, der in der Firebase Console registriert ist. Der FCM-Server kann pro Gerät gleichzeitig vier verschiedene minimierbare Nachrichten mit jeweils einem anderen Minimierungsschlüssel speichern. Wenn Sie diese Zahl überschreiten, behält FCM nur vier Minimierungsschlüssel bei und es gibt keine Garantie dafür, welche beibehalten werden sollen.
Themennachrichten ohne Nutzlast sind standardmäßig minimiert. Benachrichtigungen können immer minimiert werden und ignorieren den Parameter collapse_key.
Welche soll ich verwenden?
Minimierbare Nachrichten sind in Bezug auf die Leistung besser geeignet, sofern deine Anwendung keine nicht minimierbaren Nachrichten verwenden muss. Wenn Sie jedoch minimierbare Nachrichten verwenden, denken Sie daran, dass FCM jeweils nur maximal vier verschiedene Minimierungsschlüssel pro Registrierungstoken verwenden kann. Sie dürfen diese Anzahl nicht überschreiten, da dies unvorhersehbare Folgen haben könnte.
| Anwendungsszenario | Senden | |
|---|---|---|
| Nicht minimierbar | Jede Nachricht ist für die Clientanwendung wichtig und muss zugestellt werden. | Mit Ausnahme von Benachrichtigungen können alle Nachrichten standardmäßig nicht minimiert werden. |
| Klappbar | Wenn eine neuere Nachricht vorhanden ist, die eine ältere, zugehörige Nachricht für die Clientanwendung irrelevant macht, ersetzt FCM die ältere Nachricht. Beispiele: Nachrichten, die zum Initiieren einer Datensynchronisierung vom Server verwendet werden, oder veraltete Benachrichtigungen. | Legen Sie den entsprechenden Parameter in Ihrer Nachrichtenanfrage fest:
|
Priorität einer Nachricht festlegen
Sie haben zwei Möglichkeiten, Downstream-Nachrichten eine Zustellungspriorität zuzuweisen: normale und hohe Priorität. Obwohl sich das Verhalten je nach Plattform geringfügig unterscheidet, funktioniert die Übermittlung von Nachrichten mit normaler und hoher Priorität so:
Normale Priorität: Nachrichten mit normaler Priorität werden sofort zugestellt, wenn die App im Vordergrund ausgeführt wird. Bei Apps im Hintergrund kann sich die Bereitstellung verzögern. Für weniger zeitkritische Nachrichten wie Benachrichtigungen über neue E-Mails, die Synchronisierung der Benutzeroberfläche oder die Synchronisierung von App-Daten im Hintergrund sollten Sie die normale Priorität für die Zustellung auswählen.
Hohe Priorität. FCM versucht selbst dann, Nachrichten mit hoher Priorität sofort zu senden, wenn sich das Gerät im Stromsparmodus befindet. Nachrichten mit hoher Priorität sind für zeitkritische, für den Nutzer sichtbare Inhalte gedacht.
Hier ist ein Beispiel für eine Nachricht mit normaler Priorität, die über das FCM-HTTP-v1-Protokoll gesendet wird, um einen Zeitschriftenabonnenten darüber zu informieren, dass neue Inhalte zum Download verfügbar sind:
{
"message":{
"topic":"subscriber-updates",
"notification":{
"body" : "This week's edition is now available.",
"title" : "NewsMagazine.com",
},
"data" : {
"volume" : "3.21.15",
"contents" : "http://www.news-magazine.com/world-week/21659772"
},
"android":{
"priority":"normal"
},
"apns":{
"headers":{
"apns-priority":"5"
}
},
"webpush": {
"headers": {
"Urgency": "high"
}
}
}
}
Weitere plattformspezifische Details zum Festlegen der Nachrichtenpriorität:
- APNs-Dokumentation
- Priorität von Nachrichten festlegen und verwalten (Android)
- Dringlichkeit in Web-Push-Nachrichten
Lebensdauer einer Nachricht festlegen
FCM stellt Nachrichten in der Regel sofort nach dem Senden zu. Dies ist jedoch nicht immer möglich. Wenn die Plattform beispielsweise Android ist, kann das Gerät ausgeschaltet, offline oder aus anderen Gründen nicht verfügbar sein. Oder FCM kann Nachrichten absichtlich verzögern, um zu verhindern, dass eine App übermäßig viele Ressourcen verbraucht und die Akkulaufzeit beeinträchtigt.
In diesem Fall speichert FCM die Nachricht und stellt sie so schnell wie möglich zu. Das ist in den meisten Fällen kein Problem, es gibt jedoch einige Anwendungen, bei denen eine verspätete Nachricht unter Umständen nie zugestellt wird. Handelt es sich bei der Nachricht beispielsweise um einen eingehenden Anruf oder eine Videochat-Benachrichtigung, ist sie nur für kurze Zeit von Bedeutung, bevor der Anruf beendet wird. Wenn es sich bei der Nachricht um eine Einladung zu einem Termin handelt, ist sie nutzlos, wenn sie nach dem Ende des Termins empfangen wird.
Unter Android und Web/JavaScript können Sie die maximale Lebensdauer einer Nachricht festlegen. Der Wert muss eine Dauer zwischen 0 und 2.419.200 Sekunden (28 Tage) sein und entspricht der maximalen Zeit, für die FCM die Nachricht speichert und versucht, sie zuzustellen. Für Anfragen, die dieses Feld nicht enthalten, gilt standardmäßig der maximale Zeitraum von vier Wochen.
Hier sind einige mögliche Anwendungsmöglichkeiten für diese Funktion:
- Eingehende Anrufe per Videoanruf
- Ablaufende Einladungsereignisse
- Kalendertermine
Ein weiterer Vorteil der Angabe der Lebensdauer einer Nachricht besteht darin, dass FCM keine minimierbaren Nachrichtendrosselung auf Nachrichten mit einem Gültigkeitsdauer-Wert von 0 Sekunden anwendet.
FCM bietet die bestmögliche Verarbeitung von Nachrichten, die "jetzt oder nie" zugestellt werden müssen. Beachten Sie, dass ein Wert von 0 für time_to_live bedeutet, dass Nachrichten verworfen werden, die nicht sofort zugestellt werden können. Da solche Nachrichten jedoch nie gespeichert werden, bietet dies die beste Latenz beim Senden von Benachrichtigungen.
Hier ein Beispiel für eine Anfrage mit TTL:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
},
"apns":{
"headers":{
"apns-expiration":"1604750400"
}
},
"android":{
"ttl":"4500s"
},
"webpush":{
"headers":{
"TTL":"4500"
}
}
}
}
Lebensdauer einer Nachricht
Wenn ein Anwendungsserver eine Nachricht an FCM sendet und eine Nachrichten-ID zurückerhält, bedeutet dies nicht, dass die Nachricht bereits an das Gerät zugestellt wurde. Vielmehr bedeutet dies, dass sie zur Lieferung angenommen wurde. Was mit der Nachricht geschieht, nachdem sie akzeptiert wurde, hängt von vielen Faktoren ab.
Im Best-Case-Szenario wird die Nachricht sofort zugestellt, wenn das Gerät mit FCM verbunden ist, der Bildschirm eingeschaltet ist und es keine Drosselungsbeschränkungen gibt.
Wenn das Gerät verbunden ist, sich aber im Stromsparmodus befindet, wird von FCM eine Nachricht mit niedriger Priorität gespeichert, bis der Stromsparmodus des Geräts beendet ist. Und genau hier spielt das Flag collapse_key eine Rolle: Wenn bereits eine Nachricht mit demselben Minimierungsschlüssel (und Registrierungstoken) vorhanden ist und auf die Zustellung wartet, wird die alte Nachricht verworfen und die neue Nachricht ersetzt (d. h. die alte Nachricht wird durch die neue minimiert). Wenn jedoch kein Minimierungsschlüssel festgelegt ist, werden sowohl die neuen als auch die alten Nachrichten für die zukünftige Zustellung gespeichert.
Wenn das Gerät nicht mit FCM verbunden ist, wird die Nachricht gespeichert, bis eine Verbindung hergestellt wurde (auch unter Berücksichtigung der Regeln für den Minimierungsschlüssel). Wenn eine Verbindung hergestellt wird, sendet FCM alle ausstehenden Nachrichten an das Gerät. Wenn das Gerät nie wieder verbunden werden kann (z. B. weil es auf die Werkseinstellungen zurückgesetzt wurde), wird das Zeitlimit für die Nachricht überschritten und sie aus dem FCM-Speicher verworfen. Das Standardzeitlimit beträgt vier Wochen, wenn das Flag time_to_live nicht festgelegt ist.
So erhalten Sie mehr Informationen zur Zustellung einer Nachricht:
Weitere Informationen zur Zustellung von Nachrichten auf Android- oder Apple-Plattformen finden Sie im FCM-Berichts-Dashboard. Dort wird die Anzahl der Nachrichten aufgezeichnet, die auf Apple- und Android-Geräten gesendet und geöffnet wurden. Außerdem werden Daten für „Impressionen“ (von Nutzern gesehene Benachrichtigungen) für Android-Apps erfasst.
Wenn das Gerät bei Android-Geräten mit aktiviertem Direct Channel Messaging mehr als einen Monat lang keine Verbindung zu FCM hergestellt hat, akzeptiert FCM die Nachricht weiterhin, verwirft sie aber sofort. Wenn das Gerät innerhalb von vier Wochen nach der letzten Datennachricht, die Sie an es gesendet haben, eine Verbindung herstellt, empfängt Ihr Client den onDeletedMessages()-Callback. Die App kann dann die Situation ordnungsgemäß verarbeiten, indem sie in der Regel eine vollständige Synchronisierung vom Anwendungsserver anfordert.
Wenn FCM versucht, eine Nachricht an das Gerät zu senden, und die App deinstalliert wurde, verwirft FCM diese Nachricht sofort und macht das Registrierungstoken ungültig. Bei zukünftigen Versuchen, eine Nachricht an dieses Gerät zu senden, wird der Fehler NotRegistered ausgegeben.
Drosselung und Skalierung
Wir möchten immer jede über FCM gesendete Nachricht zustellen. Allerdings führt die Zustellung jeder Nachricht manchmal zu einer schlechten Nutzererfahrung insgesamt. In anderen Fällen müssen wir Grenzen setzen, damit FCM für alle Absender einen skalierbaren Dienst bereitstellt.
Drosselung von Nachrichten bei minimierbaren Nachrichten
Wie oben beschrieben, handelt es sich bei minimierbaren Nachrichten um Benachrichtigungen ohne Inhalt, die so konzipiert sind, dass sie übereinander minimiert werden. Wenn ein Entwickler die gleiche Nachricht zu häufig an eine App wiederholt, verzögern wir Nachrichten (Drosselung), um die Belastung des Akkus des Nutzers zu verringern.
Wenn Sie beispielsweise eine große Anzahl neuer E-Mail-Synchronisierungsanfragen an ein einzelnes Gerät senden, verzögern wir die nächste E-Mail-Synchronisierungsanfrage möglicherweise um einige Minuten, damit das Gerät mit einer niedrigeren durchschnittlichen Rate synchronisiert werden kann. Diese Drosselung dient ausschließlich dazu, die Auswirkungen auf den Akku auf den Nutzer zu begrenzen.
Wenn Ihr Anwendungsfall hohe Burst-Sendemuster erfordert, sind nicht minimierbare Nachrichten möglicherweise die richtige Wahl. Geben Sie bei solchen Nachrichten den Inhalt an, um die Akkukosten zu reduzieren.
Wir begrenzen minimierbare Nachrichten auf 20 Nachrichten pro App und Gerät, wobei eine Nachricht alle 3 Minuten aufgefüllt wird.
Drosselung von XMPP-Server
Wir begrenzen die Rate, mit der Sie eine Verbindung zu FCM-XMPP-Servern herstellen können, auf 400 Verbindungen pro Minute und Projekt. Dies sollte kein Problem für die Nachrichtenzustellung sein, ist aber wichtig, um die Stabilität des Systems sicherzustellen. Für jedes Projekt ermöglicht FCM 2.500 Verbindungen parallel.
Beim Upstream-Messaging mit XMPP begrenzt FCM Upstream-Nachrichten auf 1.500.000/Minute pro Projekt, um eine Überlastung von Upstream-Zielservern zu vermeiden.
Wir begrenzen Upstream-Nachrichten pro Gerät auf 1.000 Nachrichten pro Minute,um eine schnelle Akkuentladung durch unerwünschtes App-Verhalten zu verhindern.
Maximale Nachrichtenrate an ein einzelnes Gerät
Bei Android können Sie bis zu 240 Nachrichten/Minute und 5.000 Nachrichten/Stunde an ein einzelnes Gerät senden. Dieser hohe Schwellenwert soll kurzfristige Traffic-Bursts zulassen, z. B. wenn Nutzer schnell über einen Chat interagieren. Dadurch wird verhindert, dass Fehler beim Senden von Logik den Akku eines Geräts versehentlich entladen.
Bei iOS wird ein Fehler zurückgegeben, wenn die Rate die APNs-Limits überschreitet.
Nachrichtenlimit für Themen
Die Rate für das Hinzufügen oder Entfernen von Themenabos ist auf 3.000 Abfragen pro Sekunde pro Projekt begrenzt.
Informationen zu den Senderaten von Nachrichten finden Sie unter Fanout-Drosselung.
Fanout-Drosselung
Bei der Nachrichten-Fanout wird eine Nachricht an mehrere Geräte gesendet, z. B. wenn Sie ein Targeting auf Themen und Gruppen vornehmen oder Benachrichtigungen erstellen für Zielgruppen oder Nutzersegmente.
Die Nachrichten-Fanouts erfolgen nicht sofort, sodass gelegentlich mehrere Fanouts gleichzeitig ausgeführt werden. Wir begrenzen die Anzahl gleichzeitiger Nachrichten-Fanouts pro Projekt auf 1.000. Danach können wir weitere Fanout-Anfragen ablehnen oder das Fanout der Anfragen aufschieben, bis einige der bereits laufenden Fanouts abgeschlossen sind.
Die tatsächlich erreichbare Fanout-Rate wird von der Anzahl der Projekte beeinflusst, die gleichzeitig Fanouts anfordern. Eine Fanout-Rate von 10.000 Abfragen pro Sekunde für ein einzelnes Projekt ist nicht ungewöhnlich. Diese Zahl ist jedoch keine Garantie und ergibt sich aus der Gesamtlast des Systems. Beachten Sie, dass die verfügbare Fanout-Kapazität nach Projekten und nicht nach Fanout-Anfragen aufgeteilt wird. Wenn Ihr Projekt also zwei Fanouts hat, wird jedes Fanout nur die Hälfte der verfügbaren Fanout-Rate sehen. Die empfohlene Methode zum Maximieren der Fanout-Geschwindigkeit besteht darin, jeweils nur ein aktives Fanout auszuführen.
FCM-Ports und Ihre Firewall
Wenn Ihre Organisation eine Firewall hat, die den Traffic zum oder vom Internet einschränkt, müssen Sie sie so konfigurieren, dass Mobilgeräte eine Verbindung mit FCM herstellen können, damit Geräte in Ihrem Netzwerk Nachrichten empfangen können. FCM verwendet normalerweise Port 5228, manchmal aber auch 443, 5229 und 5230.
Für Geräte, die eine Verbindung zu Ihrem Netzwerk herstellen, stellt FCM keine spezifischen IP-Adressen bereit, da sich unser IP-Bereich zu häufig ändert und Ihre Firewallregeln nicht mehr aktuell sind, was die Nutzerfreundlichkeit beeinträchtigen könnte. Idealerweise sollten Sie die Ports 5228-5230 und 443 ohne IP-Einschränkungen auf die Zulassungsliste setzen. Wenn Sie jedoch eine IP-Einschränkung benötigen, sollten Sie alle in goog.json aufgeführten IP-Adressen auf die Zulassungsliste setzen. Diese umfangreiche Liste wird regelmäßig aktualisiert. Es wird empfohlen, Ihre Regeln monatlich zu aktualisieren. Probleme, die durch Firewall-IP-Einschränkungen verursacht werden, sind oft sporadisch und schwer zu diagnostizieren.
Wir bieten eine Reihe von Domainnamen an, die anstelle von IP-Adressen auf die Zulassungsliste gesetzt werden können. Diese Hostnamen sind unten aufgeführt. Wenn wir beginnen, zusätzliche Hostnamen zu verwenden, wird die Liste hier aktualisiert. Die Verwendung von Domainnamen für Ihre Firewallregel funktioniert auf Ihrem Firewallgerät möglicherweise nicht.
Zu öffnende TCP-Ports:
- 5228
- 5229
- 5230
- 443
Zu öffnende Hostnamen:
- mtalk.google.com
- mtalk4.google.com
- mtalk-staging.google.com
- mtalk-dev.google.com
- alt1-mtalk.google.com
- alt2-mtalk.google.com
- alt3-mtalk.google.com
- alt4-mtalk.google.com
- alt5-mtalk.google.com
- alt6-mtalk.google.com
- alt7-mtalk.google.com
- alt8-mtalk.google.com
- android.apis.google.com
- device-provisioning.googleapis.com
- firebaseinstallations.googleapis.com
Firewalls für Network Address Translation und/oder Stateful Packet Inspection:
Wenn Ihr Netzwerk Network Address Translation (NAT) oder Stateful Packet Inspection (SPI) implementiert, implementieren Sie ein Zeitlimit von mindestens 30 Minuten für unsere Verbindungen über die Ports 5228–5230. So können wir eine zuverlässige Verbindung herstellen und gleichzeitig den Akkuverbrauch der Mobilgeräte Ihrer Nutzer reduzieren.
VPN-Interaktionen und Umgehbarkeit
Firebase Cloud Messaging unternimmt verschiedene Schritte, um dafür zu sorgen, dass die Push-Messaging-Verbindung vom Telefon zum Server so oft wie möglich zuverlässig und verfügbar ist. Die Verwendung eines VPN erschwert diesen Aufwand.
VPNs maskieren die zugrunde liegenden Informationen, die FCM benötigt, um die Verbindung zu optimieren, um Zuverlässigkeit und Akkulaufzeit zu maximieren. In einigen Fällen unterbrechen VPNs aktiv langlebige Verbindungen, was die Nutzerfreundlichkeit aufgrund verpasster oder verzögerter Nachrichten oder hoher Akkukosten beeinträchtigt. Wenn das VPN entsprechend konfiguriert ist, umgehen wir das VPN mithilfe einer verschlüsselten Verbindung (über das Basisnetzwerk-WLAN oder LTE), um eine zuverlässige, akkufreundliche Nutzung zu gewährleisten. Die Verwendung von umgehbaren VPNs durch FCM ist spezifisch für den FCM-Push-Benachrichtigungskanal. Für anderen FCM-Traffic, z. B. Registrierungstraffic, wird das VPN verwendet, sofern es aktiv ist. Wenn die FCM-Verbindung das VPN umgeht, verliert sie zusätzliche Vorteile, die das VPN möglicherweise bietet, z. B. die IP-Maskierung.
Unterschiedliche VPNs haben unterschiedliche Methoden, um zu steuern, ob das VPN umgangen werden kann oder nicht. Eine entsprechende Anleitung finden Sie in der Dokumentation Ihres VPN.
Wenn das VPN nicht so konfiguriert ist, dass es umgangen werden kann, verwendet Firebase Cloud Messaging das VPN-Netzwerk, um eine Verbindung zum Server herzustellen. Dies kann dazu führen, dass Nachrichten verzögert werden und der Akku stärker beansprucht wird, da Cloud Messaging versucht, die Verbindung über die VPN-Verbindung aufrechtzuerhalten.
Anmeldedaten
Je nachdem, welche FCM-Funktionen Sie implementieren, benötigen Sie möglicherweise die folgenden Anmeldedaten aus Ihrem Firebase-Projekt:
| Projekt-ID | Eine eindeutige Kennung für Ihr Firebase-Projekt, die in Anfragen an den HTTP-Endpunkt FCM v1 verwendet wird. Dieser Wert ist in der Firebase Console im Bereich Einstellungen verfügbar. |
| Registrierungstoken | Ein eindeutiger Tokenstring, der die einzelnen Client-App-Instanzen identifiziert. Das Registrierungstoken ist für Nachrichten an einzelne Geräte und in Gerätegruppen erforderlich. Registrierungstokens müssen geheim gehalten werden. |
| Absender-ID | Ein eindeutiger numerischer Wert, der beim Erstellen Ihres Firebase-Projekts erstellt wird und in der Firebase Console im Bereich Einstellungen auf dem Tab Cloud Messaging verfügbar ist. Die Sender-ID wird verwendet, um jeden Absender zu identifizieren, der Nachrichten an die Clientanwendung senden kann. |
| Zugriffstoken | Ein kurzlebiges OAuth 2.0-Token, das Anfragen an die HTTP v1 API autorisiert. Dieses Token ist mit einem Dienstkonto verknüpft, das zu Ihrem Firebase-Projekt gehört. Zum Erstellen und Rotieren von Zugriffstokens führen Sie die unter Sendeanfragen autorisieren beschriebenen Schritte aus. |
| Serverschlüssel (für **veraltete** Legacy-Protokolle) | Ein Serverschlüssel, der Ihren Anwendungsserver für den Zugriff auf Google-Dienste autorisiert, einschließlich des Sendens von Nachrichten über die verworfenen Legacy-Protokolle von Firebase Cloud Messaging. Wichtig:Fügen Sie den Serverschlüssel nirgendwo in Ihren Clientcode ein. Verwende außerdem nur Serverschlüssel, um deinen Anwendungsserver zu autorisieren. Android-, Apple-Plattform- und Browserschlüssel werden von FCM abgelehnt. |