Ta strona została przetłumaczona przez Cloud Translation API.

Informacje o wiadomościach w FCM

Firebase Cloud Messaging (FCM) oferuje szeroki zakres opcji i możliwości przesyłania wiadomości. Informacje na tej stronie pomogą Ci zrozumieć różne typy wiadomości FCM i to, co możesz z nimi zrobić.

Typy wiadomości

Za pomocą FCM możesz wysyłać do klientów 2 rodzaje wiadomości:

komunikaty z powiadomieniami, które czasami nazywa się „komunikatami wyświetlanymi”. Te parametry są obsługiwane automatycznie przez pakiet SDK FCM.
wiadomości z danymi, które są obsługiwane przez aplikację kliencką.

Wiadomości z powiadomieniami zawierają wstępnie zdefiniowany zestaw kluczy widocznych dla użytkownika. Natomiast wiadomości danych zawierają tylko definiowane przez użytkownika pary klucz-wartość. Wiadomości z powiadomieniami mogą zawierać opcjonalny ładunek danych. Maksymalny ładunek dla obu typów wiadomości to 4096 bajtów, z wyjątkiem sytuacji, gdy wysyłasz wiadomości z konsoli Firebase, która narzuca limit 1000 znaków.

	Przypadek użycia	Jak wysłać
Powiadomienie	FCM Pakiet SDK wyświetla wiadomość na urządzeniach użytkowników końcowych w imieniu aplikacji klienckiej, gdy działa ona w tle. Jeśli aplikacja działa na pierwszym planie w momencie otrzymania powiadomienia, jej kod decyduje o zachowaniu. Wiadomości zawierają wstępnie zdefiniowany zestaw kluczy widocznych dla użytkownika oraz opcjonalny zestaw danych w postaci niestandardowych par klucz-wartość.	W zaufanym środowisku, takim jak Cloud Functions lub serwer aplikacji, użyj pakietu Admin SDK lub interfejsu HTTP API w wersji 1. Ustaw klucz `notification`. Może zawierać opcjonalny ładunek danych. zawsze można je zwinąć. Zapoznaj się z kilkoma przykładami wyświetlania powiadomień i przesyłania ładunków żądań. Użyj narzędzia do tworzenia powiadomień: wpisz tekst wiadomości, tytuł itp. i wyślij. Dodaj opcjonalny ładunek danych, podając dane niestandardowe.
Komunikat o danych	Aplikacja klienta odpowiada za przetwarzanie wiadomości danych. Komunikaty danych zawierają tylko niestandardowe pary klucz-wartość bez zastrzeżonych nazw kluczy (patrz poniżej).	W zaufanym środowisku, takim jak Cloud Functions lub serwer aplikacji, używaj pakietu Admin SDK lub protokołów serwera FCM. W żądaniu wysyłania ustaw klucz `data`.

Używaj wiadomości z powiadomieniami, gdy chcesz, aby pakiet SDK FCM automatycznie wyświetlał powiadomienia, gdy aplikacja działa w tle. Używaj wiadomości z danymi, gdy chcesz przetwarzać wiadomości za pomocą kodu własnej aplikacji klienckiej.

FCM może wysyłać powiadomienia zawierające opcjonalny ładunek danych. W takich przypadkach FCM odpowiada za wyświetlanie ładunku danych powiadomienia, a aplikacja klienta za ładunek danych.

Wiadomości z powiadomieniami

Do celów testowych lub marketingowych oraz ponownego zaangażowania użytkowników możesz wysyłać wiadomości z powiadomieniami za pomocą konsoli Firebase. Konsola Firebase udostępnia testy A/B oparte na analityce, które pomagają dopracować i ulepszać komunikaty marketingowe.

Aby wysyłać wiadomości z powiadomieniami za pomocą pakietu Admin SDK lub protokołów FCM, ustaw klucz notification z wymaganym wstępnie zdefiniowanym zestawem opcji klucz-wartość dla widocznej dla użytkownika części wiadomości z powiadomieniem. Oto na przykład wiadomość z powiadomieniem w aplikacji do przesyłania wiadomości w formacie JSON. Użytkownik zobaczy na urządzeniu wiadomość z tytułem „Portugalia – Dania” i tekstem „Świetny mecz!”:

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

Wiadomości z powiadomieniami są dostarczane do obszaru powiadomień, gdy aplikacja działa w tle. W przypadku aplikacji na pierwszym planie wiadomości są obsługiwane przez funkcję wywołania zwrotnego.

Pełną listę zdefiniowanych wstępnie kluczy dostępnych do tworzenia wiadomości z powiadomieniami znajdziesz w dokumentacji obiektu powiadomienia HTTP v1 Protocol.

Komunikaty dotyczące danych

Aby wysłać ładunek danych do aplikacji klienckiej, ustaw odpowiedni klucz z niestandardowymi parami klucz-wartość.

Oto na przykład wiadomość w formacie JSON w tej samej aplikacji do przesyłania wiadomości, w której informacje są zapisane w kluczu data, a aplikacja kliencka ma interpretować zawartość:

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

Powyższy przykład pokazuje użycie pola najwyższego poziomu, czyli wspólnego pola data, które jest interpretowane przez klientów na wszystkich platformach, które otrzymują wiadomość. Na każdej platformie aplikacja klienta otrzymuje ładunek danych w funkcji wywołania zwrotnego.

Szyfrowanie wiadomości danych

Warstwę transportową Androida (patrz architektura FCM) wykorzystuje szyfrowanie punkt-punkt. W zależności od potrzeb możesz dodać szyfrowanie end-to-end do wiadomości danych. FCM nie zapewnia kompleksowego rozwiązania. Dostępne są jednak rozwiązania zewnętrzne, takie jak Capillary czy DTLS.

wiadomości z opcjonalnym ładunkiem danych,

Możesz wysyłać wiadomości z powiadomieniami zarówno programowo, jak i za pomocą konsoli Firebase, które zawierają opcjonalny ładunek danych w postaci niestandardowych par klucz-wartość. W komponencie powiadomień użyj pól Dane niestandardowe w sekcji Opcje zaawansowane.

Zachowanie aplikacji podczas odbierania wiadomości zawierających zarówno dane ładunku, jak i powiadomienia, zależy od tego, czy aplikacja działa w tle czy na pierwszym planie, a także od tego, czy jest aktywna w momencie odbioru.

W tle aplikacje otrzymują dane powiadomienia w obszarze powiadomień i obsługują je tylko wtedy, gdy użytkownik kliknie powiadomienie.
Gdy aplikacja działa na pierwszym planie, otrzymuje obiekt message z obiema dostępnymi ładowaniami.

Oto wiadomość w formacie JSON zawierająca klucz notification 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

Zarówno protokół Firebase Admin SDK, jak i protokół HTTP FCM w wersji 1 umożliwiają ustawianie w żądaniach wiadomości wszystkich pól dostępnych w obiekcie message. Obejmuje to m.in.:

wspólny zestaw pól, które mają być interpretowane przez wszystkie wystąpienia aplikacji, które otrzymują wiadomość;
zestawy pól określonej platformy, np. AndroidConfig i WebpushConfig, interpretowane tylko przez instancje aplikacji działające na określonej platformie.

Blokady dla poszczególnych platform umożliwiają dostosowywanie wiadomości do różnych platform, aby zapewnić ich prawidłowe przetwarzanie po otrzymaniu. Backend FCM weźmie pod uwagę wszystkie określone parametry i dostosuje wiadomość do każdej platformy.

Kiedy używać pól wspólnych

Używaj pól wspólnych, gdy:

kierowanie na instancje aplikacji na wszystkich platformach: Apple, Android i internet;
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 związanych z poszczególnymi platformami

Używaj pól związanych z poszczególnymi platformami, jeśli chcesz:

Wysyłanie pól tylko na określone platformy
Wyślij pola specyficzne dla platformy oprócz pól wspólnych.

Jeśli chcesz wysyłać wartości tylko na określone platformy, nie używaj wspólnych pól. Zamiast nich używaj pól specyficznych dla danej platformy. Aby na przykład wysyłać powiadomienia tylko na platformy Apple i do przeglądarki, ale nie na urządzenia z Androidem, musisz użyć 2 oddzielnych zestawów pól: jednego dla Apple i drugiego dla przeglądarki.

Jeśli wysyłasz wiadomości z określonymi opcjami dostarczania, użyj pól określonych dla danej platformy, aby je ustawić. W razie potrzeby możesz podać różne wartości dla poszczególnych platform. Nawet jeśli chcesz ustawić tę samą wartość na wszystkich platformach, musisz użyć pól specyficznych dla danej platformy. Dzieje się tak, ponieważ każda platforma może interpretować tę wartość nieco inaczej. Na przykład czas życia w Androidzie jest ustawiany jako czas wygaśnięcia w sekundach, a w przypadku Apple jako data wygaśnięcia.

Przykład: wiadomość z powiadomieniem z opcjami dostarczania na poszczególnych platformach

Poniższe żądanie wysyłania w wersji 1 wysyła wspólny tytuł i treść powiadomienia do wszystkich platform, ale też niektóre zastąpienia specyficzne dla danej platformy. W szczególności prośba:

ustawia długi czas istnienia dla platform Android i internetowych, a priorytet wiadomości APN (platformy Apple) ustawia na niski;
ustawia odpowiednie klucze, aby zdefiniować wynik kliknięcia powiadomienia przez użytkownika na Androidzie i Apple – odpowiednio click_action i 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"
       }
     }
   }
 }

Szczegółowe informacje o kluczach dostępnych w blokach specyficznych dla platformy w ciele wiadomości znajdziesz w dokumentacji referencyjnej HTTP w wersji 1. Więcej informacji o tworzeniu żądań wysyłania, które zawierają treść wiadomości, znajdziesz w artykule Tworzenie żądań wysyłania.

Opcje dostawy

FCM udostępnia określony zestaw opcji dostarczania wiadomości wysyłanych na urządzenia z Androidem oraz umożliwia korzystanie z podobnych opcji na platformach Apple i w internecie. Na przykład zachowanie „zwinięcia” jest obsługiwane na Androidzie za pomocą FCM collapse_key, na urządzeniach Apple za pomocą apns-collapse-id oraz w JavaScript/na stronie internetowej za pomocą Topic. Szczegółowe informacje znajdziesz w opisach w tej sekcji i powiązanej dokumentacji.

Wiadomości niezwijane i zwijane

Wiadomość niezałamana oznacza, że każda wiadomość jest dostarczana do urządzenia. Wiadomość nieskładana zawiera przydatne treści, w przeciwieństwie do składanej wiadomości, np. „ping” bez treści, która ma na celu umożliwienie aplikacji mobilnej nawiązanie połączenia z serwerem w celu pobrania danych.

Typowe przypadki użycia nieskładanych wiadomości to wiadomości czatu lub wiadomości o wysokiej priorytecie. Na przykład w aplikacji do przesyłania wiadomości MMS-owych chcesz dostarczyć wszystkie wiadomości, ponieważ każda z nich ma inną treść.

W przypadku Androida można zapisać bez zwijania 100 wiadomości. Jeśli zostanie osiągnięty limit, wszystkie przechowywane wiadomości zostaną odrzucone. Gdy urządzenie ponownie połączy się z internetem, otrzyma specjalną wiadomość z informacją o osiągnięciu limitu. Aplikacja może wtedy odpowiednio zareagować, zwykle prosząc o pełną synchronizację z serwera aplikacji.

Wiadomość z możliwością złożenia to wiadomość, która może zostać zastąpiona nową wiadomością, jeśli nie została jeszcze dostarczona na urządzenie.

Zwijane komunikaty są często używane do informowania aplikacji mobilnej o potrzebie zsynchronizowania danych z serwerem. Przykładem może być aplikacja sportowa, która informuje użytkowników o najnowszych wynikach. Ważna jest tylko najnowsza wiadomość.

Aby oznaczyć wiadomość jako składaną na urządzeniu z Androidem, dodaj parametr collapse_key do danych wiadomości. Domyślnie klucz składania to nazwa pakietu aplikacji zarejestrowana w konsoli Firebase. Serwer FCM może przechowywać jednocześnie 4 różne zwijane wiadomości na urządzenie, z których każda ma inny klucz zwinięcia. Jeśli przekroczysz tę liczbę, FCM zachowa tylko 4 klucze zwijania, bez gwarancji, które z nich zostaną zachowane.

Wiadomości dotyczące tematu bez ładunku są domyślnie zwijane. Wiadomości z powiadomieniami są zawsze możliwe do zwinięcia i ignorują parametr collapse_key.

Którego mam użyć?

Z punktu widzenia wydajności lepsze są wiadomości, które można zwinąć, o ile Twoja aplikacja nie musi używać wiadomości, których nie można zwinąć. Jeśli jednak używasz wiadomości z możliwością zwijania, pamiętaj, że FCM pozwala na używanie maksymalnie 4 różnych kluczy zwijania przez FCM na token rejestracji w danym momencie. Nie możesz przekroczyć tej liczby, ponieważ może to spowodować nieprzewidziane konsekwencje.

	Przypadek użycia	Jak wysłać
Nie można zwinąć	Każda wiadomość jest ważna dla aplikacji klienckiej i musi zostać dostarczona.	Z wyjątkiem wiadomości z powiadomieniami wszystkie wiadomości są domyślnie nieskładane.
Zwijana	Gdy pojawi się nowsza wiadomość, która powoduje, że starsza wiadomość staje się nieistotna dla aplikacji klienta, FCM zastępuje starszy komunikat. Na przykład: wiadomości służące do inicjowania synchronizacji danych z serwera lub nieaktualne wiadomości z powiadomieniami.	Ustaw odpowiedni parametr w prośbie o wiadomość: `collapseKey` na Androidzie `apns-collapse-id` w Apple `Topic` w internecie `collapse_key` w starszych protokołach (wszystkie platformy)

Ustawianie priorytetu wiadomości

Masz 2 opcje przypisywania priorytetu dostawy wiadomościom wysyłanym dalej: normalny i wysoki priorytet. Chociaż sposób działania różni się nieco w zależności od platformy, dostarczanie wiadomości o normalnym i wysokim priorytecie wygląda tak:

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 wiadomości, które nie są tak pilne, np. powiadomień o nowych e-mailach, synchronizacji interfejsu lub synchronizacji danych aplikacji w tle, wybierz normalny priorytet przesyłania.
Wysoki priorytet. Komunikacja w chmurze Firebase próbuje natychmiast dostarczać wiadomości o wysokiej priorytecie, nawet jeśli urządzenie jest w trybie Doze. Komunikaty o wysokim priorytecie dotyczą treści widocznych dla użytkownika, które mają ograniczony czas ważności.

Podczas wysyłania wiadomości danych na urządzenia Apple priorytet musi zostać ustawiony na 5, czyli normalny priorytet. Wiadomości wysyłane z wysokim priorytetem są odrzucane przez backend FCM z błędem INVALID_ARGUMENT.

Oto przykład wiadomości o normalnym priorytecie wysłanej za pomocą protokołu FCMHTTP w wersji 1, aby powiadomić subskrybenta czasopisma o dostępności nowych treści 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"
      }
    }
  }
}

Więcej informacji o ustawianiu priorytetu wiadomości w przypadku poszczególnych platform:

Krytyczne przypadki użycia

Interfejsy API FCM nie są przeznaczone do ostrzegania o wypadkach i innych sytuacjach wysokiego ryzyka, w których użycie lub błąd interfejsów API może spowodować śmierć, obrażenia ciała lub szkody dla środowiska (takich jak obsługa obiektów jądrowych, kontrola lotów czy systemy podtrzymujące życie). Wszelkie takie działania są wyraźnie zabronione na mocy art. 4 a. 7 Warunków korzystania z usługi. Użytkownik ponosi wyłączną odpowiedzialność za zarządzanie zgodnością aplikacji z Warunkami oraz za wszelkie szkody wynikające z nieprzestrzegania tych Warunków. Google udostępnia interfejsy API „w stanie, w jakim są”, i zastrzega sobie prawo do przerwania udostępniania interfejsów API lub ich części, funkcji lub dostępu do nich z dowolnych powodów i w dowolnym momencie bez ponoszenia odpowiedzialności ani innych zobowiązań wobec użytkownika lub jego użytkowników.

Ustawianie okresu ważności wiadomości

FCM zwykle dostarcza wiadomości natychmiast po ich wysłaniu. Nie zawsze jest to jednak możliwe. Jeśli na przykład platforma to Android, urządzenie może być wyłączone, offline lub niedostępne z innego powodu. Aplikacja FCM może też celowo opóźniać wiadomości, aby zapobiec nadmiernemu zużyciu zasobów przez aplikację i niekorzystnemu wpływowi na czas pracy na baterii.

W takim przypadku FCM przechowuje wiadomość i dostarcza ją tak szybko, jak to możliwe. W większości przypadków jest to w porządku, ale w niektórych aplikacjach opóźnione wiadomości mogą wcale nie dotrzeć. Jeśli na przykład wiadomość dotyczy nadchodzącego połączenia lub powiadomienia o rozmowie wideo, jest ona istotna tylko przez krótki czas przed zakończeniem połączenia. Jeśli wiadomość jest zaproszeniem na wydarzenie, jest bezużyteczna, jeśli została dostarczona po zakończeniu wydarzenia.

W Androidzie i JavaScript możesz określić maksymalny czas życia wiadomości. Wartość musi być czasem trwania od 0 do 2419 200 sekund (28 dni) i odpowiada maksymalnemu okresowi, przez który usługa FCM przechowuje i próbuje dostarczyć wiadomość. W przypadku żądań, które nie zawierają tego pola, domyślnie ustawiany jest maksymalny okres 4 tygodnie.

Oto kilka możliwych zastosowań tej funkcji:

Połączenia przychodzące na czacie wideo
Wydarzenia dotyczące wygasających zaproszeń
Wydarzenia w kalendarzu

Kolejną zaletą określania czasu życia wiadomości jest to, że FCM nie stosuje ograniczania liczby wyświetleń wiadomości, które można złożyć, w przypadku wiadomości o wartości czasu istnienia równej 0 sekund. FCM zapewnia jak najlepszą obsługę wiadomości, które muszą zostać dostarczone „teraz lub nigdy”. Pamiętaj, że wartość time_to_live 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 najkrótszy czas opóźnienia przy wysyłaniu powiadomień.

Oto przykład żądania z uwzględnieniem czasu trwania:

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

Czas trwania wiadomości

Gdy serwer aplikacji publikuje wiadomość na stronie FCM i otrzymuje w zamian identyfikator wiadomości, nie oznacza to, że wiadomość została już dostarczona na urządzenie. Oznacza to, że została zaakceptowana do dostarczenia. To, co dzieje się z wiadomością po jej zaakceptowaniu, zależy od wielu czynników.

W najlepszym przypadku, jeśli urządzenie jest połączone z FCM, ekran jest włączony i nie ma żadnych ograniczeń, wiadomość zostanie dostarczona od razu.

Jeśli urządzenie jest połączone, ale znajduje się w trybie Doze, wiadomość o niskim priorytecie jest przechowywana przez FCM do momentu, gdy urządzenie wyjdzie z tego trybu. Właśnie w tym miejscu pojawia się flaga collapse_key: jeśli istnieje już wiadomość z tym samym kluczem składania (i tokenem rejestracji) przechowywana i oczekująca na dostarczenie, stara wiadomość zostaje odrzucona, a nowa zajmuje jej miejsce (czyli stara wiadomość zostaje złożona przez nową). Jeśli jednak klucz collapse nie jest ustawiony, zarówno nowe, jak i stare wiadomości są przechowywane na potrzeby przyszłych wysyłek.

Jeśli urządzenie nie jest połączone z FCM, wiadomość jest przechowywana do czasu nawiązania połączenia (z ponownym uwzględnieniem reguł dotyczących klucza zwinięcia). Po nawiązaniu połączenia FCM prześle na urządzenie wszystkie oczekujące wiadomości. Jeśli urządzenie nigdy więcej nie zostanie połączone (na przykład, jeśli zostało zresetowane do ustawień fabrycznych), wiadomość ostatecznie wygaśnie i zostanie usunięta z pamięci FCM. Domyślny limit czasu to 4 tygodnie, chyba że ustawiona jest flaga time_to_live.

Aby uzyskać więcej informacji o dostarczaniu wiadomości:

Aby uzyskać więcej informacji o dostarczaniu wiadomości na platformach Android i Apple, skorzystaj z FCMpanelu raportów, który zawiera informacje o liczbie wiadomości wysłanych i otwartych na urządzeniach Apple i Android oraz dane o wyświetleniach (powiadomieniach wyświetlanych użytkownikom) aplikacji na Androida.

Na urządzeniach z Androidem, na których włączono wysyłanie wiadomości na kanale bezpośrednim, jeśli urządzenie nie było połączone z FCM przez ponad miesiąc, FCM nadal przyjmuje wiadomość, ale natychmiast ją odrzuca. Jeśli urządzenie połączy się w ciągu 4 tygodni od wysłania do niego ostatniej wiadomości z danymi, Twój klient otrzyma wywołanie zwrotne onDeletedMessages(). Aplikacja może wtedy odpowiednio zareagować, zwykle prosząc o pełną synchronizację z serwera aplikacji.

Gdy FCM próbuje dostarczyć wiadomość na urządzenie, a aplikacja została odinstalowana, FCM od razu odrzuca tę wiadomość i unieważnia token rejestracji. Kolejne próby wysłania wiadomości do tego urządzenia spowodują błąd NotRegistered.

Ograniczanie liczby żądań i limity

Naszym celem jest zawsze dostarczanie wszystkich wiadomości wysyłanych przez FCM. Jednak wyświetlanie wszystkich wiadomości może czasami powodować niekorzystne wrażenia użytkowników. W innych przypadkach musimy wyznaczać granice, aby mieć pewność, że FCM zapewnia skalowalny serwis dla wszystkich nadawców. Rodzaje limitów i kwot opisane w tej sekcji pomagają nam zachować równowagę między tymi ważnymi czynnikami.

Ograniczanie przesyłania wiadomości w dół łańcucha

Interfejs HTTP w wersji 1 wprowadził limity na projekt na minutę dotyczące przesyłania wiadomości. Domyślna kwota 600 tys. wiadomości na minutę obejmuje ponad 99% FCMprogramistów, chroniąc jednocześnie stabilność systemu i minimalizując wpływ projektów o wysokiej intensywności.

Nagłe zmiany w natężeniu ruchu mogą powodować błędy związane z przekroczeniem limitu. W przypadku przekroczenia limitu system zwraca kod stanu HTTP 429 (QUOTA_EXCEEDED), dopóki limit nie zostanie uzupełniony w następującej minucie. Odpowiedzi 429 mogą być też zwracane w sytuacjach przeciążenia, dlatego zdecydowanie zalecamy obsługę odpowiedzi 429 zgodnie z opublikowanymi rekomendacjami.

Uwaga:

Limit na ścieżce w dół dotyczy wiadomości, a nie żądań.
Błędy klienta (kod stanu HTTP 400–499) są zliczane (z wyjątkiem kodu 429).
Limity są podawane w minutach, ale nie są one dopasowywane do czasu zegara.

Limity

Limity, wykorzystanie i błędy możesz wyświetlić w konsoli Google Cloud:

Otwórz konsolę Google Cloud.
Kliknij Interfejsy API i usługi.
Na liście wybierz Firebase Cloud Messaging API.
Kliknij LIMITY PRZYDZIELANIA I LIMITY SYSTEMU.

UWAGA: Te wykresy nie są dokładnie dopasowane czasowo do minut limitu, co oznacza, że kod 429 może być wyświetlany, gdy wydaje się, że ruch jest poniżej limitu.

Wysyłanie prośby o zwiększenie limitu

Zanim poprosisz o zwiększenie limitu, upewnij się, że:

regularnie wykorzystujesz co najmniej 80% limitu przez co najmniej 5 minut dziennie;
Współczynnik błędów klienta jest mniejszy niż 5%, zwłaszcza w szczycie natężenia ruchu.
Stosujesz sprawdzone metody wysyłania wiadomości na dużą skalę.

Jeśli spełniasz te kryteria, możesz przesłać prośbę o zwiększenie limitu kwoty o maksymalnie +25%, a FCM dołoży wszelkich starań, aby spełnić Twoją prośbę (nie możemy zagwarantować zwiększenia limitu).

Jeśli potrzebujesz większej puli wiadomości na niższym poziomie ze względu na zbliżający się termin lub tymczasowe zdarzenie, poproś o pulę z co najmniej 15-dniowym wyprzedzeniem, abyśmy mieli wystarczająco dużo czasu na rozpatrzenie prośby. W przypadku dużych zapytań (ponad 18 mln wiadomości na minutę) wymagane jest co najmniej 30-dniowe powiadomienie. Prośby o uruchomienie i specjalne wydarzenia są nadal objęte wymaganiami dotyczącymi współczynnika błędów klienta i sprawdzonych metod.

Zobacz też odpowiedzi na pytania dotyczące limitów FCM.

Limit wiadomości związanych z tematem

Szybkość dodawania i usuwania subskrypcji tematu jest ograniczona do 3000 QPS na projekt.

Informacje o częstotliwości wysyłania wiadomości znajdziesz w artykule Ograniczanie rozsyłania.

Ograniczanie wyjścia

Rozsyłanie wiadomości to proces wysyłania wiadomości na wiele urządzeń, np. gdy kierujesz reklamy na tematy i grupy lub używasz Edytora powiadomień, aby docierać do określonych odbiorców lub segmentów użytkowników.

Rozpowszechnianie wiadomości nie jest natychmiastowe, dlatego czasami może się zdarzyć, że rozpowszechnianie odbywa się równolegle. Ograniczamy liczbę równoczesnych rozsyłek wiadomości na projekt do 1000. Po tym czasie możemy odrzucić dodatkowe prośby o rozproszenie lub odłożyć ich realizację do czasu zakończenia rozproszeń, które są już w toku.

Na rzeczywistą osiągalną szybkość rozgałęzienia wpływa liczba projektów, które jednocześnie proszą o rozgałęzienia. Częstotliwość rozgałęzienia 10 tys. QPS w przypadku pojedynczego projektu nie jest rzadkością, ale ta liczba nie jest gwarantowana i zależy od całkowitego obciążenia systemu. Pamiętaj, że dostępna pojemność rozgałęzienia jest dzielona między projekty, a nie między prośbami o rozgałęzienie. Jeśli więc w Twoim projekcie są 2 rozgałęzienia w toku, każde z nich będzie korzystać tylko z połowy dostępnej szybkości. Aby zmaksymalizować szybkość rozgałęzienia, zalecamy prowadzenie tylko 1 aktywnej operacji rozgałęzienia.

ograniczanie liczby wiadomości zwijanych,

Jak opisano powyżej, wiadomości z możliwością zwijania to powiadomienia bez treści, które są przeznaczone do zwijania na siebie. Jeśli deweloper powtarza tę samą wiadomość w aplikacji zbyt często, opóźniamy (ograniczamy) wysyłanie wiadomości, aby zmniejszyć wpływ na baterię użytkownika.

Jeśli na przykład wysyłasz na jedno urządzenie dużą liczbę nowych żądań synchronizacji e-maili, możemy opóźnić wysyłanie kolejnego żądania synchronizacji e-maili o kilka minut, aby urządzenie mogło synchronizować się z niższą średnią szybkością. Ograniczenie to jest wprowadzane wyłącznie w celu ograniczenia wpływu na zużycie baterii odczuwanego przez użytkownika.

Jeśli Twój przypadek użycia wymaga wysyłania dużej liczby wiadomości w krótkim czasie, wiadomości nieskładane mogą być odpowiednim wyborem. W takich wiadomościach należy uwzględnić treść, aby zmniejszyć zużycie baterii.

Liczba składanych wiadomości jest ograniczona do 20 wiadomości na aplikację na urządzeniu, z możliwością uzupełnienia o 1 wiadomość co 3 minuty.

Ograniczanie przepustowości serwera XMPP

Ograniczamy szybkość łączenia się z serwerami XMPP FCM do 400 połączeń na minutę na projekt. Nie powinno to stanowić problemu w dostarczaniu wiadomości, ale jest ważne dla zapewnienia stabilności systemu. W przypadku każdego projektu usługa FCM umożliwia 2500 równoległych połączeń.

W przypadku przesyłania komunikatów w dół za pomocą XMPP usługa FCM ogranicza liczbę komunikatów w dół do 1 500 000 na minutę na projekt, aby uniknąć przeciążenia serwerów docelowych.

Ograniczamy liczbę wiadomości przesyłanych z urządzenia na 1000 na minutę,aby chronić baterię przed rozładowywaniem się z powodu nieprawidłowego działania aplikacji.

Maksymalna częstotliwość wysyłania wiadomości na jedno urządzenie

W przypadku Androida możesz wysyłać maksymalnie 240 wiadomości na minutę i 5000 wiadomości na godzinę na jedno urządzenie. Wysoki próg ma na celu umożliwienie krótkotrwałych wzrostów natężenia ruchu, np. gdy użytkownicy szybko komunikują się w czacie. Ten limit zapobiega błędom w logice wysyłania, które mogą spowodować przypadkowe rozładowanie baterii urządzenia.

W przypadku iOS zwracamy błąd, gdy częstotliwość przekracza limity APN.

FCM i zapora sieciowa

Jeśli Twoja organizacja ma zaporę sieciową, która ogranicza ruch do internetu lub z internetu, musisz ją skonfigurować tak, aby urządzenia mobilne mogły się łączyć 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 Twoje reguły zapory sieciowej mogą się zdezaktualizować, co może mieć wpływ na działanie usługi. W idealnej sytuacji porty 5228–5230 i 443 powinny być dozwolone bez ograniczeń adresów IP. Jeśli jednak musisz ustawić ograniczenie adresów IP, dodaj do listy dozwolonych wszystkie adresy IP wymienione w pliku goog.json. Ta duża lista jest regularnie aktualizowana, dlatego zalecamy aktualizowanie reguł co miesiąc. Problemy spowodowane ograniczeniami zapory sieciowej dotyczącymi adresów IP są często sporadyczne i trudne do zdiagnozowania.

Oferujemy zestaw nazw domen, które można dodać do listy dozwolonych zamiast adresów IP. Te nazwy hostów znajdziesz poniżej. Jeśli zaczniemy używać dodatkowych nazw hostów, zaktualizujemy tę listę. Korzystanie z nazwy domeny w regułach zapory może, ale nie musi działać na Twoim urządzeniu z zaporą.

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

zapora sieciowa NAT lub zapora z kontrolą stanu pakietów:

Jeśli Twoja sieć korzysta z funkcji NAT (Network Address Translation) lub SPI (Stateful Packet Inspection), ustaw limit czasu na 30 minut lub dłuższy w przypadku połączeń przez porty 5228–5230. Dzięki temu możemy zapewnić niezawodną łączność, jednocześnie zmniejszając zużycie baterii w urządzeniach mobilnych użytkowników.

Interakcje z siecią VPN i możliwość jej obejścia

Firebase Cloud Messaging podejmuje różne działania, aby połączenie wiadomości push z telefonu na serwer było niezawodne i dostępne tak często, jak to możliwe. Korzystanie z sieci VPN komplikuje ten proces.

Sieci VPN maskują informacje, których FCM potrzebuje do dostosowania połączenia, aby zmaksymalizować niezawodność i czas pracy na baterii. W niektórych przypadkach VPN-y aktywnie przerywają długotrwałe połączenia, co powoduje niewygodę użytkowników z powodu braku lub opóźnienia wiadomości albo wysokiego zużycia baterii. Gdy sieć VPN jest skonfigurowana tak, abyśmy mogli to zrobić, omijamy ją, korzystając z szyfrowanego połączenia (przez sieć podstawową Wi-Fi lub LTE), aby zapewnić niezawodność i oszczędność baterii. Korzystanie przez FCM z omijalnych sieci VPN jest specyficzne dla kanału FCM Push Notification. Inny ruch FCM, np. ruch związany z rejestracją, korzysta z sieci VPN, jeśli jest ona aktywna. Gdy połączenie FCMominie sieć VPN, traci dodatkowe korzyści, jakie zapewnia VPN, takie jak maskowanie adresu IP.

Różne sieci VPN mają różne metody kontrolowania, czy można je obejść. Instrukcje znajdziesz w dokumentacji konkretnej sieci VPN.

Jeśli sieć VPN nie jest skonfigurowana tak, aby można było ją ominąć, Firebase Cloud Messaging będzie używać sieci VPN do nawiązywania połączenia z serwerem. Może to powodować okresy opóźnień w dostarczaniu wiadomości i większe zużycie baterii, ponieważ Cloud Messaging musi utrzymywać połączenie przez sieć VPN.

Dane logowania

W zależności od tego, które funkcje FCM chcesz zaimplementować, możesz potrzebować tych danych logowania z Twojego projektu Firebase:

Identyfikator projektu	Unikalny identyfikator Twojego projektu Firebase używany w żądaniach do punktu końcowego HTTP v1 FCM. Ta wartość jest dostępna w konsoli Firebase w panelu Ustawienia.
Token rejestracji	Unikalny ciąg znaków tokena, który identyfikuje każdą instancję aplikacji klienta. Token rejestracji jest wymagany w przypadku wiadomości na pojedynczym urządzeniu i wiadomości grupowych. Pamiętaj, że tokeny rejestracji muszą być utrzymywane w tajemnicy.
Identyfikator nadawcy	Unikalna wartość liczbowa utworzona podczas tworzenia projektu Firebase, dostępna na karcie Cloud Messaging w konsoli Firebase w panelu Ustawienia. Identyfikator nadawcy służy do identyfikacji każdego nadawcy, który może wysyłać wiadomości do aplikacji klienta.
Token dostępu	Krótkotrwały token OAuth 2.0, który autoryzuje żądania do interfejsu API HTTP w wersji 1. Ten token jest powiązany z kontem usługi należącym do Twojego projektu Firebase. Aby utworzyć i zastąpić tokeny dostępu, wykonaj czynności opisane w artykule Autoryzowanie żądań wysyłania.
Klucz serwera (w przypadku wycofanych starszych protokołów)	klucz serwera, który autoryzuje serwer aplikacji do uzyskiwania dostępu do usług Google, w tym do wysyłania wiadomości za pomocą przestarzałych protokołów Firebase Cloud Messaging. Ważne: klucza serwera nie należy umieszczać nigdzie w kodzie klienta. Pamiętaj też, aby autoryzować serwer aplikacji tylko za pomocą kluczy serwera. Klucze Androida, platformy Apple i przeglądarki są odrzucane przez FCM.