Informacje o wiadomościach w FCM

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ć.

Rodzaje 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”. Pakiet SDK FCM obsługuje je automatycznie.
• 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. Wyjątkiem jest wysyłanie wiadomości z konsoli Firebase, w której obowiązuje limit 1000 znaków.

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, jeśli chcesz przetwarzać wiadomości za pomocą własnego kodu aplikacji klienckiej.

FCM może wysyłać powiadomienia z opcjonalnym ładunkiem danych. W takich przypadkach FCM odpowiada za wyświetlanie danych payload powiadomienia, a aplikacja klienta za dane payload.

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 niezbędnym wstępnie zdefiniowanym zestawem opcji klucz-wartość dla widocznej dla użytkownika części powiadomienia. Oto na przykład wiadomość z powiadomieniem w aplikacji do obsługi wiadomości błyskawicznych zapisana w formacie JSON. 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ę wstępnie zdefiniowanych kluczy dostępnych w przypadku komunikatów z powiadomieniami o tworzeniu znajdziesz w dokumentacji referencyjnej obiektu powiadomień protokołu HTTP w wersji 1.

Komunikaty dotyczące danych

Aby wysłać ładunek danych do aplikacji klienckiej, ustaw odpowiedni klucz z niestandardowymi parami klucz-wartość.

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

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

Powyższy przykład 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 klienta otrzymuje ładunek danych w funkcji wywołania zwrotnego.

Szyfrowanie wiadomości z danymi

Warstwa transportu w Androidzie (zobacz architekturę FCM) używa szyfrowania typu punkt-punkt. W zależności od 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ć wiadomości z powiadomieniami zarówno programowo, jak i za pomocą konsoli Firebase, które zawierają opcjonalny ładunek danych 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 działa na pierwszym planie, aplikacja odbiera obiekt wiadomości z dostępnymi ładunkami.

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 i WebpushConfig, interpretowane tylko przez instancje aplikacji działające na określonej platformie.

Blokady związane z konkretnymi platformami umożliwiają dostosowywanie wiadomości do różnych platform, dzięki czemu są one przetwarzane poprawnie po otrzymaniu. Backend FCM weźmie pod uwagę wszystkie określone parametry i dostosuje wiadomość do każdej platformy.

Kiedy używać wspólnych pól

Używaj wspólnych pól, gdy:

• kierowanie na instancje aplikacji na wszystkich platformach: Apple, Android i internet;
• Wysyłanie wiadomości do tematów

Wszystkie instancje aplikacji (niezależnie od platformy) mogą interpretować te wspólne pola:

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

Kiedy używać pól związanych z poszczególnymi platformami

Używaj pól związanych z poszczególnymi platformami, 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 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, skorzystaj z pól na odpowiedniej platformie, aby je skonfigurować. 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: powiadomienie z opcjami dostarczania obowiązującymi na danej 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 danych w przypadku platform internetowych i Android, a priorytet wiadomości APNs (platformy Apple) zostaje ustawiony na niski
• ustawia odpowiednie klucze, aby zdefiniować wynik kliknięcia powiadomienia przez użytkownika na Androidzie i Apple – odpowiednio click_action i category.

{
  "message":{
     "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
     "notification":{
       "title":"Match update",
       "body":"Arsenal goal in added time, score is now 3-0"
     },
     "android":{
       "ttl":"86400s",
       "notification"{
         "click_action":"OPEN_ACTIVITY_1"
       }
     },
     "apns": {
       "headers": {
         "apns-priority": "5",
       },
       "payload": {
         "aps": {
           "category": "NEW_MESSAGE_CATEGORY"
         }
       }
     },
     "webpush":{
       "headers":{
         "TTL":"86400"
       }
     }
   }
 }

Szczegółowe informacje o kluczach dostępnych w blokach związanych z konkretną platformą w ciele wiadomości znajdziesz w dokumentacji 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 funkcja zwijania wiadomości jest obsługiwana na Androidzie przez platformę collapse_key FCM, na Apple przez apns-collapse-id oraz w języku JavaScript/internetowym przez Topic. Szczegółowe informacje znajdziesz w opisach w tej sekcji i powiązanej dokumentacji.

Wiadomości, których nie można zwijać ani zwijać

Wiadomość niezałamowana oznacza, że każda wiadomość jest dostarczana do urządzenia. Wiadomość, której nie można zwinąć, zawiera przydatne treści, w przeciwieństwie do wiadomości, której nie można zwinąć, np. „ping” bez treści, aby aplikacja mobilna mogła skontaktować się z serwerem i pobrać dane.

Typowe przypadki użycia wiadomości, których nie można zwijać, to wiadomości na czacie lub wiadomości krytyczne. Na przykład w aplikacji do 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 znowu połączy się z internetem, otrzyma specjalny komunikat 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 zwijaną w Androidzie, umieść w ładunku wiadomości parametr collapse_key. 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 zwinięcia, 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 z nich 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 zwijania przez FCM na token rejestracji w danym momencie. Nie możesz przekroczyć tej liczby, ponieważ może to spowodować nieprzewidziane konsekwencje.

Ustawianie priorytetu wiadomości

Priorytet dostarczania możesz przypisać do kolejnych wiadomości na 2 sposoby: normalny i wysoki. Chociaż działanie jest nieco inne w zależności od platformy, dostarczanie zwykłych wiadomości i wiadomości o wysokim priorytecie wygląda tak:

• Normalny priorytet. 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. Wiadomości o wysokim priorytecie są przeznaczone do przesyłania pilnych treści widocznych dla użytkowników.

Oto przykład wiadomości o normalnym priorytecie wysłanej za pomocą protokołu FCM HTTP 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 na poziomie platformy:

• 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 negatywny wpływ 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ść stanowi połączenie przychodzące lub powiadomienie na czacie wideo, jest ona ważna tylko przez krótki czas, zanim połączenie zostanie zakończone. Jeśli wiadomość jest zaproszeniem na wydarzenie, jest bezużyteczna, jeśli 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 wydarzenia zaproszeń
• 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 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 istnieje już wiadomość z tym samym kluczem składania (i tokenem rejestracji) przechowywana i oczekująca na dostarczenie, stara wiadomość zostaje odrzucona, a nowa zajmuje jej miejsce (czyli stara wiadomość zostaje złożona przez nową). Jeśli jednak nie ustawisz klucza collapse, zarówno nowe, jak i stare wiadomości zostaną zapisane na potrzeby przyszłych wysyłek.

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 nie zostanie ponownie połączone (na przykład jeśli zostało przywrócone do ustawień fabrycznych), wiadomość w końcu wygaśnie i zostanie usunięta z pamięci FCM. Domyślny limit czasu to 4 tygodnie, chyba że ustawiono flagę time_to_live.

Aby uzyskać więcej informacji o dostarczaniu wiadomości:

Więcej informacji o dostarczaniu wiadomości na platformach Android i Apple znajdziesz w panelu raportowania FCM, który rejestruje liczbę wysłanych i otwartych wiadomości na urządzeniach Apple i z Androidem oraz dane na temat wyświetleń (powiadomień widocznych dla użytkowników) w aplikacjach 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 prawidłowo obsłużyć sytuację, zwykle wysyłając do serwera aplikacji żądanie pełnej synchronizacji.

Na koniec, gdy FCM próbuje dostarczyć wiadomość na urządzenie, a aplikacja została odinstalowana, FCM natychmiast 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 przez 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 wzorce ruchu mogą powodować błędy związane z przekroczeniem limitu. W scenariuszu przekroczenia limitu system wyświetla kod stanu HTTP 429 (QUOTA_EXCEEDED), aż limit zostanie wypełniony w następnej minucie. Odpowiedzi 429 mogą być też zwracane w sytuacjach przeciążenia, dlatego zdecydowanie zalecamy obsługę odpowiedzi 429 zgodnie z opublikowanymi rekomendacjami.

Uwaga:

• Limit pobierania danych mierzy liczbę wiadomości, a nie żądań.
• Błędy klienta (kod stanu HTTP 400–499) są zliczane (z wyjątkiem kodu 429).
• Limity są podawane w minutach, ale nie są one dopasowywane do czasu zegara.

Limity

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

1. Otwórz konsolę Google Cloud.
2. Wybierz Interfejsy API i usługi.
3. Z listy tabel wybierz Firebase Cloud Messaging API.
4. 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 ruch wydaje się być 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.
• 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 kwoty o maksymalnie 25%, a FCM dołoży wszelkich starań, aby spełnić Twoje oczekiwania (nie możemy jednak zagwarantować zwiększenia limitu).

Jeśli potrzebujesz większej puli wiadomości na niższym poziomie z powodu zbliżającego się uruchomienia lub tymczasowego zdarzenia, 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. Prośby o uruchomienie i specjalne wydarzenia są nadal objęte wymaganiami dotyczącymi współczynnika błędów klienta i sprawdzonych metod.

Zobacz też odpowiedzi na pytania dotyczące limitów FCM.

Limit wiadomości w temacie

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 zwielokrotniania

Rozsyłanie wiadomości to proces wysyłania wiadomości na wiele urządzeń, np. gdy kierujesz reklamy na tematy i grupy lub gdy używasz Edytora powiadomień do kierowania na grupy odbiorców lub segmenty 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.

Rzeczywisty współczynnik ekspansji, które można osiągnąć, zależy od liczby projektów, które proszą o to w tym samym czasie. Współczynnik zwielokrotnienia 10 tys. zapytań/s w przypadku pojedynczego projektu nie jest niczym niezwykłym, ale ta liczba nie jest gwarantowana i jest wynikiem całkowitego obciążenia systemu. Warto zauważyć, że dostępna pojemność rozpowszechniania jest dzielona między projekty, a nie między żądaniami rozpowszechniania. Jeśli więc w Twoim projekcie 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, zwijane wiadomości to powiadomienia bez treści, które zwijają się na siebie. Jeśli deweloper powtarza tę samą wiadomość w aplikacji zbyt często, opóźniamy (ograniczamy) wysyłanie wiadomości, aby ograniczyć 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 częstych wzorców wysyłania serii, dobrym rozwiązaniem mogą być wiadomości, których nie można zwinąć. Pamiętaj, aby umieścić takie wiadomości w odpowiednich treściach, aby obniżyć koszty baterii.

Liczba składanych wiadomości jest ograniczona do 20 wiadomości na aplikację na urządzeniu, z możliwością uzupełnienia o 1 wiadomość 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 utrudniać dostarczania 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 wiadomości z serwera XMPP FCM ogranicza liczbę komunikatów nadrzędnych do 1 500 000 na minutę, aby uniknąć przeciążenia wcześniejszych serwerów docelowych.

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żna wysyłać do 240 wiadomości na minutę i 5000 wiadomości na godzinę na jedno urządzenie. Ten wysoki próg ma umożliwić krótkotrwałe skoki ruchu, np. gdy użytkownicy szybko wchodzą w interakcję z użytkownikiem na czacie. Ten limit zapobiega błędom w logice wysyłania, które mogą przypadkowo rozładować baterię 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 przez ograniczenia adresów IP zapory sieciowej często mają charakter przejściowy i trudne do zdiagnozowania.

Oferujemy zestaw nazw domen, które zamiast adresów IP można umieścić na liście dozwolonych. Nazwy hostów podano 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 w Twojej sieci działa translacja adresów sieciowych (NAT) lub stanowa inspekcja pakietów (SPI), zastosuj co najmniej 30-minutowy limit czasu połączeń przez porty 5228–5230. Dzięki temu możemy 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 sieci VPN aktywnie przerywają długotrwałe połączenia, co pogarsza wrażenia użytkowników z powodu brakujących lub opóźnionych wiadomości albo wysoki koszt baterii. Gdy sieć VPN jest skonfigurowana tak, abyśmy mogli to zrobić, omijamy VPN, używając 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 zalety, jakie zapewnia VPN, takie jak maskowanie adresu IP.

Różne sieci VPN mają różne metody kontroli, które decydują o tym, czy można je ominąć. Instrukcje znajdziesz w dokumentacji konkretnej sieci VPN.

Jeśli sieć VPN nie jest skonfigurowana do pomijania, Firebase Cloud Messaging użyje jej do nawiązania połączenia z serwerem. Może to spowodować opóźnienia w wysyłaniu wiadomości i większe wykorzystanie baterii, ponieważ Cloud Messaging utrzymuje 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 projektu Firebase: