Komunikacja w chmurze Firebase (FCM) oferuje szeroki zakres opcji i funkcji przesyłania wiadomości. Zawiera ona informacje o różnych typach wiadomości FCM i o tym, co można z nimi zrobić.
Typy wiadomości
Usługa FCM pozwala wysyłać klientom 2 rodzaje wiadomości:
- Powiadomienia, czasami nazywane „wyświetlaniem wiadomości”. Są one obsługiwane przez pakiet SDK FCM automatycznie.
- Wiadomości z danymi obsługiwane przez aplikację kliencką.
Wiadomości z powiadomieniami zawierają wstępnie zdefiniowany zestaw kluczy widocznych dla użytkowników. Wiadomości z danymi zawierają natomiast tylko zdefiniowane przez użytkownika niestandardowe pary klucz-wartość. Powiadomienia mogą zawierać opcjonalny ładunek danych. Maksymalny ładunek dla obu typów wiadomości to 4096 bajtów, z wyjątkiem wysyłania wiadomości z konsoli Firebase, w której obowiązuje limit 1000 znaków.
| Scenariusz | Jak wysyłać | |
|---|---|---|
| Powiadomienie | Pakiet SDK FCM wyświetla wiadomość na urządzeniach użytkowników w imieniu aplikacji klienckiej, gdy działa ona w tle. W przeciwnym razie, jeśli w chwili odebrania powiadomienia aplikacja działa na pierwszym planie, działanie określa jej kod. Wiadomości z powiadomieniami mają wstępnie zdefiniowany zestaw kluczy widocznych dla użytkowników i opcjonalny ładunek danych w postaci niestandardowych par klucz-wartość. |
|
| Wiadomość dotycząca danych | Za przetwarzanie wiadomości z danymi odpowiada aplikacja kliencka. Komunikaty z danymi mają tylko niestandardowe pary klucz-wartość bez zarezerwowanych nazw kluczy (patrz poniżej). | W zaufanym środowisku, takim jak
Cloud Functions lub serwer aplikacji, użyj pakietu Admin SDK lub protokołów serwera FCM. W żądaniu wysłania ustaw klucz data.
|
Używaj komunikatów z powiadomieniami, jeśli chcesz, aby pakiet SDK FCM automatycznie obsługiwał wyświetlanie powiadomień, gdy aplikacja działa w tle. Użyj wiadomości z danymi, gdy chcesz przetwarzać wiadomości za pomocą własnego kodu aplikacji klienckiej.
FCM może wysłać powiadomienie z opcjonalnym ładunkiem danych. W takich przypadkach FCM obsługuje wyświetlanie ładunku powiadomień, a aplikacja kliencka obsługuje ładunek danych.
Powiadomienia
Do celów testowych lub marketingowych albo do ponownego angażowania użytkowników możesz wysyłać powiadomienia za pomocą konsoli Firebase. Konsola Firebase udostępnia testy A/B oparte na danych analitycznych, które pomagają doprecyzować i ulepszyć przekaz marketingowy.
Aby automatycznie wysyłać powiadomienia za pomocą pakietu Admin SDK lub protokołów FCM, ustaw klucz notification z niezbędnym zestawem opcji par klucz-wartość widocznych dla użytkowników. Oto przykład wiadomości z powiadomieniem w formacie JSON w aplikacji czatu. Użytkownik może się spodziewać komunikatu „Portugalia kontra Dania” i tekst „świetne dopasowanie!”:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}
Powiadomienia są dostarczane do paska powiadomień, gdy aplikacja działa w tle. W przypadku aplikacji działających na pierwszym planie wiadomości są obsługiwane przez funkcję wywołania zwrotnego.
Pełną listę wstępnie zdefiniowanych kluczy dostępnych do tworzenia komunikatów z powiadomieniami znajdziesz w dokumentacji obiektu powiadomień protokołu HTTP w wersji 1.
Wiadomości z danymi
Ustaw odpowiedni klucz w niestandardowych parach klucz-wartość, aby wysłać ładunek danych do aplikacji klienckiej.
Oto przykład: poniżej znajduje się komunikat w formacie JSON umieszczony w tej samej aplikacji komunikatora co wyżej. Informacje te są umieszczone we wspólnym kluczu data, a aplikacja kliencka powinna zinterpretować jej treść:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
}
Powyższy przykład przedstawia wykorzystanie pola data najwyższego poziomu, które jest interpretowane przez klientów na wszystkich platformach, które otrzymują wiadomość.
Na każdej platformie aplikacja kliencka odbiera ładunek danych za pomocą funkcji wywołania zwrotnego.
Szyfrowanie wiadomości z danymi
Warstwa transportowa Androida (patrz architektura FCM) wykorzystuje szyfrowanie połączenia między punktami. W zależności od potrzeb możesz zdecydować się na dodanie pełnego szyfrowania do wiadomości z danymi. FCM nie zapewnia kompleksowego rozwiązania. Dostępne są jednak rozwiązania zewnętrzne, np. Capillary lub DTLS.
Powiadomienia z opcjonalnym ładunkiem danych
Możesz wysyłać powiadomienia (automatycznie lub za pomocą konsoli Firebase) zawierające opcjonalny ładunek niestandardowych par klucz-wartość. W Kreatorze powiadomień użyj pól Dane niestandardowe w Opcjach zaawansowanych.
Sposób działania aplikacji podczas odbierania wiadomości, które zawierają ładunki powiadomień i ładunki danych, zależy od tego, czy aplikacja działa w tle czy na pierwszym planie. Zasadniczo jest ona aktywna w momencie odbioru, czy nie.
- W tle aplikacje odbierają ładunek powiadomień na pasku powiadomień i obsługują je tylko wtedy, gdy użytkownik kliknie powiadomienie.
- Na pierwszym planie aplikacja odbiera obiekt wiadomości z dostępnymi ładunkami obu rodzajów ładunków.
Oto wiadomość w formacie JSON, która zawiera zarówno klucz notification, jak i klucz data:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}
Dostosowywanie komunikatu na różnych platformach
Zarówno pakiet SDK Firebase Admin, jak i protokół HTTP FCM v1 pozwalają w żądaniu wiadomości ustawić wszystkie pola dostępne w obiekcie message. Obejmuje to m.in.:
- wspólny zbiór pól do interpretowania przez wszystkie instancje aplikacji, które otrzymały wiadomość.
- Zbiory pól związane z konkretną platformą, takie jak
AndroidConfigiWebpushConfig, interpretowane tylko przez instancje aplikacji działające na określonej platformie.
Blokady związane z określoną platformą umożliwiają elastyczne dostosowywanie wiadomości przeznaczonych dla różnych platform, aby zapewnić ich prawidłową obsługę po otrzymaniu. Backend FCM weźmie pod uwagę wszystkie określone parametry i dostosuje wiadomość dla każdej platformy.
Kiedy używać wspólnych pól
Używaj często używanych pól, gdy:
- kierowanie na instancje aplikacji na wszystkich platformach – Apple, Android i w internecie;
- Wysyłanie wiadomości do tematów
Wszystkie instancje aplikacji, niezależnie od platformy, mogą interpretować te typowe pola:
Kiedy używać pól zależnie od platformy
Użyj pól związanych z daną platformą, jeśli chcesz:
- Wysyłaj pola tylko na określone platformy
- Wysyłaj pola związane z poszczególnymi platformami oprócz wspólnych pól.
Jeśli chcesz wysyłać wartości tylko do określonych platform, nie używaj wspólnych pól. Stosuj pola związane z daną platformą. Aby np. wysłać powiadomienie tylko na platformy Apple i strony internetowe, ale nie na Androida, musisz użyć 2 osobnych zestawów pól – jednego dla Apple i jednego dla stron internetowych.
Gdy wysyłasz wiadomości z określonymi opcjami dostarczania, skorzystaj z pól właściwych na danej platformie, aby skonfigurować te opcje. Jeśli chcesz, możesz podać różne wartości dla poszczególnych platform. Jeśli jednak chcesz ustawić zasadniczo tę samą wartość na różnych platformach, musisz użyć pól związanych z daną platformą. Wynika to z faktu, że każda platforma może interpretować tę wartość nieco inaczej, np. na Androidzie jest to czas ważności w sekundach, a w Apple – data.
Przykład: powiadomienie z opcjami dostarczania zależnymi od platformy
Podane niżej żądanie wysyłania w wersji 1 wysyła wspólny tytuł powiadomienia do wszystkich platform, ale też niektóre zastąpienia związane z daną platformą. Chodzi konkretnie o to:
- ustawia długi czas życia platform internetowych i Androida, a priorytet wiadomości APNs (platformy Apple) ustawiany na niski.
- ustawia odpowiednie klawisze do określania wyniku kliknięcia powiadomienia przez użytkownika 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"
}
}
}
}
Szczegółowe informacje o kluczach dostępnych w blokach na poszczególnych platformach w treści wiadomości znajdziesz w dokumentacji protokołu HTTP w wersji 1. Więcej informacji o tworzeniu żądań wysyłania zawierających treść wiadomości znajdziesz w artykule o tworzeniu żądań wysyłania.
Opcje dostawy
FCM zapewnia określony zestaw opcji dostarczania wiadomości wysyłanych na urządzenia z Androidem oraz podobne opcje na platformach Apple i w internecie. Na przykład „zwijane” wiadomości są obsługiwane w Androidzie za pomocą funkcji collapse_key FCM, na urządzeniach Apple – apns-collapse-id oraz w przypadku JavaScriptu/przeglądarki (Topic). Szczegółowe informacje znajdziesz w opisach w tej sekcji oraz w powiązanej dokumentacji referencyjnej.
Wiadomości niezwijane i zwijane
Wiadomość niezwijana oznacza, że każda pojedyncza wiadomość zostanie dostarczona na urządzenie. Wiadomość, której nie da się zwijać, zawiera przydatne treści – w przeciwieństwie do wiadomości zwijanych, np. ping bez treści do aplikacji mobilnej, w celu skontaktowania się z serwerem w celu pobrania danych.
Typowym przypadkiem użycia wiadomości, których nie da się zwijać, są wiadomości na czacie lub wiadomości o znaczeniu krytycznym. Na przykład w aplikacji do obsługi czatu warto przekazać każdą wiadomość, bo każda wiadomość ma inną treść.
W Androidzie obowiązuje limit 100 wiadomości, które można przechowywać bez zwijania. Gdy limit zostanie osiągnięty, wszystkie przechowywane wiadomości zostaną odrzucone. Gdy urządzenie będzie z powrotem online, otrzyma specjalny komunikat z informacją o osiągnięciu limitu. Aplikacja może wtedy odpowiednio rozwiązać problem, zwykle żądając od serwera aplikacji pełnej synchronizacji.
Wiadomość zwijana to wiadomość, która może zostać zastąpiona nową wiadomością, jeśli nie została jeszcze dostarczona na urządzenie.
Częstym przypadkiem użycia wiadomości zwijanych są wiadomości, których aplikacja mobilna potrzebuje, aby synchronizować dane z serwera. Może to być np. aplikacja sportowa, która informuje użytkowników o najnowszych wynikach. Ważna jest tylko najnowsza wiadomość.
Aby oznaczyć wiadomość jako zwijaną na Androidzie, umieść w jej ładunku parametr collapse_key. Domyślnie kluczem zwinięcia jest nazwa pakietu aplikacji zarejestrowana w konsoli Firebase. Serwer FCM może jednocześnie przechowywać 4 różne wiadomości zwijane na urządzenie, każdą z innym kluczem zwinięcia. Jeśli przekroczysz tę liczbę, FCM zachowa tylko 4 klucze zwijania bez gwarancji, które z nich zostaną zachowane.
Wiadomości z tematów bez ładunku są domyślnie zwijane. Powiadomienia zawsze można zwijać i ignorują parametr collapse_key.
Której opcji mam użyć?
Wiadomości zwijane to lepszy wybór z punktu widzenia wydajności, pod warunkiem że aplikacja nie musi używać wiadomości niezwijanych. Jeśli jednak używasz wiadomości zwijanych, pamiętaj, że FCM pozwala na użycie maksymalnie 4 różnych kluczy zwijania na token rejestracji. Nie możesz przekroczyć tej liczby, ponieważ może to spowodować nieprzewidywalne konsekwencje.
| Scenariusz | Jak wysyłać | |
|---|---|---|
| Niezwijana | Każda wiadomość jest ważna dla aplikacji klienckiej i musi zostać dostarczona. | Domyślnie wszystkie wiadomości nie mogą być zwijane (oprócz powiadomień). |
| Składane | Gdy pojawi się nowsza wiadomość, która renderuje starszą, powiązaną wiadomość nieistotną dla aplikacji klienckiej, FCM zastępuje starszą wiadomość. Na przykład: wiadomości używane do inicjowania synchronizacji danych z serwera lub nieaktualne powiadomienia. | Ustaw odpowiedni parametr w prośbie o rozpoczęcie czatu:
|
Określanie priorytetu wiadomości
Dostępne są 2 opcje przypisywania priorytetu dostarczania do kolejnych wiadomości: normalny i wysoki. Chociaż działanie tych wiadomości różni się w zależności od platformy, dostarczanie wiadomości o normalnym i wysokim priorytecie działa w ten sposób:
Zwykły 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. Wybierz normalny priorytet dostarczania, aby otrzymywać wiadomości, które są mniej ważne, na przykład powiadomienia o nowych e-mailach, synchronizację interfejsu użytkownika lub synchronizację danych aplikacji w tle.
Wysoki priorytet. FCM spróbuje dostarczyć wiadomości o wysokim priorytecie natychmiast, nawet jeśli urządzenie jest w trybie uśpienia. Wiadomości o wysokim priorytecie są przeznaczone do treści, które są widoczne dla użytkowników i wymagają czasu.
Oto przykład zwykłej wiadomości priorytetowej wysyłanej za pomocą protokołu HTTP w wersji 1 FCM, która informuje subskrybenta czasopisma o możliwości pobrania nowych 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"
}
}
}
}
Szczegółowe informacje o ustawianiu priorytetu wiadomości na poszczególnych platformach:
- Dokumentacja APN
- Ustawianie priorytetu wiadomości i zarządzanie nim (Android)
- Pilność w przypadku wiadomości push w przeglądarce
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 w inny sposób niedostępne. FCM może też celowo opóźniać wysyłanie wiadomości, aby zapobiec zużywaniu nadmiernej ilości zasobów przez aplikację i negatywnie wpłynąć na żywotność baterii.
W takim przypadku FCM przechowuje wiadomość i dostarcza ją tak szybko, jak to możliwe. W większości przypadków jest to normalne, ale w niektórych aplikacjach spóźnione wiadomości mogą nigdy nie zostać dostarczone. Jeśli na przykład wiadomość jest powiadomieniem o połączeniu przychodzącym lub czacie wideo, ma ona znaczenie tylko przez krótki czas, zanim połączenie zostanie zakończone. Jeśli wiadomość jest zaproszeniem na wydarzenie, nie będzie potrzebna, jeśli zostanie dostarczona po zakończeniu wydarzenia.
W przypadku Androida i internetu/JavaScriptu możesz określić maksymalny okres ważności wiadomości. Wartość musi mieścić się w przedziale od 0 do 2 419 200 sekund (28 dni) i odpowiada maksymalnego czasu, przez jaki FCM przechowuje i próbuje dostarczyć wiadomość. Żądania, które nie zawierają tego pola, domyślnie stosują maksymalny okres 4 tygodni.
Oto kilka możliwych zastosowań tej funkcji:
- Połączenia przychodzące na czacie wideo
- Wygasające wydarzenia
- Wydarzenia w kalendarzu
Inną zaletą określenia okresu ważności wiadomości jest to, że FCM nie stosuje ograniczania zwijania wiadomości do wiadomości, których czas życia wiadomości wynosi 0 sekund.
FCM zapewnia odpowiednią obsługę wiadomości, które muszą zostać dostarczone „teraz” lub „nigdy”. Pamiętaj, że wartość time_to_live wynosząca 0 oznacza, że wiadomości, których nie można dostarczyć od razu, są odrzucane. Jednak ponieważ takie wiadomości nigdy nie są przechowywane, zapewnia to najlepszy czas oczekiwania przy wysyłaniu wiadomości z powiadomieniami.
Oto przykład żądania, które zawiera 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
Jeśli serwer aplikacji opublikuje wiadomość w FCM i otrzyma z powrotem jej identyfikator, nie oznacza to, że wiadomość została już dostarczona na urządzenie. Wskazuje natomiast, że została ona zaakceptowana w dostawie. To, co stanie się z wiadomością po jej zaakceptowaniu, zależy od wielu czynników.
W najlepszym przypadku, jeśli urządzenie jest połączone z FCM, ekran jest włączony i nie ma żadnych ograniczeń ograniczania, wiadomość jest dostarczana od razu.
Jeśli urządzenie jest połączone, ale jest w trybie uśpienia, FCM przechowuje wiadomość o niskim priorytecie, dopóki urządzenie nie przejdzie poza tryb uśpienia. Właśnie w tym miejscu odgrywa flaga collapse_key: jeśli istnieje już wiadomość z tym samym kluczem zwinięcia (i tokenem rejestracji) i czeka na dostarczenie, stara wiadomość jest odrzucana i zastępuje nową (tzn. stara wiadomość jest zwinięta przez nową). Jeśli jednak nie zostanie ustawiony klucz zwijania, zarówno nowe, jak i stare wiadomości będą przechowywane na potrzeby dostarczania w przyszłości.
Jeśli urządzenie nie jest połączone z FCM, wiadomość jest przechowywana do czasu nawiązania połączenia (ponownie z poszanowaniem zasad zwijania). Po nawiązaniu połączenia FCM dostarczy na urządzenie wszystkie oczekujące wiadomości. Jeśli urządzenie nie połączy się ponownie (np. po przywróceniu ustawień fabrycznych), wiadomość w końcu przekroczy limit czasu i zostanie usunięta z pamięci FCM. Domyślny limit czasu to 4 tygodnie, chyba że jest ustawiona 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, zapoznaj się z panelem raportowania FCM, który zawiera liczbę wysłanych i otwartych wiadomości na urządzeniach Apple i z Androidem, a także dane o „wyświetleniach” (powiadomieniach widocznych przez użytkowników) w aplikacjach na Androida.
W przypadku urządzeń z Androidem z włączonym czatem bezpośrednim, a urządzenie nie łączyło się z FCM od ponad miesiąca, FCM nadal akceptuje wiadomość, ale natychmiast ją odrzuca. Jeśli urządzenie połączy się w ciągu 4 tygodni od wysłania do niego ostatniej wiadomości z danymi, klient otrzyma wywołanie zwrotne onDeletedMessages(). Aplikacja może wtedy odpowiednio rozwiązać problem, zwykle żądając od serwera aplikacji pełnej synchronizacji.
Gdy FCM próbuje dostarczyć wiadomość na urządzenie, gdy aplikacja została odinstalowana, od razu ją odrzuca i unieważni token rejestracji. W przyszłości próby wysłania wiadomości na to urządzenie będą powodować błąd NotRegistered.
Ograniczanie i skalowanie
Naszym celem jest zawsze dostarczanie każdej wiadomości wysłanej przez FCM. Dostarczenie każdej wiadomości czasami obniża jednak ogólne wrażenia użytkownika. W innych przypadkach musimy wprowadzić granice, aby mieć pewność, że FCM zapewni skalowalną usługę dla wszystkich nadawców.
Ograniczanie możliwości zwijania wiadomości
Jak opisano powyżej, wiadomości zwijane to powiadomienia pozbawione treści, które mogą się zwijać na siebie. Jeśli deweloper zbyt często powtarza ten sam komunikat w aplikacji, opóźniamy (ograniczanie) komunikatów, aby zmniejszyć obciążenie baterii użytkownika.
Jeśli na przykład wysyłasz dużą liczbę nowych żądań synchronizacji poczty e-mail na jedno urządzenie, możemy opóźnić następne żądanie synchronizacji poczty e-mail o kilka minut, aby urządzenie mogło przeprowadzić synchronizację z mniejszą średnią szybkością. Ma to na celu wyłącznie ograniczenie wpływu baterii na użytkowników.
Jeśli Twój przypadek użycia wymaga wzorców wysyłania o dużej liczbie impulsów, dobrym rozwiązaniem mogą być wiadomości niezwijane. Pamiętaj, aby w przypadku takich wiadomości uwzględnić ich treść, aby obniżyć koszty baterii.
Ograniczamy liczbę zwijanych wiadomości do 20 wiadomości na aplikację na urządzenie. Jedna wiadomość jest uzupełniana co 3 minuty.
Ograniczanie serwera XMPP
Ograniczamy szybkość, z jaką możesz się łączyć z serwerami XMPP FCM, do 400 połączeń na minutę na projekt. Nie powinno to stanowić problemu z dostarczaniem wiadomości, ale jest ważne dla zapewnienia stabilności systemu. W każdym projekcie FCM dopuszcza równolegle 2500 połączeń.
W przypadku przesyłania wiadomości z użyciem XMPP FCM ogranicza liczbę wiadomości nadrzędnych do 1 500 000 minut na projekt, aby uniknąć przeciążenia nadrzędnych serwerów docelowych.
Limit wysyłania wiadomości na urządzenie wynosi 1000 na minutę,co ma zapobiec rozładowywaniu baterii przez nieodpowiednie działanie aplikacji.
Maksymalna liczba wiadomości wysyłanych do jednego urządzenia
W Androidzie na jedno urządzenie możesz wysłać do 240 wiadomości na minutę i do 5000 wiadomości na godzinę. Ten wysoki próg ma na celu umożliwienie krótkoterminowego zwiększenia ruchu, np. w momencie szybkiej interakcji użytkowników na czacie. Ten limit zapobiega przypadkowemu rozładowaniu baterii urządzenia przez błędy związane z wysyłaniem logiki.
W iOS zwracamy błąd, gdy szybkość przekracza limity APNs.
Limit wiadomości w temacie
Współczynnik dodawania/usuwania subskrypcji tematów jest ograniczony do 3000 zapytań na sekundę na projekt.
Informacje o częstotliwości wysyłania wiadomości znajdziesz w artykule Ograniczanie wykorzystania fanów.
Ograniczanie zasięgu
Rozprzestrzenianie się wiadomości to proces wysyłania wiadomości na wiele urządzeń, na przykład gdy kierujesz je na tematy i grupy lub gdy używasz Kreatora powiadomień do kierowania reklam na odbiorców lub segmenty użytkowników.
Rozprzestrzenianie się wiadomości nie jest natychmiastowe, dlatego od czasu do czasu można prowadzić wiele kampanii jednocześnie. Ograniczamy liczbę równoczesnych fanoutów na projekt do 1000. Po tym czasie możemy odrzucić dodatkowe prośby o rozpowszechnianie lub odroczyć ich rozpowszechnianie do momentu zakończenia części już trwających rozpowszechniania.
Rzeczywisty osiągalny wskaźnik rozpowszechnienia zależy od liczby projektów, które w tym samym czasie prosiły o przekazanie dalej. Częstotliwość 10 000 zapytań na sekundę w przypadku pojedynczego projektu nie jest rzadka, ale ta liczba nie jest gwarantowana i wynika z całkowitego obciążenia systemu. Pamiętaj, że dostępna moc rozpowszechniania jest dzielona między projekty, a nie żądania rozpowszechniania. Jeśli więc Twój projekt ma 2 rozszerzenia, każde z nich zobaczy tylko połowę dostępnego odsetka. Zalecanym sposobem na zmaksymalizowanie szybkości fanouta jest posiadanie tylko jednego aktywnego rozpowszechnienia naraz.
Porty FCM a zapora sieciowa
Jeśli Twoja organizacja ma zaporę sieciową ograniczającą ruch do i z internetu, musisz ją skonfigurować w taki sposób, aby urządzenia mobilne mogły łączyć się z FCM. Dzięki temu urządzenia w Twojej sieci będą mogły odbierać wiadomości. FCM zwykle używa portu 5228, ale czasami używa portu 443, 5229 i 5230.
W przypadku urządzeń łączących się z Twoją siecią FCM nie podaje konkretnych adresów IP, ponieważ nasz zakres adresów IP zmienia się zbyt często, a reguły zapory sieciowej mogą stać się nieaktualne, co negatywnie wpłynie na wygodę użytkowników. Najlepiej dodać porty 5228-5230 i 443 do listy dozwolonych bez ograniczeń adresu IP. Jeśli jednak musisz zastosować ograniczenie adresów IP, dodaj do listy dozwolonych wszystkie adresy IP wymienione w pliku goog.json. Ta długa lista jest regularnie aktualizowana, ale zalecamy ich aktualizowanie co miesiąc. Problemy powodowane przez ograniczenia adresu IP zapory sieciowej często przemijają i są trudne do zdiagnozowania.
Oferujemy zestaw nazw domen, które można umieścić na liście dozwolonych zamiast adresów IP. Te nazwy hostów są wymienione poniżej. Jeśli zaczniemy używać dodatkowych nazw hostów, zaktualizujemy ich listę tutaj. Użycie nazw domen w regule zapory sieciowej może nie działać w Twojej zaporze sieciowej, ale nie musi.
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
Zapory sieciowe do translacji adresów sieciowych lub stanowej inspekcji pakietów:
Jeśli w Twojej sieci jest stosowane translacja adresów sieciowych (NAT) lub stanowa inspekcja pakietów (SPI), zaimplementuj 30-minutowe lub dłuższe czas oczekiwania dla naszych połączeń przez porty 5228–5230. Dzięki temu możemy zapewniać niezawodne połączenia, a jednocześnie zmniejszać zużycie baterii przez urządzenia mobilne użytkowników.
Interakcje z siecią VPN i możliwość ominięcia
Komunikacja w chmurze Firebase (FCM) podejmuje różne działania, aby zagwarantować niezawodność i dostępność komunikacji push między telefonem a serwerem. Korzystanie z sieci VPN utrudnia to zadanie.
Sieci VPN maskują informacje, które FCM potrzebuje do dostrojenia połączenia w celu zmaksymalizowania niezawodności i czasu pracy na baterii. W niektórych przypadkach sieci VPN aktywnie przerywają długotrwałe połączenia, co negatywnie wpływa na wygodę użytkowników z powodu nieodebranych lub opóźnionych wiadomości albo wysokiego kosztu baterii. Jeśli sieć VPN na to pozwala, omijamy ją za pomocą szyfrowanego połączenia (w sieci podstawowej Wi-Fi lub LTE), aby zapewnić niezawodne działanie i bezproblemowe korzystanie z baterii. Użycie przez FCM połączeń VPN z możliwością pominięcia dotyczy tylko kanału powiadomień push FCM. Inny ruch FCM, np. ruch zarejestrowany, korzysta z sieci VPN, jeśli jest aktywna. Gdy połączenie FCM omija sieć VPN, traci dodatkowe korzyści zapewniane przez tę usługę, takie jak maskowanie adresów IP.
Różne sieci VPN mają różne metody kontrolowania, czy można je ominąć. Instrukcje znajdziesz w dokumentacji konkretnej sieci VPN.
Jeśli sieć VPN nie jest skonfigurowana jako możliwa do pominięcia, Komunikacja w chmurze Firebase będzie łączyć się z serwerem przez sieć VPN. Może to spowodować opóźnienia w wiadomościach i zwiększyć wykorzystanie baterii, ponieważ Komunikacja w chmurze pracuje nad utrzymaniem połączenia przez połączenie VPN.
Dane uwierzytelniające
W zależności od wdrożonych funkcji FCM możesz potrzebować tych danych logowania z projektu Firebase:
| Identyfikator projektu | Unikalny identyfikator projektu Firebase używany w żądaniach wysyłanych do punktu końcowego HTTP FCM w wersji 1. Ta wartość jest dostępna w panelu Ustawienia konsoli Firebase. |
| Token rejestracji | Unikalny ciąg tokena identyfikujący każdą instancję aplikacji klienckiej. Token rejestracji jest wymagany do obsługi wiadomości na jednym urządzeniu i w grupie urządzeń. Pamiętaj, że tokeny rejestracji należy przechowywać w tajemnicy. |
| Identyfikator nadawcy | Unikalna wartość liczbowa utworzona podczas tworzenia projektu Firebase dostępna na karcie Komunikacja w chmurze w panelu Ustawienia w konsoli Firebase. Identyfikator nadawcy służy do identyfikacji każdego nadawcy, który może wysyłać wiadomości do aplikacji klienckiej. |
| Token dostępu | Tymczasowy token OAuth 2.0, który autoryzuje żądania wysyłane do interfejsu API HTTP v1. Ten token jest powiązany z kontem usługi, które należy do Twojego projektu Firebase. Aby utworzyć i wykonać rotację tokenów dostępu, wykonaj czynności opisane w sekcji Autoryzacja wysyłania żądań. |
| Klucz serwera (na potrzeby **wycofanych** starszych protokołów) | Klucz serwera, który autoryzuje serwer aplikacji na potrzeby dostępu do usług Google, w tym do wysyłania wiadomości za pomocą wycofanych starszych protokołów Firebase Cloud Messaging. Ważne: w kodzie klienta nie umieszczaj klucza serwera. Upewnij się też, że do autoryzacji serwera aplikacji używasz tylko kluczy serwera. FCM odrzuca Androida, platformę Apple i klucze przeglądarki. |