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 zu verstehen und was Sie damit tun können.
Nachrichtentypen
Mit FCM können Sie zwei Arten von Nachrichten an Clients senden:
- Benachrichtigungsmeldungen, die manchmal als „Anzeigemeldungen“ bezeichnet werden. Diese werden vom FCM SDK automatisch gehandhabt.
- Datennachrichten, die von der Client-App verarbeitet werden.
Benachrichtigungsmeldungen enthalten einen vordefinierten Satz von für den Benutzer sichtbaren Schlüsseln. Im Gegensatz dazu enthalten Datennachrichten nur Ihre benutzerdefinierten benutzerdefinierten Schlüssel-Wert-Paare. Benachrichtigungsnachrichten können eine optionale Datennutzlast enthalten. Die maximale Nutzlast für beide Nachrichtentypen beträgt 4000 Byte, außer beim Senden von Nachrichten über die Firebase-Konsole, die eine Beschränkung auf 1024 Zeichen erzwingt.
| Szenario verwenden | Wie senden | |
|---|---|---|
| Benachrichtigungsnachricht | Das FCM SDK zeigt die Nachricht im Namen der Client-App auf Endbenutzergeräten an, wenn sie im Hintergrund ausgeführt wird. Andernfalls, wenn die App im Vordergrund ausgeführt wird, wenn die Benachrichtigung empfangen wird, bestimmt der Code der App das Verhalten. Benachrichtigungsmeldungen haben einen vordefinierten Satz von für den Benutzer sichtbaren Schlüsseln und eine optionale Datennutzlast von 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 Ihrem App-Server das Admin SDK oder die FCM-Serverprotokolle : Legen Sie nur den data fest. |
Verwenden Sie Benachrichtigungsmeldungen, wenn Sie möchten, dass das FCM SDK automatisch eine Benachrichtigung anzeigt, wenn Ihre App im Hintergrund ausgeführt wird. Verwenden Sie Datennachrichten, wenn Sie die Nachrichten mit Ihrem eigenen Client-App-Code verarbeiten möchten.
FCM kann eine Benachrichtigungsnachricht einschließlich einer optionalen Datennutzlast senden. In solchen Fällen verarbeitet FCM die Anzeige der Benachrichtigungsnutzlast, und die Client-App verarbeitet die Datennutzlast.
Benachrichtigungsmeldungen
Zu Testzwecken oder für Marketingzwecke und zur erneuten Interaktion mit Nutzern können Sie Benachrichtigungen über die Firebase-Konsole senden . Die Firebase-Konsole bietet analysebasierte A/B-Tests , mit denen Sie Marketingbotschaften verfeinern und verbessern können.
Um Benachrichtigungsmeldungen programmgesteuert mit dem Admin SDK oder den FCM-Protokollen zu senden, legen Sie den notification mit dem erforderlichen vordefinierten Satz von Schlüsselwertoptionen für den für den Benutzer sichtbaren Teil der Benachrichtigungsmeldung fest. Hier ist beispielsweise eine Benachrichtigungsnachricht im JSON-Format in einer IM-App. Der Benutzer erwartet eine Nachricht mit dem Titel „Portugal vs. Denmark“ und dem Text „great match!“. am Gerät:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}Benachrichtigungsmeldungen werden an die Benachrichtigungsleiste gesendet, wenn sich die App im Hintergrund befindet. Bei Apps im Vordergrund werden Nachrichten von einer Callback-Funktion verarbeitet.
In der Referenzdokumentation finden Sie die vollständige Liste der vordefinierten Schlüssel, die für Gebäudebenachrichtigungen verfügbar sind:
- Benachrichtigungsobjekt des HTTP v1-Protokolls
- Legacy-HTTP-Protokoll-Benachrichtigungsnutzlast
- Benachrichtigungsnutzlast des XMPP-Protokolls
Datenmeldungen
Legen Sie den entsprechenden Schlüssel mit Ihren benutzerdefinierten Schlüssel-Wert-Paaren fest, um eine Datennutzlast an die Client-App zu senden.
Hier ist zum Beispiel eine JSON-formatierte Nachricht in derselben IM-App wie oben, wobei die Informationen in den gemeinsamen data gekapselt sind und von der Client-App erwartet wird, dass sie den Inhalt interpretiert:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
} Das obige Beispiel zeigt die Verwendung des obersten oder gemeinsamen data , das von Clients auf allen Plattformen interpretiert wird, die die Nachricht erhalten. Auf jeder Plattform erhält die Client-App die Datennutzlast in einer Callback-Funktion.
Verschlüsselung für Datennachrichten
Die Android-Transportschicht (siehe FCM-Architektur ) verwendet Punkt-zu-Punkt-Verschlüsselung. Abhängig von Ihren Anforderungen können Sie sich entscheiden, Datennachrichten eine Ende-zu-Ende-Verschlüsselung hinzuzufügen. FCM bietet keine End-to-End-Lösung. Es stehen jedoch externe Lösungen wie Capillary oder DTLS zur Verfügung.
Benachrichtigungsmeldungen mit optionaler Datennutzlast
Sowohl programmgesteuert als auch über die Firebase-Konsole können Sie Benachrichtigungen senden, die eine optionale Nutzlast von benutzerdefinierten Schlüssel-Wert-Paaren enthalten. Verwenden Sie im Benachrichtigungs-Composer die benutzerdefinierten Datenfelder in den erweiterten Optionen .
Das App-Verhalten beim Empfang von Nachrichten, die sowohl Benachrichtigungs- als auch Datennutzlasten enthalten, hängt davon ab, ob sich die App im Hintergrund oder im Vordergrund befindet – im Wesentlichen, ob sie zum Zeitpunkt des Empfangs aktiv ist oder nicht.
- Im Hintergrund empfangen Apps die Benachrichtigungsnutzlast in der Benachrichtigungsleiste und verarbeiten die Datennutzlast nur, wenn der Benutzer auf die Benachrichtigung tippt.
- Im Vordergrund empfängt Ihre App ein Nachrichtenobjekt mit beiden verfügbaren Payloads.
Hier ist eine Nachricht im JSON-Format, die sowohl den notification als auch den data enthält:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}Anpassen einer Nachricht über Plattformen hinweg
Das Firebase Admin SDK und das HTTP-Protokoll FCM v1 ermöglichen es Ihren Nachrichtenanforderungen, alle im message verfügbaren Felder festzulegen. Das beinhaltet:
- ein gemeinsamer Satz von Feldern, die von allen App-Instanzen interpretiert werden, die die Nachricht empfangen.
- plattformspezifische Sätze von Feldern wie
AndroidConfigundWebpushConfig, die nur von App-Instanzen interpretiert werden, die auf der angegebenen Plattform ausgeführt werden.
Plattformspezifische Blöcke geben Ihnen die Flexibilität, Nachrichten für verschiedene Plattformen anzupassen, um sicherzustellen, dass sie beim Empfang korrekt behandelt werden. Das FCM-Backend berücksichtigt alle angegebenen Parameter und passt die Nachricht für jede Plattform an.
Wann sollten gemeinsame Felder verwendet werden?
Verwenden Sie allgemeine Felder, wenn Sie:
- Ausrichtung auf App-Instanzen auf allen Plattformen – Apple, Android und Web
- Senden von Nachrichten an Themen
Alle App-Instanzen können unabhängig von der Plattform die folgenden gemeinsamen Felder interpretieren:
Wann sollten plattformspezifische Felder verwendet werden?
Verwenden Sie plattformspezifische Felder, wenn Sie Folgendes möchten:
- Senden Sie Felder nur an bestimmte Plattformen
- Senden Sie zusätzlich zu den allgemeinen Feldern plattformspezifische Felder
Wenn Sie Werte nur an bestimmte Plattformen senden möchten, verwenden Sie keine gemeinsamen Felder. verwenden Sie plattformspezifische Felder. Um beispielsweise eine Benachrichtigung nur an Apple-Plattformen und das Web, aber nicht an Android zu senden, müssen Sie zwei separate Feldsätze verwenden, einen für Apple und einen für das Web.
Wenn Sie Nachrichten mit bestimmten Zustelloptionen senden, verwenden Sie plattformspezifische Felder, um diese festzulegen. Sie können bei Bedarf unterschiedliche Werte pro Plattform angeben. Aber selbst wenn Sie plattformübergreifend im Wesentlichen denselben Wert festlegen möchten, müssen Sie plattformspezifische Felder verwenden. Dies liegt daran, dass jede Plattform den Wert etwas anders interpretieren kann – beispielsweise wird die Lebensdauer auf Android als Ablaufzeit in Sekunden festgelegt, während sie auf Apple als Ablaufdatum festgelegt wird.
Beispiel: Benachrichtigungsnachricht mit plattformspezifischen Zustelloptionen
Die folgende v1-Sendeanforderung sendet einen gemeinsamen Benachrichtigungstitel und -inhalt an alle Plattformen, sendet aber auch einige plattformspezifische Außerkraftsetzungen. Konkret die Bitte:
- legt eine lange Lebensdauer für Android- und Webplattformen fest, während die Nachrichtenpriorität von APNs (Apple-Plattformen) auf eine niedrige Einstellung gesetzt wird
- legt die entsprechenden Schlüssel fest, um das Ergebnis eines Benutzertipps auf die Benachrichtigung auf Android und Apple zu definieren –
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 HTTP v1-Referenzdokumentation . Weitere Informationen zum Erstellen von Sendeanforderungen, die den Nachrichtentext enthalten, finden Sie unter Erstellen von Sendeanforderungen .
Lieferoptionen
FCM bietet einen bestimmten Satz von Zustelloptionen für Nachrichten, die an Android-Geräte gesendet werden, und ermöglicht ähnliche Optionen auf Apple-Plattformen und im Internet. Beispielsweise wird das „reduzierbare“ Nachrichtenverhalten auf Android über collapse_key von FCM, auf Apple über apns-collapse-id und auf JavaScript/Web über Topic unterstützt. Einzelheiten finden Sie in den Beschreibungen in diesem Abschnitt und in der zugehörigen Referenzdokumentation.
Nicht zusammenklappbare und zusammenklappbare Nachrichten
Eine nicht komprimierbare Nachricht bedeutet, dass jede einzelne Nachricht an das Gerät übermittelt wird. Eine nicht komprimierbare Nachricht liefert einige nützliche Inhalte, im Gegensatz zu einer komprimierbaren Nachricht wie einem inhaltslosen „Ping“ an die mobile App, um den Server zu kontaktieren, um Daten abzurufen.
Einige typische Anwendungsfälle von nicht komprimierbaren Nachrichten sind Chatnachrichten oder kritische Nachrichten. In einer IM-App möchten Sie beispielsweise jede Nachricht zustellen, da jede Nachricht einen anderen Inhalt hat.
Für Android gibt es ein Limit von 100 Nachrichten, die ohne Zusammenbruch gespeichert werden können. Wenn das Limit erreicht ist, werden alle gespeicherten Nachrichten verworfen. Wenn das Gerät wieder online ist, erhält es eine spezielle Meldung, dass das Limit erreicht wurde. Die App kann die Situation dann ordnungsgemäß handhaben, indem sie normalerweise eine vollständige Synchronisierung vom App-Server anfordert.
Eine zusammenklappbare Nachricht ist eine Nachricht, die durch eine neue Nachricht ersetzt werden kann, wenn sie noch an das Gerät geliefert werden muss.
Ein häufiger Anwendungsfall für reduzierbare Nachrichten sind Nachrichten, mit denen eine mobile App angewiesen wird, Daten vom Server zu synchronisieren. Ein Beispiel wäre eine Sport-App, die Benutzer mit dem neuesten Ergebnis aktualisiert. Nur die neueste Nachricht ist relevant.
Um eine Nachricht unter Android als reduzierbar zu markieren, fügen Sie den Parameter collapse_key in die Nachrichtennutzlast ein. Standardmäßig ist der Minimierungsschlüssel der App-Paketname, der in der Firebase-Konsole registriert ist. Der FCM-Server kann gleichzeitig vier verschiedene komprimierbare Nachrichten pro Gerät speichern, jede mit einem anderen Reduzierschlüssel. Wenn Sie diese Anzahl überschreiten, behält FCM nur vier Collapse-Keys, ohne Garantie dafür, welche aufbewahrt werden.
Themennachrichten ohne Payload sind standardmäßig komprimierbar. Benachrichtigungsmeldungen sind immer reduzierbar und ignorieren den collapse_key Parameter.
Welche soll ich verwenden?
Unter dem Gesichtspunkt der Leistung sind reduzierbare Nachrichten die bessere Wahl, vorausgesetzt, Ihre App muss keine nicht reduzierbaren Nachrichten verwenden. Wenn Sie jedoch reduzierbare Nachrichten verwenden, denken Sie daran, dass FCM nur die Verwendung von maximal vier verschiedenen Reduzierschlüsseln durch FCM pro Registrierungstoken zu einem bestimmten Zeitpunkt zulässt. Sie dürfen diese Zahl nicht überschreiten, da dies zu unvorhersehbaren Folgen führen kann.
| Szenario verwenden | Wie senden | |
|---|---|---|
| Nicht zusammenklappbar | Jede Nachricht ist für die Client-App wichtig und muss zugestellt werden. | Mit Ausnahme von Benachrichtigungen sind alle Nachrichten standardmäßig nicht komprimierbar. |
| Zusammenklappbar | Wenn es eine neuere Nachricht gibt, die eine ältere, verwandte Nachricht für die Client-App irrelevant macht, ersetzt FCM die ältere Nachricht. Zum Beispiel: Nachrichten, die verwendet werden, um eine Datensynchronisierung vom Server zu initiieren, oder veraltete Benachrichtigungsnachrichten. | Setzen Sie den entsprechenden Parameter in Ihrer Nachrichtenanfrage:
|
Einstellen der Priorität einer Nachricht
Sie haben zwei Möglichkeiten, Downstream-Nachrichten eine Zustellpriorität zuzuweisen: normale und hohe Priorität. Obwohl sich das Verhalten je nach Plattform leicht unterscheidet, funktioniert die Zustellung von Nachrichten mit normaler und hoher Priorität wie folgt:
Normale Priorität. Nachrichten mit normaler Priorität werden sofort zugestellt, wenn sich die App im Vordergrund befindet. Bei Apps im Hintergrund kann sich die Lieferung verzögern. Wählen Sie für weniger zeitkritische Nachrichten, z. B. Benachrichtigungen über neue E-Mails, die Synchronisierung Ihrer Benutzeroberfläche oder die Synchronisierung von App-Daten im Hintergrund, die normale Zustellungspriorität.
Hohe Priorität. FCM versucht, Nachrichten mit hoher Priorität sofort zuzustellen, selbst wenn sich das Gerät im Doze-Modus befindet. Nachrichten mit hoher Priorität sind für zeitkritische, für den Benutzer sichtbare Inhalte.
Hier ist ein Beispiel für eine Nachricht mit normaler Priorität, die über das FCM HTTP v1-Protokoll gesendet wird, um einen Zeitschriftenabonnenten zu benachrichtigen, dass neue Inhalte zum Herunterladen 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
- Nachrichtenpriorität festlegen und verwalten (Android)
- Dringlichkeit der Web-Push-Nachricht
Festlegen der Lebensdauer einer Nachricht
FCM liefert Nachrichten normalerweise unmittelbar nach dem Senden. Dies ist jedoch möglicherweise nicht immer möglich. Wenn die Plattform beispielsweise Android ist, könnte das Gerät ausgeschaltet, offline oder anderweitig 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 negativ beeinflusst.
In diesem Fall speichert FCM die Nachricht und übermittelt sie, sobald dies möglich ist. Während dies in den meisten Fällen in Ordnung ist, gibt es einige Apps, für die eine verspätete Nachricht möglicherweise auch nie zugestellt wird. Wenn es sich bei der Nachricht beispielsweise um einen eingehenden Anruf oder eine Video-Chat-Benachrichtigung handelt, ist sie nur für einen kurzen Zeitraum von Bedeutung, bevor der Anruf beendet wird. Oder wenn die Nachricht eine Einladung zu einer Veranstaltung ist, ist sie nutzlos, wenn sie nach Ende der Veranstaltung empfangen wird.
Unter Android und Web/JavaScript können Sie die maximale Lebensdauer einer Nachricht angeben. Der Wert muss eine Dauer von 0 bis 2.419.200 Sekunden (28 Tage) sein und entspricht dem maximalen Zeitraum, für den FCM die Nachricht speichert und zuzustellen versucht. Anfragen, die dieses Feld nicht enthalten, gelten standardmäßig für den maximalen Zeitraum von vier Wochen.
Hier sind einige mögliche Verwendungen für diese Funktion:
- Video-Chat eingehende Anrufe
- Auslaufende Einladungsveranstaltungen
- Kalenderereignisse
Ein weiterer Vorteil der Angabe der Lebensdauer einer Nachricht besteht darin, dass FCM niemals Nachrichten mit einem Time-to-Live-Wert von 0 Sekunden drosselt. Mit anderen Worten, FCM garantiert Best Effort für Nachrichten, die „jetzt oder nie“ zugestellt werden müssen. Beachten Sie, dass ein time_to_live Wert von 0 bedeutet, dass Nachrichten, die nicht sofort zugestellt werden können, verworfen werden. Da solche Nachrichten jedoch nie gespeichert werden, bietet dies die beste Latenz zum Senden von Benachrichtigungsnachrichten.
Hier ist ein Beispiel für eine Anfrage, die TTL enthält:
{
"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 App-Server eine Nachricht an FCM sendet und eine Nachrichten-ID zurückerhält, bedeutet dies nicht, dass die Nachricht bereits an das Gerät übermittelt wurde. Es bedeutet vielmehr, dass es zur Lieferung angenommen wurde. Was mit der Nachricht passiert, nachdem sie akzeptiert wurde, hängt von vielen Faktoren ab.
Im besten Fall, wenn das Gerät mit FCM verbunden ist, der Bildschirm eingeschaltet ist und keine Drosselungsbeschränkungen vorliegen, wird die Nachricht sofort zugestellt.
Wenn das Gerät verbunden ist, sich aber im Doze-Modus befindet, wird eine Nachricht mit niedriger Priorität vom FCM gespeichert, bis das Gerät den Doze-Modus verlässt. Und hier spielt das collapse_key Flag eine Rolle: Wenn bereits eine Nachricht mit demselben Collapse-Key (und Registrierungstoken) gespeichert ist und auf die Zustellung wartet, wird die alte Nachricht verworfen und die neue Nachricht nimmt ihren Platz ein (d. h. die alte Nachricht wird durch die neue zugeklappt). Wenn der Reduzierschlüssel jedoch nicht festgelegt ist, werden sowohl die neuen als auch die alten Nachrichten für eine zukünftige Zustellung gespeichert.
Wenn das Gerät nicht mit dem FCM verbunden ist, wird die Nachricht gespeichert, bis eine Verbindung hergestellt wird (wieder unter Einhaltung der Regeln für den Zusammenbruchschlüssel). Wenn eine Verbindung hergestellt ist, liefert FCM alle anstehenden Nachrichten an das Gerät. Wenn das Gerät nie wieder verbunden wird (z. B. wenn es auf die Werkseinstellungen zurückgesetzt wurde), läuft die Nachricht schließlich ab und wird aus dem FCM-Speicher verworfen. Das Standardzeitlimit beträgt vier Wochen, es sei denn, das Flag time_to_live ist gesetzt.
Um mehr Einblick in die Zustellung einer Nachricht zu erhalten:
Um mehr Einblick in die Zustellung von Nachrichten auf Android- oder Apple-Plattformen zu erhalten, sehen Sie sich das FCM-Berichts-Dashboard an, das die Anzahl der auf Apple- und Android-Geräten gesendeten und geöffneten Nachrichten zusammen mit Daten für „Impressionen“ (von Benutzern gesehene Benachrichtigungen) aufzeichnet Android Apps.
Wenn bei Android-Geräten mit aktiviertem Direktkanal-Messaging das Gerät länger als einen Monat nicht mit FCM verbunden war, akzeptiert FCM die Nachricht dennoch, verwirft sie jedoch sofort. Wenn das Gerät innerhalb von vier Wochen nach der letzten Datennachricht, die Sie ihm gesendet haben, eine Verbindung herstellt, erhält Ihr Client den onDeletedMessages()- Callback. Die App kann die Situation dann ordnungsgemäß handhaben, indem sie normalerweise eine vollständige Synchronisierung vom App-Server anfordert.
Wenn FCM schließlich versucht, eine Nachricht an das Gerät zu übermitteln, und die App deinstalliert wurde, verwirft FCM diese Nachricht sofort und macht das Registrierungstoken ungültig. Zukünftige Versuche, eine Nachricht an dieses Gerät zu senden, führen zu einem NotRegistered Fehler.
Drosselung und Skalierung
Unser Ziel ist es, immer jede über FCM gesendete Nachricht zuzustellen. Das Zustellen jeder Nachricht führt jedoch manchmal zu einer insgesamt schlechten Benutzererfahrung. In anderen Fällen müssen wir Grenzen bereitstellen, um sicherzustellen, dass FCM einen skalierbaren Dienst für alle Absender bereitstellt.
Reduzierbare Nachrichtendrosselung
Wie oben beschrieben, sind komprimierbare Nachrichten inhaltslose Benachrichtigungen, die dafür ausgelegt sind, übereinander zu kollabieren. Für den Fall, dass ein Entwickler dieselbe Nachricht zu oft an eine App wiederholt, verzögern (drosseln) wir Nachrichten, um die Auswirkungen auf den Akku eines Benutzers zu verringern.
Wenn Sie beispielsweise eine große Anzahl neuer E-Mail-Synchronisierungsanforderungen an ein einzelnes Gerät senden, verzögern wir die nächste E-Mail-Synchronisierungsanforderung möglicherweise um einige Minuten, damit das Gerät mit einer niedrigeren Durchschnittsrate synchronisieren kann. Diese Drosselung erfolgt ausschließlich, um die Auswirkungen auf den Akku zu begrenzen, die der Benutzer erfährt.
Wenn Ihr Anwendungsfall hohe Burst-Sendemuster erfordert, sind nicht komprimierbare Nachrichten möglicherweise die richtige Wahl. Achten Sie bei solchen Nachrichten darauf, den Inhalt in solche Nachrichten aufzunehmen, um die Batteriekosten zu senken.
Wir beschränken reduzierbare Nachrichten auf 20 Nachrichten pro App und Gerät, wobei alle 3 Minuten eine Nachricht neu aufgefüllt wird.
Drosselung des XMPP-Servers
Wir begrenzen die Rate, mit der Sie sich mit FCM-XMPP-Servern verbinden können, auf 400 Verbindungen pro Minute und Projekt. Dies sollte kein Problem für die Nachrichtenübermittlung darstellen, ist aber wichtig, um die Stabilität unseres Systems zu gewährleisten.
Für jedes Projekt erlaubt FCM 2500 parallele Verbindungen.
Maximale Nachrichtenrate an ein einzelnes Gerät
Für 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 Verkehrsspitzen zulassen, z. B. wenn Benutzer schnell über den Chat interagieren. Diese Grenze verhindert, dass Fehler beim Senden von Logik versehentlich den Akku eines Geräts entladen.
Für iOS geben wir einen Fehler zurück, wenn die Rate die APNs-Grenzen überschreitet.
Upstream-Nachrichtenlimit
Wir begrenzen Upstream-Nachrichten auf 1.500.000/Minute pro Projekt, um eine Überlastung der Upstream-Zielserver zu vermeiden.
Wir begrenzen Upstream-Nachrichten pro Gerät auf 1.000/Minute, um eine Batterieentladung durch schlechtes App-Verhalten zu verhindern.
Nachrichtenlimit für Themen
Die Rate zum Hinzufügen/Entfernen von Themenabonnements ist auf 3.000 QPS pro Projekt begrenzt.
Informationen zu Nachrichtensenderaten finden Sie unter Fanout-Drosselung .
Fanout-Drosselung
Nachrichten-Fanout ist der Prozess des Sendens einer Nachricht an mehrere Geräte, z. B. wenn Sie Themen und Gruppen ansprechen oder wenn Sie den Benachrichtigungs-Composer verwenden, um Zielgruppen oder Benutzersegmente anzusprechen.
Das Nachrichten-Fanout erfolgt 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 zusätzliche Fanout-Anfragen ablehnen oder das Fanout der Anfragen verschieben, bis einige der bereits laufenden Fanouts abgeschlossen sind.
Die tatsächlich erreichbare Fanout-Rate wird durch die Anzahl der Projekte beeinflusst, die gleichzeitig Fanouts anfordern. Eine Fanout-Rate von 10.000 QPS für ein einzelnes Projekt ist keine Seltenheit, aber diese Zahl ist keine Garantie und ergibt sich aus der Gesamtlast des Systems. Es ist wichtig zu beachten, dass die verfügbare Fanout-Kapazität auf Projekte und nicht auf Fanout-Anforderungen aufgeteilt wird. Wenn Ihr Projekt also zwei Fanouts in Bearbeitung hat, wird jedem Fanout nur die Hälfte der verfügbaren Fanout-Rate angezeigt. Die empfohlene Methode zur Maximierung Ihrer Fanout-Geschwindigkeit besteht darin, jeweils nur einen aktiven Fanout zu verwenden.
FCM-Ports und Ihre Firewall
Wenn Ihre Organisation über eine Firewall verfügt, um den Datenverkehr zum oder vom Internet einzuschränken, müssen Sie sie so konfigurieren, dass mobile Geräte eine Verbindung mit FCM herstellen können, damit Geräte in Ihrem Netzwerk Nachrichten empfangen können. FCM verwendet normalerweise Port 5228, aber manchmal auch 443, 5229 und 5230.
Für Geräte, die sich mit Ihrem Netzwerk verbinden, stellt FCM keine spezifischen IPs bereit, da sich unser IP-Bereich zu häufig ändert und Ihre Firewall-Regeln veraltet sein könnten, was sich auf die Erfahrung Ihrer Benutzer auswirkt. Idealerweise die Ports 5228-5230 und 443 ohne IP-Einschränkungen auf die Positivliste setzen. Wenn Sie jedoch eine IP-Einschränkung haben müssen, sollten Sie alle in goog.json aufgeführten IP-Adressen auf die Zulassungsliste setzen. Diese große Liste wird regelmäßig aktualisiert, und es wird empfohlen, Ihre Regeln monatlich zu aktualisieren. Probleme, die durch Firewall-IP-Einschränkungen verursacht werden, treten häufig sporadisch auf und sind schwer zu diagnostizieren.
Wir bieten eine Reihe von Domänennamen an, die anstelle von IP-Adressen auf die Zulassungsliste gesetzt werden können. Diese Hostnamen sind unten aufgeführt. Wenn wir anfangen, zusätzliche Hostnamen zu verwenden, werden wir die Liste hier aktualisieren. Die Verwendung von Domänennamen für Ihre Firewall-Regel kann in Ihrem Firewall-Gerät funktionieren oder 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
- gerätebereitstellung.googleapis.com
- firebaseinstallations.googleapis.com
Network Address Translation- und/oder Stateful Packet Inspection-Firewalls:
Wenn Ihr Netzwerk Network Address Translation (NAT) oder Stateful Packet Inspection (SPI) implementiert, implementieren Sie ein 30-minütiges oder längeres Timeout für unsere Verbindungen über die Ports 5228-5230. Dadurch können wir eine zuverlässige Konnektivität bereitstellen und gleichzeitig den Akkuverbrauch der Mobilgeräte Ihrer Benutzer reduzieren.
Referenzen
Je nachdem, welche FCM-Funktionen Sie implementieren, benötigen Sie möglicherweise die folgenden Anmeldeinformationen aus Ihrem Firebase-Projekt:
| Projekt-ID | Ein eindeutiger Bezeichner für Ihr Firebase-Projekt, der in Anfragen an den HTTP-Endpunkt von FCM v1 verwendet wird. Dieser Wert ist im Einstellungsbereich der Firebase-Konsole verfügbar. |
| Registrierungstoken | Eine eindeutige Tokenzeichenfolge, die jede Client-App-Instanz identifiziert. Das Registrierungstoken ist für die Nachrichtenübermittlung an einzelne Geräte und Gerätegruppen erforderlich. Beachten Sie, dass Registrierungstoken geheim gehalten werden müssen. |
| Absenderidentität | Ein eindeutiger numerischer Wert, der beim Erstellen Ihres Firebase-Projekts erstellt wird und auf der Registerkarte „Cloud Messaging “ im Bereich „Einstellungen“ der Firebase-Konsole verfügbar ist. Die Absender-ID wird verwendet, um jeden Absender zu identifizieren, der Nachrichten an die Client-App senden kann. |
| Zugangstoken | Ein kurzlebiges OAuth 2.0-Token, das Anforderungen an die HTTP v1-API autorisiert. Dieses Token ist mit einem Dienstkonto verknüpft, das zu Ihrem Firebase-Projekt gehört. Befolgen Sie zum Erstellen und Rotieren von Zugriffstoken die unter Sendeanforderungen autorisieren beschriebenen Schritte. |
| Serverschlüssel (für ältere Protokolle) | Ein Serverschlüssel, der Ihren App-Server für den Zugriff auf Google-Dienste autorisiert, einschließlich des Sendens von Nachrichten über die Legacy-Protokolle von Firebase Cloud Messaging. Sie erhalten den Serverschlüssel, wenn Sie Ihr Firebase-Projekt erstellen. Sie können es auf der Registerkarte „Cloud Messaging“ im Bereich „Einstellungen“ der Firebase-Konsole anzeigen. Wichtig: Fügen Sie den Serverschlüssel nirgendwo in Ihren Clientcode ein. Stellen Sie außerdem sicher, dass Sie nur Serverschlüssel verwenden, um Ihren App-Server zu autorisieren. Android-, Apple-Plattform- und Browserschlüssel werden von FCM abgelehnt. |