Komunikacja w chmurze Firebase (FCM) oferuje szeroki zakres opcji komunikacji i jej możliwości. Informacje na tej stronie mają na celu pomaga zrozumieć różne typy wiadomości w FCM i dowiedzieć się, co z nimi można 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 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 1000 znaków, .
| Scenariusz korzystania | Jak wysyłać | |
|---|---|---|
| Powiadomienie | Pakiet FCM SDK 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 .
Funkcje w 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, jeśli pakiet SDK FCM 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 z opcjonalnymi danymi ładunek. W takich przypadkach FCM wyświetla powiadomienie a aplikacja kliencka – za jego pomocą.
Powiadomienia
Do testów lub marketingu i ponownego angażowania użytkowników możesz wysłać wiadomości z powiadomieniami w konsoli Firebase. Konsola Firebase udostępnia funkcje analityczne Testy A/B pomagają ulepszać ulepszania komunikatów marketingowych.
Aby automatycznie wysyłać powiadomienia za pomocą pakietu Admin SDK lub
w przypadku protokołów FCM ustaw w kluczu notification parametr
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 pakiet SDK Firebase Admin, jak i protokół HTTP FCM w wersji 1 umożliwiają 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.
AndroidConfigiWebpushConfig, 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_actionicategory.
{
"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 na:
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 przez: collapse_key w FCM, na urządzeniu Apple przez
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
zarejestrowane 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ę,
Zachowuje tylko w FCM
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 FCM zezwala na użycie maksymalnie 4 różnych kluczy zwijania według 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, 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 wysył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
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. FCM może też celowo opóźniać wysyłanie wiadomości. aby zapobiec zużywaniu przez aplikację nadmiernej ilości zasobów i co wpływa na żywotność baterii.
W takim przypadku FCM zapisuje 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, 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 możliwości zwijania wiadomości do wiadomości z
czas życia danych wynoszący 0 sekund.
FCM zapewnia najlepszą obsługę wiadomości, które muszą zostać
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 publikuje wiadomość w FCM i odbiera 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 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.
przez FCM, dopóki urządzenie nie wróci do trybu 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 FCM, wiadomość jest 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
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,
zostanie usunięty z pamięci FCM. 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 panelu raportowania FCM, 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 było połączone z FCM od ponad miesiąca, FCM nadal zaakceptuje wiadomość, ale natychmiast ją odrzuci. 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 i
aplikacja została odinstalowana, FCM natychmiast odrzuca tę wiadomość,
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% programistów FCM, jednocześnie chroniąc stabilność systemu 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%, a FCM dołoży wszelkich starań, aby zrealizować Twoją prośbę (nie możemy zagwarantować wzrostu).
Jeśli ze względu na zbliżające się wprowadzenie 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 Wymagane jest powiadomienie 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 opóźnić ich rozpowszechnianie do czasu, gdy część z 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 deweloper 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.
Porty FCM 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ę z FCM, aby urządzenia w Twojej sieci mogły odbierać wiadomości. FCM zwykle używa portu 5228, ale czasami – 443, 5229 i 5230).
W przypadku urządzeń łączących się w 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 udostępniać wiarygodne dane 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
Komunikacja w chmurze Firebase (FCM) podejmuje różne działania, aby zapewnić 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ą bazowe informacje, które są niezbędne 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 FCM, np. 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 jest skonfigurowana do pomijania, Komunikacja w chmurze Firebase (FCM) 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ż Komunikacja w chmurze pozwala utrzymywać połączenie 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 Panel Ustawienia w konsoli Firebase. |
| 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 z wiadomościami grupowymi. Pamiętaj, że tokeny rejestracji należy przechowywać w tajemnicy. |
| Identyfikator nadawcy | Niepowtarzalna wartość liczbowa tworzona podczas tworzenia projektu Firebase, dostępne w Karta Komunikacja w chmurze 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 Komunikację w chmurze Firebase (FCM) 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. |