Catch up on everthing we announced at this year's Firebase Summit. 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. In einer vertrauten Umgebung, wie Cloud - notification Funktionen oder die App - Server, verwenden Sie das Admin SDK oder die FCM - Server - Protokolle : Stellen Sie die notification Kann optionale Datennutzlast haben. Immer zusammenklappbar.

    Hier sehen Sie einige Beispiele von Anzeigebenachrichtigungen und Sendeanforderung Nutzlasten.

  2. Verwenden Sie die Benachrichtigung Komponist : Geben Sie den Nachrichtentext, Titel, usw., und senden. 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). In einer vertrauten Umgebung, wie Cloud - data Funktionen oder die App - Server, verwenden Sie das Admin SDK oder die FCM - Server - Protokolle : Stellen Sie die data nur Schlüssel.

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

Zum Testen oder für Marketing und Benutzer Wiedereingriff, können Sie Benachrichtigungsmeldungen mit der Firebase Konsole senden . Die Firebase - Konsole bietet Analytik-basierte A / B - Tests , um Ihnen zu verfeinern und Marketing - Botschaften verbessern.

Um programmatisch sandten Benachrichtigungsmeldungen des Admin - SDK oder die FCM - Protokolle verwenden, stellen Sie die notification Schlüssel mit dem erforderlichen vordefinierten Satz von Schlüssel-Wert - Optionen für den Benutzer sichtbaren Teil der Benachrichtigung. 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.

Zum Beispiel, hier ist eine JSON-formatierte Nachricht in dem gleichen IM App wie oben, wo die Informationen in dem gemeinsamen gekapselten data und die Client - Anwendung wird erwartet , um den Inhalt zu interpretieren:

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

Das obige Beispiel wird die Verwendung des obersten Ebene oder gemeinsamen data das von den Kunden auf allen Plattformen interpretiert wird, der die Nachricht empfangen. Auf jeder Plattform erhält 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 Datennachrichten mit einer Ende-zu-Ende-Verschlüsselung versehen. FCM bietet keine End-to-End-Lösung. Allerdings gibt es externe Lösungen zur Verfügung, wie Kapillar oder DTLS .

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. Im Benachrichtigungen Komponisten , verwenden Sie die Benutzerdefinierte Datenfelder in Erweiterte 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.

  • Wenn im Hintergrund, erhalten apps die Benachrichtigung Nutzlast in dem Infobereich, und nur die Daten Nutzlast handhaben, wenn der Benutzer auf der Benachrichtigung tippt.
  • Wenn im Vordergrund, erhält Ihre App eine Nachricht Objekt mit beiden verfügbaren Nutzlasten.

Hier ist eine JSON-formatierte Nachricht sowohl die enthält notification Schlüssel und 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

Das Firebase Admin SDK und das FCM v1 HTTP - Protokoll ermöglichen sowohl Ihre Nachrichtenanforderungen alle Felder in der zur Verfügung stehenden festlegen message Objekt. Das beinhaltet:

  • ein gemeinsamer Satz von Feldern von allen App - Instanzen , die die Nachricht erhalten , interpretiert werden.
  • plattformspezifische Sätze von Feldern, wie AndroidConfig und WebpushConfig , nur von diesem interpretiert Instanzen App auf der angegebenen Plattform ausgeführt wird .

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:

  • Targeting App - Instanzen auf allen Plattformen - Apple, 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
  • Sende plattformspezifische Felder zusätzlich zu den gemeinsamen Bereichen

Jedes Mal , wenn Sie Werte wollen auf bestimmte Plattformen nur senden, verwenden Sie keine gemeinsame Felder; plattformspezifische Felder verwenden. Um beispielsweise eine Benachrichtigung nur an Apple-Plattformen und das Web, aber nicht an Android zu senden, müssen Sie zwei separate Feldersätze verwenden, einen für Apple und einen für das Web.

Wenn Sie Nachrichten mit bestimmten Senden Lieferoptionen für die Verwendung plattformspezifische Felder sie einzustellen. 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 interpretieren kann etwas anders, zum Beispiel Time-to-live auf Android als Ablaufzeit in Sekunden eingestellt, während auf Apple es als Ablaufdatum festgelegt ist.

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 von APNs (Apple-Plattformen) auf eine niedrige Einstellung gesetzt wird
  • setzt die entsprechenden Tasten , um das Ergebnis eines Benutzers tippen Sie auf die Benachrichtigung über Android und Apple definieren - click_action und category sind.
{
  "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"
       }
     }
   }
 }

Siehe die HTTP v1 Referenzdokumentation für die vollständigen Einzelheiten über die verfügbaren Tasten in plattformspezifische Blöcken im Nachrichtentext. Weitere Informationen über Sendeaufträge erstellen , die den Nachrichtentext enthalten, finden Sie Build - Sendeaufträge .

Lieferoptionen

FCM bietet einen bestimmten Satz von Zustellungsoptionen für Nachrichten, die an Android-Geräte gesendet werden, und ermöglicht ähnliche Optionen auf Apple-Plattformen und im Web. Zum Beispiel : „zusammenlegbare“ wird Meldung Verhalten auf Android über FCM unterstützten collapse_key , auf Apple ü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-kollabierbaren Nachricht zeigt , 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.

Zusammenlegbarer Nachricht ist eine Nachricht , die von einer neuen Nachricht ersetzt werden können , wenn es noch an das Gerät geliefert werden.

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 als zusammenklappbar auf Android zu markieren, umfassen die collapse_key Parameter in der Payload der Message. 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 pro Registrierungstoken durch den FCM 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 Apple
  • Topic auf Web
  • collapse_key in Legacy - Protokolle (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 Datennachricht . 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. B. Benachrichtigungen über neue E-Mails, die Synchronisierung Ihrer Benutzeroberfläche oder die Synchronisierung von App-Daten im Hintergrund, die normale Zustellungspriorität.

    Wenn eine normale Prioritätsnachricht auf Android erhalten, die eine Hintergrunddaten - Synchronisierung für Ihre Anwendung anfordert, können Sie eine Aufgabe mit planen Work es zu handhaben, wenn das Netzwerk verfügbar ist.

  • Hohe Priorität. FCM versucht, Nachrichten mit hoher Priorität sofort zu übermitteln, sodass FCM 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 eingeführt App Standby - Eimer , die die Anzahl der FCM - Meldungen mit hoher Priorität zu begrenzen können Sie Ihre App senden , die in dem Benutzer mit der App oder sehen eine Benachrichtigung zur Folge haben. 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 die Synchronisierung für weitere in-App - Inhalte auf Android benötigen, können Sie eine Aufgabe mit planen Work , dass im Hintergrund zu behandeln.

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. Beachten Sie, dass ein time_to_live Wert von 0 bedeutet Nachrichten , die nicht sofort verworfen werden , geliefert werden können. 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, stellen Sie sicher , dass Sie jeden Absender Absender - ID . 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 nicht mehrere Sender - IDs auf ein Token - Anfrage hinzufügen zu tun, 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 das ist , wo die collapse_key Flagge eine Rolle spielt: wenn es bereits eine Nachricht mit demselben Minimierungsschlüssel (und Registrierungstoken) gespeichert und wartet auf Lieferung, die alte Nachricht verworfen und die neue Nachricht an seine Stelle tritt (das heißt, die alten 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 , die time_to_live Flag gesetzt ist.

So erhalten Sie mehr Einblick in die Zustellung einer Nachricht:

    Um einen besseren Einblick in die Übermittlung von Nachrichten auf Android oder Apple - Plattformen zu erhalten, finden Sie in der FCM - Reporting - Dashboard , das die Anzahl der gesendeten Nachrichten und geöffnet auf Apple und Android - Geräte erfasst, zusammen mit den Daten für „Eindrücke“ (Mitteilungen von Nutzern gesehen) für Android 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 Datennachricht verbindet Sie an ihn gesendet, erhält Ihr Kunde der 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. Zukunft versucht , eine Nachricht an das Gerät führt zu einem senden 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 beschränken Upstream - Nachrichten bei 1.500.000 / Minute pro Projekt Upstream - Zielserver zu überlasten.

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.

Für Nachrichtensenderaten siehe Fanout Throttling .

Fanout-Drosselung

Nachricht Fanout ist der Prozess eine Nachricht an mehrere Geräte zu senden, wenn Sie beispielsweise gezielt Themen und Gruppen, oder wenn Sie den Benachrichtigungen Komponisten zu Zielgruppen oder Benutzersegmenten.

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 ergibt sich 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 jedoch 443, 5229 und 5230.

Für Geräte, die mit Ihrem Netzwerk verbunden sind, stellt FCM keine spezifischen IPs 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 und 443 ohne IP-Einschränkungen in die Zulassungsliste aufnehmen. Allerdings, wenn Sie eine IP - Einschränkung haben, sollten Sie alle IP - Adressen aufgeführt in AllowList goog.json . 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.

Wir bieten eine Reihe von Domainnamen an, die anstelle von IP-Adressen zugelassen 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 Firewallregel kann auf Ihrem Firewallgerät möglicherweise nicht funktionieren.

Zu öffnende Häfen:

  • 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.clients.google.com
  • device-provisioning.googleapis.com

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 in dem verfügbaren Firebase Konsole Einstellungen Bereich.
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 Zahlenwert erstellt , wenn Sie Ihr Projekt Firebase, in der erstellen Cloud Messaging Registerkarte der Konsole Einstellungen Firebase Bereich. 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. So erstellen und drehen Zugriffstoken, folgen Sie den beschriebenen Schritten in Autorisieren Senden Anfragen .
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 in der Ansicht Cloud Messaging - Registerkarte des Firebase Konsole Einstellungen Bereich.

Wichtig: Sie nicht den Server - Schlüssel überall in Ihrem Client - Code. Stellen Sie außerdem sicher, dass Sie nur Serverschlüssel verwenden, um Ihren App-Server zu autorisieren. Android-, Apple-Plattform- und Browserschlüssel werden von FCM abgelehnt.