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ść. |
|
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 z opcjonalnym ładunkiem 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 programowo wysyłać powiadomienia 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 powiadomienia. Oto na przykład wiadomość z powiadomieniem w formacie JSON w aplikacji do przesyłania wiadomości błyskawicznych. 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 obsługi wiadomości błyskawicznych, w której informacje są zaszyfrowane w kluczu wspólnym 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 kliencka otrzymuje dane ładunku 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ć powiadomienia programowo lub za pomocą konsoli Firebase. Wiadomości te mogą zawierać opcjonalny ładunek 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
iWebpushConfig
, 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ądarek, ale nie na urządzenia z Androidem, musisz użyć 2 oddzielnych zestawów pól: jednego dla Apple i drugiego dla przeglądarek.
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 konkretnej platformie
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 życia dla platform Android i internetowych, a priorytet wiadomości APN (platformy Apple) na niski.
- ustawia odpowiednie klucze, aby zdefiniować wynik kliknięcia powiadomienia przez użytkownika na urządzeniach z Androidem i Apple – odpowiednio
click_action
icategory
.
{ "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
Niezwijana wiadomość 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 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ść:
|
Ustawianie priorytetu wiadomości
Masz 2 opcje przypisywania priorytetu dostawy wiadomościom przesył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.
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:
- Dokumentacja APNs
- Ustawianie priorytetu wiadomości i zarządzanie nim (Android)
- Poziom pilności wiadomości ze stron internetowych
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
- Wygasające zaproszenia
- 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 ograniczeń w obrębie usługi, wiadomość zostanie dostarczona natychmiast.
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 jest już wiadomość z tym samym kluczem zwinięcia (i tokenem rejestracji) przechowywana i oczekująca na dostarczenie, stara wiadomość zostaje odrzucona, a nowa zajmuje jej miejsce (czyli stara wiadomość zostaje zwinięta przez nową). Jeśli jednak klucz collapse nie jest ustawiony, zarówno nowe, jak i stare wiadomości są przechowywane na potrzeby przyszłej wysyłki.
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 przesył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 ostatniej wiadomości danych, 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 za pomocą FCM. Jednak przesyłanie 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ół określa liczbę wiadomości, a nie żądań.
- Błędy klienta (kod stanu HTTP 400–499) są zliczane (z wyjątkiem kodu 429).
- Limity są ustalane na minuty, ale nie są one dopasowywane do 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. W przypadku żądań dotyczących premier i specjalnych wydarzeń nadal obowiązują wymagania dotyczące 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 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. Częstotliwość rozgałęzienia 10 tys. QPS w przypadku pojedynczego projektu nie jest rzadkością, ale nie jest to wartość 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ć wysł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 1 wiadomości 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 dotyczącymi adresów IP w zaporze sieciowej 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 urządzeń 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 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 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 nigdzie umieszczać 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. |