Informacje o wiadomościach w FCM

Komunikacja w chmurze Firebase (FCM) oferuje szeroką gamę opcji i funkcji przesyłania wiadomości. Ta strona pomoże Ci zrozumieć różne typy wiadomości w FCM i dowiedzieć się, co możesz z nimi zrobić.

Rodzaje wiadomości

W FCM możesz wysyłać do klientów 2 typy 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ą.

Powiadomienia zawierają wstępnie zdefiniowany zestaw kluczy widocznych dla użytkowników. Komunikaty z danymi zawierają natomiast tylko zdefiniowane przez użytkownika niestandardowe pary klucz-wartość. Wiadomości z powiadomieniami mogą zawierać opcjonalny ładunek danych. Maksymalny ładunek w przypadku obu typów wiadomości to 4096 bajtów. Wyjątkiem jest wysyłanie wiadomości z konsoli Firebase, gdzie obowiązuje limit 1000 znaków.

	Scenariusz korzystania	Jak wysyłać
Powiadomienie	Pakiet FCM SDK wyświetla komunikat na urządzeniach użytkowników 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żytkowników i opcjonalny ładunek danych składający się z 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 klawisz notification. Może mieć opcjonalny ładunek danych. Zawsze zwijana. Zobacz przykłady powiadomień wyświetlania i wyślij ładunki żądań. Użyj edytora powiadomień: wpisz tekst wiadomości, tytuł itp. i wyślij. Dodaj opcjonalny ładunek danych, wpisując dane niestandardowe.
Wiadomość z danymi	Aplikacja kliencka jest odpowiedzialna za przetwarzanie wiadomości z danymi. Wiadomości z danymi mają tylko niestandardowe pary klucz-wartość bez zarezerwowanych 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. W żądaniu wysłania ustaw klucz data.

Jeśli chcesz, by pakiet FCM SDK automatycznie wyświetlał powiadomienia, gdy Twoja aplikacja działa w tle, użyj tych komunikatów. Używaj wiadomości z danymi, jeśli chcesz przetwarzać wiadomości za pomocą własnego kodu aplikacji klienckiej.

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

Powiadomienia

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ą doskonalić i ulepszać przekaz marketingowy.

Aby automatycznie wysyłać powiadomienia z użyciem pakietu Admin SDK lub protokołów FCM, ustaw klucz notification z odpowiednim wstępnie zdefiniowanym zestawem opcji par klucz-wartość dla widocznej dla użytkownika części wiadomości z powiadomieniem. Oto przykładowe powiadomienie w formacie JSON w aplikacji do obsługi czatu. Użytkownik może się spodziewać wiadomości zatytułowanej „Portugalia kontra Dania” z tekstem „świetne dopasowanie!”:

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

Gdy aplikacja działa w tle, powiadomienia są dostarczane do obszaru powiadomień. 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

Ustaw odpowiedni klucz wraz z własnymi parami klucz-wartość, aby wysyłać ładunek danych do aplikacji klienckiej.

Poniżej znajduje się na przykład wiadomość w formacie JSON w tej samej aplikacji do obsługi czatu co powyżej, w której informacje są zawarte we wspólnym kluczu data, a aplikacja kliencka ma interpretować jej treść:

{
  "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 z danymi

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 powiadomieniami z opcjonalnym ładunkiem danych

Zarówno w sposób zautomatyzowany, jak i za pomocą konsoli Firebase możesz wysyłać powiadomienia zawierające opcjonalny ładunek złożony z 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 odbierają ładunek powiadomień w obszarze powiadomień i obsługują go 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 zarówno klucz notification, jak i 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 SDK Firebase Admin i protokół HTTP FCM w wersji 1 umożliwiają ustawianie wszystkich pól dostępnych w obiekcie message w żądaniach wiadomości. Obejmuje to:

• 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 wspólnych pól, 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:

• message.notification.title
• message.notification.body
• message.data

Kiedy używać pól związanych z konkretną platformą

Użyj pól związanych z konkretną platformą, jeśli chcesz:

• Wysyłaj pola tylko do określonych platform
• Wysyłaj pola dotyczące platformy oprócz wspólnych pól.

Jeśli chcesz wysyłać wartości tylko do konkretnych platform, nie używaj wspólnych pól. Używaj pól związanych z daną platformą. 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 witryny.

Jeśli wysyłasz wiadomości z określonymi opcjami dostarczania, skorzystaj z pól na odpowiedniej platformie, aby je skonfigurować. Jeśli chcesz, możesz podać różne wartości na poszczególnych platformach. Nawet wtedy, gdy chcesz ustawić zasadniczo tę samą wartość na różnych platformach, musisz użyć pól dotyczących konkretnej platformy. Jest to spowodowane tym, że każda platforma może nieco inaczej interpretować wartość – na przykład na Androidzie czas życia jest ustawiany jako czas ważności w sekundach, a na Apple – jako datę ważności.

Przykład: powiadomienie z opcjami dostarczania obowiązującymi na danej platformie

Poniższe żądanie wysłania w wersji 1 wysyła wspólny tytuł i treść powiadomienia na wszystkie platformy, ale dodatkowo wysyła niektóre zastąpienia na tych platformach. W szczególności chodzi o:

• ustawia długi czas życia danych w przypadku platform internetowych i Android, a priorytet wiadomości APNs (platformy Apple) zostaje ustawiony 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 na temat kluczy dostępnych w blokach na poziomie platformy znajdziesz w treści wiadomości w dokumentacji referencyjnej 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 przeglądarce. Na przykład funkcja zwijania wiadomości jest obsługiwana w Androidzie przez usługę 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, których nie można zwijać ani zwijać

Wiadomość niezwijana 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 zwijanej wiadomości (np. niezwijanej wiadomości „ping” wysyłanej do aplikacji mobilnej w celu pobrania danych).

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 powinna być dostępna każda 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 będzie ponownie online, 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ść zwijana 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 najnowszym wyniku. Trafna jest tylko najnowsza wiadomość.

Aby oznaczyć wiadomość jako zwijaną na Androidzie, umieść w ładunku wiadomości parametr collapse_key. Domyślnie klucz zwinięcia to nazwa pakietu aplikacji zarejestrowana w konsoli Firebase. Serwer FCM może jednocześnie przechowywać 4 różne wiadomości zwijane na urządzeniu, każdy z innym kluczem zwijania. Jeśli przekroczysz tę liczbę, FCM zachowa tylko 4 klucze zwinięcia i nie będzie mieć gwarancji, które z nich zostaną zachowane.

Wiadomości tematyczne bez ładunku są domyślnie zwijane. Wiadomości z powiadomieniami zawsze można zwijać 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 komunikatów zwijanych, pamiętaj, że FCM zezwala w danym momencie na użycie maksymalnie 4 różnych kluczy zwijania na token rejestracji. Nie możesz przekroczyć tej liczby, ponieważ może to spowodować nieprzewidywalne konsekwencje.

	Scenariusz korzystania	Jak wysyłać
Niezwijana	Każda wiadomość jest ważna dla aplikacji klienckiej i musi zostać dostarczona.	Domyślnie nie można zwijać wszystkich wiadomości (z wyjątkiem powiadomień).
Składane	Gdy pojawia się nowsza wiadomość, która wyświetla starszy, powiązany komunikat nieistotny dla aplikacji klienckiej, FCM zastępuje starszą wiadomość. Na przykład: wiadomości służące do inicjowania synchronizacji danych z serwera lub nieaktualne komunikaty z powiadomieniami.	Ustaw odpowiedni parametr w żądaniu wiadomości: collapseKey na Androidzie apns-collapse-id na urządzeniu Apple Topic w przeglądarce 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ż działanie jest nieco inne w zależności od platformy, dostarczanie zwykłych wiadomości i wiadomości o wysokim priorytecie wygląda tak:

• Normalny priorytet. Komunikaty 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 mniej pilnych wiadomości, np. powiadomień o nowych e-mailach, synchronizowania interfejsu użytkownika lub synchronizowania 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 uśpienia. Wiadomości o wysokim priorytecie są przeznaczone do przesyłania pilnych treści widocznych dla użytkowników.

Oto przykład normalnej wiadomości o priorytecie wysyłanej przez protokół HTTP FCM w wersji 1 w celu powiadomienia 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:

• Dokumentacja APN
• Ustawianie priorytetu wiadomości i zarządzanie nim (Android)
• Pilność związana z wiadomością push w internecie

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ć wysyłanie wiadomości, aby zapobiec zużywaniu przez aplikację nadmiernej ilości zasobów i ograniczaniu czasu 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 zostanie odebrana 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ść. Żądania, które nie zawierają tego pola, są domyślnie ustawione na maksymalny okres 4 tygodni.

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 FCM nie stosuje ograniczania zwijania wiadomości do wiadomości o czasie życia wiadomości o wartości 0 sekund. FCM zapewnia najlepszą obsługę wiadomości, które muszą zostać dostarczone „teraz lub nigdy”. Pamiętaj, że wartość time_to_live o wartości 0 oznacza, że wiadomości, których nie można dostarczyć od razu, są odrzucane. Jednak takie wiadomości nigdy nie są przechowywane, co zapewnia najkrótszy czas oczekiwania przy wysyłaniu powiadomień.

Oto przykład żądania zawierającego wartość 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"
      }
    }
  }
}

Czas trwania 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 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 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 jest w uśpieniu, w FCM jest przechowywana wiadomość o niskim priorytecie do czasu, aż urządzenie nie wróci do trybu uśpienia. Właśnie tu pomaga flaga collapse_key: jeśli istnieje już wiadomość z tym samym kluczem zwinięcia (i tokenem rejestracji) zapisana i oczekująca na dostarczenie, stara wiadomość jest odrzucana i zastępuje nową (tzn. stara wiadomość zostanie zwinięta przez nową). Jeśli jednak nie ustawisz klucza zwijania, zarówno nowe, jak i stare wiadomości będą przechowywane na potrzeby przyszłego dostarczenia.

Jeśli urządzenie nie jest połączone z FCM, wiadomość jest przechowywana do czasu nawiązania połączenia (z uwzględnieniem reguł kluczy zwijania). Po nawiązaniu połączenia FCM dostarcza wszystkie oczekujące wiadomości do urządzenia. 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 wynosi 4 tygodnie, chyba że zostanie ustawiona flaga 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ę wiadomości wysłanych i otwartych 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 z włączoną funkcją czatu bezpośredniego kanału, jeśli urządzenie nie łączy 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 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.

Wreszcie, gdy FCM próbuje przekazać wiadomość na urządzenie, a aplikacja została odinstalowana, od razu odrzuca tę wiadomość i unieważnia token rejestracji. Jeśli w przyszłości spróbujesz wysłać wiadomość na to urządzenie, pojawi się błąd NotRegistered.

Ograniczanie wykorzystania

Naszym celem jest dostarczanie każdej wiadomości wysyłanej 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. Typy limitów opisane w tej sekcji pomagają zrównoważyć te ważne czynniki.

Ograniczanie przesyłania wiadomości

W interfejsie HTTP w wersji 1 wprowadzono limity na minutę przesyłania wiadomości w poszczególnych projektach. Domyślny limit 600 tys. wiadomości na minutę obejmuje ponad 99% deweloperów FCM przy jednoczesnym zapewnieniu stabilności systemu i minimalizacji wpływu 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. W przypadku przeciążenia może też zwrócić 429 odpowiedzi, dlatego zdecydowanie zalecamy obsługę odpowiedzi 429 zgodnie z opublikowanymi zaleceniami.

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 na minutę, ale nie są one zgodne z zegarem.

Limit monitorowania

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

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

UWAGA: te wykresy nie są ściśle dostosowane w czasie do limitu minut, co oznacza, że w przypadku ruchu poniżej limitu można wyświetlać 429 sekund.

Prośba o zwiększenie limitu

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

• Twoje wykorzystanie regularnie przekracza ≥80% limitu przez co najmniej 5 kolejnych minut dziennie.
• Współczynnik błędów klienta wynosi mniej niż 5%, zwłaszcza podczas szczytowego ruchu.
• Przestrzegasz sprawdzonych metod 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 zrealizować 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 usługi i żądania zdarzeń specjalnych nadal zależą od współczynnika błędów klienta i wymagań dotyczących sprawdzonych metod.

Przeczytaj też najczęstsze pytania na temat limitów FCM.

Limit wiadomości w temacie

Częstotliwość dodawania i usuwania subskrypcji tematów jest ograniczona do 3000 zapytań na sekundę na projekt.

Informacje o częstotliwości wysyłania wiadomości znajdziesz w sekcji Ograniczanie liczby wyświetleń przez fanów.

Ograniczanie zwielokrotniania

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 lub je opóźnić do momentu zakończenia niektórych aktualnie rozpowszechnionych próśb.

Rzeczywista liczba zwielokrotnienia, które można osiągnąć, zależy od liczby projektów, które proszą o to w tym samym czasie. 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, aby zmniejszyć zużycie baterii.

Jeśli na przykład wysyłasz dużą liczbę nowych żądań synchronizacji poczty e-mail na jedno urządzenie, możemy opóźnić następną prośbę o synchronizację o kilka minut, aby urządzenie mogło przeprowadzać synchronizację 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ąć. Pamiętaj, aby umieścić takie wiadomości w swoich treściach, aby obniżyć koszty baterii.

Ograniczamy możliwość zwijania wiadomości do 20 wiadomości na aplikację na urządzenie, przy czym 1 wiadomość pojawia się ponownie 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 utrudniać dostarczania wiadomości, ale jest ważne dla zapewnienia stabilności systemu. W każdym projekcie FCM dopuszcza 2500 równoległych połączeń.

W przypadku przesyłania wiadomości z serwera XMPP FCM ogranicza liczbę komunikatów nadrzędnych do 1 500 000 na minutę, aby uniknąć przeciążenia wcześniejszych 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ść przesyłania wiadomości na 1 urządzenie

W przypadku Androida można wysyłać do 240 wiadomości na minutę i 5000 wiadomości na godzinę na jedno urządzenie. Ten wysoki próg ma umożliwić krótkotrwałe skoki ruchu, np. gdy użytkownicy szybko wchodzą w interakcję z użytkownikiem na czacie. Ten limit zapobiega przypadkowym rozładowywaniem baterii urządzenia przez błędy podczas wysyłania elementów logicznych.

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

Porty FCM i zapora sieciowa

Jeśli w Twojej organizacji jest zapora sieciowa, która ogranicza ruch do i z internetu, musisz skonfigurować ją tak, aby zezwalała urządzeniom mobilnym na łączenie się z FCM. Dzięki temu urządzenia będą mogły odbierać wiadomości. FCM zwykle używa portu 5228, ale czasami używa portu 443, 5229 i 5230.

W przypadku urządzeń łączących się z Twoją siecią FCM nie podaje konkretnych adresów IP, ponieważ zakres adresów IP zmienia się zbyt często i reguły zapory sieciowej mogą zostać nieaktualne, co wpływa na wrażenia użytkowników. Najlepiej dodać do listy dozwolonych porty 5228-5230 i 443 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 długa lista jest regularnie aktualizowana, więc 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 znajdziesz poniżej. Gdy zaczniemy używać dodatkowych nazw hosta, zaktualizujemy listę tutaj. 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

Zapory sieciowe usługi translacji adresów sieciowych lub stanowej inspekcji pakietów:

Jeśli w Twojej sieci działa translacja adresów sieciowych (NAT) lub stanowa inspekcja pakietów (SPI), zastosuj co najmniej 30-minutowy limit czasu połączeń przez porty 5228–5230. Dzięki temu możemy zapewniać niezawodne połączenia, zmniejszając zużycie baterii przez urządzenia mobilne użytkowników.

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

Komunikacja w chmurze Firebase (FCM) podejmuje różne działania, aby zapewnić niezawodność i częstotliwość przesyłania komunikatów push z telefonu do serwera. Korzystanie z sieci VPN komplikuje te działania.

Sieci VPN maskują podstawowe informacje, które są niezbędne do dostrojenia połączenia przez FCM w celu zmaksymalizowania niezawodności i żywotności baterii. W niektórych przypadkach sieci VPN aktywnie przerywają długotrwałe połączenia, co pogarsza komfort użytkowników z powodu brakujących lub opóźnionych wiadomości albo wysoki koszt baterii. Jeśli konfiguracja VPN na to pozwala, pomijamy ją za pomocą szyfrowanego połączenia (przez sieć Wi-Fi lub LTE), aby zapewnić niezawodne działanie i baterię. Korzystanie w 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ą, używa sieci VPN, jeśli jest aktywna. Gdy połączenie FCM omija sieć VPN, traci dostęp do dodatkowych korzyści, jakie może zapewnić sieć VPN, takich jak maskowanie adresów 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 do pomijania, Komunikacja w chmurze Firebase używa jej do łączenia się z serwerem. Z tego powodu wiadomości mogą być opóźnione i powodować większe wykorzystanie baterii, ponieważ usługa Komunikacja w chmurze utrzymuje połączenie przez sieć VPN.

Dane uwierzytelniające

W zależności od tego, jakie funkcje FCM wdrożysz, możesz potrzebować tych danych logowania z projektu Firebase:

Identyfikator projektu	Unikalny identyfikator projektu Firebase używany w żądaniach wysyłanych do punktu końcowego HTTP FCM w wersji 1. Ta wartość jest dostępna w panelu Ustawienia konsoli Firebase.
Token rejestracji	Unikalny ciąg tokena, który identyfikuje każdą instancję aplikacji klienckiej. Token rejestracji jest wymagany do przesyłania wiadomości z pojedynczych urządzeń i grup urządzeń. Pamiętaj, że tokeny rejestracji muszą być przechowywane w tajemnicy.
Identyfikator nadawcy	Unikalna wartość liczbowa tworzona podczas tworzenia projektu Firebase. Jest dostępna na karcie Komunikacja w chmurze w panelu Ustawienia w 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 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 wykonać rotację tokenów dostępu, wykonaj czynności opisane w artykule Autoryzacja wysyłania żądań.
Klucz serwera (na potrzeby **wycofanych** starszych protokołów)	Klucz serwera, który autoryzuje serwer aplikacji dostęp do usług Google, w tym do wysyłania wiadomości za pomocą wycofanych starszych protokołów Firebase Cloud Messaging. Ważne: nie umieszczaj klucza serwera nigdzie w kodzie klienta. Pamiętaj też, aby autoryzować serwer aplikacji tylko za pomocą kluczy serwera. Klucze Androida, platformy Apple oraz przeglądarki są odrzucane przez FCM.