Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Informationen zu 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 zu verstehen, was Sie damit tun können.

Nachrichtentypen

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

  • Benachrichtigungsnachrichten, die manchmal als "Nachrichten anzeigen" bezeichnet werden. Diese werden vom FCM SDK automatisch verarbeitet.
  • Datennachrichten, die von der Client-App verarbeitet werden.

Benachrichtigungsnachrichten enthalten einen vordefinierten Satz von vom 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 KB, außer beim Senden von Nachrichten über die Firebase-Konsole, wodurch eine Beschränkung auf 1024 Zeichen erzwungen wird.

Szenario verwenden Wie senden
Benachrichtigungsnachricht FCM zeigt die Nachricht automatisch Endbenutzergeräten im Namen der Client-App an. Benachrichtigungsnachrichten verfügen über einen vordefinierten Satz von vom Benutzer sichtbaren Schlüsseln und eine optionale Datennutzlast von benutzerdefinierten Schlüssel-Wert-Paaren.
  1. Verwenden Sie in einer vertrauenswürdigen Umgebung wie Cloud-Funktionen oder Ihrem App-Server das Admin-SDK oder die FCM-Serverprotokolle : Legen Sie den notification . Kann optionale Datennutzdaten enthalten. Immer zusammenklappbar.
  2. Verwenden Sie den Benachrichtigungs-Composer : Geben Sie den Nachrichtentext, den Titel usw. ein und senden Sie ihn. Fügen Sie optionale Datennutzdaten 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-Funktionen oder Ihrem App-Server das Admin-SDK oder die FCM-Serverprotokolle : Legen Sie nur den data .

Verwenden Sie Benachrichtigungsnachrichten, wenn FCM die Anzeige einer Benachrichtigung im Namen Ihrer Client-App übernehmen soll. Verwenden Sie Datennachrichten, wenn Sie die Nachrichten in Ihrer Client-App verarbeiten möchten.

FCM kann eine Benachrichtigungsnachricht mit einer optionalen Datennutzlast senden. In solchen Fällen übernimmt FCM die Anzeige der Benachrichtigungsnutzdaten und die Client-App die Datennutzdaten.

Benachrichtigungsnachrichten

Zum Testen oder für Marketing und Wiedereingliederung von Benutzern können Sie Benachrichtigungsnachrichten über die Firebase-Konsole senden . Die Firebase-Konsole bietet analytikbasierte A / B-Tests, mit denen Sie Marketingbotschaften verfeinern und verbessern können.

Um programmgesteuert Benachrichtigungsnachrichten mit dem Admin SDK oder den FCM-Protokollen zu senden, legen Sie den notification mit den erforderlichen vordefinierten Schlüsselwertoptionen für den vom 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 "Great Match!" Erwarten. auf dem Gerät:

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

Benachrichtigungsnachrichten werden an die Benachrichtigungsleiste gesendet, wenn sich die App im Hintergrund befindet. Bei Apps im Vordergrund werden Nachrichten von einer Rückruffunktion verarbeitet.

In der Referenzdokumentation finden Sie eine vollständige Liste der vordefinierten Schlüssel, die zum Erstellen von Benachrichtigungsnachrichten 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, in der 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 Datennutzdaten in einer Rückruffunktion. ::

Benachrichtigungsnachrichten mit optionaler Datennutzlast

Sowohl programmgesteuert als auch über die Firebase-Konsole können Sie Benachrichtigungsnachrichten senden, die eine optionale Nutzlast von benutzerdefinierten Schlüssel-Wert-Paaren enthalten. Verwenden Sie im Notifications Composer die Felder Benutzerdefinierte Daten in den erweiterten Optionen .

Das Verhalten der App beim Empfang von Nachrichten, die sowohl Benachrichtigungs- als auch Datennutzdaten 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 Benachrichtigungsnutzdaten in der Benachrichtigungsleiste und verarbeiten die Datennutzdaten nur, wenn der Benutzer auf die Benachrichtigung tippt.
  • Im Vordergrund empfängt Ihre App ein Nachrichtenobjekt mit beiden verfügbaren Nutzdaten.

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"
    }
  }
}

Plattformübergreifendes Anpassen einer Nachricht

Mit dem Firebase Admin SDK und dem HTTP-Protokoll FCM v1 können Ihre Nachrichtenanforderungen alle im message verfügbaren Felder festlegen. Das beinhaltet:

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

Plattformspezifische Blöcke bieten Ihnen die Flexibilität, Nachrichten für verschiedene Plattformen anzupassen, um sicherzustellen, dass sie beim Empfang korrekt behandelt werden. Das FCM-Backend berücksichtigt alle angegebenen Parameter und passt die Nachricht für jede Plattform an.

Wann werden allgemeine Felder verwendet?

Verwenden Sie allgemeine Felder, wenn Sie:

  • Targeting von App-Instanzen auf allen Plattformen - iOS, Android und Web
  • Senden von Nachrichten an Themen

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

Wann werden plattformspezifische Felder verwendet?

Verwenden Sie plattformspezifische Felder, wenn Sie:

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

Verwenden Sie keine allgemeinen Felder, wenn Sie Werte nur an bestimmte Plattformen senden möchten. Verwenden Sie plattformspezifische Felder. Um beispielsweise eine Benachrichtigung nur an iOS und das Web, nicht jedoch an Android zu senden, müssen Sie zwei separate Feldsätze verwenden, eines für iOS und eines für das Web.

Wenn Sie Nachrichten mit bestimmten Zustelloptionen senden, verwenden Sie plattformspezifische Felder, um sie festzulegen. Sie können bei Bedarf unterschiedliche Werte pro Plattform angeben. Selbst wenn Sie plattformübergreifend im Wesentlichen den gleichen 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 iOS es als Ablaufdatum festgelegt ist.

Beispiel: Benachrichtigungsnachricht mit plattformspezifischen Zustelloptionen

Die folgende v1-Sendeanforderung sendet einen gemeinsamen Benachrichtigungstitel und -inhalt an alle Plattformen, sendet jedoch auch einige plattformspezifische Überschreibungen. Insbesondere die Anfrage:

  • Legt eine lange Lebensdauer für Android- und Webplattformen fest, während die Nachrichtenpriorität für APNs (iOS) auf eine niedrige Einstellung festgelegt wird
  • Legt die entsprechenden Schlüssel fest, um das Ergebnis eines Benutzertipps auf die Benachrichtigung unter 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"
       }
     }
   }
 }

Ausführliche Informationen zu den Schlüsseln, die in plattformspezifischen Blöcken im Nachrichtentext verfügbar sind, finden Sie in der Referenzdokumentation zu HTTP v1 . Weitere Informationen zum Erstellen von Sendeanforderungen , die den Nachrichtentext enthalten, finden Sie unter Erstellen von Sendeanforderungen .

Lieferoptionen

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

Nicht zusammenlegbare und zusammenlegbare Nachrichten

Eine nicht zusammenklappbare Nachricht zeigt an, 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 inhaltsfreien "Ping" an die mobile App, um den Server zum Abrufen von Daten zu kontaktieren.

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 übermitteln, da jede Nachricht einen anderen Inhalt hat.

Für Android gibt es ein Limit von 100 Nachrichten, die ohne Zusammenbruch gespeichert werden können. Wenn das Limit erreicht ist, werden alle gespeicherten Nachrichten verworfen. Wenn das Gerät wieder online ist, erhält es eine spezielle Meldung, dass das Limit erreicht wurde. Die App kann dann ordnungsgemäß mit der Situation umgehen, 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 der neuesten Punktzahl 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. Mit FCM können maximal vier verschiedene Reduzierungsschlüssel pro Android-Gerät gleichzeitig vom App-Server verwendet werden. Mit anderen Worten, der FCM-Server kann gleichzeitig vier verschiedene reduzierbare Nachrichten pro Gerät mit jeweils einem anderen Kollapsschlüssel speichern. Wenn Sie diese Anzahl überschreiten, behält FCM nur vier Reduzierungsschlüssel bei, ohne dass garantiert wird, welche beibehalten werden.

Welches soll ich verwenden?

Zusammenklappbare Nachrichten sind vom Standpunkt der Leistung aus eine bessere Wahl, vorausgesetzt, Ihre App muss keine nicht zusammenklappbaren Nachrichten verwenden. Wenn Sie jedoch reduzierbare Nachrichten verwenden, denken Sie daran, dass FCM zu einem bestimmten Zeitpunkt nur maximal vier verschiedene Reduzierungsschlüssel vom FCM-Verbindungsserver pro Registrierungstoken verwenden kann. Sie dürfen diese Anzahl nicht überschreiten, da dies zu unvorhersehbaren Folgen führen kann.

Szenario verwenden Wie senden
Nicht zusammenlegbar 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. Beispiel: Nachrichten zum Initiieren einer Datensynchronisierung vom Server oder veraltete Benachrichtigungsnachrichten. Stellen Sie den entsprechenden Parameter in Ihrer Nachrichtenanforderung ein:
  • collapseKey auf Android
  • apns-collapse-id unter iOS
  • Topic im Web
  • collapse_key in älteren Protokollen (alle Plattformen)

Festlegen der Priorität einer Nachricht

Sie haben zwei Möglichkeiten, Downstream-Nachrichten unter Android eine Zustellungspriorität zuzuweisen: normale und hohe Priorität. Die Zustellung von Nachrichten mit normaler und hoher Priorität funktioniert folgendermaßen:

  • 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 in Doze befindet, kann die Lieferung verzögert werden, um die Batterie zu schonen. Wählen Sie für weniger zeitkritische Nachrichten, z. B. Benachrichtigungen über neue E-Mails, Synchronisierung Ihrer Benutzeroberfläche oder Synchronisierung von App-Daten im Hintergrund, die normale Zustellungspriorität.

    Wenn Sie unter 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 sie 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 aktivieren 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, ohne dass der Benutzer Ihre App verwendet oder eine Benachrichtigung anzeigt. Wenn als Antwort auf eine Nachricht mit hoher Priorität eine Benachrichtigung in einer für den Benutzer sichtbaren Weise angezeigt wird, wird Ihr App-Standby-Bucket-Kontingent von dieser Nachricht nicht verbraucht.

    Vermeiden Sie es, eine Verbindung zu Ihren Servern herzustellen, bevor Sie eine Benachrichtigung anzeigen, da sich ein kleiner Teil der mobilen Android-Bevölkerung in Netzwerken mit hoher Latenz befindet. Ein Rückruf an den Server vor Ablauf der zulässigen Verarbeitungszeit kann für Benutzer in Netzwerken mit hoher Latenz ein Risiko darstellen. 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 unter Android synchronisieren müssen, können Sie mit WorkManager eine Aufgabe planen , um diese im Hintergrund zu erledigen.

Hier ist ein Beispiel für eine Nachricht mit normaler Priorität, die über das FCM HTTP v1-Protokoll gesendet wird, um einen Zeitschriftenabonnenten darüber zu informieren, dass neue Inhalte zum Herunterladen verfügbar sind:

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

Weitere plattformspezifische Details zum Festlegen der Nachrichtenpriorität:

Festlegen der Lebensdauer einer Nachricht

FCM liefert Nachrichten normalerweise sofort nach dem Senden. Dies ist jedoch möglicherweise nicht immer möglich. Wenn die Plattform beispielsweise Android ist, kann das Gerät ausgeschaltet, offline oder auf andere Weise nicht verfügbar sein. Oder FCM verzögert absichtlich Nachrichten, 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, für die eine verspätete Nachricht möglicherweise genauso gut nie zugestellt wird. Wenn es sich bei der Nachricht beispielsweise um einen eingehenden Anruf oder eine Video-Chat-Benachrichtigung handelt, ist sie nur für einen kurzen Zeitraum von Bedeutung, bevor der Anruf beendet wird. Wenn es sich bei der Nachricht um eine Einladung zu einem Ereignis handelt, ist sie nutzlos, wenn sie nach Beendigung des Ereignisses empfangen wird.

Unter Android und Web / JavaScript können Sie die maximale Lebensdauer einer Nachricht angeben. Der Wert muss eine Dauer von 0 bis 2.419.200 Sekunden (28 Tage) 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 einen Zeitraum von maximal vier Wochen.

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

  • Video-Chat eingehende Anrufe
  • Auslaufende Einladungsereignisse
  • Kalenderereignisse

Ein weiterer Vorteil der Angabe der Lebensdauer einer Nachricht besteht darin, dass FCM Nachrichten niemals mit einem Wert für die Lebensdauer von 0 Sekunden drosselt. Mit anderen Worten, FCM garantiert den besten Aufwand 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 für das Senden von Benachrichtigungsnachrichten.

Hier ist ein Beispiel für eine Anforderung, 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

Mit FCM können mehrere Parteien Nachrichten an dieselbe Client-App 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 enthält möglicherweise eine URL, damit die Client-App den Artikel herunterladen kann. Anstatt alle Sendeaktivitäten an einem Ort zu zentralisieren, können Sie mit FCM jedem dieser Mitwirkenden seine eigenen Nachrichten senden lassen.

Stellen Sie zum Aktivieren dieser Funktion sicher, dass Sie die Absender- ID jedes Absenders haben. Wenn Sie eine Registrierung anfordern, ruft die Client-App das Token mehrmals ab, jedes Mal mit einer anderen Absender-ID im Zielgruppenfeld. Dabei wird die Token-Abrufmethode für die angegebene Plattform verwendet:

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

Teilen Sie schließlich das Registrierungstoken mit den entsprechenden Absendern, und diese können Nachrichten mit ihren eigenen Authentifizierungsschlüsseln an die Client-App senden.

Beachten Sie, dass die Anzahl der Absender auf 100 begrenzt ist.

Lebensdauer einer Nachricht

Wenn ein App-Server eine Nachricht an FCM sendet und eine Nachrichten-ID zurückerhält, bedeutet dies nicht, dass die Nachricht bereits an das Gerät übermittelt wurde. Es bedeutet vielmehr, dass es zur Lieferung angenommen wurde. Was mit der Nachricht passiert, nachdem sie akzeptiert wurde, hängt von vielen Faktoren ab.

Im besten Fall, wenn das Gerät mit FCM verbunden ist, der Bildschirm eingeschaltet ist und keine Drosselungsbeschränkungen bestehen, wird die Nachricht sofort zugestellt.

Wenn das Gerät angeschlossen ist, sich jedoch in Doze befindet, wird von FCM eine Nachricht mit niedriger Priorität gespeichert, bis das Gerät nicht mehr in Doze ist. Und hier spielt das collapse_key Flag eine Rolle: Wenn bereits eine Nachricht mit demselben Collapse-Schlüssel (und demselben Registrierungstoken) gespeichert ist und auf die Zustellung wartet, wird die alte Nachricht verworfen und die neue Nachricht tritt an ihre Stelle (dh die alte Nachricht wird durch die neue reduziert). Wenn der Reduzierungsschlü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 ist (wiederum unter Beachtung der Kollapsschlüsselregeln). Wenn eine Verbindung hergestellt wird, ü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 Nachricht möglicherweise ab und wird aus dem FCM-Speicher verworfen. Das Standardzeitlimit beträgt vier Wochen, sofern das Flag time_to_live nicht time_to_live ist.

So erhalten Sie mehr Einblick in die Zustellung einer Nachricht:

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

Wenn bei Android-Geräten mit aktiviertem Direktkanal-Messaging das Gerät länger als einen Monat keine Verbindung zu FCM hergestellt hat, akzeptiert FCM die Nachricht weiterhin, verwirft sie jedoch sofort. Wenn das Gerät innerhalb von vier Wochen nach der letzten an ihn gesendeten Datennachricht eine Verbindung herstellt , erhält Ihr Client den Rückruf onDeletedMessages () . Die App kann dann ordnungsgemäß mit der Situation umgehen, indem sie normalerweise eine vollständige Synchronisierung vom App-Server anfordert.

Wenn FCM 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. Die Zustellung 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 Service für alle Absender bietet.

Drosselbare Nachrichtendrosselung

Wie oben beschrieben, sind reduzierbare 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 wiederholt, verzögern wir (drosseln) Nachrichten, um die Auswirkungen auf den Akku eines Benutzers zu verringern.

Wenn Sie beispielsweise eine große Anzahl neuer E-Mail-Synchronisierungsanforderungen an ein einzelnes Gerät senden, verzögern wir möglicherweise die nächste E-Mail-Synchronisierungsanforderung um einige Minuten, damit das Gerät mit einer niedrigeren Durchschnittsrate synchronisieren kann. Diese Drosselung erfolgt streng, um die Auswirkungen des Benutzers auf die Batterie 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 reduzierbare Nachrichten auf einen Burst von 20 Nachrichten pro App und Gerät, wobei alle 3 Minuten 1 Nachricht nachgefüllt 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 kein Problem für die Nachrichtenübermittlung sein, ist jedoch wichtig, um die Stabilität unseres Systems sicherzustellen.

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 Verkehrsstöße ermöglichen, z. B. wenn Benutzer schnell über den Chat interagieren. Diese Grenze verhindert, dass Fehler beim Senden der Logik versehentlich den Akku eines Geräts entladen.

Upstream-Nachrichtenlimit

Wir begrenzen Upstream-Nachrichten auf 1.500.000 / Minute pro Projekt, um eine Überlastung der Upstream-Zielserver zu vermeiden.

Wir begrenzen Upstream-Nachrichten pro Gerät auf 1.000 / Minute, um den Akku vor schlechtem App-Verhalten zu schützen.

Themen-Nachrichtenlimit

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

Informationen zum Senden von Nachrichten finden Sie unter Fanout-Drosselung .

Fanout-Drosselung

Beim Nachrichten-Fanout wird eine Nachricht an mehrere Geräte gesendet, z. B. wenn Sie Themen und Gruppen als Ziel festlegen oder wenn Sie den Benachrichtigungs-Composer verwenden, um Zielgruppen oder Benutzersegmente anzusprechen.

Das Nachrichten-Fanout erfolgt nicht sofort. Daher werden gelegentlich mehrere Fanouts gleichzeitig ausgeführt. Wir begrenzen die Anzahl der gleichzeitigen Nachrichten-Fanouts pro Projekt auf 1.000. Danach können wir zusätzliche Fanout-Anfragen ablehnen oder das Fanout der Anfragen verschieben, bis einige der bereits laufenden Fanouts abgeschlossen sind.

Die tatsächlich erreichbare Fanout-Rate wird durch die Anzahl der Projekte beeinflusst, die gleichzeitig Fanouts anfordern. Eine Fanout-Rate von 10.000 QPS für ein einzelnes Projekt ist keine Seltenheit, aber diese Anzahl ist keine Garantie und ergibt sich aus der Gesamtlast des Systems. Es ist wichtig zu beachten, dass die verfügbare Fanout-Kapazität auf Projekte und nicht auf Fanout-Anfragen aufgeteilt wird. Wenn in Ihrem Projekt 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 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, mit der der Datenverkehr zum oder vom Internet eingeschränkt werden kann, 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 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 Firewall-Regeln möglicherweise nicht mehr aktuell sind und sich auf die Benutzererfahrung auswirken. Im Idealfall werden Sie die Ports 5228-5230 ohne IP-Einschränkungen auf die Whitelist setzen. Wenn Sie jedoch eine IP-Einschränkung haben müssen, sollten Sie alle IP-Adressen in den IPv4- und IPv6-Blöcken auflisten, die im Google- Lieferavis von 15169 aufgeführt sind . Dies ist eine große Liste, und Sie sollten planen, Ihre Regeln monatlich zu aktualisieren. Probleme, die durch IP-Einschränkungen der Firewall verursacht werden, treten häufig auf und sind schwer zu diagnostizieren.

Für eingehende Nachrichten zu öffnende Ports:

  • 5228
  • 5229
  • 5230
  • 443

Ports für ausgehende Verbindungen:

Eine davon (Option 1 wird bevorzugt):

  1. Keine IP-Einschränkungen
  2. Alle IP-Adressen, die in den IP-Blöcken enthalten sind, die im Lieferavis von Google von 15169 aufgeführt sind . Vergessen Sie nicht, dies mindestens einmal im Monat zu aktualisieren.

Firewalls für die Übersetzung von Netzwerkadressen und / oder Stateful Packet Inspection:

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

Referenzen

Abhängig davon, 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 Anforderungen an den HTTP-Endpunkt FCM v1 verwendet wird. Dieser Wert ist im Bereich Einstellungen der Firebase-Konsole verfügbar.
Registrierungstoken

Eine eindeutige Token-Zeichenfolge, die jede Client-App-Instanz identifiziert. Das Registrierungstoken wird für Nachrichten an einzelne Geräte und Gerätegruppen benötigt. Beachten Sie, dass Registrierungstoken geheim gehalten werden müssen.

Absenderidentität Ein eindeutiger numerischer Wert, der beim Erstellen Ihres Firebase-Projekts erstellt wird und auf der Registerkarte Cloud Messaging im Bereich Einstellungen der Firebase-Konsole verfügbar ist. Die Absender-ID wird verwendet, um jeden Absender zu identifizieren, der Nachrichten an die Client-App senden kann.
Zugangstoken Ein kurzlebiges OAuth 2.0-Token, das Anforderungen an die HTTP v1-API autorisiert. Dieses Token ist einem Dienstkonto zugeordnet, das zu Ihrem Firebase-Projekt gehört. Befolgen Sie zum Erstellen und Drehen von Zugriffstoken die unter Autorisieren von Sendeanforderungen beschriebenen Schritte.
Serverschlüssel (für ältere Protokolle)

Ein Serverschlüssel, der Ihren App-Server für den Zugriff auf Google-Dienste autorisiert, einschließlich des Sendens von Nachrichten über die älteren Firebase Cloud Messaging-Protokolle. 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.