Firebase Cloud Messaging (FCM) oferuje szeroki zakres opcji komunikacji i jej możliwości. Informacje na tej stronie mają na celu pomogą Ci zrozumieć różne typy wiadomości w usłudze FCM i dowiedzieć się, co z nimi można zrobić.
Rodzaje wiadomości
FCM umożliwia wysyłanie do klientów 2 typów 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 zdefiniowaną przez użytkownika niestandardową parę klucz-wartość. pary. Powiadomienia mogą zawierać opcjonalne elementy ładunek danych. Maksymalny ładunek dla obu typów wiadomości to 4096 bajtów. Wyjątkiem wysyłanie wiadomości za pomocą konsoli Firebase, co wymusza użycie 1000 znaków .
Scenariusz korzystania | Jak wysyłać | |
---|---|---|
Powiadomienie | Pakiet SDK FCM wyświetla wiadomość na urządzeniach użytkowników w imieniu aplikacji klienta, gdy działa ona w tle. W przeciwnym razie, jeśli aplikacja działa na pierwszym planie, gdy kod aplikacji określa działanie. Wiadomości z powiadomieniami mają wstępnie zdefiniowany zestaw kluczy widocznych dla użytkowników oraz opcjonalny ładunek danych niestandardowych par klucz-wartość. |
|
Wiadomość z danymi | Aplikacja kliencka jest odpowiedzialna za przetwarzanie wiadomości z danymi. Komunikaty dotyczące danych mają tylko niestandardowe pary klucz-wartość bez zarezerwowanych nazw kluczy (patrz poniżej). | w zaufanym środowisku, takim jak .
Cloud Functions
lub serwera aplikacji, użyj funkcji
Pakiet Admin SDK
Protokoły serwera FCM. W żądaniu wysłania ustaw data
.
|
Używaj komunikatów z powiadomieniami, gdy pakiet FCM SDK ma obsługiwać wyświetlanie automatyczne powiadomienie, 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 wysłać powiadomienie wraz z opcjonalnymi danymi ładunek. W takich przypadkach FCM obsługuje wyświetlanie powiadomienia a aplikacja kliencka – za jego pomocą.
Powiadomienia
Do testów lub marketingu i ponownego angażowania użytkowników możesz wysłać w konsoli Firebase. Konsola Firebase udostępnia funkcje analityczne Testy A/B, które pomagają ulepszać ulepszania komunikatów marketingowych.
Aby automatycznie wysyłać powiadomienia za pomocą pakietu Admin SDK lub
FCM, ustaw klucz notification
z parametrem
niezbędnego wstępnie zdefiniowanego zestawu opcji par klucz-wartość dla
częścią wiadomości z powiadomieniem. Oto przykładowy plik w formacie JSON
w aplikacji do obsługi czatu. Użytkownik może spodziewać się wyświetlenia
wiadomość o tytule „Portugalia kontra Dania” oraz tekst
"świetne dopasowanie!" na urządzeniu:
{ "message":{ "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...", "notification":{ "title":"Portugal vs. Denmark", "body":"great match!" } } }
Gdy aplikacja jest dostarczana do obszaru powiadomień, Aplikacja znajduje się w tle. W przypadku aplikacji na pierwszym planie wiadomości są obsługiwane przez funkcję wywołania zwrotnego.
Zobacz obiekt powiadomień protokołu HTTP w wersji 1. dokumentacja dla pełnej listy wstępnie zdefiniowanych kluczy dostępnych na potrzeby powiadomień o budynku wiadomości.
Komunikaty dotyczące danych
Ustaw właściwy klucz z niestandardowymi parami klucz-wartość na wysyłania ładunku danych do aplikacji klienckiej.
Oto przykład:
wiadomości w formacie JSON w tej samej aplikacji do obsługi czatu co powyżej,
gdzie informacje są zawarte we wspólnym kluczu data
i
aplikacja kliencka ma interpretować treści:
{ "message":{ "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...", "data":{ "Nick" : "Mario", "body" : "great match!", "Room" : "PortugalVSDenmark" } } }
Powyższy przykład przedstawia wykorzystanie wspólnego, najwyższego poziomu pola data
,
interpretowane przez klientów korzystających z różnych platform, które otrzymują wiadomość.
Na każdej platformie aplikacja kliencka otrzymuje ładunek danych
w funkcji wywołania zwrotnego.
Szyfrowanie wiadomości z danymi
Warstwa transportu w Androidzie (zobacz architekturę FCM) wykorzystuje szyfrowanie punkt-punkt. W zależności od 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, jako Capillary lub DTLS
Wiadomości z powiadomieniami z opcjonalnym ładunkiem danych
Powiadomienia możesz wysyłać automatycznie lub za pomocą konsoli Firebase. wiadomości zawierające opcjonalny ładunek złożony z niestandardowych par klucz-wartość. W twórcy powiadomień, użyj pól Dane niestandardowe w Opcje zaawansowane.
Zachowanie aplikacji podczas odbierania wiadomości zawierających zarówno powiadomienia, jak i dane zależy od tego, czy aplikacja działa w tle, czy na pierwszym planie – niezależnie od tego, czy jest aktywny w momencie rachunek.
- Kiedy w tle, aplikacje otrzymują ładunek powiadomień w polu w obszarze powiadomień i obsługuje ładunek danych tylko wtedy, gdy użytkownik kliknij powiadomienie.
- Gdy działa na pierwszym planie, aplikacja odbiera wiadomość. z dostępnymi ładunkami.
Oto wiadomość w formacie JSON zawierająca
Klucz notification
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
Zarówno protokół HTTP Firebase Admin SDK, jak i protokoły HTTP FCM w wersji 1 zezwalają na przesyłanie wiadomości
prosi o ustawienie wszystkich pól dostępnych
message
.
obiektu. Obejmuje to:
- wspólny zestaw pól do interpretowania przez wszystkie instancje aplikacji, które odebranie wiadomości.
- zestawy pól właściwych dla danej platformy, np.
AndroidConfig
iWebpushConfig
, interpretowane tylko przez instancje aplikacji działające na określonej platformie.
Blokady związane z określoną platformą zapewniają elastyczność w dostosowywaniu komunikatów z różnych platform, aby mieć pewność, że po otrzymaniu pliku będą obsługiwane poprawnie. Backend FCM bierze pod uwagę wszystkie określone parametry i dostosowuje parametr na każdą platformę.
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:
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ólne pola; korzystać z pól związanych z daną platformą. Aby na przykład wysłać powiadomienie, tylko na platformy Apple i internet, ale nie na Androida, musisz użyć dwóch osobnych zbiorów 1 dla Apple, a drugi dla sieci.
Gdy wysyłasz wiadomości z określonymi opcji dostawy, ustaw je za pomocą pól powiązanych z konkretną platformą. Możesz określić różne wartości na każdą platformę, jeśli w dowolnym momencie. Jednak nawet wtedy, gdy chcesz ustawić zasadniczo tę samą wartość musisz użyć pól dotyczących konkretnej platformy. To dlatego, że każda platforma może zinterpretować wartość nieco inaczej – np. czas życia danych to ustawiany na Androidzie jako czas ważności w sekundach, a na Apple data ważności.
Przykład: powiadomienie z opcjami dostarczania obowiązującymi na danej platformie
Poniższe żądanie wysłania w wersji 1 powoduje wysłanie wspólnego tytułu powiadomienia oraz na wszystkie platformy, ale wysyła też niektóre zastąpienia na poszczególnych 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
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" } } } }
Zobacz dokumentację HTTP v1. aby uzyskać szczegółowe informacje o kluczach dostępnych w blokad w treści wiadomości. Więcej informacji na temat: wysyłanie żądań wysyłania zawierających treść wiadomości, zobacz Tworzenie żądań wysyłania.
Opcje dostawy
FCM udostępnia określony zestaw opcji dostarczania wiadomości wysyłanych do
urządzeń z Androidem i umożliwia korzystanie z podobnych opcji
Platformy i internet Apple. Na przykład „zwijane” zachowanie wiadomości jest obsługiwane na
Android za pośrednictwem urządzenia collapse_key
użytkownika FCM, na urządzeniu Apple za pośrednictwem
apns-collapse-id
i JavaScript/Web (za pomocą Topic
). Więcej informacji:
opisów dostępnych w tej sekcji i odpowiedniej dokumentacji.
Wiadomości, których nie można zwijać ani zwijać
Wiadomość niezwijana oznacza, że każda wiadomość dostarczonych na urządzenie. Niezwijana wiadomość zawiera przydatne informacje treści, a nie zwijanych wiadomości, np. „ping” bez treści, do skontaktować się z serwerem, aby pobrać dane.
Niektóre typowe przypadki użycia wiadomości, których nie można zwijać, to wiadomości na czacie lub wiadomości o krytycznym znaczeniu. W przypadku aplikacji do obsługi czatu chcesz na przykład dostarczać każdą wiadomość, każda wiadomość ma inną treść.
W przypadku Androida obowiązuje limit 100 wiadomości, które można zapisać bez i zwięzłość. Jeśli osiągnięto limit, wszystkie zapisane wiadomości zostaną odrzucone. Gdy urządzenie pojawi się z powrotem online, zostanie wyświetlony specjalny komunikat informujący o osiągnięciu limitu. Aplikacja jest w stanie odpowiednio zareagować na sytuację, zazwyczaj prosząc o wypełnienie synchronizację z serwerem aplikacji.
Wiadomość zwijana to wiadomość, która może zostać zastąpiona nową wiadomość, jeśli nie została jeszcze dostarczona na urządzenie.
Wiadomości zwijane często są wykorzystywane do to aplikacja mobilna do synchronizowania danych z serwerem. An np. aplikacja sportowa, która przekazuje użytkownikom najnowsze wyniki. Trafna jest tylko najnowsza wiadomość.
Aby oznaczyć wiadomość jako zwijaną na urządzeniu z Androidem, dołącz do niej atrybut
collapse_key
parametr w
ładunek wiadomości. Domyślnie kluczem zwijania jest nazwa pakietu aplikacji
zarejestrowany w konsoli Firebase. Serwer FCM może
przechowywać cztery różne zwijane wiadomości w
urządzeń, każdy z innym kluczem zwinięcia. Jeśli przekroczysz tę liczbę,
Funkcja FCM zachowuje tylko
4 klucze zwijania bez gwarancji, które z nich zostaną zachowane.
Wiadomości tematyczne bez ładunku są domyślnie zwijane. Powiadomienia
są zawsze zwijane 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. Pamiętaj jednak: jeśli używasz wiadomości zwijanych, pamiętaj, że W FCM można używać maksymalnie 4 różnych kluczy zwijania do FCM na token rejestracji. Nie możesz przekroczyć tej liczby. W przeciwnym razie może spowodować nieprzewidywalne konsekwencje.
Scenariusz korzystania | Jak wysyłać | |
---|---|---|
Niezwijana | Każda wiadomość jest ważna dla aplikacji klienckiej i musi być dostarczone. | Nie możesz zwinąć wszystkich wiadomości oprócz powiadomień wartość domyślną. |
Składane | Gdy pojawia się nowsza wiadomość, która renderuje starszą, powiązaną wiadomość nieistotne dla aplikacji klienckiej, polecenie FCM zastępuje starszą wiadomość. Na przykład: wiadomości użyte do zainicjowania synchronizacji danych z serwera lub nieaktualne powiadomienia. | Ustaw odpowiedni parametr w żądaniu wysłania wiadomości:
|
Ustawianie priorytetu wiadomości
Priorytet dostarczania możesz przypisać kolejnym wiadomościom na dwa sposoby: normalny i wysoki priorytet. Chociaż działanie jest nieco inne w zależności od tego, i dostarczanie wiadomości o normalnym i wysokim priorytecie podobny do tego:
Normalny priorytet. Wiadomości o normalnym priorytecie są dostarczane natychmiast, gdy aplikacja znajduje się na pierwszym planie. W przypadku aplikacji działających w tle dostawa może być opóźniony. W przypadku mniej pilnych wiadomości, takich jak powiadomienia o nowych e-mailach, synchronizację interfejsu użytkownika i synchronizacja danych aplikacji wybierz zwykły priorytet wyświetlania.
Wysoki priorytet. FCM próbuje wyświetlać reklamy o wysokim priorytecie wiadomości natychmiast, 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 priorytetowej wysłanej przez FCM Protokół HTTP v1 do powiadamiania czasopisma subskrybent, że można pobrać nowe treści:
{ "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 APNs
- Ustawianie priorytetu wiadomości i zarządzanie nim (Android)
- Pilność związana z wiadomością push w internecie
Przypadki użycia o znaczeniu krytycznym
Interfejsy API usługi FCM nie są przeznaczone do alertów o zagrożeniu oraz innych rodzajów ryzyka związanego z zastosowaniem lub awarie interfejsów API mogą spowodować śmierć, obrażenia ciała lub wpływ na środowisko szkody (takie jak eksploatacja obiektów jądrowych, kontrola lotów lub systemy podtrzymywania życia). Takie użytkowanie jest wyraźnie zabronione na mocy Artykuł 4. a. 7 Warunków korzystania z usługi. Reklamodawca ponosi wyłączną odpowiedzialność za zarządzanie zgodności aplikacji z Warunkami oraz wszelkimi szkodami niezgodności z przepisami. Google udostępnia interfejsy API w stanie „takim, jaki jest”, i zastrzega sobie prawo do zaprzestania działania interfejsów API ani części, funkcji czy też dostępu do nich z dowolnego powodu i w żadnym bez ponoszenia odpowiedzialności i innych zobowiązań wobec Ciebie 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 platforma to z Androidem, urządzenie może być wyłączone, offline lub z innego powodu niedostępne. Lub FCM może celowo opóźniać wiadomości aby zapobiec zużywaniu przez aplikację nadmiernej ilości zasobów i co wpływa na żywotność baterii.
W takim przypadku FCM przechowuje wiadomość i dostarcza ją natychmiast jak to możliwe. W większości przypadków jest to dobre rozwiązanie, ale istnieją aplikacje, które która może nigdy nie zostać dostarczona. Na przykład, jeśli plik jest to połączenie przychodzące lub powiadomienie na czacie wideo; ma znaczenie przez krótki czas, zanim połączenie zostanie zakończone. Jeśli wiadomość to zaproszenia na wydarzenie, jest bezużyteczne, jeśli zostało odebrane po zakończeniu wydarzenia.
W Androidzie i w przeglądarce internetowej/JavaScript możesz określić maksymalny okres ważności . Wartość musi mieć długość od 0 do 2 419 200 sekund (28 dni) i odpowiada maksymalnemu okresowi, w którym FCM zapisuje wiadomość i próbuje ją dostarczyć. Żądania, które ich nie zawierają domyślny okres to cztery 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 ważności wiadomości jest to,
FCM nie stosuje ograniczania zwijania wiadomości do wiadomości z
czas życia danych wynoszący 0 sekund.
FCM zapewnia najlepszą obsługę wiadomości, które muszą być
które trafiły „teraz albo nigdy”. Pamiętaj, że
time_to_live
ma wartość
Wartość 0 oznacza, że wiadomości, których nie można dostarczyć od razu, są odrzucane. Pamiętaj jednak:
ponieważ takie wiadomości nigdy nie są zapisywane, zapewnia to najlepsze opóźnienia
wysyłania 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 wiadomość nie oznacza, że wiadomość została już dostarczona urządzenia. Wskazuje natomiast, że produkt został zaakceptowany do dostawy. Co się dzieje z 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, z dostawą od razu.
Jeśli urządzenie jest połączone, ale w trybie uśpienia, zostanie zapisana wiadomość o niskim priorytecie.
do FCM, aż urządzenie wróci do stanu uśpienia. oraz
tutaj odgrywa rolę flagi collapse_key
: jeśli występuje
ma już wiadomość z tym samym kluczem zwinięcia (i tokenem rejestracji) zapisanym
i czekam na
dostarczanie, stara wiadomość jest odrzucana i zastępuje nową
(czyli stara wiadomość zostanie zwinięta przez nową). Jeśli jednak widok zwinięty
nie jest ustawiony, zarówno nowe, jak i stare wiadomości są przechowywane na potrzeby przyszłego dostarczenia.
Jeśli urządzenie nie jest połączone z aplikacją FCM, wiadomość będzie przechowywana do
nawiązane jest połączenie (z zachowaniem reguł kluczy zwijania). Gdy
zostanie nawiązane połączenie, FCM dostarczy wszystkie oczekujące wiadomości do
urządzenia. Jeśli urządzenie nie połączy się ponownie
(jeśli na przykład zostały przywrócone do ustawień fabrycznych), wiadomość po pewnym czasie wygaśnie,
został usunięty z FCM pamięci. Domyślny limit czasu wynosi 4 tygodnie,
chyba że jest ustawiona flaga time_to_live
.
Aby uzyskać szczegółowe informacje o dostarczaniu wiadomości:
Aby dowiedzieć się więcej o dostarczaniu wiadomości na platformach Android i Apple, zapoznaj się z artykułem FCM panelu raportowania, który rejestruje liczba wiadomości wysłanych i otwartych na urządzeniach Apple i z Androidem oraz dane dotyczące „wyświetleń” (powiadomienia użytkowników) dotyczące aplikacji na Androida.
Na urządzeniach z Androidem, na których włączono funkcję czatu, jeśli urządzenie nie łączyło się z FCM od ponad miesiąca, FCM nadal akceptuje wiadomość, ale natychmiast ją odrzuca. Jeśli urządzenie łączy się w ciągu 4 tygodni od ostatniej wysłanej do niego wiadomości. klient otrzymuje wywołanie zwrotne onRemoveMessages(). Aplikacja jest w stanie odpowiednio zareagować na sytuację, zazwyczaj prosząc o wypełnienie synchronizację z serwerem aplikacji.
Wreszcie, gdy FCM próbuje dostarczyć wiadomość na urządzenie,
aplikacja została odinstalowana, FCM natychmiast odrzuca tę wiadomość i
unieważnia token rejestracji. Przyszłe próby wysłania wiadomości pod ten adres
powoduje wystąpienie błędu NotRegistered
.
Ograniczanie wykorzystania
Naszym celem jest dostarczanie każdej wiadomości wysyłanej przez FCM. Pamiętaj jednak: dostarczanie każdej wiadomości powoduje czasami pogorszenie ogólnych wrażeń użytkownika. W innych przypadkach musimy określić granice, aby mieć pewność, że FCM zapewnia skalowalną usługę dla wszystkich nadawców. Typy limitów opisane w Ta sekcja pomoże Ci zrównoważyć te ważne czynniki.
Ograniczanie przesyłania wiadomości
Wprowadzono limity na minutę dla poszczególnych projektów w interfejsie API HTTP w wersji 1 i wysyłanie wiadomości. Domyślny limit 600 tys. wiadomości na minutę obejmuje ponad 99% FCM deweloperów przy jednoczesnym zapewnieniu stabilności systemu oraz i minimalizować wpływ gwałtownych projektów.
Ruch o dużym natężeniu ruchu może spowodować błędy związane z przekroczeniem limitu. Za przekroczenie limitu system wyświetla kod stanu HTTP 429 (QUOTA_EXCEEDED) do momentu w ciągu minuty zostanie uzupełniony limit. Odpowiedzi mogą też zostać zwrócone w ciągu 429 odpowiedzi przez przeciążenie, dlatego zdecydowanie zalecamy stosowanie kodów 429 zgodnie z opublikowanych rekomendacji.
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:
- Otwórz konsolę Google Cloud
- Wybierz Interfejsy API i usługi
- Z listy tabel wybierz Firebase Cloud Messaging API.
- Zaznacz Limity OGRANICZENIA SYSTEMOWE
UWAGA: te wykresy nie są ściśle dostosowane w czasie do limitów minut, co oznacza Żądania 429 mogą być wyświetlane, gdy ruch jest poniżej limitu.
Prośba o zwiększenie limitu
Zanim poprosisz o zwiększenie limitu, sprawdź, czy:
- Wykorzystanie regularnie przekracza 80% limitu przez co najmniej 5 kolejnych minut dziennie.
- Masz < Współczynnik błędów klienta na poziomie 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 maksymalnie +25% i FCM dołożą wszelkich starań, aby zrealizować Twoją prośbę (nie możemy zagwarantować wzrostu).
Jeśli z powodu zbliżającego się wprowadzenia na rynek potrzebujesz większego limitu na przesyłanie wiadomości na dalszych etapach tymczasowe, poproś o limit co najmniej 15 dni wcześniej, wystarczająco dużo czasu na jego rozpatrzenie. W przypadku dużych żądań (ponad 18 mln wiadomości na minutę) co najmniej Powiadomienie jest wymagane z 30-dniowym wyprzedzeniem. Premiery i prośby o wydarzenia specjalne są nadal dostępne zgodnie ze współczynnikiem błędów klienta i wymaganiami 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ń, na przykład zarówno w przypadku kierowania na tematy i grupy, jak i przy korzystaniu z funkcji Kompozytor powiadomień do kierowania na odbiorców lub segmenty użytkowników.
Rozpowszechnianie wiadomości nie jest natychmiastowe, więc czasami zwielokrotnienia w toku w toku. Ograniczamy liczbę równoczesnych wiadomości liczba zwielokrotnienia na projekt do 1000. Po tym czasie możemy odrzucić dodatkowe rozpowszechnianie. lub odroczyć czas ich rozpowszechniania do czasu zwielokrotnienia postępów.
Rzeczywista liczba zwielokrotnienia, które można osiągnąć, zależy od liczby projektów prosić o zgodę w tym samym czasie. Współczynnik zwielokrotnienia wynoszący 10 000 zapytań na sekundę konkretnego projektu nie jest niczym niezwykłym, ale ta liczba nie jest gwarantowana jest wynikiem łącznego obciążenia systemu. Warto pamiętać, że dostępna pojemność rozpowszechniania jest dzielona między projekty, a nie między zwielokrotnienie żądań. Jeśli więc Twój projekt ma w toku 2 zwielokrotnienia, każdy z nich widzą tylko połowę dostępnego współczynnika rozpowszechniania. Zalecany sposób na zmaksymalizowanie prędkość zwielokrotnienia jest możliwa tylko dla 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 będą się na siebie zwijać. W przypadku, gdy programista powtarza do aplikacji zbyt często, opóźniamy ich wysyłanie, aby ograniczyć co wpływa na żywotność baterii.
Jeśli na przykład wysyłasz dużą liczbę nowych żądań synchronizacji poczty e-mail do jednej urządzenie może opóźnić następną prośbę o synchronizację poczty e-mail o kilka minut, może synchronizować się z niższą średnią szybkością. To ograniczanie odbywa się wyłącznie w celu zmniejszanie wpływu baterii na baterię.
Jeśli Twój przypadek użycia wymaga wzorców wysyłania serii, wiadomości, których nie można zwinąć, mogą że jest to właściwy wybór. W przypadku takich wiadomości umieść treść w wiadomości, aby obniżyć koszty baterii.
Ograniczamy zwijanie wiadomości do serii 20 wiadomości na aplikację na urządzenie, ponowne uzupełnianie 1 wiadomości co 3 minuty.
Ograniczanie wykorzystania serwera XMPP
Szybkość nawiązywania połączeń z serwerami XMPP FCM ograniczamy do 400 połączeń. na minutę na projekt. Nie powinno to być problemem z dostarczeniem wiadomości, ma duże znaczenie dla zapewnienia stabilności systemu. Dla każdego projektu FCM dopuszcza 2500 połączenia równolegle.
Limity w FCM w przypadku wysyłania wiadomości z protokołem XMPP komunikatów nadrzędnych z szybkością 1 500 000/minutę na projekt, aby uniknąć przeciążenia serwerów docelowych źródłowych.
Aby chronić przed zużyciem baterii,ograniczamy częstotliwość wysyłania na urządzenie do 1000 wiadomości na minutę z powodu niewłaściwego działania aplikacji.
Maksymalna częstotliwość przesyłania wiadomości na 1 urządzenie
W przypadku Androida możesz wysyłać do 240 wiadomości na minutę i 5000 wiadomości na godzinę urządzenia. Ten wysoki próg ma umożliwiać krótkotrwałe skoki ruchu, np. gdy użytkownicy szybko wchodzą w interakcję na czacie. Ten limit zapobiega błędom wysyłania mechanizmów logicznych wynikających z przypadkowego rozładowywania baterii urządzenia.
W przypadku iOS zwracamy błąd, gdy wartość przekracza limity APN.
FCM porty i zapora sieciowa
Jeśli w Twojej organizacji jest zapora sieciowa, która ogranicza ruch do z internetu, musisz skonfigurować go tak, aby zezwolić urządzeniom mobilnym na łączenie się za pomocą usługi FCM, aby urządzenia w Twojej sieci 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 udostępnia z powodu zbyt częstego zmieniania zakresu adresów IP i reguł zapory sieciowej mogą stać się nieaktualne, co wpłynie na z myślą o użytkownikach. Najlepiej dodać do listy dozwolonych porty 5228–5230 i 443 bez ograniczeń adresów IP. Jeśli jednak wymagany jest adres IP , dodaj do listy dozwolonych wszystkie adresy IP wymienione w pliku goog.json. Ta długa lista jest regularnie aktualizowana, dlatego zalecamy co miesiąc. Problemy spowodowane przez ograniczenia adresów IP zapory sieciowej są często przejściowe i trudne do zdiagnozowania.
Oferujemy zestaw nazw domen, które zamiast adresu IP można dodać do listy dozwolonych adresów. Nazwy hostów znajdziesz poniżej. Jeśli zaczniemy używać dodatkowych nazwy hostów, zaktualizujemy listę tutaj. Używanie nazw domen jako zapory sieciowej może nie działać w Twojej zaporze.
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 jest wdrożone tłumaczenie adresów sieciowych (NAT) lub pakiet stanowy Inspekcja (SPI), wdróż limit czasu wynoszący co najmniej 30 minut połączeń przez porty 5228-5230. Dzięki temu możemy dostarczać połączenia sieciowe, zmniejszając zużycie baterii przez użytkowników telefon komórkowy urządzenia.
Interakcje z siecią VPN i możliwość pomijania
Firebase Cloud Messaging podejmuje różne działania, aby zapewnić przekazywanie komunikatów push połączenie między telefonem a serwerem jest niezawodne i dostępne tak często, jak jak to tylko możliwe. Korzystanie z sieci VPN komplikuje te działania.
Sieci VPN maskują informacje, które są używane przez usługę FCM do dostrajania połączenia w celu maksymalizacji niezawodności żywotności baterii. W niektórych przypadkach aktywne sieci VPN powodują zerwanie długotrwałych połączeń, co negatywnie wpływa na wrażenia użytkowników z powodu utraty lub opóźnione wiadomości czy wysoki koszt baterii. Gdy konfiguracja sieci VPN zezwala nam w ten sposób omijamy sieć VPN, korzystając z szyfrowanego połączenia (przez sieć podstawową Wi-Fi lub LTE), by zapewnić niezawodne i oszczędne baterię z myślą o użytkownikach. Korzystanie przez FCM z sieci VPN z możliwością pominięcia zależy od Kanał powiadomień push FCM. Inny ruch z sieci FCM, taki jak podczas rejestracji, używa sieci VPN, jeśli jest ona aktywna. Gdy FCM omija VPN i traci dodatkowe korzyści, jakie może zapewnić VPN, takich jak maskowanie adresów IP.
Różne sieci VPN stosują różne metody określania, czy mogą być pomijane. Instrukcje znajdziesz w dokumentacji konkretnej sieci VPN.
Jeśli sieć VPN nie została skonfigurowana w sposób umożliwiający jej pomijanie, Firebase Cloud Messaging będzie użyj sieci VPN do połączenia z serwerem. Może to spowodować w okresach, gdy wiadomości są opóźnione i mogą wydłużyć czas pracy na baterii. ponieważ Cloud Messaging służy do utrzymywania połączenia przez sieć VPN połączenia.
Dane logowania
W zależności od tego, które funkcje FCM wdrożysz, może być konieczne te dane logowania z projektu Firebase:
Identyfikator projektu | Unikalny identyfikator Twojego projektu Firebase używany w żądaniach kierowanych do Punkt końcowy HTTP FCM w wersji 1. Ta wartość to dostępne w FirebasePanel Ustawienia w konsoli. |
Token rejestracji | Unikalny ciąg tokena, który identyfikuje każdą instancję aplikacji klienckiej. Token rejestracji jest wymagany w przypadku pojedynczego urządzenia i urządzenia i wysyłać wiadomości grupowe. Pamiętaj, że tokeny rejestracji należy przechowywać w tajemnicy. |
Identyfikator nadawcy | Niepowtarzalna wartość liczbowa tworzona podczas tworzenia projektu Firebase, dostępne w Karta Cloud Messaging w konsoli Firebase Okienko Ustawienia. Identyfikator nadawcy służy do identyfikowania nadawca, 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 HTTP v1. API. Ten token jest powiązany z kontem usługi, które należy do do projektu Firebase. Aby utworzyć i wykonać rotację tokenów dostępu, postępuj zgodnie z czynności opisane w sekcji Autoryzacja wysyłania żądań. |
Klucz serwera (na potrzeby **wycofanych** starszych protokołów) | Serwer który autoryzuje serwer aplikacji dostępu do usług Google, w tym wysyłania wiadomości za pośrednictwem wycofano atrybut Firebase Cloud Messaging starsze protokoły. Ważne: nie podawaj klucza serwera nigdzie kod klienta. Pamiętaj też, aby autoryzować swoje serwera aplikacji. Klucze Androida, platformy Apple oraz przeglądarki są odrzucane przez FCM |