FCM-Nachrichten

Firebase Cloud Messaging (FCM) bietet eine Vielzahl von Messaging-Optionen und ‑Funktionen. Die Informationen auf dieser Seite sollen Ihnen helfen, die verschiedenen Arten von FCM-Mitteilungen zu verstehen und zu erfahren, was Sie damit tun können.

Mitteilungstypen

Mit FCM können Sie zwei Arten von Nachrichten an Kunden senden:

• Benachrichtigungen, die manchmal auch als „Anzeigenachrichten“ bezeichnet werden. Diese werden automatisch vom FCM SDK verarbeitet.
• Datenbenachrichtigungen, die von der Client-App verarbeitet werden.

Benachrichtigungen enthalten eine vordefinierte Gruppe von für Nutzer sichtbaren Schlüsseln. Datenmeldungen 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, außer beim Senden von Nachrichten über die Firebase-Konsole, wo ein Limit von 1.000 Zeichen gilt.

	Nutzungsszenario	So senden Sie
Benachrichtigungstext	Das FCM SDK zeigt die Mitteilung auf Endnutzergeräten im Namen der Client-App an, wenn diese im Hintergrund ausgeführt wird. Wenn die App im Vordergrund ausgeführt wird, wenn die Benachrichtigung empfangen wird, wird das Verhalten durch den Code der App bestimmt. Benachrichtigungen haben einen vordefinierten Satz von für den Nutzer sichtbaren Schlüsseln und eine optionale Datennutzlast mit benutzerdefinierten Schlüssel/Wert-Paaren.	Verwenden Sie in einer vertrauenswürdigen Umgebung wie Cloud Functions oder Ihrem App-Server das Admin SDK oder die HTTP v1 API. Legen Sie den notification-Schlüssel fest. Kann eine optionale Daten-Nutzlast enthalten. Immer minimierbar Beispiele für Displaybenachrichtigungen und Nutzlasten für Sendeanfragen Notifications Composer: Geben Sie den Nachrichtentext, den Titel usw. ein und senden Sie die Benachrichtigung. Fügen Sie eine optionale Daten-Payload hinzu, indem Sie benutzerdefinierte Daten angeben.
Datennachricht	Die Client-App ist für die Verarbeitung von Datennachrichten verantwortlich. Datennachrichten enthalten 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 in der Send-Anfrage den data-Schlüssel fest.

Verwenden Sie Benachrichtigungsmeldungen, wenn das FCM SDK eine Benachrichtigung automatisch anzeigen soll, wenn Ihre App im Hintergrund ausgeführt wird. Verwenden Sie Daten-Nachrichten, wenn Sie die Nachrichten mit Ihrem eigenen Client-App-Code verarbeiten möchten.

FCM kann eine Benachrichtigung mit einer optionalen Datennutzlast senden. In solchen Fällen verarbeitet FCM die Nutzlast der Benachrichtigung und die Client-App die Datennutzlast.

Benachrichtigungen

Für Tests oder für Marketing und Re-Engagement von Nutzern können Sie Benachrichtigungen über die Firebase-Konsole senden. Die Firebase-Konsole bietet A/B-Tests auf Grundlage von Analysen, mit denen Sie Marketingbotschaften 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 mit der erforderlichen vordefinierten Gruppe von Schlüssel/Wert-Optionen für den für den Nutzer sichtbaren Teil der Benachrichtigung fest. Hier sehen Sie ein Beispiel für eine im JSON-Format formatierte Benachrichtigung in einer Messaging-App. Der Nutzer kann auf dem Gerät eine Nachricht mit dem Titel „Portugal vs. Denmark“ und dem Text „great match!“ erwarten:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

Benachrichtigungen werden in der Benachrichtigungsleiste angezeigt, 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, die zum Erstellen von Benachrichtigungen verwendet werden können, finden Sie in der Referenzdokumentation zum Benachrichtigungsobjekt für das HTTP v1-Protokoll.

Datennachrichten

Legen Sie den entsprechenden Schlüssel mit Ihren benutzerdefinierten Schlüssel/Wert-Paaren fest, um eine Daten-Payload an die Client-App zu senden.

Verwenden Sie keine reservierten Wörter in Ihren benutzerdefinierten Schlüssel/Wert-Paaren. Reservierte Wörter sind unter anderem „from“, „notification“, „message_type“ oder alle Wörter, die mit „google“ oder „gcm“ beginnen.

Hier ist beispielsweise eine JSON-formatierte Nachricht in derselben IM-App wie oben, in der die Informationen im gemeinsamen Schlüssel data enthalten sind und die Client-App den Inhalt interpretieren soll:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

Im obigen Beispiel wird die Verwendung des Felds data auf oberster Ebene oder des gemeinsamen Felds veranschaulicht, das von Clients auf allen Plattformen interpretiert wird, die die Nachricht empfangen. Auf jeder Plattform empfängt die Client-App die Daten-Payload in einer Callback-Funktion.

Verschlüsselung für Datenmeldungen

Die Android-Transportschicht (siehe FCM-Architektur) verwendet eine Punkt-zu-Punkt-Verschlüsselung. Je nach Bedarf können Sie Datenmitteilungen eine Ende-zu-Ende-Verschlüsselung hinzufügen. FCM bietet keine End-to-End-Lösung. Es sind jedoch externe Lösungen wie Capillary oder DTLS verfügbar.

Benachrichtigungen mit optionaler Daten-Payload

Sowohl programmatisch als auch über die Firebase-Konsole können Sie Benachrichtigungen mit einer optionalen Nutzlast aus benutzerdefinierten Schlüssel/Wert-Paaren senden. Verwenden Sie im Benachrichtigungs-Composer die Felder Benutzerdefinierte Daten unter Erweiterte Optionen.

Das Verhalten der App beim Empfang von Nachrichten, die sowohl Benachrichtigungs- als auch Daten-Payloads enthalten, hängt davon ab, ob die App im Hintergrund oder im Vordergrund ausgeführt wird – also davon, ob sie zum Zeitpunkt des Empfangs aktiv ist.

• Im Hintergrund erhalten Apps die Benachrichtigungs-Payload in der Benachrichtigungsleiste und verarbeiten die Daten-Payload erst, wenn der Nutzer auf die Benachrichtigung tippt.
• Wenn sich die App im Vordergrund befindet, empfängt sie ein Message-Objekt mit beiden verfügbaren Nutzlasten.

Hier ist eine JSON-formatierte Nachricht, 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"
    }
  }
}

Nachricht plattformübergreifend anpassen

Sowohl mit Firebase Admin SDK als auch mit dem FCM v1-HTTP-Protokoll können Sie in Ihren Nachrichtenanfragen alle Felder festlegen, die im message-Objekt verfügbar sind. Dazu zählen:

• einen gemeinsamen Satz von Feldern, die von allen App-Instanzen interpretiert werden, die die Nachricht empfangen.
• plattformspezifische Feldgruppen wie AndroidConfig und WebpushConfig, die nur von App-Instanzen interpretiert werden, die auf der angegebenen Plattform ausgeführt werden.

Plattformspezifische Blöcke bieten Ihnen die Flexibilität, Nachrichten für verschiedene Plattformen anzupassen, damit sie bei Erhalt richtig verarbeitet 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 gemeinsame Felder, wenn Sie:

• Targeting auf App-Instanzen auf allen Plattformen – Apple, Android und Web
• Nachrichten an Themen senden

Alle App-Instanzen, unabhängig von der Plattform, können die folgenden gemeinsamen Felder interpretieren:

• message.notification.title
• message.notification.body
• message.data

Wann sollten plattformspezifische Felder verwendet werden?

Verwenden Sie plattformspezifische Felder, wenn Sie:

• Felder nur an bestimmte Plattformen senden
• Plattformspezifische Felder zusätzlich zu den gemeinsamen Feldern senden

Wenn Sie Werte nur an bestimmte Plattformen senden möchten, verwenden Sie keine gemeinsamen Felder, sondern plattformspezifische Felder. Wenn Sie beispielsweise eine Benachrichtigung nur an Apple-Plattformen und das Web, aber nicht an Android senden möchten, müssen Sie zwei separate Gruppen von Feldern 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. Sie können bei Bedarf unterschiedliche Werte für die einzelnen Plattformen angeben. Auch wenn Sie im Grunde denselben Wert für alle Plattformen festlegen möchten, müssen Sie plattformspezifische Felder verwenden. Das liegt daran, dass jede Plattform den Wert möglicherweise etwas anders interpretiert. Unter Android wird die Gültigkeitsdauer beispielsweise als Ablaufzeit in Sekunden festgelegt, während sie bei Apple als Ablaufdatum festgelegt wird.

Beispiel: Benachrichtigungsnachricht 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 Folgendes:

• Legt eine lange Gültigkeitsdauer für Android- und Webplattformen fest und setzt die Nachrichtenpriorität für APNs (Apple-Plattformen) auf einen niedrigen Wert.
• Legt die entsprechenden Schlüssel fest, um das Ergebnis eines Nutzertaps auf die Benachrichtigung unter Android und Apple zu definieren – click_action bzw. 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"
       }
     }
   }
 }

Vollständige 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 Sendeanfragen, die den Nachrichtentext enthalten, finden Sie unter Sendeanfragen erstellen.

Lieferoptionen

FCM bietet eine Reihe von Zustellungsoptionen für Nachrichten, die an Android-Geräte gesendet werden, und ermöglicht ähnliche Optionen auf Apple-Plattformen und im Web. Das Verhalten von „minimierbaren“ Nachrichten wird beispielsweise auf Android über FCM collapse_key, 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 gesendet wird. Eine nicht minimierbare Nachricht enthält nützliche Inhalte, im Gegensatz zu einer minimierbaren Nachricht wie einem inhaltslosen „Ping“ an die mobile App, um Daten vom Server abzurufen.

FCM garantiert keine Reihenfolge der Zustellung.

Typische Anwendungsfälle für nicht minimierbare Nachrichten sind Chatnachrichten oder wichtige Nachrichten. In einer Messaging-App möchten Sie beispielsweise jede Nachricht zustellen, da jede Nachricht unterschiedliche Inhalte hat.

Bei Android können ohne Minimierung maximal 100 Nachrichten gespeichert werden. Wenn das Limit erreicht ist, werden alle gespeicherten Nachrichten verworfen. Wenn das Gerät wieder online ist, erhält es eine spezielle Nachricht, die darauf hinweist, dass das Limit erreicht wurde. Die App kann dann entsprechend reagieren, in der Regel durch Anfordern einer vollständigen Synchronisierung vom App-Server.

Eine minimierbare Nachricht ist eine Nachricht, die durch eine neue Nachricht ersetzt werden kann, wenn sie noch nicht auf dem Gerät zugestellt wurde.

Ein häufiger Anwendungsfall für minimierbare Nachrichten sind Nachrichten, mit denen eine mobile App aufgefordert wird, Daten vom Server zu synchronisieren. Ein Beispiel wäre eine Sport-App, die Nutzer über den aktuellen Spielstand informiert. Nur die letzte Nachricht ist relevant.

Wenn Sie eine Nachricht unter Android als minimierbar markieren möchten, fügen Sie den Parameter collapse_key in die Nutzlast der Nachricht ein. Standardmäßig ist der Collapse-Schlüssel der in der Firebase-Konsole registrierte Paketname der App. Auf dem FCM-Server können gleichzeitig vier verschiedene minimierbare Nachrichten pro Gerät gespeichert werden, die jeweils einen anderen Minimierungsschlüssel haben. Wenn Sie diese Anzahl überschreiten, behält FCM nur vier Schlüssel für das Minimieren bei. Es gibt keine Garantie dafür, welche Schlüssel beibehalten werden.

Themennachrichten ohne Nutzlast sind standardmäßig minimierbar. Benachrichtigungen sind immer minimierbar und der Parameter collapse_key wird ignoriert.

Welche sollte ich verwenden?

Aus Leistungssicht sind minimierbare Nachrichten die bessere Wahl, sofern Ihre App keine nicht minimierbaren Nachrichten benötigt. Wenn Sie jedoch minimierbare Nachrichten verwenden, beachten Sie, dass FCM zu einem bestimmten Zeitpunkt nur maximal vier verschiedene Minimierungsschlüssel pro Registrierungstoken zulässt.FCM Sie dürfen diese Zahl nicht überschreiten, da dies zu unvorhersehbaren Folgen führen kann.

	Nutzungsszenario	So senden Sie
Nicht minimierbar	Jede Nachricht ist für die Client-App wichtig und muss zugestellt werden.	Mit Ausnahme von Benachrichtigungsnachrichten sind alle Nachrichten standardmäßig nicht minimierbar.
Minimierbar	Wenn es eine neuere Nachricht gibt, durch die eine ältere, zugehörige Nachricht für die Client-App irrelevant wird, wird die ältere Nachricht durch FCM ersetzt. Beispiele: Nachrichten, die verwendet werden, um eine Datensynchronisierung vom Server aus zu starten, oder veraltete Benachrichtigungen.	Legen Sie den entsprechenden Parameter in Ihrer Nachrichtenanfrage fest: collapseKey auf Android-Geräten apns-collapse-id auf Apple Topic im Web collapse_key in Legacy-Protokollen (alle Plattformen)

Priorität einer Nachricht festlegen

Sie haben zwei Optionen zum Zuweisen der Zustellpriorität für Downstream-Nachrichten: „normal“ und „hoch“. Das Verhalten unterscheidet sich zwar geringfügig zwischen den Plattformen, die Zustellung von Nachrichten mit normaler und hoher Priorität funktioniert jedoch so:

• Normale Priorität: Nachrichten mit normaler Priorität werden sofort zugestellt, wenn die App im Vordergrund ausgeführt wird. Bei Apps, die im Hintergrund ausgeführt werden, kann es zu Verzögerungen bei der Zustellung kommen. 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 Zustellungspriorität auswählen.

• Hohe Priorität: FCM versucht, Nachrichten mit hoher Priorität sofort zu senden, auch wenn sich das Gerät im Inaktivmodus befindet. Nachrichten mit hoher Priorität sind für zeitkritische, für Nutzer sichtbare Inhalte vorgesehen.

Beim Senden von Datennachrichten an Apple-Geräte muss die Priorität auf 5 oder „normal“ festgelegt werden. Nachrichten, die mit hoher Priorität gesendet werden, werden vom FCM-Backend mit dem Fehler INVALID_ARGUMENT abgelehnt.

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 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 Informationen zum Festlegen der Nachrichtenpriorität:

• APNs-Dokumentation
• Nachrichtenpriorität festlegen und verwalten (Android)
• Dringlichkeit von Web-Push-Benachrichtigungen

Lebenswichtige Anwendungsfälle

Die FCM-APIs sind nicht für Notfallbenachrichtigungen oder andere Aktivitäten mit hohem Risiko konzipiert, bei denen die Nutzung oder der Ausfall der APIs zu Tod, Personenschäden oder Umweltschäden führen könnte (z. B. der Betrieb von kerntechnischen Anlagen, die Überwachung des Flugverkehrs oder Lebenserhaltungssysteme). Eine solche Nutzung ist gemäß Abschnitt 4.a. ausdrücklich untersagt. 7 der Nutzungsbedingungen. Sie sind allein dafür verantwortlich, dass Ihre App den Nutzungsbedingungen entspricht, und haften für alle Schäden, die durch Ihre Nichteinhaltung entstehen. Google stellt die APIs „wie besehen“ zur Verfügung und behält sich das Recht vor, die APIs oder einen Teil bzw. eine Funktion davon oder Ihren Zugriff darauf aus einem beliebigen Grund und zu einem beliebigen Zeitpunkt ohne Haftung oder sonstige Verpflichtung Ihnen oder Ihren Nutzern gegenüber einzustellen.

Gültigkeitsdauer einer Nachricht festlegen

FCM stellt Nachrichten in der Regel sofort nach dem Senden zu. Das ist jedoch nicht immer möglich. Wenn die Plattform beispielsweise Android ist, kann das Gerät ausgeschaltet, offline oder anderweitig nicht verfügbar sein. Oder FCM verzögert Nachrichten absichtlich, um zu verhindern, dass eine App zu viele Ressourcen verbraucht und die Akkulaufzeit negativ beeinflusst.

In diesem Fall speichert FCM die Nachricht und stellt sie so bald wie möglich zu. In den meisten Fällen ist das kein Problem, aber bei einigen Apps ist es wichtig, dass Nachrichten rechtzeitig zugestellt werden. Wenn die Nachricht beispielsweise eine Benachrichtigung über einen eingehenden Anruf oder Videochat ist, ist sie nur für kurze Zeit relevant, bevor der Anruf beendet wird. Oder wenn die Nachricht eine Einladung zu einem Termin ist, 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 angeben. Der Wert muss eine Dauer zwischen 0 und 2.419.200 Sekunden (28 Tage) sein. Er entspricht dem maximalen Zeitraum, in dem FCM die Nachricht speichert und versucht, sie zuzustellen. Bei Anfragen, die dieses Feld nicht enthalten, wird standardmäßig der maximale Zeitraum von vier Wochen verwendet.

Hier sind einige mögliche Anwendungsbereiche für diese Funktion:

• Eingehende Videoanrufe
• Ablaufende Einladungsereignisse
• Kalendertermine

Ein weiterer Vorteil der Angabe der Lebensdauer einer Nachricht ist, dass FCM die Drosselung von minimierbaren Nachrichten nicht auf Nachrichten mit einem TTL-Wert von 0 Sekunden anwendet. FCM bietet eine Best-Effort-Verarbeitung von 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, ist die Latenz beim Senden von Benachrichtigungen am geringsten.

Hier ist ein Beispiel für eine Anfrage, die 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 das nicht, dass die Nachricht bereits auf dem Gerät zugestellt wurde. Das bedeutet nicht, dass es bereits ausgeliefert wurde, sondern dass es für die Auslieferung angenommen wurde. Was mit der Nachricht passiert, nachdem sie akzeptiert wurde, hängt von vielen Faktoren ab.

Im Best-Case-Szenario, wenn das Gerät mit FCM verbunden ist, das Display eingeschaltet ist und keine Einschränkungen durch Drosselung vorliegen, wird die Nachricht sofort zugestellt.

Wenn das Gerät verbunden ist, sich aber im Inaktivmodus befindet, wird eine Nachricht mit niedriger Priorität von FCM gespeichert, bis das Gerät den Inaktivmodus verlässt. Hier kommt das Flag collapse_key ins Spiel: Wenn bereits eine Nachricht mit demselben Collapse-Schlüssel (und Registrierungstoken) gespeichert ist und auf die Zustellung wartet, wird die alte Nachricht verworfen und die neue Nachricht tritt an ihre Stelle (d. h. die alte Nachricht wird durch die neue Nachricht zusammengefasst). Wenn der Collapse-Schlüssel jedoch nicht festgelegt ist, werden sowohl die neue als auch die alte Nachricht für die zukünftige Zustellung gespeichert.

Wenn das Gerät nicht mit FCM verbunden ist, wird die Nachricht gespeichert, bis eine Verbindung hergestellt wird (wobei die Regeln für den Collapse-Schlüssel beachtet werden). Wenn eine Verbindung hergestellt wird, werden alle ausstehenden Nachrichten von FCM an das Gerät gesendet. Wenn das Gerät nie wieder verbunden wird (z. B. wenn es auf die Werkseinstellungen zurückgesetzt wurde), läuft die Zeit für die Meldung irgendwann ab und sie wird aus dem FCM-Speicher gelöscht. Die Standardzeitüberschreitung beträgt vier Wochen, sofern das Flag time_to_live nicht festgelegt ist.

So erhalten Sie weitere Informationen zur Zustellung einer Nachricht:

Weitere Informationen zur Zustellung von Nachrichten auf Android- oder Apple-Plattformen finden Sie im FCM-Berichtsdashboard. Dort wird die Anzahl der Nachrichten erfasst, die auf Apple- und Android-Geräten gesendet und geöffnet wurden. Außerdem sind Daten zu „Impressionen“ (Benachrichtigungen, die von Nutzern gesehen wurden) für Android-Apps verfügbar.

Wenn auf Android-Geräten mit aktivierter Direktkanal-Nachrichtenfunktion seit mehr als einem Monat keine Verbindung zu FCM hergestellt wurde, akzeptiert FCM die Nachricht zwar, verwirft sie aber sofort. Wenn sich das Gerät innerhalb von vier Wochen nach der letzten Datenmeldung, die Sie an das Gerät gesendet haben, verbindet, erhält Ihr Client den onDeletedMessages()-Callback. Die App kann dann entsprechend reagieren, in der Regel durch Anfordern einer vollständigen Synchronisierung vom App-Server.

Wenn FCM schließlich 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 Kontingente

Unser Ziel ist es, jede über FCM gesendete Nachricht zuzustellen. Allerdings kann es zu einer schlechten Nutzererfahrung führen, wenn jede Nachricht zugestellt wird. In anderen Fällen müssen wir Grenzen festlegen, damit FCM einen skalierbaren Dienst für alle Absender bereitstellen kann. Die in diesem Abschnitt beschriebenen Arten von Limits und Kontingenten helfen uns, diese wichtigen Faktoren in Einklang zu bringen.

Hinweis :Die in diesem Abschnitt beschriebenen Limits können sich ändern.

Drosselung nachgelagerter Nachrichten

Mit der HTTP v1 API wurden Kontingente pro Projekt und Minute für Downstream-Messaging eingeführt. Das Standardkontingent von 600.000 Nachrichten pro Minute deckt über 99% der FCM-Entwickler ab und schützt gleichzeitig die Stabilität des Systems und minimiert die Auswirkungen von Projekten mit Spitzen.

Spitzen im Traffic können zu Fehlern aufgrund von Kontingentüberschreitungen führen. Wenn das Kontingent überschritten wird, gibt das System den HTTP-Statuscode 429 (QUOTA_EXCEEDED) zurück, bis das Kontingent in der folgenden Minute wieder aufgefüllt wird. 429-Antworten können auch in Überlastungssituationen zurückgegeben werden. Wir empfehlen daher dringend, 429-Antworten gemäß den veröffentlichten Empfehlungen zu verarbeiten.

Hinweis:

• Beim Downstream-Kontingent werden Nachrichten und nicht Anfragen gemessen.
• Clientfehler (HTTP-Statuscode 400–499) werden gezählt (außer 429).
• Kontingente gelten pro Minute, aber diese Minuten sind nicht an die Uhrzeit angepasst.

Kontingent für Monitoring

Sie können Kontingente, Nutzung und Fehler in der Google Cloud Console ansehen:

1. Rufen Sie die Google Cloud-Konsole auf.
2. Wählen Sie APIs & Dienste aus.
3. Wählen Sie in der Tabellenliste die Firebase Cloud Messaging API aus.
4. Wählen Sie KONTINGENTE UND SYSTEMLIMITS aus.

HINWEIS: Diese Grafiken sind nicht genau auf die Kontingentminuten abgestimmt. Das bedeutet, dass möglicherweise 429-Fehler ausgegeben werden, obwohl der Traffic unter dem Kontingent liegt.

Kontingenterhöhung anfordern

Bevor Sie eine Kontingenterhöhung beantragen, sollten Sie Folgendes prüfen:

• Ihre Nutzung liegt regelmäßig mindestens 5 Minuten pro Tag bei ≥ 80% des Kontingents.
• Sie haben ein Client-Fehlerverhältnis von unter 5 %, insbesondere bei Spitzen-Traffic.
• Sie halten sich an die Best Practices für das Senden von Nachrichten im großen Maßstab.

Wenn Sie diese Kriterien erfüllen, können Sie eine Kontingenterhöhung um bis zu 25% anfordern. FCM wird sich nach Kräften bemühen, die Anfrage zu erfüllen. Eine Erhöhung kann jedoch nicht garantiert werden.

Wenn Sie aufgrund eines bevorstehenden Starts oder eines temporären Ereignisses mehr Kontingent für Downstream-Nachrichten benötigen, fordern Sie das Kontingent mindestens 15 Tage im Voraus an, damit genügend Zeit für die Bearbeitung der Anfrage bleibt. Bei großen Anfragen (>18 Millionen Nachrichten pro Minute) ist eine Vorlaufzeit von mindestens 30 Tagen erforderlich. Für Anfragen zu Produkteinführungen und besonderen Ereignissen gelten weiterhin die Anforderungen an das Clientfehlerverhältnis und die Best Practices.

Häufig gestellte Fragen zu FCM-Kontingenten

Limit für Themennachrichten

Die Rate für das Hinzufügen/Entfernen von Themenabos ist auf 3.000 Abfragen pro Sekunde pro Projekt begrenzt.

Informationen zu den Raten für das Senden von Nachrichten finden Sie unter Fanout-Drosselung.

Fan-Out-Drosselung

Beim Fanout von Nachrichten wird eine Nachricht an mehrere Geräte gesendet, z. B. wenn Sie auf Themen und Gruppen ausrichten oder wenn Sie mit dem Notifications Composer auf Zielgruppen oder Nutzersegmente ausrichten.

Das Fanout von Nachrichten erfolgt nicht sofort. Daher kann es vorkommen, dass mehrere Fanouts gleichzeitig laufen. Wir beschränken die Anzahl gleichzeitiger Message-Fanouts pro Projekt auf 1.000. Danach lehnen wir möglicherweise zusätzliche Fanout-Anfragen ab oder verschieben die Fanout-Anfragen, 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 nicht ungewöhnlich, aber diese Zahl ist keine Garantie und hängt von der Gesamtlast des Systems ab. Die verfügbare Fanout-Kapazität wird auf Projekte aufgeteilt und nicht auf Fanout-Anfragen. Wenn für Ihr Projekt also zwei Fanouts laufen, wird für jeden Fanout nur die Hälfte der verfügbaren Fanout-Rate verwendet. Am besten maximieren Sie die Fanout-Geschwindigkeit, indem Sie jeweils nur einen aktiven Fanout-Vorgang ausführen.

Minimierbare Nachrichtenbegrenzung

Wie oben beschrieben, sind minimierbare Nachrichten inhaltslose Benachrichtigungen, die übereinander minimiert werden. Wenn ein Entwickler dieselbe Nachricht zu häufig an eine App sendet, verzögern wir die Nachrichten, um den Akkuverbrauch des Nutzers zu reduzieren.

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 erfolgt ausschließlich, um die Auswirkungen auf den Akku für den Nutzer zu begrenzen.

Wenn Ihr Anwendungsfall hohe Burst-Sende-Muster erfordert, sind nicht minimierbare Nachrichten möglicherweise die richtige Wahl. Achten Sie bei solchen Nachrichten darauf, dass der Inhalt in diesen Nachrichten enthalten ist, um die Akku-Kosten zu senken.

Wir beschränken minimierbare Nachrichten auf 20 Nachrichten pro App und Gerät. Danach wird alle 3 Minuten eine neue Nachricht hinzugefügt.

Maximale Nachrichtenrate für ein einzelnes Gerät

Unter Android können Sie bis zu 240 Nachrichten pro Minute und 5.000 Nachrichten pro Stunde an ein einzelnes Gerät senden. Dieser hohe Grenzwert soll kurzfristige Traffic-Spitzen ermöglichen, z. B. wenn Nutzer schnell über den Chat interagieren. Dieses Limit verhindert, dass der Akku eines Geräts durch Fehler in der Sendelogik versehentlich entladen wird.

Unter iOS wird ein Fehler zurückgegeben, wenn die Rate die APNs-Grenzwerte überschreitet.

Achtung: Senden Sie nicht regelmäßig Nachrichten mit dieser maximalen Rate. Das kann die Ressourcen von Endnutzern verschwenden und Ihre App kann als missbräuchlich gekennzeichnet werden.

FCM-Ports und Ihre Firewall

Wenn Ihre Organisation eine Firewall verwendet, um den Traffic zum oder vom Internet einzuschränken, müssen Sie sie so konfigurieren, dass sich Mobilgeräte mit FCM verbinden 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 sich mit Ihrem Netzwerk verbinden, stellt FCM keine bestimmten IPs bereit, da sich unser IP-Bereich zu häufig ändert und Ihre Firewallregeln veraltet sein könnten, was sich auf die Nutzererfahrung auswirken würde. Im Idealfall sollten Sie die Ports 5228–5230 und 443 ohne IP-Beschränkungen auf die Zulassungsliste setzen. Wenn Sie jedoch eine IP-Beschränkung benötigen, sollten Sie alle in goog.json aufgeführten IP-Adressen auf die Zulassungsliste setzen. Diese lange Liste wird regelmäßig aktualisiert. Wir empfehlen Ihnen, Ihre Regeln monatlich zu aktualisieren. Probleme, die durch IP-Einschränkungen der Firewall verursacht werden, treten oft nur zeitweise auf und sind 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 zusätzliche Hostnamen verwenden, werden wir die Liste hier aktualisieren. Die Verwendung von Domainnamen für Ihre Firewallregel funktioniert möglicherweise nicht auf Ihrem Firewallgerät.

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 mit Network Address Translation (NAT) und/oder Stateful Packet Inspection (SPI):

Wenn in Ihrem Netzwerk Network Address Translation (NAT) oder Stateful Packet Inspection (SPI) implementiert ist, 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 bereitstellen und gleichzeitig den Akkuverbrauch der Mobilgeräte Ihrer Nutzer reduzieren.

Hinweis :Wenn Sie Benachrichtigungen über APNs erhalten, müssen Sie auch die von Apple angegebenen Ports öffnen.

VPN-Interaktionen und Umgehungsmöglichkeiten

Firebase Cloud Messaging ergreift verschiedene Maßnahmen, um sicherzustellen, dass die Push-Messaging-Verbindung vom Smartphone zum Server zuverlässig ist und so oft wie möglich verfügbar ist. Die Verwendung eines VPN erschwert dies.

VPNs verschleiern die zugrunde liegenden Informationen, die FCM benötigt, um die Verbindung zu optimieren und die Zuverlässigkeit und Akkulaufzeit zu maximieren. In einigen Fällen werden langlebige Verbindungen durch VPNs aktiv unterbrochen, was zu einer schlechten Nutzererfahrung führt, da Nachrichten verpasst oder verzögert werden oder der Akkuverbrauch hoch ist. Wenn das VPN so konfiguriert ist, dass wir dies tun dürfen, umgehen wir das VPN über eine verschlüsselte Verbindung (über das WLAN oder LTE des Basisnetzwerks), um eine zuverlässige und akkusparende Nutzung zu ermöglichen. Die Verwendung von umgehbaren VPNs durch FCM ist spezifisch für den FCM-Push-Benachrichtigungskanal. Anderer FCM-Traffic, z. B. Registrierungstraffic, verwendet das VPN, wenn es aktiv ist. Wenn die FCM-Verbindung das VPN umgeht, gehen zusätzliche Vorteile verloren, die das VPN möglicherweise bietet, z. B. das Maskieren der IP-Adresse.

Bei verschiedenen VPNs gibt es unterschiedliche Methoden, um zu steuern, ob sie umgangen werden können. Eine 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 FCM v1-HTTP-Endpunkt verwendet wird. Dieser Wert ist in der Firebase-Konsole im Bereich Einstellungen verfügbar.
Registrierungstoken	Ein eindeutiger Token-String, der jede Client-App-Instanz identifiziert. Das Registrierungstoken ist für die Nachrichtenübermittlung an einzelne Geräte und Gerätegruppen erforderlich. Registrierungstokens müssen geheim gehalten werden.
Sender-ID	Ein eindeutiger numerischer Wert, der beim Erstellen Ihres Firebase-Projekts generiert wird. Sie finden ihn in der Registerkarte Cloud MessagingFirebaseFirebase-Konsole. Die Absender-ID wird verwendet, um jeden Absender zu identifizieren, der Nachrichten an die Client-App 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. Wenn Sie Zugriffstokens erstellen und rotieren möchten, folgen Sie der Anleitung unter Sendeanfragen autorisieren.
Serverschlüssel (für **eingestellte** Legacy-Protokolle)	Ein Serverschlüssel, der Ihren App-Server für den Zugriff auf Google-Dienste autorisiert, einschließlich des Sendens von Nachrichten über die eingestellten Firebase Cloud Messaging-Legacy-Protokolle. Wichtig:Fügen Sie den Serverschlüssel nicht in Ihren Clientcode ein. Verwenden Sie außerdem nur Serverschlüssel, um Ihren App-Server zu autorisieren. Android-, Apple-Plattform- und Browserschlüssel werden von FCM abgelehnt.