Über FCM-Meldungen

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

Nachrichtentypen

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

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

Benachrichtigungsnachrichten 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 4.000 Byte, außer beim Senden von Nachrichten von der Firebase-Konsole, die eine Beschränkung auf 1.000 Zeichen erzwingt.

Szenario verwenden Wie senden
Benachrichtigungsnachricht Das FCM SDK zeigt die Nachricht im Namen der Client-App auf Endbenutzergeräten an, wenn diese im Hintergrund ausgeführt wird. Andernfalls, wenn die App beim Empfang der Benachrichtigung im Vordergrund ausgeführt wird, bestimmt der Code der App das Verhalten. Benachrichtigungsnachrichten verfügen über einen vordefinierten Satz von für den Benutzer sichtbaren Schlüsseln und eine optionale Datennutzlast aus benutzerdefinierten Schlüssel-Wert-Paaren.

  1. 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 fest. Kann optionale Datennutzlast haben. Immer zusammenklappbar.

    Sehen Sie sich einige Beispiele für Anzeigebenachrichtigungen und Sendeanforderungsnutzlasten an.

  2. Verwenden Sie den Benachrichtigungseditor : Geben Sie den Nachrichtentext, den Titel usw. ein und senden Sie ihn. Fügen Sie optionale Datennutzlast hinzu, indem Sie benutzerdefinierte Daten bereitstellen.
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 in der Sendeanforderung den data fest.

Verwenden Sie Benachrichtigungsmeldungen, wenn Sie möchten, dass das FCM SDK die automatische Anzeige einer Benachrichtigung übernimmt, 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 übernimmt FCM die Anzeige der Benachrichtigungsnutzlast und die Client-App kümmert sich um die Datennutzlast.

Benachrichtigungsnachrichten

Zu Testzwecken oder für Marketing- und Benutzereinbindungen können Sie Benachrichtigungen über die Firebase-Konsole senden . Die Firebase-Konsole bietet analysebasierte A/B-Tests, die Ihnen helfen, Marketingbotschaften zu verfeinern und zu verbessern.

Um Benachrichtigungsnachrichten mithilfe des Admin SDK oder der FCM-Protokolle programmgesteuert zu senden, legen Sie den notification mit den erforderlichen vordefinierten Schlüsselwertoptionen für den für den Benutzer sichtbaren Teil der Benachrichtigungsnachricht fest. Hier ist beispielsweise eine JSON-formatierte Benachrichtigungsnachricht in einer IM-App. Der Benutzer kann eine Nachricht mit dem Titel „Portugal vs. Dänemark“ und dem Text „Tolles Spiel!“ erwarten. auf dem Gerät:

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

Benachrichtigungen werden an die Benachrichtigungsleiste übermittelt, wenn die App im Hintergrund ausgeführt wird. Bei Apps im Vordergrund werden Nachrichten von einer Rückruffunktion verarbeitet.

Die vollständige Liste der vordefinierten Schlüssel, die zum Erstellen von Benachrichtigungsnachrichten verfügbar sind, finden Sie in der Referenzdokumentation zum HTTP v1-Protokoll-Benachrichtigungsobjekt .

Datennachrichten

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 beispielsweise eine JSON-formatierte Nachricht in derselben IM-App wie oben, wobei die Informationen im 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 allgemeinen data , 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 für Datennachrichten

Der Android Transport Layer (siehe FCM-Architektur ) verwendet Punkt-zu-Punkt-Verschlüsselung. Abhängig von Ihren Anforderungen können Sie sich dafür 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.

Benachrichtigungsnachrichten mit optionaler Datennutzlast

Sowohl programmgesteuert als auch über die Firebase-Konsole können Sie Benachrichtigungsnachrichten senden, die eine optionale Nutzlast benutzerdefinierter Schlüssel-Wert-Paare 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 davon, 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, bei dem beide Nutzlasten verfügbar sind.

Hier ist eine JSON-formatierte Nachricht, 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 plattformübergreifend

Sowohl das Firebase Admin SDK als auch das HTTP-Protokoll FCM v1 ermöglichen es Ihren Nachrichtenanfragen, alle im message verfügbaren Felder festzulegen. Das beinhaltet:

  • ein gemeinsamer Satz von Feldern, der von allen App-Instanzen interpretiert werden soll, die die Nachricht empfangen.
  • Plattformspezifische Feldsätze wie AndroidConfig und WebpushConfig , 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 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:

  • 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, nicht aber 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 Zustellungsoptionen senden, verwenden Sie plattformspezifische Felder, um diese festzulegen. Sie können bei Bedarf unterschiedliche Werte pro Plattform angeben. Selbst wenn Sie jedoch plattformübergreifend im Wesentlichen denselben Wert festlegen möchten, müssen Sie plattformspezifische Felder verwenden. Dies liegt daran, dass jede Plattform den Wert möglicherweise etwas anders interpretiert. Beispielsweise wird die Gültigkeitsdauer bei Android als Ablaufzeit in Sekunden festgelegt, während sie bei 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 Überschreibungen. Im Einzelnen lautet die Anfrage:

  • legt eine lange Lebensdauer für Android- und Webplattformen fest, während die Nachrichtenpriorität der APNs (Apple-Plattformen) auf einen niedrigen Wert gesetzt wird
  • legt die entsprechenden Tasten fest, um das Ergebnis eines Benutzertipps auf die Benachrichtigung auf 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"
       }
     }
   }
 }

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

Lieferoptionen

FCM bietet eine Reihe spezifischer Zustellungsoptionen für an Android-Geräte gesendete Nachrichten 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 reduzierbare und reduzierbare Nachrichten

Eine nicht reduzierbare Nachricht bedeutet, dass jede einzelne Nachricht an das Gerät übermittelt wird. Eine nicht reduzierbare Nachricht liefert einige nützliche Inhalte, im Gegensatz zu einer reduzierbaren Nachricht wie einem inhaltslosen „Ping“ an die mobile App, um den Server zu kontaktieren und Daten abzurufen.

Einige typische Anwendungsfälle für nicht reduzierbare Nachrichten sind Chat-Nachrichten 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 Absturz 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äß bewältigen, 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 nicht an das Gerät übermittelt wurde.

Ein häufiger Anwendungsfall für zusammenklappbare 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 Punktestand aktualisiert. Nur die aktuellste Nachricht ist relevant.

Um eine Nachricht auf Android als reduzierbar zu markieren, fügen Sie den Parameter collapse_key in die Nachrichtennutzlast ein. Standardmäßig ist der Minimierungsschlüssel der in der Firebase-Konsole registrierte App-Paketname. Der FCM-Server kann gleichzeitig vier verschiedene reduzierbare Nachrichten pro Gerät speichern, jede mit einem anderen Reduzierschlüssel. Wenn Sie diese Zahl überschreiten, behält FCM nur vier Minimierungsschlüssel und gibt keine Garantie dafür, welche beibehalten werden.

Themennachrichten ohne Nutzlast sind standardmäßig reduzierbar. Benachrichtigungsnachrichten sind immer ausblendbar und ignorieren den Parameter collapse_key .

Was soll ich verwenden?

Reduzierbare Nachrichten sind unter Leistungsgesichtspunkten die bessere Wahl, vorausgesetzt, Ihre App muss keine nicht reduzierbaren Nachrichten verwenden. Wenn Sie jedoch zusammenklappbare Nachrichten verwenden, denken Sie daran, dass FCM zu einem bestimmten Zeitpunkt nur die Verwendung von maximal vier verschiedenen Zusammenbruchschlüsseln durch FCM pro Registrierungstoken zulässt. Sie dürfen diese Zahl nicht überschreiten, da dies sonst 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 Benachrichtigungsnachrichten sind alle Nachrichten standardmäßig nicht reduzierbar.
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 zum Initiieren einer Datensynchronisierung vom Server verwendet werden, oder veraltete Benachrichtigungsnachrichten. Legen Sie in Ihrer Nachrichtenanforderung den entsprechenden Parameter fest:
  • collapseKey auf Android
  • apns-collapse-id auf Apple
  • Topic im Web
  • collapse_key in älteren Protokollen (alle Plattformen)

Festlegen der Priorität einer Nachricht

Sie haben zwei Möglichkeiten, Downstream-Nachrichten die Zustellungspriorität zuzuweisen: normale und hohe Priorität. Obwohl sich das Verhalten von Plattform zu 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 die App im Vordergrund ist. Bei Apps im Hintergrund kann es zu Verzögerungen bei der Lieferung kommen. Wählen Sie für weniger zeitkritische Nachrichten, wie 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, auch wenn sich das Gerät im Doze-Modus befindet. Nachrichten mit hoher Priorität sind für zeitkritische, für den Benutzer sichtbare Inhalte vorgesehen.

Hier ist ein Beispiel einer normalen Prioritätsnachricht, 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 Details zum Festlegen der Nachrichtenpriorität:

Festlegen der Lebensdauer einer Nachricht

FCM stellt Nachrichten normalerweise sofort nach dem Senden zu. Dies ist jedoch möglicherweise nicht immer möglich. Wenn es sich bei der Plattform beispielsweise um Android handelt, könnte das Gerät ausgeschaltet, offline oder aus anderen Gründen nicht verfügbar sein. Oder FCM verzögert möglicherweise Nachrichten absichtlich, um zu verhindern, dass eine App übermäßig Ressourcen verbraucht und sich negativ auf die Akkulaufzeit auswirkt.

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, bei denen eine verspätete Nachricht möglicherweise auch nie zugestellt wird. Handelt es sich bei der Nachricht beispielsweise um einen eingehenden Anruf oder eine Video-Chat-Benachrichtigung, ist sie nur für einen kurzen Zeitraum von Bedeutung, bevor der Anruf beendet wird. Oder wenn es sich bei der Nachricht um eine Einladung zu einer Veranstaltung handelt, ist sie nutzlos, wenn sie erst nach Ende der Veranstaltung eingeht.

Auf 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) haben und entspricht dem maximalen Zeitraum, für den FCM die Nachricht speichert und zuzustellen versucht. Für Anfragen, die dieses Feld nicht enthalten, gilt standardmäßig der maximale Zeitraum von vier Wochen.

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

  • Video-Chat für eingehende Anrufe
  • Ablaufende Einladungsveranstaltungen
  • Kalenderereignisse

Ein weiterer Vorteil der Angabe der Lebensdauer einer Nachricht besteht darin, dass FCM keine zusammenklappbare Nachrichtendrosselung auf Nachrichten mit einem Time-to-Live-Wert von 0 Sekunden anwendet. FCM ermöglicht die bestmögliche Handhabung 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 niemals gespeichert werden, bietet dies die beste Latenz für das 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 das nicht, dass die Nachricht bereits an das Gerät übermittelt wurde. Es bedeutet vielmehr, dass es zur Lieferung angenommen wurde. Was mit der Nachricht nach der Annahme passiert, 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, speichert FCM eine Nachricht mit niedriger Priorität, bis das Gerät den Doze-Modus verlässt. Und hier spielt das Flag collapse_key eine Rolle: 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 (also die alte) tritt an ihre Stelle Die Nachricht wird durch die neue Nachricht ausgeblendet). Wenn der Minimierungsschlüssel jedoch nicht 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 wird (auch hier unter Berücksichtigung der Regeln für die Minimierungstaste). Wenn eine Verbindung hergestellt ist, übermittelt FCM alle ausstehenden 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 Meldung irgendwann ab und wird aus dem FCM-Speicher verworfen. Das Standard-Timeout beträgt vier Wochen, sofern das Flag time_to_live nicht gesetzt ist.

Um mehr Einblick in die Zustellung einer Nachricht zu erhalten:

    Weitere Einblicke in die Zustellung von Nachrichten auf Android- oder Apple-Plattformen erhalten Sie im FCM-Berichts-Dashboard , das die Anzahl der auf Apple- und Android-Geräten gesendeten und geöffneten Nachrichten sowie Daten zu „Impressionen“ (von Benutzern gesehene Benachrichtigungen) aufzeichnet Android Apps.

Bei Android-Geräten mit aktiviertem Direct Channel Messaging gilt: Wenn das Gerät länger als einen Monat lang keine Verbindung zum FCM hergestellt hat, akzeptiert FCM die Nachricht zwar, verwirft sie jedoch sofort. Wenn das Gerät innerhalb von vier Wochen nach der letzten Datennachricht, die Sie an es gesendet haben, eine Verbindung herstellt, erhält Ihr Client den Rückruf onDeletedMessages() . Die App kann die Situation dann ordnungsgemäß bewältigen, 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, jede über FCM gesendete Nachricht stets zuzustellen. Allerdings führt die Übermittlung jeder Nachricht manchmal zu einer insgesamt schlechten Benutzererfahrung. In anderen Fällen müssen wir Grenzen festlegen, um sicherzustellen, dass FCM einen skalierbaren Dienst für alle Absender bereitstellt.

Reduzierbare Nachrichtendrosselung

Wie oben beschrieben handelt es sich bei zusammenklappbaren Nachrichten um inhaltslose Benachrichtigungen, die so gestaltet sind, dass sie übereinander ausgeblendet werden. Für den Fall, dass ein Entwickler zu häufig dieselbe Nachricht an eine App sendet, 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-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 Durchschnittsrate synchronisiert werden kann. Diese Drosselung erfolgt ausschließlich, um die Auswirkungen auf die Batterie für den Benutzer zu begrenzen.

Wenn Ihr Anwendungsfall hohe Burst-Sendemuster erfordert, sind nicht reduzierbare Nachrichten möglicherweise die richtige Wahl. Stellen Sie bei solchen Nachrichten sicher, dass der Inhalt in solchen Nachrichten enthalten ist, um die Batteriekosten zu senken.

Wir beschränken die Anzahl zusammenklappbarer Nachrichten auf maximal 20 Nachrichten pro App und Gerät, wobei alle 3 Minuten eine neue Nachricht hinzugefügt wird.

Drosselung des XMPP-Servers

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 für die Nachrichtenzustellung kein Problem darstellen, ist aber wichtig, um die Stabilität des Systems sicherzustellen. Für jedes Projekt ermöglicht FCM 2500 Verbindungen parallel.

Für Upstream-Nachrichten mit XMPP begrenzt FCM Upstream-Nachrichten auf 1.500.000/Minute pro Projekt, um eine Überlastung der Upstream-Zielserver zu vermeiden.

Wir begrenzen die Upstream-Nachrichten pro Gerät auf 1.000/Minute, um eine Batterieentladung durch schlechtes App-Verhalten zu verhindern.

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 Verkehrsstöße ermöglichen, beispielsweise wenn Benutzer schnell über Chat interagieren. Dieser Grenzwert verhindert, dass Fehler in der Sendelogik unbeabsichtigt den Akku eines Geräts entladen.

Für iOS geben wir einen Fehler zurück, wenn die Rate die APN-Grenzwerte überschreitet.

Beschränkung der Themennachrichten

Die Rate zum Hinzufügen/Entfernen von Themenabonnements ist auf 3.000 QPS pro Projekt begrenzt.

Informationen zu Nachrichtenversandraten finden Sie unter Fanout-Drosselung .

Fanout-Drosselung

Beim Nachrichten-Fanout handelt es sich um den Vorgang, bei dem eine Nachricht an mehrere Geräte gesendet wird, z. B. wenn Sie Themen und Gruppen gezielt ansprechen oder wenn Sie den Notifications Composer verwenden, um Zielgruppen oder Benutzersegmente anzusprechen.

Der 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 weitere 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, diese Zahl ist jedoch 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-Anfragen aufgeteilt wird. Wenn in Ihrem Projekt also zwei Fanouts laufen, wird bei jedem Fanout nur die Hälfte der verfügbaren Fanout-Rate angezeigt. Die empfohlene Methode zur Maximierung Ihrer Fanout-Geschwindigkeit besteht darin, jeweils nur ein aktives Fanout auszuführen.

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 diese 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, manchmal jedoch 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 Firewall-Regeln veraltet sein könnten, was sich auf die Benutzererfahrung auswirken könnte. Idealerweise sollten Sie die Ports 5228–5230 und 443 ohne IP-Einschränkungen auf die Zulassungsliste setzen. Wenn Sie jedoch eine IP-Beschränkung haben müssen, 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, treten häufig nur 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 auf Ihrem Firewall-Gerät funktionsfähig sein oder auch 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

Network Address Translation- und/oder Stateful Packet Inspection-Firewalls:

Wenn Ihr Netzwerk Network Address Translation (NAT) oder Stateful Packet Inspection (SPI) implementiert, implementieren Sie eine Zeitüberschreitung von 30 Minuten oder mehr für unsere Verbindungen über die Ports 5228–5230. Dadurch können wir eine zuverlässige Konnektivität bereitstellen und gleichzeitig den Batterieverbrauch der Mobilgeräte Ihrer Benutzer reduzieren.

VPN-Interaktionen und Umgehungsfähigkeit

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

VPNs maskieren die zugrunde liegenden Informationen, die FCM benötigt, um seine Verbindung zu optimieren und so die Zuverlässigkeit und Akkulaufzeit zu maximieren. In einigen Fällen unterbrechen VPNs aktiv langlebige Verbindungen, was zu einer schlechten Benutzererfahrung aufgrund verpasster oder verzögerter Nachrichten oder hoher Batteriekosten führt. Wenn das VPN so konfiguriert ist, dass wir dies zulassen, umgehen wir das VPN mithilfe einer verschlüsselten Verbindung (über das Basisnetzwerk WLAN oder LTE), um ein zuverlässiges, batterieschonendes Erlebnis zu gewährleisten. Die Verwendung umgehbarer VPNs durch FCM ist spezifisch für den FCM-Push-Benachrichtigungskanal. Anderer FCM-Verkehr, wie z. B. Registrierungsverkehr, nutzt das VPN, sofern es aktiv ist. Wenn die FCM-Verbindung das VPN umgeht, gehen zusätzliche Vorteile verloren, die das VPN möglicherweise bietet, wie z. B. IP-Maskierung.

Verschiedene VPNs verfügen über unterschiedliche Methoden zur Steuerung, ob es umgangen werden kann oder nicht. Anweisungen dazu finden Sie in der Dokumentation zu Ihrem spezifischen VPN.

Wenn das VPN nicht als umgehbar konfiguriert ist, verwendet Firebase Cloud Messaging das VPN-Netzwerk, um eine Verbindung zum Server herzustellen. Dies kann dazu führen, dass Nachrichten zeitweise verzögert gesendet werden und der Akku stärker beansprucht wird, da Cloud Messaging die Verbindung über die VPN-Verbindung aufrechterhält.

Referenzen

Abhängig davon, welche FCM-Funktionen Sie implementieren, benötigen Sie möglicherweise die folgenden Anmeldeinformationen für Ihr 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 im Bereich „Einstellungen“ 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 Anfragen an die HTTP v1-API autorisiert. Dieses Token ist mit einem Dienstkonto verknüpft, das zu Ihrem Firebase-Projekt gehört. Um Zugriffstoken zu erstellen und zu rotieren, befolgen Sie die unter Autorisieren von Sendeanforderungen beschriebenen Schritte.
Serverschlüssel (für **veraltete** 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 veralteten Firebase Cloud Messaging-Legacy-Protokolle.

Wichtig: Fügen Sie den Serverschlüssel nirgendwo in Ihren Clientcode ein. Stellen Sie außerdem sicher, dass Sie zur Autorisierung Ihres App-Servers nur Serverschlüssel verwenden. Android-, Apple-Plattform- und Browserschlüssel werden von FCM abgelehnt.