Save the date for Firebase Demo Day 2024. Learn how to build and run modern, AI-powered apps users love. Learn more.

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 funkcji związanych z wiadomościami. Informacje na tej stronie pomogą Ci zrozumieć różne typy wiadomości FCM i dowiedzieć się, co możesz z nimi zrobić.

Rodzaje wiadomości

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

Powiadomienia, czasami nazywane „wiadomościami wyświetlanymi”. Są one obsługiwane przez pakiet SDK FCM automatycznie.
Komunikaty z danymi 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 wiadomości są wysyłane z konsoli Firebase, która narzuca limit 1000 znaków.

	Przypadek użycia	Jak wysył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. W przeciwnym razie, gdy po otrzymaniu powiadomienia aplikacja działa na pierwszym planie, o działaniu decyduje jej kod. Wiadomości z powiadomieniami mają wstępnie zdefiniowany zestaw kluczy widocznych dla użytkownika oraz opcjonalny ładunek danych w postaci niestandardowych par klucz-wartość.	W zaufanym środowisku, takim jak Cloud Functions lub serwer aplikacji, użyj pakietu Admin SDK lub interfejsu API HTTP w wersji 1. Ustaw klucz `notification`. Może zawierać opcjonalny ładunek danych. zawsze można je zwinąć. Zobacz przykłady powiadomień wyświetlania i wyślij ładunki żą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 kliencka jest odpowiedzialna za przetwarzanie wiadomości z danymi. 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, jeśli chcesz przetwarzać wiadomości za pomocą własnego kodu aplikacji klienckiej.

FCM może wysyłać powiadomienia z opcjonalnym ładunkiem danych. W takich przypadkach FCM wyświetla ładunek powiadomień, a aplikacja kliencka obsługuje ładunek danych.

Wiadomości z powiadomieniami

Na potrzeby testów, marketingu i ponownego zaangażowania użytkowników możesz wysyłać wiadomości z powiadomieniami za pomocą konsoli Firebase. Konsola Firebase udostępnia oparte na analityce testy A/B, które pomagają doprecyzować i ulepszać 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 wiadomość z powiadomieniem w aplikacji do obsługi wiadomości błyskawicznych zapisana 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ę wstępnie zdefiniowanych kluczy dostępnych w przypadku komunikatów z powiadomieniami o tworzeniu znajdziesz w dokumentacji referencyjnej obiektu powiadomień protokołu HTTP w wersji 1.

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 przedstawia wykorzystanie wspólnego pola data najwyższego poziomu, które jest interpretowane przez klienty na wszystkich platformach, które odbierają wiadomość. Na każdej platformie aplikacja kliencka odbiera ładunek danych w funkcji wywołania zwrotnego.

Szyfrowanie wiadomości danych

Warstwa transportu w Androidzie (zobacz architekturę FCM) używa szyfrowania typu punkt-punkt. W zależności od swoich potrzeb możesz zdecydować się na pełne szyfrowanie wiadomości z danymi. 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,

Zarówno automatycznie, jak i za pomocą konsoli Firebase możesz wysyłać powiadomienia z opcjonalnym ładunkiem niestandardowych par klucz-wartość. W Kreatorze powiadomień użyj pól Dane niestandardowe w Opcjach zaawansowanych.

Zachowanie aplikacji w przypadku odbierania wiadomości zawierających 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 odbierania.

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

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

Protokół HTTP Firebase Admin SDK i FCM w wersji 1 umożliwiają Twoim żądaniom wiadomości ustawianie wszystkich pól dostępnych w obiekcie message. Obejmuje to m.in.:

wspólny zestaw pól do interpretowania przez wszystkie instancje aplikacji, które otrzymają wiadomość.
zbiorów pól związanych z konkretną platformą, takich jak AndroidConfig i WebpushConfig, interpretowane tylko przez instancje aplikacji działające na określonej platformie.

Blokady związane z konkretnymi platformami umożliwiają dostosowywanie wiadomości do różnych platform, dzięki czemu są one przetwarzane poprawnie po otrzymaniu. Backend FCM bierze pod uwagę wszystkie określone parametry i dostosowuje wiadomość dla każdej platformy.

Kiedy używać wspólnych pól

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

kierowanie na instancje aplikacji na wszystkich platformach – Apple, Android i sieć.
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 konkretną platformą

Użyj pól związanych z konkretną platformą, 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 np. wysłać powiadomienie tylko na platformy Apple i w przeglądarce, ale nie na Androida, musisz użyć 2 osobnych zbiorów pól – jednego dla Apple i drugiego dla internetu.

Jeśli wysyłasz wiadomości z określonymi opcjami dostarczania, użyj pól określonych dla danej platformy, aby je ustawić. Jeśli chcesz, możesz podać różne wartości na poszczególnych platformach. 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 chodzi o:

ustawia długi czas istnienia dla platform Android i internetowych, a priorytet wiadomości APN (platformy Apple) ustawia na niski;
ustawia odpowiednie klawisze do określenia wyniku kliknięcia powiadomienia na urządzeniu z Androidem i urządzenia 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 związanych z konkretną platformą w ciele wiadomości znajdziesz w dokumentacji HTTP w wersji 1. Więcej informacji o tworzeniu żądań wysyłania zawierających treść wiadomości znajdziesz w artykule o tworzeniu żądań wysyłania.

Opcje dostawy

FCM udostępnia określony zestaw opcji dostarczania wiadomości wysyłanych na urządzenia z Androidem oraz podobne opcje na platformach Apple i w internecie. Na przykład funkcja zwijania wiadomości jest obsługiwana na Androidzie przez platformę collapse_key FCM, na Apple przez apns-collapse-id oraz w języku JavaScript/internetowym przez Topic. Szczegółowe informacje znajdują się w opisach w tej sekcji i w odpowiedniej dokumentacji.

Wiadomości niezwijane i zwijane

Wiadomość niezałamowana oznacza, że każda wiadomość jest dostarczana do urządzenia. Wiadomość, której nie można zwinąć, zawiera przydatne treści, w przeciwieństwie do wiadomości, której nie można zwinąć, np. „ping” bez treści, aby aplikacja mobilna mogła skontaktować się z serwerem i pobrać dane.

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 czatu chcesz dostarczać każdą wiadomość, ponieważ każda wiadomość ma inną treść.

Na Androidzie obowiązuje limit 100 wiadomości, które można przechowywać bez zwijania. Po osiągnięciu limitu wszystkie zapisane wiadomości zostają odrzucone. Gdy urządzenie znowu połączy się z internetem, otrzyma specjalny komunikat o osiągnięciu limitu. Aplikacja może wtedy prawidłowo obsłużyć sytuację, zwykle wysyłając do serwera aplikacji żądanie pełnej synchronizacji.

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.

Wiadomości zwijane często są wykorzystywane do tego, by aplikacja mobilna synchronizowała dane z serwerem. Przykładem może być aplikacja sportowa, która informuje użytkowników o najnowszych wynikach. Trafna jest tylko najnowsza wiadomość.

Aby oznaczyć wiadomość jako składaną na urządzeniu z Androidem, dodaj parametr collapse_key do treści wiadomości. Domyślnie klucz zwinięcia 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 zwinięcia, 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 z nich mam użyć?

Zwijane wiadomości to lepszy wybór z punktu widzenia wydajności, o ile aplikacja nie musi używać wiadomości niezwijanych. 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.

	Scenariusz korzystania	Jak wysłać
Niezwijana	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.
Składane	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 żądaniu wiadomości: `collapseKey` na Androidzie `apns-collapse-id` na urządzeniu Apple `Topic` w internecie `collapse_key` w starszych protokołach (wszystkie platformy)

Ustawianie priorytetu wiadomości

Priorytet dostarczania możesz przypisać do kolejnych wiadomości na 2 sposoby: normalny i wysoki. 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 dostarczenie może być opóźnione. 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. Wiadomości o wysokim priorytecie są przeznaczone do przesyłania pilnych treści widocznych dla użytkowników.

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

Oto przykład wiadomości o normalnym priorytecie wysłanej za pomocą protokołu FCM HTTP 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 na poziomie platformy:

Przypadki użycia o znaczeniu krytycznym

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 zaprzestania ich działania, ich części lub funkcji bądź dostępu do nich, z dowolnego powodu i w dowolnym momencie, bez ponoszenia odpowiedzialności i innych zobowiązań wobec Państwa lub 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 platformą jest Android, urządzenie może być wyłączone, offline lub z innego powodu niedostępne. FCM może też celowo opóźniać komunikaty, aby zapobiec zużywaniu przez aplikację nadmiernych zasobów i niekorzystnie wpływać na czas pracy na baterii.

W takim przypadku FCM zapisuje wiadomość i dostarcza ją tak szybko, jak to możliwe. W większości przypadków jest to dobre rozwiązanie, ale w przypadku niektórych aplikacji opóźniona wiadomość może nie zostać dostarczona. Jeśli na przykład wiadomość stanowi połączenie przychodzące lub powiadomienie na czacie wideo, jest ona ważna tylko przez krótki czas, zanim połączenie zostanie zakończone. Jeśli wiadomość jest zaproszeniem na wydarzenie, jest bezużyteczna, jeśli została dostarczona po zakończeniu wydarzenia.

Na urządzeniach z Androidem i w przeglądarkach internetowych/JavaScript możesz określić maksymalny czas życia wiadomości. Wartość musi mieć czas trwania z zakresu od 0 do 2 419 200 sekund (28 dni) i odpowiada maksymalnym okresowi, przez jaki 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
Wygasające wydarzenia zaproszeń
Wydarzenia w kalendarzu

Inną zaletą określania okresu życia wiadomości jest to, że funkcja FCM nie stosuje ograniczania zwijania wiadomości do wiadomości o czasie życia danych równym 0 sekund. FCM zapewnia 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. Wskazuje natomiast, że produkt został zaakceptowany do dostawy. To, co stanie się z wiadomością po jej zaakceptowaniu, zależy od wielu czynników.

W najlepszym przypadku, jeśli urządzenie jest połączone z siecią FCM, ekran jest włączony i nie ma żadnych ograniczeń ograniczania przepustowości, wiadomość jest dostarczana 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 nie ustawisz klucza collapse, zarówno nowe, jak i stare wiadomości zostaną zapisane 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 nie zostanie ponownie połączone (na przykład jeśli zostało przywrócone do ustawień fabrycznych), wiadomość w końcu wygaśnie i zostanie usunięta z pamięci FCM. Domyślny limit czasu to 4 tygodnie, chyba że ustawiono flagę time_to_live.

Aby uzyskać szczegółowe informacje o dostarczaniu wiadomości:

Więcej informacji o dostarczaniu wiadomości na platformach Android i Apple znajdziesz w panelu raportowania FCM, który rejestruje liczbę wysłanych i otwartych wiadomości na urządzeniach Apple i z Androidem oraz dane na temat wyświetleń (powiadomień widocznych dla użytkowników) w aplikacjach na Androida.

W przypadku urządzeń z Androidem, na których jest włączona funkcja czatu, jeśli urządzenie nie łączy się z siecią FCM przez ponad miesiąc, FCM nadal akceptuje wiadomość, ale natychmiast ją odrzuca. Jeśli urządzenie połączy się w ciągu 4 tygodni od ostatniej wysłanej do niego wiadomości dotyczącej danych, klient otrzyma wywołanie zwrotne onRemoveMessages(). Aplikacja może wtedy prawidłowo obsłużyć sytuację, zwykle wysyłając do serwera aplikacji żądanie pełnej synchronizacji.

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. Pamiętaj jednak, że przesłanie wszystkich wiadomości może negatywnie wpłynąć na ogólne wrażenia użytkowników. W innych przypadkach musimy określić granice, aby mieć pewność, że FCM oferuje skalowalną usługę 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ślny limit 600 tys. wiadomości na minutę obejmuje ponad 99% deweloperów FCM, chroniąc stabilność systemu i minimalizując wpływ gwałtownych projektów.

Nagłe wzorce ruchu mogą powodować błędy związane z przekroczeniem limitu. W scenariuszu przekroczenia limitu system wyświetla kod stanu HTTP 429 (QUOTA_EXCEEDED), aż limit zostanie wypełniony w następnej minucie. Odpowiedzi 429 mogą być też zwracane w sytuacjach przeciążenia, dlatego zdecydowanie zalecamy obsługę odpowiedzi 429 zgodnie z opublikowanymi rekomendacjami.

Uwaga:

Limit pobierania danych mierzy liczbę wiadomości, a nie żądań.
Zliczane są błędy klienta (kod stanu HTTP 400–499) (z wy��ączeniem błędów 429).
Limity są podawane w minutach, ale nie są one dopasowywane do czasu zegara.

Limit monitorowania

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

Otwórz konsolę Google Cloud
Wybierz Interfejsy API i usługi.
Z listy tabel wybierz Firebase Cloud Messaging API.
Wybierz LIMITY I OGRANICZENIA SYSTEMOWE.

UWAGA: te wykresy nie są ściśle dostosowane w czasie do limitu minut, co oznacza, że 429 s mogą być wyświetlane, gdy ruch wydaje się poniżej limitu.

Prośba o zwiększenie limitu

Zanim poprosisz o zwiększenie limitu, sprawdź, czy:

regularnie wykorzystujesz co najmniej 80% limitu przez co najmniej 5 minut dziennie;
Współczynnik błędów klienta wynosi mniej niż 5%, zwłaszcza podczas szczytowego 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 o ponad 25%, a FCM dołoży wszelkich starań, aby spełnić tę prośbę (nie możemy zagwarantować zwiększenia limitu).

Jeśli ze względu na zbliżające się uruchomienie lub tymczasowe zdarzenie potrzebujesz większego limitu na przesyłanie wiadomości, poproś o zwiększenie limitu co najmniej 15 dni wcześniej, aby dać Ci wystarczająco dużo czasu na obsługę tej prośby. W przypadku dużych żądań (ponad 18 mln wiadomości na minutę) wymagane jest powiadomienie z co najmniej 30-dniowym wyprzedzeniem. Uruchomienia aplikacji i żądania zdarzeń specjalnych nadal zależą od współczynnika błędów klienta i wymagań dotyczących 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 sekcji Ograniczanie liczby wyświetleń przez fanów.

Ograniczanie wyjścia

Rozpowszechnianie wiadomości to proces wysyłania wiadomości na wiele urządzeń, np. podczas kierowania na tematy i grupy lub gdy używasz kompozytora powiadomień do kierowania reklam na odbiorców lub segmenty użytkowników.

Rozpowszechnianie wiadomości nie jest natychmiastowe, więc czasami trwa kilka równoczesnych rozgłosów. Ograniczamy liczbę równoczesnych fanoutów 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 rozprzestrzeniania, które już się rozpoczęło.

Na rzeczywistą osiągalną szybkość rozgałęzienia wpływa liczba projektów, które jednocześnie proszą o rozgałęzienia. Współczynnik zwielokrotnienia 10 tys. zapytań/s w przypadku pojedynczego projektu nie jest niczym niezwykłym, ale ta liczba nie jest gwarantowana i jest wynikiem całkowitego obciążenia systemu. Warto zauważyć, że dostępna pojemność rozpowszechniania jest dzielona między projekty, a nie między żądaniami rozpowszechniania. Jeśli więc w Twoim projekcie trwają dwa zwielokrotnienia, każdy z nich zobaczy tylko połowę dostępnych wartości. Zalecanym sposobem na zmaksymalizowanie szybkości wczytywania jest używanie tylko jednego aktywnego zwielokrotnienia w tym samym czasie.

Ograniczanie rozmiaru wiadomości zwijanych

Jak opisano powyżej, zwijane wiadomości to powiadomienia bez treści, które zwijają się na siebie. Jeśli deweloper zbyt często powtarza tę samą wiadomość w aplikacji, opóźniamy ich wysyłanie, by zmniejszyć zużycie baterii.

Jeśli na przykład wysyłasz na jedno urządzenie dużą liczbę nowych żądań synchronizacji e-maili, możemy opóźnić wysłanie kolejnego żądania synchronizacji e-maili o kilka minut, aby urządzenie mogło synchronizować się z niższą średnią szybkością. Ma to na celu wyłącznie ograniczenie wywierania wpływu na baterię.

Jeśli Twój przypadek użycia wymaga częstych wzorców wysyłania serii, dobrym rozwiązaniem mogą być wiadomości, których nie można zwinąć. 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 wykorzystania serwera XMPP

Ograniczenie szybkości, z jaką możesz łączyć 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.

W celu ochrony baterii przed wyczerpaniem się baterii w związku z niewłaściwym działaniem aplikacji ograniczamy liczbę wysyłanych wiadomości na urządzenie do 1000 na minutę.

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. Ten 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ą przypadkowo rozładować baterię urządzenia.

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

FCM porty 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ę w Twojej sieci FCM nie podaje konkretnych adresów IP, ponieważ nasz zakres adresów IP zbyt często się zmienia i reguły zapory sieciowej mogą stać się nieaktualne, co wpłynie na komfort użytkowników. W idealnej sytuacji porty 5228–5230 i 443 powinny być dozwolone bez ograniczeń adresów IP. Jeśli jednak konieczne jest stosowanie ograniczenia 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 przez ograniczenia adresów IP zapory sieciowej często mają charakter przejściowy i trudne do zdiagnozowania.

Oferujemy zestaw nazw domen, które zamiast adresów IP można umieścić na liście dozwolonych. Nazwy hostów podano poniżej. Jeśli zaczniemy używać dodatkowych nazw hostów, zaktualizujemy tę listę. Używanie nazw domen w regule zapory sieciowej może, ale nie musi, działać w zaporze sieciowej.

Porty TCP do otworzenia:

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 urządzeń mobilnych użytkowników.

Interakcje z siecią VPN i możliwość pomijania

Firebase Cloud Messaging podejmuje różne działania, aby mieć pewność, że połączenie wiadomości push z telefonu do serwera jest niezawodne i dostępne tak często, jak to możliwe. Korzystanie z sieci VPN komplikuje ten proces.

Sieci VPN maskują podstawowe informacje, których FCM musi dostroić swoje połączenie w celu zmaksymalizowania niezawodności i żywotności 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 VPN, używając szyfrowanego połączenia (przez sieć podstawową Wi-Fi lub LTE), aby zapewnić niezawodność i oszczędność baterii. Korzystanie przez FCM z sieci VPN z możliwością pominięcia zależy od kanału powiadomień push FCM. 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 zalety, jakie zapewnia VPN, takie jak maskowanie adresu IP.

Różne sieci VPN mają różne metody określania, czy można je omijać. 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 stara się utrzymać 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 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 tokena, który identyfikuje każdą instancję aplikacji klienckiej. 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 tworzona podczas tworzenia projektu Firebase. Jest dostępna na karcie Cloud Messaging panelu Ustawienia w konsoli Firebase. 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 wysyłane do interfejsu API HTTP w wersji 1. Ten token jest powiązany z kontem usługi, które należy do Twojego projektu Firebase. Aby utworzyć i rotować tokeny dostępu, wykonaj czynności opisane w artykule Autoryzowanie żądań wysyłania.
Klucz serwera (na potrzeby wycofanych starszych protokołów)	Klucz serwera, który upoważnia serwer aplikacji do uzyskiwania dostępu do usług Google, w tym do wysyłania wiadomości za pomocą wycofanych starszych protokołów Firebase Cloud Messaging. Ważne: klucza serwera nie należy umieszczać w żadnym miejscu kodu klienta. Pamiętaj też, aby autoryzować serwer aplikacji tylko za pomocą kluczy serwera. Klucze Androida, platformy Apple i przeglądarki są odrzucane przez FCM.