Check out what’s new from Firebase@ Google I/O 2021, and join our alpha program for early access to the new Remote Config personalization feature. Learn more

Über FCM-Nachrichten

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:

  • Benachrichtigungsnachrichten, die manchmal als "Anzeigenachrichten" bezeichnet werden. 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. Datennachrichten hingegen enthalten 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 Begrenzung von 1024 Zeichen erzwingt.

Szenario verwenden Wie senden
Benachrichtigungsnachricht FCM zeigt die Nachricht automatisch im Namen der Client-App auf den Endbenutzergeräten an. Benachrichtigungsnachrichten haben einen vordefinierten Satz von für den Benutzer sichtbaren Schlüsseln und eine optionale Datennutzlast von 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 FCM-Serverprotokolle : Legen Sie den notification . 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 nur den data .

Verwenden Sie Benachrichtigungen, wenn Sie möchten, dass FCM die Anzeige einer Benachrichtigung im Namen Ihrer Client-App übernimmt. Verwenden Sie Datennachrichten, wenn Sie die Nachrichten in Ihrer Client-App 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 verarbeitet die Datennutzlast.

Benachrichtigungen

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

Um Benachrichtigungsnachrichten programmgesteuert mit dem Admin SDK oder den FCM-Protokollen 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 User 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!"
    }
  }
}

Benachrichtigungen werden an die Benachrichtigungsleiste gesendet, wenn die App im Hintergrund läuft. Bei Apps im Vordergrund werden Nachrichten über eine Callback-Funktion abgewickelt.

In der Referenzdokumentation finden Sie die vollständige Liste der vordefinierten Schlüssel, die für Gebäudebenachrichtigungsnachrichten verfügbar sind:

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, den Inhalt zu interpretieren:

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

Das obige Beispiel zeigt die Verwendung des Top-Level- oder allgemeinen data , das von Clients auf allen Plattformen interpretiert wird, die die Nachricht empfangen. 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 eine Punkt-zu-Punkt-Verschlüsselung. Abhängig von Ihren Anforderungen können Sie Datennachrichten mit einer Ende-zu-Ende-Verschlüsselung versehen. FCM bietet keine End-to-End-Lösung. Es stehen jedoch externe Lösungen wie Kapillare oder DTLS zur Verfügung .

Benachrichtigungsnachrichten mit optionaler Datennutzlast

Sowohl programmatisch als auch über die Firebase-Konsole können Sie Benachrichtigungen 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 Empfangen 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 mit beiden verfügbaren Nutzlasten.

Hier ist eine JSON-formatierte Nachricht, die sowohl den notification als auch den data :

{
  "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 wird, die die Nachricht empfangen.
  • plattformspezifische AndroidConfig von Feldern, 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 allgemeine Felder verwendet werden?

Verwenden Sie allgemeine Felder, wenn Sie:

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

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

Wann sollten plattformspezifische Felder verwendet werden?

Verwenden Sie plattformspezifische Felder, wenn Sie:

  • Felder nur an bestimmte Plattformen senden
  • Senden Sie plattformspezifische Felder zusätzlich zu den allgemeinen Feldern

Wenn Sie Werte nur an bestimmte Plattformen senden möchten, verwenden Sie keine allgemeinen Felder; plattformspezifische Felder verwenden. Um beispielsweise eine Benachrichtigung nur an iOS und das Web, aber nicht an Android zu senden, müssen Sie zwei separate Feldersätze verwenden, einen für iOS 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 – zum Beispiel wird die Lebensdauer auf Android als Ablaufzeit in Sekunden festgelegt, während sie auf iOS 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. Konkret die Bitte:

  • legt eine lange Lebensdauer für Android- und Web-Plattformen fest, während die Nachrichtenpriorität der APNs (iOS) auf eine niedrige Einstellung gesetzt wird
  • legt die entsprechenden Schlüssel fest, um das Ergebnis eines Benutzertippens auf die Benachrichtigung auf Android und iOS 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 Sendeanforderungen , die den Nachrichtentext enthalten, finden Sie unter Erstellen von Sendeanforderungen .

Lieferoptionen

FCM bietet einen bestimmten Satz von Zustellungsoptionen für Nachrichten, die an Android-Geräte gesendet werden, und ermöglicht ähnliche Optionen für iOS und das Web. Beispielsweise wird das Verhalten von "zusammenklappbaren" Nachrichten auf Android über den collapse_key FCM, auf iOS über apns-collapse-id und auf JavaScript/Web über Topic . Einzelheiten finden Sie in den Beschreibungen in diesem Abschnitt und in der zugehörigen Referenzdokumentation.

Nicht zusammenklappbare und zusammenklappbare Nachrichten

Eine nicht zusammenklappbare Nachricht bedeutet, dass jede einzelne Nachricht an das Gerät geliefert wird. Eine nicht komprimierbare Nachricht liefert einige nützliche Inhalte, im Gegensatz zu einer komprimierbaren Nachricht wie einem inhaltsfreien "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 Kollabieren 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äß verarbeiten, 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 werden muss.

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 Spielstand aktualisiert. Nur die aktuellste Nachricht ist relevant.

Um eine Nachricht unter Android als komprimierbar zu markieren, fügen Sie den Parameter " collapse_key in die Nachrichtennutzlast ein. Standardmäßig ist der Minimierungsschlüssel der Name des App-Pakets, 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 Zahl überschreiten, behält FCM nur vier Minimierungsschlüssel, ohne dass garantiert wird, welche Schlüssel aufbewahrt werden.

Themennachrichten ohne Nutzlast sind standardmäßig reduzierbar.

Welche soll ich verwenden?

Aus Leistungsgesichtspunkten sind komprimierbare Nachrichten die bessere Wahl, sofern Ihre App keine nicht komprimierbaren Nachrichten verwenden muss. Wenn Sie jedoch komprimierbare Nachrichten verwenden, denken Sie daran, dass FCM zu einem bestimmten Zeitpunkt nur die Verwendung von maximal vier verschiedenen Reduzierschlüsseln durch den FCM-Verbindungsserver pro Registrierungstoken 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 Benachrichtigungsnachrichten sind alle Nachrichten standardmäßig nicht komprimierbar.
Zusammenklappbar Wenn eine neuere Nachricht vorhanden ist, die eine ältere zugehörige 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:
  • collapseKey auf Android
  • apns-collapse-id auf iOS
  • Topic im Web
  • collapse_key in Legacy-Protokollen (alle Plattformen)

Priorität einer Nachricht einstellen

Sie haben zwei Möglichkeiten, Downstream-Nachrichten auf Android eine Zustellpriorität zuzuweisen: normale und hohe Priorität. Die Zustellung von Nachrichten mit normaler und hoher Priorität funktioniert wie folgt:

  • Normale Priorität. Dies ist die Standardpriorität für Datennachrichten . Nachrichten mit normaler Priorität werden sofort zugestellt, wenn sich die App im Vordergrund befindet. Wenn sich das Gerät im Ruhezustand befindet, kann sich die Lieferung verzögern, um die Batterie zu schonen. Wählen Sie für weniger zeitkritische Nachrichten, z.

    Wenn Sie auf Android eine Nachricht mit normaler Priorität erhalten, die eine Hintergrunddatensynchronisierung für Ihre App anfordert, können Sie mit WorkManager eine Aufgabe planen , um diese zu bearbeiten, wenn das Netzwerk verfügbar ist.

  • Hohe Priorität. FCM versucht, Nachrichten mit hoher Priorität sofort zu übermitteln, sodass der FCM-Dienst bei Bedarf ein schlafendes Gerät aufwecken und eine eingeschränkte Verarbeitung ausführen kann (einschließlich eines sehr eingeschränkten Netzwerkzugriffs). Nachrichten mit hoher Priorität sollten im Allgemeinen zu einer Benutzerinteraktion mit Ihrer App oder ihren Benachrichtigungen führen. Wenn FCM ein Muster erkennt, in dem dies nicht der Fall ist, werden Ihre Nachrichten möglicherweise nicht mehr priorisiert. Android P hat App-Standby-Buckets eingeführt, die die Anzahl der FCM-Nachrichten mit hoher Priorität begrenzen, die Sie an Ihre App senden können und die nicht dazu führen, dass der Benutzer Ihre App verwendet oder eine Benachrichtigung anzeigt. Wenn als Reaktion auf eine Nachricht mit hoher Priorität eine Benachrichtigung für den Benutzer sichtbar angezeigt wird, wird Ihr App-Standby-Bucket-Kontingent von dieser Nachricht nicht verbraucht.

    Da sich ein kleiner Teil der mobilen Android-Bevölkerung in Netzwerken mit hoher Latenz befindet, vermeiden Sie es, eine Verbindung zu Ihren Servern herzustellen, bevor Sie eine Benachrichtigung anzeigen. Ein Rückruf zum Server vor Ablauf der zulässigen Verarbeitungszeit kann für Benutzer in Netzwerken mit hoher Latenz riskant sein. Fügen Sie stattdessen den Benachrichtigungsinhalt in die FCM-Nachricht ein und zeigen Sie ihn sofort an. Wenn Sie für zusätzliche In-App-Inhalte auf Android synchronisieren müssen, können Sie mit WorkManager eine Aufgabe planen , die dies im Hintergrund erledigt .

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:

Einstellen der Lebensdauer einer Nachricht

FCM stellt Nachrichten normalerweise unmittelbar nach dem Senden zu. 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äßige Ressourcen verbraucht und die Akkulaufzeit negativ beeinflusst.

In diesem Fall speichert FCM die Nachricht und übermittelt sie, sobald dies möglich ist. Obwohl dies in den meisten Fällen in Ordnung ist, gibt es einige Apps, bei denen eine verspätete Nachricht möglicherweise nie zugestellt wird. Handelt es sich bei der Nachricht beispielsweise um einen eingehenden Anruf oder eine Videochat-Benachrichtigung, ist sie nur für einen kurzen Zeitraum sinnvoll, bevor der Anruf beendet wird. Oder wenn die Nachricht eine Einladung zu einer Veranstaltung ist, ist sie nutzlos, wenn sie nach dem Ende der Veranstaltung empfangen wird.

Unter Android und Web/JavaScript können Sie die maximale Lebensdauer einer Nachricht festlegen. Der Wert muss eine Dauer von 0 bis 2.419.200 Sekunden (28 Tage) haben und entspricht dem maximalen Zeitraum, für den FCM die Nachricht speichert und versucht, sie zuzustellen. Anfragen, die dieses Feld nicht enthalten, haben standardmäßig den maximalen Zeitraum von vier Wochen.

Hier sind einige Verwendungsmöglichkeiten für diese Funktion:

  • Eingehende Anrufe per Video-Chat
  • Auslaufende Einladungsereignisse
  • Kalenderereignisse

Ein weiterer Vorteil der Angabe der Lebensdauer einer Nachricht besteht darin, dass FCM Nachrichten mit einem Time-to-Live-Wert von 0 Sekunden niemals drosselt. Mit anderen Worten, FCM garantiert Best Effort für Nachrichten, die "jetzt oder nie" zugestellt werden müssen. time_to_live Sie, dass ein time_to_live Wert von 0 bedeutet, dass Nachrichten, die nicht sofort time_to_live 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"
      }
    }
  }
}

Empfangen von Nachrichten von mehreren Absendern

FCM ermöglicht es mehreren Parteien, Nachrichten an dieselbe Client-App zu senden. Angenommen, die Client-App ist ein Artikelaggregator mit mehreren Mitwirkenden, und jeder von ihnen sollte in der Lage sein, eine Nachricht zu senden, wenn er einen neuen Artikel veröffentlicht. Diese Nachricht kann eine URL enthalten, damit die Client-App den Artikel herunterladen kann. Anstatt alle Sendeaktivitäten an einem Ort zu zentralisieren, gibt Ihnen FCM die Möglichkeit, jedem dieser Mitwirkenden seine eigenen Nachrichten senden zu lassen.

Um diese Funktion zu aktivieren, vergewissern Sie sich, dass Sie die Absender- ID jedes Absenders haben . Beim Anfordern einer Registrierung ruft die Client-App das Token mehrmals ab, jedes Mal mit einer anderen Absender-ID im Zielgruppenfeld, und verwendet die Token-Abrufmethode für die angegebene Plattform:

Stellen Sie sicher, dass Sie einer einzelnen Token-Anfrage nicht mehrere Absender-IDs hinzufügen, da dies zu unvorhersehbaren Ergebnissen führen kann. Tätigen Sie jeden Anruf separat, einmal pro Absender-ID.

Geben Sie schließlich das Registrierungstoken für die entsprechenden Absender frei, und diese können mit ihren eigenen Authentifizierungsschlüsseln Nachrichten an die Client-App senden.

Beachten Sie, dass es maximal 100 mehrere Absender gibt.

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 zugestellt 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 es keine Drosselungsbeschränkungen gibt, wird die Nachricht sofort zugestellt.

Wenn das Gerät verbunden ist, sich aber im Doze-Modus befindet, wird vom FCM eine Nachricht mit niedriger Priorität gespeichert, bis das Gerät den Doze-Modus verlassen hat. Und hier spielt das Flag " collapse_key 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 (also die alte .). Nachricht wird durch die neue zugeklappt). 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 (wiederum unter Beachtung der Regeln für den Minimierungsschlü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 möglicherweise ab und wird aus dem FCM-Speicher verworfen. Das Standard-Timeout beträgt vier Wochen, es sei denn, das time_to_live Flag ist gesetzt.

So erhalten Sie mehr Einblick in die Zustellung einer Nachricht:

    Weitere Informationen zur Zustellung von Nachrichten auf Android- oder iOS-Geräten finden Sie im FCM-Berichts-Dashboard , das die Anzahl der gesendeten und geöffneten Nachrichten auf iOS- und Android-Geräten sowie Daten für "Impressionen" (von Benutzern gesehene Benachrichtigungen) für Android aufzeichnet Apps.

Bei Android-Geräten mit aktiviertem Direktkanal-Messaging akzeptiert FCM die Nachricht immer noch, wenn das Gerät länger als einen Monat nicht mit FCM verbunden war, verwirft sie jedoch sofort. Wenn das Gerät innerhalb von vier Wochen nach der letzten von Ihnen gesendeten Datennachricht eine Verbindung herstellt , erhält Ihr Client den onDeletedMessages()- Rückruf. Die App kann die Situation dann ordnungsgemäß verarbeiten, indem sie normalerweise eine vollständige Synchronisierung vom App-Server anfordert.

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. 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 festlegen, um sicherzustellen, dass FCM einen skalierbaren Dienst für alle Absender bereitstellt.

Einklappbare Nachrichtendrosselung

Wie oben beschrieben, sind komprimierbare Nachrichten inhaltsfreie Benachrichtigungen, die so konzipiert sind, dass sie übereinander kollabieren. Für den Fall, dass ein Entwickler dieselbe Nachricht zu häufig an eine App sendet, verzögern (drosseln) wir Nachrichten, um die Auswirkungen auf den Akku eines Benutzers zu reduzieren.

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 synchronisiert werden kann. Diese Drosselung erfolgt ausschließlich, um die Auswirkungen auf den Akku des Benutzers zu begrenzen.

Wenn Ihr Anwendungsfall hohe Burst-Sendemuster erfordert, sind nicht zusammenklappbare Nachrichten möglicherweise die richtige Wahl. Achten Sie bei solchen Nachrichten darauf, den Inhalt in solche Nachrichten aufzunehmen, um die Akkukosten zu senken.

Wir begrenzen zusammenklappbare Nachrichten auf 20 Nachrichten pro App und Gerät, wobei alle 3 Minuten 1 Nachricht 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 für die Nachrichtenübermittlung kein Problem darstellen, ist jedoch 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

Sie können bis zu 240 Nachrichten/Minute und 5.000 Nachrichten/Stunde an ein einzelnes Gerät senden. Dieser hohe Schwellenwert soll kurzfristige Datenverkehrsausbrüche ermöglichen, z. B. wenn Benutzer schnell über einen Chat interagieren. Diese Grenze verhindert, dass Fehler in der Sendelogik versehentlich den Akku eines Geräts entladen.

Limit für Upstream-Nachrichten

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 den Akkuverbrauch durch schlechtes App-Verhalten zu vermeiden.

Nachrichtenlimit für Themen

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

Informationen zu den Senderaten von Nachrichten finden Sie unter Fanout-Drosselung .

Fanout-Drosselung

Nachrichten-Fanout ist der Vorgang des Sendens einer Nachricht an mehrere Geräte, z. B. wenn Sie Themen und Gruppen ansprechen oder den Benachrichtigungs-Composer verwenden, um Zielgruppen oder Benutzersegmente anzusprechen.

Nachrichten-Fanouts erfolgen nicht sofort, sodass gelegentlich mehrere Fanouts gleichzeitig ausgeführt werden. Wir begrenzen die Anzahl gleichzeitiger Nachrichten-Fanouts pro Projekt auf 1.000. Danach können wir weitere Fanout-Anfragen ablehnen oder das Fanout der Anfragen 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 resultiert aus der Gesamtbelastung des Systems. Beachten Sie, dass die verfügbare Fanout-Kapazität auf Projekte und nicht auf Fanout-Anfragen aufgeteilt wird. Wenn in Ihrem Projekt also zwei Fanouts ausgeführt werden, wird für jedes Fanout nur die Hälfte der verfügbaren Fanout-Rate angezeigt. Die empfohlene Methode zur Maximierung der Fanout-Geschwindigkeit besteht darin, jeweils nur einen aktiven Fanout zu betreiben.

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, manchmal aber auch 5229 und 5230.

Für ausgehende Verbindungen stellt FCM keine spezifischen IP-Adressen bereit, da sich unser IP-Bereich zu häufig ändert und Ihre Firewallregeln möglicherweise veraltet sind, was sich auf die Erfahrung Ihrer Benutzer auswirkt. Idealerweise sollten Sie die Ports 5228-5230 ohne IP-Einschränkungen auf die Whitelist setzen. Wenn Sie jedoch eine IP-Einschränkung benötigen , sollten Sie alle in goog.json aufgeführten IP-Adressen auf die Whitelist setzen . Diese umfangreiche Liste wird regelmäßig aktualisiert, und es wird empfohlen, Ihre Regeln monatlich zu aktualisieren. Probleme, die durch Firewall-IP-Beschränkungen verursacht werden, treten häufig zeitweise auf und sind schwer zu diagnostizieren.

Für eingehende Nachrichten zu öffnende Ports:

  • 5228
  • 5229
  • 5230
  • 443

Ports, um ausgehende Verbindungen zuzulassen:

Eine davon (Option 1 wird bevorzugt):

  1. Keine IP-Beschränkungen
  2. Alle IP-Adressen für Standarddomänen.

    Um eine aktuelle Liste dieser Adressen abzurufen, befolgen Sie die Anweisungen unter IP-Adressen für Standarddomänen .

Firewalls zur Netzwerkadressübersetzung und/oder Stateful Packet Inspection:

Wenn Ihr Netzwerk Network Address Translation (NAT) oder Stateful Packet Inspection (SPI) implementiert, implementieren Sie ein Timeout von 30 Minuten oder länger 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 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 Einzelgeräte- und Gerätegruppen-Messaging 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 dem Tab " Cloud Messaging" des Einstellungsbereichs 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 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 alten 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-, iOS- und Browserschlüssel werden von FCM abgelehnt.