Firebase Cloud Messaging (FCM) oferuje szeroki zakres opcji i możliwości przesyłania wiadomości. Informacje na tej stronie mają na celu pomóc Ci zrozumieć różne rodzaje komunikatów FCM i dowiedzieć się, co możesz z nimi zrobić.
Typy wiadomości
Dzięki FCM możesz wysyłać klientom dwa rodzaje wiadomości:
- Komunikaty powiadomień, czasami określane jako „komunikaty wyświetlane”. Są one obsługiwane automatycznie przez FCM SDK.
- Komunikaty danych, które są obsługiwane przez aplikację kliencką.
Komunikaty powiadomień zawierają predefiniowany zestaw kluczy widocznych dla użytkownika. Z kolei komunikaty danych zawierają tylko zdefiniowane przez użytkownika niestandardowe pary klucz-wartość. Komunikaty powiadomień mogą zawierać opcjonalny ładunek danych. Maksymalny ładunek dla obu typów wiadomości to 4000 bajtów, z wyjątkiem wysyłania wiadomości z konsoli Firebase, która wymusza limit 1024 znaków.
| Użyj scenariusza | Jak wysłać | |
|---|---|---|
| Wiadomość powiadomienia | FCM SDK wyświetla komunikat na urządzeniach użytkowników końcowych w imieniu aplikacji klienckiej, gdy jest ona uruchomiona w tle. W przeciwnym razie, jeśli aplikacja działa na pierwszym planie po odebraniu powiadomienia, kod aplikacji określa zachowanie. Wiadomości powiadomień mają wstępnie zdefiniowany zestaw kluczy widocznych dla użytkownika i opcjonalny ładunek danych w postaci niestandardowych par klucz-wartość. |
|
| Wiadomość danych | Aplikacja kliencka jest odpowiedzialna za przetwarzanie komunikatów danych. Komunikaty danych mają tylko niestandardowe pary klucz-wartość bez zastrzeżonych nazw kluczy (patrz poniżej). | W zaufanym środowisku, takim jak Cloud Functions lub serwer aplikacji, użyj pakietu Admin SDK lub protokołów serwera FCM : ustaw tylko klucz data . |
Użyj komunikatów powiadomień, jeśli chcesz, aby zestaw SDK FCM obsługiwał automatyczne wyświetlanie powiadomienia, gdy aplikacja działa w tle. Użyj komunikatów danych, jeśli chcesz przetworzyć komunikaty przy użyciu własnego kodu aplikacji klienckiej.
FCM może wysłać powiadomienie zawierające opcjonalny ładunek danych. W takich przypadkach FCM obsługuje wyświetlanie ładunku powiadomienia, a aplikacja kliencka obsługuje ładunek danych.
Komunikaty powiadomień
W celu testowania lub marketingu i ponownego zaangażowania użytkowników możesz wysyłać powiadomienia za pomocą konsoli Firebase . Konsola Firebase zapewnia oparte na analizie analizy testy A/B , które pomagają udoskonalić i udoskonalić komunikaty marketingowe.
Aby programowo wysyłać powiadomienia za pomocą pakietu Admin SDK lub protokołów FCM, ustaw klucz notification z niezbędnym wstępnie zdefiniowanym zestawem opcji klucz-wartość dla widocznej dla użytkownika części powiadomienia. Oto na przykład powiadomienie w formacie JSON w aplikacji IM. Użytkownik może spodziewać się wiadomości zatytułowanej „Portugalia kontra Dania” z tekstem „świetny mecz!” na urządzeniu:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}Powiadomienia są dostarczane do paska powiadomień, gdy aplikacja działa w tle. W przypadku aplikacji na pierwszym planie wiadomości są obsługiwane przez funkcję wywołania zwrotnego.
Zapoznaj się z dokumentacją referencyjną, aby zapoznać się z pełną listą predefiniowanych kluczy dostępnych dla komunikatów powiadomień o budynkach:
- Obiekt powiadomienia protokołu HTTP v1
- Ładunek powiadomień starszego protokołu HTTP
- Ładunek powiadomienia protokołu XMPP
Komunikaty danych
Ustaw odpowiedni klucz za pomocą niestandardowych par klucz-wartość, aby wysłać ładunek danych do aplikacji klienckiej.
Oto na przykład wiadomość w formacie JSON w tej samej aplikacji IM, co powyżej, gdzie informacje są zawarte we wspólnym kluczu data , a aplikacja kliencka ma interpretować treść:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
} Powyższy przykład pokazuje użycie najwyższego poziomu, czyli wspólnego pola data , które jest interpretowane przez klientów na wszystkich platformach otrzymujących wiadomość. Na każdej platformie aplikacja kliencka odbiera ładunek danych w funkcji wywołania zwrotnego.
Szyfrowanie wiadomości danych
Warstwa transportowa systemu Android (zobacz Architektura FCM ) wykorzystuje szyfrowanie punkt-punkt. W zależności od potrzeb możesz zdecydować się na dodanie kompleksowego szyfrowania do wiadomości z danymi. FCM nie zapewnia kompleksowych rozwiązań. Dostępne są jednak rozwiązania zewnętrzne, takie jak Capillary lub DTLS .
Komunikaty powiadomień z opcjonalnym ładunkiem danych
Zarówno programowo, jak i za pośrednictwem konsoli Firebase możesz wysyłać powiadomienia zawierające opcjonalny ładunek niestandardowych par klucz-wartość. W kompozytorze powiadomień użyj niestandardowych pól danych w opcjach zaawansowanych .
Zachowanie aplikacji podczas odbierania wiadomości, które zawierają zarówno powiadomienia, jak i ładunki danych, zależy od tego, czy aplikacja działa w tle, czy na pierwszym planie — zasadniczo od tego, czy jest aktywna w momencie odbioru.
- W tle aplikacje otrzymują ładunek powiadomienia na pasku powiadomień i obsługują ładunek danych tylko wtedy, gdy użytkownik dotknie powiadomienia.
- Na pierwszym planie aplikacja otrzymuje obiekt wiadomości z dostępnymi obydwoma ładunkami.
Oto wiadomość w formacie JSON zawierająca zarówno klucz notification , jak i klucz data :
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}Dostosowywanie wiadomości na różnych platformach
Pakiet Firebase Admin SDK i protokół HTTP FCM v1 umożliwiają żądaniom wiadomości ustawianie wszystkich pól dostępnych w obiekcie message . To zawiera:
- wspólny zestaw pól do interpretacji przez wszystkie instancje aplikacji, które odbierają komunikat.
- zestawy pól specyficzne dla platformy, takie jak
AndroidConfigiWebpushConfig, interpretowane tylko przez wystąpienia aplikacji działające na określonej platformie.
Blokady specyficzne dla platformy zapewniają elastyczność dostosowywania wiadomości do różnych platform, aby zapewnić ich prawidłową obsługę po odebraniu. Backend FCM weźmie pod uwagę wszystkie określone parametry i dostosuje komunikat do każdej platformy.
Kiedy używać wspólnych pól
Używaj wspólnych pól, gdy:
- Kierowanie na wystąpienia aplikacji na wszystkich platformach — Apple, Android i w internecie
- Wysyłanie wiadomości do tematów
Wszystkie instancje aplikacji, niezależnie od platformy, mogą interpretować te wspólne pola:
Kiedy używać pól specyficznych dla platformy
Użyj pól specyficznych dla platformy, jeśli chcesz:
- Wysyłaj pola tylko do określonych platform
- Wysyłaj pola specyficzne dla platformy oprócz wspólnych pól
Gdy chcesz wysłać wartości tylko do określonych platform, nie używaj wspólnych pól; użyj pól specyficznych dla platformy. Na przykład, aby wysłać powiadomienie tylko do platform i sieci Apple, ale nie do Androida, musisz użyć dwóch oddzielnych zestawów pól, jednego dla Apple i jednego dla Internetu.
Gdy wysyłasz wiadomości z określonymi opcjami dostarczania , użyj pól specyficznych dla platformy, aby je ustawić. Jeśli chcesz, możesz określić różne wartości dla każdej platformy. Jednak nawet jeśli chcesz ustawić zasadniczo tę samą wartość na różnych platformach, musisz użyć pól specyficznych dla platformy. Wynika to z faktu, że każda platforma może nieco inaczej interpretować tę wartość — na przykład czas życia jest ustawiany w systemie Android jako czas wygaśnięcia w sekundach, podczas gdy w systemie Apple jest ustawiany jako data wygaśnięcia.
Przykład: powiadomienie z opcjami dostarczania specyficznymi dla platformy
Następujące żądanie wysłania w wersji 1 wysyła wspólny tytuł i treść powiadomienia do wszystkich platform, ale także wysyła pewne zastąpienia specyficzne dla platformy. W szczególności prośba:
- ustawia długi czas życia dla platform Android i Web, jednocześnie ustawiając niski priorytet wiadomości APN (platformy Apple)
- ustawia odpowiednie klucze, aby zdefiniować wynik dotknięcia powiadomienia przez użytkownika na Androidzie i Apple — odpowiednio
click_actionicategory.
{
"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"
}
}
}
}Zapoznaj się z dokumentacją referencyjną HTTP v1, aby uzyskać szczegółowe informacje na temat kluczy dostępnych w blokach specyficznych dla platformy w treści wiadomości. Aby uzyskać więcej informacji na temat tworzenia żądań wysłania zawierających treść wiadomości, zobacz Tworzenie żądań wysłania .
Opcje dostawy
FCM zapewnia określony zestaw opcji dostarczania wiadomości wysyłanych na urządzenia z systemem Android i pozwala na podobne opcje na platformach Apple i w Internecie. Na przykład „zwijane” zachowanie wiadomości jest obsługiwane w systemie Android za pomocą collapse_key FCM , w Apple za pośrednictwem apns-collapse-id , a w JavaScript/Web za pośrednictwem Topic . Aby uzyskać szczegółowe informacje, zobacz opisy w tej sekcji i powiązaną dokumentację referencyjną.
Wiadomości nieskładalne i składane
Niezwijalna wiadomość oznacza, że każda pojedyncza wiadomość jest dostarczana do urządzenia. Wiadomość, której nie można zwijać, zawiera przydatną treść, w przeciwieństwie do wiadomości zwijanej, takiej jak „ping” bez treści do aplikacji mobilnej w celu skontaktowania się z serwerem w celu pobrania danych.
Niektóre typowe przypadki użycia wiadomości, których nie można zwijać, to wiadomości na czacie lub wiadomości krytyczne. Na przykład w aplikacji do obsługi komunikatorów chcesz dostarczyć każdą wiadomość, ponieważ każda wiadomość ma inną treść.
W systemie Android istnieje limit 100 wiadomości, które można przechowywać bez zwijania. Jeśli limit zostanie osiągnięty, wszystkie zapisane wiadomości zostaną odrzucone. Gdy urządzenie ponownie znajdzie się w trybie online, otrzyma specjalny komunikat informujący o osiągnięciu limitu. Aplikacja może następnie prawidłowo obsłużyć sytuację, zwykle żądając pełnej synchronizacji z serwera aplikacji.
Zwijana wiadomość to wiadomość, którą można zastąpić nową wiadomością, jeśli nie została jeszcze dostarczona do urządzenia.
Typowymi przypadkami użycia zwijanych wiadomości są wiadomości używane do informowania aplikacji mobilnej o synchronizacji danych z serwerem. Przykładem może być aplikacja sportowa, która aktualizuje użytkowników najnowszymi wynikami. Istotna jest tylko najnowsza wiadomość.
Aby oznaczyć wiadomość jako składaną w systemie Android, dołącz parametr collapse_key do ładunku wiadomości. Domyślnie kluczem zwijania jest nazwa pakietu aplikacji zarejestrowana w konsoli Firebase. Serwer FCM może jednocześnie przechowywać cztery różne zwijane komunikaty na urządzenie, każdy z innym kluczem zwijania. Jeśli przekroczysz tę liczbę, FCM przechowuje tylko cztery klucze zwijania, bez gwarancji, które z nich zostaną zachowane.
Wiadomości w temacie bez ładunku są domyślnie zwijane. Wiadomości powiadomień są zawsze zwijane i będą ignorować parametr collapse_key .
Który powinienem użyć?
Zwijane wiadomości są lepszym wyborem z punktu widzenia wydajności, pod warunkiem, że Twoja aplikacja nie musi używać nieskładanych wiadomości. Jeśli jednak korzystasz z komunikatów zwijanych, pamiętaj, że FCM zezwala na użycie przez FCM maksymalnie czterech różnych kluczy zwijania na token rejestracyjny w danym momencie. Nie wolno przekraczać tej liczby, ponieważ może to spowodować nieprzewidywalne konsekwencje.
| Użyj scenariusza | Jak wysłać | |
|---|---|---|
| Nieskładany | Każda wiadomość jest ważna dla aplikacji klienckiej i musi zostać dostarczona. | Z wyjątkiem wiadomości z powiadomieniami, domyślnie wszystkie wiadomości nie są zwijane. |
| Składany | Gdy pojawia się nowsza wiadomość, która powoduje, że starsza, powiązana wiadomość jest nieistotna dla aplikacji klienckiej, FCM zastępuje starszą wiadomość. Na przykład: wiadomości używane do inicjowania synchronizacji danych z serwera lub nieaktualne powiadomienia. | Ustaw odpowiedni parametr w żądaniu wiadomości:
|
Ustawianie priorytetu wiadomości
Dostępne są dwie opcje przypisywania priorytetu dostarczania do odbieranych wiadomości: normalny i wysoki priorytet. Chociaż zachowanie różni się nieco na różnych platformach, dostarczanie wiadomości o normalnym i wysokim priorytecie działa w następujący sposób:
Normalny priorytet. Wiadomości o normalnym priorytecie są dostarczane natychmiast, gdy aplikacja działa na pierwszym planie. W przypadku aplikacji działających w tle dostawa może być opóźniona. W przypadku mniej ważnych wiadomości, takich jak powiadomienia o nowych wiadomościach e-mail, utrzymywanie synchronizacji interfejsu użytkownika lub synchronizowanie danych aplikacji w tle, wybierz normalny priorytet dostarczania.
Wysoki priorytet. FCM próbuje natychmiast dostarczyć wiadomości o wysokim priorytecie, nawet jeśli urządzenie jest w trybie drzemki. Wiadomości o wysokim priorytecie są przeznaczone dla treści wrażliwych na czas i widocznych dla użytkownika.
Oto przykład wiadomości o normalnym priorytecie wysłanej za pośrednictwem protokołu FCM HTTP v1 w celu powiadomienia subskrybenta czasopisma, że nowa treść jest dostępna do pobrania:
{
"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"
}
}
}
}
Aby uzyskać więcej szczegółowych informacji na temat ustawiania priorytetu wiadomości dotyczących konkretnych platform:
Ustawianie czasu życia wiadomości
FCM zwykle dostarcza wiadomości natychmiast po ich wysłaniu. Jednak nie zawsze może to być możliwe. Na przykład, jeśli platformą jest Android, urządzenie może być wyłączone, offline lub w inny sposób niedostępne. FCM może też celowo opóźniać wiadomości, aby uniemożliwić aplikacji nadmierne zużycie zasobów i negatywny wpływ na żywotność baterii.
W takim przypadku FCM przechowuje wiadomość i dostarcza ją tak szybko, jak to możliwe. Chociaż w większości przypadków jest to w porządku, istnieją aplikacje, dla których spóźniona wiadomość równie dobrze mogłaby nigdy nie zostać dostarczona. Na przykład, jeśli wiadomość jest powiadomieniem o połączeniu przychodzącym lub czacie wideo, ma znaczenie tylko przez krótki czas, zanim połączenie zostanie zakończone. Lub jeśli wiadomość jest zaproszeniem na wydarzenie, jest bezużyteczna, jeśli zostanie odebrana po zakończeniu wydarzenia.
W systemach Android i Web/JavaScript można określić maksymalny czas życia wiadomości. Wartość musi mieścić się w przedziale od 0 do 2 419 200 sekund (28 dni) i odpowiada maksymalnemu okresowi czasu, przez jaki FCM przechowuje i próbuje dostarczyć wiadomość. Żądania, które nie zawierają tego pola, domyślnie mają maksymalny okres czterech tygodni.
Oto kilka możliwych zastosowań tej funkcji:
- Połączenia przychodzące na czacie wideo
- Wygasające wydarzenia z zaproszeniami
- Wydarzenia w kalendarzu
Kolejną zaletą określania czasu życia komunikatu jest to, że FCM nigdy nie ogranicza komunikatów z wartością czasu wygaśnięcia wynoszącą 0 sekund. Innymi słowy, FCM gwarantuje dołożenie wszelkich starań w przypadku wiadomości, które muszą zostać dostarczone „teraz albo nigdy”. Pamiętaj, że wartość time_to_live równa 0 oznacza, że wiadomości, których nie można dostarczyć natychmiast, są odrzucane. Jednak ponieważ takie wiadomości nigdy nie są przechowywane, zapewnia to najlepsze opóźnienie dla wysyłania powiadomień.
Oto przykład żądania, które obejmuje TTL:
{
"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"
}
}
}
}Żywotność wiadomości
Gdy serwer aplikacji wysyła wiadomość do FCM i otrzymuje z powrotem identyfikator wiadomości, nie oznacza to, że wiadomość została już dostarczona do urządzenia. Oznacza to raczej, że został przyjęty do dostawy. To, co dzieje się z wiadomością po jej zaakceptowaniu, zależy od wielu czynników.
W najlepszym przypadku, jeśli urządzenie jest podłączone do FCM, ekran jest włączony i nie ma żadnych ograniczeń, wiadomość zostanie dostarczona natychmiast.
Jeśli urządzenie jest podłączone, ale znajduje się w stanie Drzemki, komunikat o niskim priorytecie jest przechowywany przez FCM do momentu wyjścia urządzenia ze stanu Drzemki. I tutaj rolę odgrywa flaga collapse_key : jeśli istnieje już wiadomość z tym samym kluczem zwinięcia (i tokenem rejestracji) przechowywana i oczekująca na dostarczenie, stara wiadomość jest odrzucana, a nowa wiadomość zajmuje jej miejsce (to znaczy stara wiadomość jest zwinięta przez nową). Jeśli jednak klucz zwijania nie jest ustawiony, zarówno nowa, jak i stara wiadomość są przechowywane do dostarczenia w przyszłości.
Jeśli urządzenie nie jest połączone z FCM, wiadomość jest przechowywana do momentu nawiązania połączenia (ponownie przestrzegając zasad klawisza zwijania). Po nawiązaniu połączenia FCM dostarcza wszystkie oczekujące wiadomości do urządzenia. Jeśli urządzenie nigdy więcej się nie połączy (na przykład po przywróceniu ustawień fabrycznych), komunikat w końcu wygaśnie i zostanie usunięty z pamięci FCM. Domyślny limit czasu wynosi cztery tygodnie, chyba że ustawiono flagę time_to_live .
Aby uzyskać więcej informacji na temat dostarczania wiadomości:
Aby uzyskać więcej informacji na temat dostarczania wiadomości na platformach Android lub Apple, zobacz pulpit nawigacyjny raportowania FCM , który rejestruje liczbę wiadomości wysłanych i otwartych na urządzeniach Apple i Android, a także dane dotyczące „wyświetleń” (powiadomień widzianych przez użytkowników) dla Aplikacje Android.
W przypadku urządzeń z systemem Android z włączonym przesyłaniem wiadomości przez kanał bezpośredni, jeśli urządzenie nie łączyło się z FCM przez ponad miesiąc, FCM nadal akceptuje wiadomość, ale natychmiast ją odrzuca. Jeśli urządzenie połączy się w ciągu czterech tygodni od ostatniej wysłanej do niego wiadomości z danymi, klient otrzyma wywołanie zwrotne onDeletedMessages() . Aplikacja może następnie prawidłowo obsłużyć sytuację, zwykle żądając pełnej synchronizacji z serwera aplikacji.
Wreszcie, gdy FCM próbuje dostarczyć wiadomość do urządzenia, a aplikacja została odinstalowana, FCM natychmiast odrzuca tę wiadomość i unieważnia token rejestracji. Przyszłe próby wysłania wiadomości do tego urządzenia zakończą się błędem NotRegistered .
Ograniczanie i skalowanie
Naszym celem jest zawsze dostarczenie każdej wiadomości wysłanej za pośrednictwem FCM. Jednak dostarczenie każdej wiadomości czasami skutkuje złym ogólnym doświadczeniem użytkownika. W innych przypadkach musimy określić granice, aby zapewnić, że FCM zapewnia skalowalną usługę dla wszystkich nadawców.
Składane ograniczanie wiadomości
Jak opisano powyżej, wiadomości zwijane to powiadomienia niezawierające treści, które zwijają się jedno na drugim. W przypadku, gdy programista zbyt często powtarza tę samą wiadomość w aplikacji, opóźniamy (ograniczamy) wiadomości, aby zmniejszyć wpływ na baterię użytkownika.
Na przykład, jeśli wysyłasz dużą liczbę nowych żądań synchronizacji poczty e-mail do jednego urządzenia, możemy opóźnić następne żądanie synchronizacji poczty e-mail o kilka minut, aby urządzenie mogło synchronizować się z niższą średnią szybkością. To dławienie odbywa się wyłącznie w celu ograniczenia wpływu baterii odczuwanego przez użytkownika.
Jeśli twój przypadek użycia wymaga wzorców wysyłania z dużą częstotliwością, właściwym wyborem mogą być wiadomości, których nie można zwijać. W przypadku takich wiadomości pamiętaj o dołączeniu ich treści, aby zmniejszyć koszt baterii.
Ograniczamy składane wiadomości do serii 20 wiadomości na aplikację na urządzenie, z uzupełnianiem 1 wiadomości co 3 minuty.
Ograniczanie serwera XMPP
Ograniczamy szybkość, z jaką możesz łączyć się z serwerami FCM XMPP, do 400 połączeń na minutę na projekt. Nie powinno to stanowić problemu z dostarczaniem wiadomości, ale jest ważne dla zapewnienia stabilności naszego systemu.
Dla każdego projektu FCM pozwala na 2500 połączeń równoległych.
Maksymalna szybkość przesyłania wiadomości do jednego urządzenia
W przypadku Androida możesz wysłać do 240 wiadomości na minutę i 5000 wiadomości na godzinę do jednego urządzenia. Ten wysoki próg ma na celu umożliwienie krótkotrwałych wzrostów ruchu, na przykład gdy użytkownicy szybko wchodzą w interakcje na czacie. To ograniczenie zapobiega przypadkowemu wyczerpaniu baterii urządzenia przez błędy w wysyłaniu logiki.
W przypadku iOS zwracamy błąd, gdy szybkość przekracza limity APN.
Limit wiadomości nadrzędnych
Ograniczamy liczbę wysyłanych wiadomości do 1 500 000/minutę na projekt, aby uniknąć przeciążenia nadrzędnych serwerów docelowych.
Ograniczamy liczbę wysyłanych wiadomości na urządzenie do 1000 wiadomości/minutę, aby chronić baterię przed zużyciem baterii w wyniku nieprawidłowego działania aplikacji.
Limit wiadomości w temacie
Szybkość dodawania/usuwania subskrypcji tematów jest ograniczona do 3000 QPS na projekt.
Aby uzyskać informacje na temat szybkości wysyłania wiadomości, zobacz Ograniczanie Fanout .
Ograniczanie fanoutów
Rozpowszechnianie wiadomości to proces wysyłania wiadomości do wielu urządzeń, na przykład podczas kierowania na tematy i grupy lub gdy używasz kompozytora powiadomień do kierowania reklam do odbiorców lub segmentów użytkowników.
Rozwielanie wiadomości nie jest natychmiastowe, więc od czasu do czasu masz kilka rozsyłanych wiadomości w tym samym czasie. Ograniczamy liczbę jednoczesnych fanoutów wiadomości na projekt do 1000. Następnie możemy odrzucić dodatkowe prośby o fanouty lub odroczyć ich wysyłanie do czasu zakończenia niektórych już trwających fanoutów.
Rzeczywisty osiągalny wskaźnik fanoutów zależy od liczby projektów żądających fanoutów w tym samym czasie. Współczynnik fanoutów na poziomie 10 000 QPS dla pojedynczego projektu nie jest rzadkością, ale ta liczba nie jest gwarancją i wynika z całkowitego obciążenia systemu. Należy zauważyć, że dostępna pojemność rozsyłania jest dzielona między projekty, a nie na żądania rozsyłania. Tak więc, jeśli twój projekt ma dwa fanouty w toku, każdy fanout zobaczy tylko połowę dostępnego wskaźnika fanoutów. Zalecanym sposobem na zmaksymalizowanie prędkości fanoutu jest posiadanie tylko jednego aktywnego fanoutu w danym momencie.
Porty FCM i zapora sieciowa
Jeśli Twoja organizacja ma zaporę, która ogranicza ruch do lub z Internetu, musisz ją skonfigurować tak, aby zezwalała urządzeniom mobilnym na łączenie się z FCM, aby urządzenia w Twojej sieci mogły odbierać wiadomości. FCM zwykle używa portu 5228, ale czasami używa portów 443, 5229 i 5230.
W przypadku urządzeń łączących się z Twoją siecią FCM nie podaje konkretnych adresów IP, ponieważ nasz zakres adresów IP zmienia się zbyt często, a reguły zapory sieciowej mogą się dezaktualizować, wpływając na wrażenia użytkowników. W idealnym przypadku należy utworzyć listę dozwolonych portów 5228-5230 i 443 bez ograniczeń dotyczących adresów IP. Jeśli jednak musisz mieć ograniczenie adresów IP, powinieneś umieścić na liście dozwolonych wszystkie adresy IP wymienione w goog.json . Ta obszerna lista jest regularnie aktualizowana i zaleca się aktualizowanie reguł co miesiąc. Problemy spowodowane ograniczeniami adresów IP zapory są często sporadyczne i trudne do zdiagnozowania.
Oferujemy zestaw nazw domen, które można umieścić na liście dozwolonych zamiast adresów IP. Te nazwy hostów są wymienione poniżej. Jeśli zaczniemy używać dodatkowych nazw hostów, zaktualizujemy listę tutaj. Używanie nazw domen dla reguły zapory może, ale nie musi, działać w urządzeniu zapory.
Porty TCP do otwarcia:
- 5228
- 5229
- 5230
- 443
Nazwy hostów do otwarcia:
- mtalk.google.com
- mtalk4.google.com
- mtalk-staging.google.com
- mtalk-dev.google.com
- alt1-mtalk.google.com
- alt2-mtalk.google.com
- alt3-mtalk.google.com
- alt4-mtalk.google.com
- alt5-mtalk.google.com
- alt6-mtalk.google.com
- alt7-mtalk.google.com
- alt8-mtalk.google.com
- android.apis.google.com
- device-provisioning.googleapis.com
- firebaseinstallations.googleapis.com
Zapory ogniowe z translacją adresów sieciowych i/lub stanową inspekcją pakietów:
Jeśli Twoja sieć korzysta z translacji adresów sieciowych (NAT) lub Stateful Packet Inspection (SPI), zastosuj 30-minutowy lub dłuższy limit czasu dla naszych połączeń przez porty 5228-5230. Dzięki temu możemy zapewnić niezawodną łączność przy jednoczesnym zmniejszeniu zużycia baterii przez urządzenia mobilne użytkowników.
Referencje
W zależności od tego, jakie funkcje FCM zaimplementujesz, możesz potrzebować następujących danych logowania z projektu Firebase:
| Identyfikator projektu | Unikalny identyfikator Twojego projektu Firebase, używany w żądaniach do punktu końcowego HTTP FCM v1. Ta wartość jest dostępna w okienku Ustawienia konsoli Firebase . |
| Token rejestracyjny | Unikalny ciąg tokenu, który identyfikuje każde wystąpienie aplikacji klienckiej. Token rejestracji jest wymagany do przesyłania komunikatów dotyczących pojedynczego urządzenia i grupy urządzeń. Pamiętaj, że tokeny rejestracyjne muszą być utrzymywane w tajemnicy. |
| Identyfikator nadawcy | Unikalna wartość liczbowa utworzona podczas tworzenia projektu Firebase, dostępna na karcie Cloud Messaging w panelu Ustawienia konsoli Firebase. Identyfikator nadawcy służy do identyfikowania każdego nadawcy, który może wysyłać wiadomości do aplikacji klienckiej. |
| Token dostępu | Krótkotrwały token OAuth 2.0, który autoryzuje żądania do interfejsu HTTP v1 API. Ten token jest powiązany z kontem usługi należącym do Twojego projektu Firebase. Aby utworzyć i rotować tokeny dostępu, wykonaj czynności opisane w artykule Autoryzacja wysyłania żądań . |
| Klucz serwera (dla starszych protokołów) | Klucz serwera, który upoważnia serwer Twojej aplikacji do uzyskiwania dostępu do usług Google, w tym do wysyłania wiadomości za pośrednictwem starszych protokołów Firebase Cloud Messaging. Klucz serwera uzyskujesz podczas tworzenia projektu Firebase. Możesz go wyświetlić na karcie Cloud Messaging w okienku Ustawienia konsoli Firebase. Ważne: nie umieszczaj klucza serwera w żadnym miejscu kodu klienta. Upewnij się też, że do autoryzacji serwera aplikacji używasz tylko kluczy serwera. Android, platforma Apple i klucze przeglądarki są odrzucane przez FCM. |