Informacje o wiadomościach w FCM

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Firebase Cloud Messaging (FCM) oferuje szeroki zakres opcji i możliwości przesyłania wiadomości. Informacje na tej stronie pomogą Ci zrozumieć różne typy wiadomości FCM i to, co możesz z nimi zrobić.

Typy wiadomości

Za pomocą FCM możesz wysyłać do klientów 2 rodzaje wiadomości:

• wiadomościami z powiadomieniami, które czasami nazywa się „wiadomościami 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, z wyjątkiem sytuacji, gdy wysyłasz wiadomości z konsoli Firebase, która narzuca 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, gdy 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 kliencka za dane payload.

Wiadomości z powiadomieniami

Do testowania, marketingu i przywracania 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ą w dostosowywaniu i ulepszaniu komunikatów marketingowych.

Aby programowo wysyłać powiadomienia za pomocą pakietu Admin SDK lub protokołów FCM, ustaw klucz notification z wymaganym wstępnie zdefiniowanym zestawem opcji klucz-wartość dla widocznej dla użytkownika części powiadomienia. Oto na przykład wiadomość z powiadomieniem w formacie JSON w aplikacji do przesyłania wiadomości błyskawicznych. Użytkownik zobaczy na urządzeniu wiadomość z tytułem „Portugalia – Dania” i tekstem „Świetny mecz!”:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

Wiadomości z powiadomieniami są dostarczane do obszaru powiadomień, gdy aplikacja działa w tle. W przypadku aplikacji na pierwszym planie wiadomości są obsługiwane przez funkcję wywołania zwrotnego.

Pełną listę zdefiniowanych wstępnie kluczy dostępnych do tworzenia wiadomości z powiadomieniami znajdziesz w dokumentacji obiektu powiadomienia HTTP v1 Protocol.

Komunikaty dotyczące danych

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

Oto na przykład wiadomość w formacie JSON w tej samej aplikacji do obsługi wiadomości błyskawicznych, w której informacje są zaszyfrowane w kluczu wspólnym data, a aplikacja kliencka ma interpretować zawartość:

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

Powyższy przykład pokazuje użycie pola najwyższego poziomu, czyli wspólnego pola data, które jest interpretowane przez klientów na wszystkich platformach, które otrzymują wiadomość. Na każdej platformie aplikacja klienta otrzymuje ładunek danych w funkcji wywołania zwrotnego.

Szyfrowanie wiadomości danych

Warstwę transportową Androida (patrz architektura FCM) wykorzystuje szyfrowanie punkt-punkt. W zależności od potrzeb możesz dodać szyfrowanie end-to-end do wiadomości danych. FCM nie zapewnia kompleksowego rozwiązania. Dostępne są jednak rozwiązania zewnętrzne, takie jak Capillary czy DTLS.

wiadomości z opcjonalnym ładunkiem danych,

Możesz wysyłać 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  składance powiadomień użyj pól Dane niestandardowe w sekcji Opcje zaawansowane.

Sposób działania aplikacji podczas odbierania wiadomości zawierających zarówno dane, jak i dane dotyczące powiadomienia, zależy od tego, czy aplikacja działa w tle, czy na pierwszym planie, a także od tego, czy jest aktywna w momencie odbioru.

• W tle aplikacje otrzymują dane powiadomienia w obszarze powiadomień i obsługują je tylko wtedy, gdy użytkownik kliknie powiadomienie.
• Gdy aplikacja działa na pierwszym planie, otrzymuje obiekt message z obiema dostępnymi ładowaniami.

Oto wiadomość w formacie JSON zawierająca klucz notification i klucz data:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

Dostosowywanie wiadomości na różnych platformach

Zarówno protokół Firebase Admin SDK, jak i protokół HTTP FCM w wersji 1 umożliwiają ustawianie w żądaniach wiadomości wszystkich pól dostępnych w obiekcie message. Obejmuje to m.in.:

• wspólny zestaw pól, który ma być interpretowany przez wszystkie wystąpienia aplikacji, które otrzymują wiadomość.
• zestawy pól związane z konkretną platformą, np. AndroidConfig i WebpushConfig, interpretowane tylko przez instancje aplikacji działające na określonej platformie.

Blokady dla poszczególnych platform umożliwiają dostosowywanie wiadomości do różnych platform, aby zapewnić ich prawidłowe przetwarzanie po otrzymaniu. Backend FCM weźmie pod uwagę wszystkie określone parametry i dostosuje wiadomość do każdej platformy.

Kiedy używać pól wspólnych

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

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

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

• 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łanie pól tylko na określone platformy
• Wyślij pola specyficzne dla platformy oprócz pól wspólnych.

Jeśli chcesz wysyłać wartości tylko na określone platformy, nie używaj wspólnych pól. Zamiast nich używaj pól specyficznych dla danej platformy. Aby na przykład wysyłać powiadomienia tylko na platformy Apple i do przeglądarki, ale nie na urządzenia z Androidem, musisz użyć 2 oddzielnych zestawów pól: jednego dla Apple i drugiego dla przeglądarki.

Jeśli wysyłasz wiadomości z określonymi opcjami dostarczania, użyj pól określonych dla danej platformy, aby je ustawić. W razie potrzeby możesz podać różne wartości dla poszczególnych platform. Jednak nawet wtedy, gdy chcesz ustawić tę samą wartość na wszystkich platformach, musisz użyć pól specyficznych dla danej platformy. Dzieje się tak, ponieważ każda platforma może interpretować tę wartość nieco inaczej. Na przykład czas życia w Androidzie jest ustawiany jako czas wygaśnięcia w sekundach, a w przypadku Apple jako data wygaśnięcia.

Przykład: wiadomość z powiadomieniem z opcjami dostarczania na poszczególnych platformach

Poniższe żądanie wysyłania w wersji 1 wysyła wspólny tytuł i treść powiadomienia do wszystkich platform, ale też niektóre zastąpienia specyficzne dla danej platformy. W szczególności prośba:

• ustawia długi czas życia dla platform Android i internetowych, a priorytet wiadomości APN (platformy Apple) ustawia 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 specyficznych dla platformy w ciele wiadomości znajdziesz w dokumentacji referencyjnej HTTP w wersji 1. Więcej informacji o tworzeniu żądań wysyłania, które zawierają treść wiadomości, znajdziesz w artykule Tworzenie żądań wysyłania.

Opcje dostawy

FCM udostępnia określony zestaw opcji dostarczania wiadomości wysyłanych na urządzenia z Androidem oraz umożliwia korzystanie z podobnych opcji na platformach Apple i w internecie. Na przykład zachowanie „zwinięcia” jest obsługiwane na Androidzie za pomocą FCM collapse_key, na urządzeniach Apple za pomocą apns-collapse-id oraz w JavaScript/na stronie internetowej za pomocą Topic. Szczegółowe informacje znajdziesz w opisach w tej sekcji i powiązanej dokumentacji.

Wiadomości niezwijane i zwijane

Wiadomość niezałamana oznacza, że każda wiadomość jest dostarczana do urządzenia. Wiadomość nieskładana zawiera przydatne treści, w przeciwieństwie do wiadomości składanej, która jest pusta i służy do nawiązania kontaktu z aplikacją mobilną w celu pobrania danych z serwera.

Typowymi przykładami nieskładanych wiadomości są wiadomości czatu lub wiadomości o wysokiej priorytecie. Na przykład w aplikacji do przesyłania wiadomości MMS-owych chcesz dostarczyć wszystkie wiadomości, ponieważ każda z nich ma inną treść.

W przypadku Androida można zapisać bez zwijania 100 wiadomości. Jeśli zostanie osiągnięty limit, wszystkie przechowywane wiadomości zostaną odrzucone. Gdy urządzenie ponownie połączy się z internetem, otrzyma specjalną wiadomość z informacją o osiągnięciu limitu. Aplikacja może wtedy odpowiednio zareagować, zwykle prosząc o pełną synchronizację z serwera aplikacji.

Wiadomość z możliwością złożenia to wiadomość, która może zostać zastąpiona nową wiadomością, jeśli nie została jeszcze dostarczona na urządzenie.

Zwijane komunikaty są często używane do informowania aplikacji mobilnej o potrzebie zsynchronizowania danych z serwerem. Przykładem może być aplikacja sportowa, która informuje użytkowników o najnowszych wynikach. Ważna jest tylko najnowsza wiadomość.

Aby oznaczyć wiadomość jako składaną na urządzeniu z Androidem, dodaj parametr collapse_key do danych wiadomości. Domyślnie klucz składania to nazwa pakietu aplikacji zarejestrowana w konsoli Firebase. Serwer FCM może jednocześnie przechowywać 4 różne zwijane wiadomości na urządzenie, z których każda ma inny klucz zwinięcia. Jeśli przekroczysz tę liczbę, FCM zachowa tylko 4 klucze zwijania, bez gwarancji, które z nich zostaną zachowane.

Wiadomości dotyczące tematu bez ładunku są domyślnie zwijane. Wiadomości z powiadomieniami są zawsze możliwe do zwinięcia i ignorują parametr collapse_key.

Którego mam użyć?

Z punktu widzenia wydajności lepsze są wiadomości, które można zwinąć, o ile Twoja aplikacja nie musi używać wiadomości, których nie można zwinąć. Jeśli jednak używasz wiadomości z możliwością zwijania, pamiętaj, że FCM pozwala na używanie maksymalnie 4 różnych kluczy 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

Masz 2 opcje przypisywania priorytetu dostawy wiadomościom wysyłanym dalej: normalny i wysoki priorytet. Chociaż działanie różni się nieco w zależności od platformy, dostarczanie wiadomości o normalnym i wysokim priorytecie wygląda tak:

• Normalny priorytet. Wiadomości o normalnym priorytecie są dostarczane natychmiast, gdy aplikacja działa na pierwszym planie. W przypadku aplikacji działających w tle dostawa może być opóźniona. W przypadku wiadomości, które nie są tak pilne, np. powiadomień o nowych e-mailach, synchronizacji interfejsu lub synchronizacji danych aplikacji w tle, wybierz normalny priorytet przesyłania.

• Wysoki priorytet. Komunikacja w chmurze Firebase próbuje natychmiast dostarczać wiadomości o wysokiej priorytecie, nawet jeśli urządzenie jest w trybie Doze. Wiadomości o wysokim priorytecie dotyczą treści, które są widoczne dla użytkownika i mają ograniczony czas ważności.

Oto przykład wiadomości o normalnym priorytecie wysłanej za pomocą protokołu FCMHTTP w wersji 1, aby powiadomić subskrybenta czasopisma o dostępności nowych treści do pobrania:

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

Więcej informacji o ustawianiu priorytetu wiadomości w przypadku poszczególnych platform:

• Dokumentacja APNs
• Ustawianie priorytetu wiadomości i zarządzanie nim (Android)
• Poziom pilności wiadomości ze stron internetowych

Krytyczne przypadki użycia

Interfejsy API FCM nie są przeznaczone do ostrzegania o wypadkach i innych działaniach wysokiego ryzyka, w przypadku których użycie lub błąd interfejsów API może doprowadzić do śmierci, obrażeń ciała lub szkód dla środowiska (takich jak obsługa obiektów jądrowych, kontrola lotów lub 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ą one dostępne”, i zastrzega sobie prawo do zaprzestania udostępniania interfejsów API lub dowolnej ich części lub funkcji oraz dostępu do nich z dowolnego powodu i w dowolnym momencie bez ponoszenia odpowiedzialności lub innych zobowiązań wobec Dewelopera lub jego użytkowników.

Ustawianie okresu ważności wiadomości

FCM zwykle dostarcza wiadomości natychmiast po ich wysłaniu. Nie zawsze jest to jednak możliwe. Jeśli na przykład platforma to Android, urządzenie może być wyłączone, offline lub niedostępne z innego powodu. Aplikacja FCM może też celowo opóźniać wiadomości, aby zapobiec nadmiernemu zużyciu zasobów przez aplikację i niekorzystnemu wpływowi na czas pracy na baterii.

W takim przypadku FCMzapisujemy wiadomość i dostarczamy ją tak szybko, jak to możliwe. W większości przypadków jest to w porządku, ale w niektórych aplikacjach opóźnione wiadomości mogą wcale nie dotrzeć. Jeśli na przykład wiadomość dotyczy nadchodzącego połączenia lub powiadomienia o rozmowie wideo, jest ona istotna tylko przez krótki czas przed zakończeniem połączenia. Jeśli wiadomość jest zaproszeniem na wydarzenie, jest bezużyteczna, jeśli została dostarczona po zakończeniu wydarzenia.

W Androidzie i na platformie Web/JavaScript możesz określić maksymalny czas życia wiadomości. Wartość musi być czasem trwania od 0 do 2419 200 sekund (28 dni) i odpowiada maksymalnemu okresowi, przez który usługa FCM przechowuje i próbuje dostarczyć wiadomość. W przypadku żądań, które nie zawierają tego pola, domyślnie ustawiany jest maksymalny okres 4 tygodnie.

Oto kilka możliwych zastosowań tej funkcji:

• Połączenia przychodzące na czacie wideo
• Wygasające zaproszenia
• Wydarzenia w kalendarzu

Kolejną zaletą określania czasu życia wiadomości jest to, że FCM nie stosuje ograniczania liczby wyświetleń wiadomości, które można złożyć, w przypadku wiadomości o wartości TTL wynoszącej 0 sekund. FCM zapewnia jak najlepszą obsługę wiadomości, które muszą zostać dostarczone „teraz lub nigdy”. Pamiętaj, że wartość time_to_live 0 oznacza, że wiadomości, których nie można dostarczyć natychmiast, są odrzucane. Jednak ponieważ takie wiadomości nigdy nie są przechowywane, zapewnia to najkrótszy czas opóźnienia przy wysyłaniu powiadomień.

Oto przykład żądania z uwzględnieniem czasu trwania:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    },
    "apns":{
      "headers":{
        "apns-expiration":"1604750400"
      }
    },
    "android":{
      "ttl":"4500s"
    },
    "webpush":{
      "headers":{
        "TTL":"4500"
      }
    }
  }
}

Czas trwania wiadomości

Gdy serwer aplikacji publikuje wiadomość na stronie FCM i otrzymuje w zamian identyfikator wiadomości, nie oznacza to, że wiadomość została już dostarczona na urządzenie. Oznacza to, że została zaakceptowana do dostarczenia. To, co dzieje się z wiadomością po jej zaakceptowaniu, zależy od wielu czynników.

W najlepszym przypadku, jeśli urządzenie jest połączone z FCM, ekran jest włączony i nie ma ograniczeń w obrębie usługi, wiadomość zostanie dostarczona natychmiast.

Jeśli urządzenie jest połączone, ale znajduje się w trybie Doze, wiadomość o niskim priorytecie jest przechowywana przez FCM do momentu, gdy urządzenie wyjdzie z tego trybu. Właśnie w tym miejscu flaga collapse_key odgrywa swoją rolę: 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 klucz collapse nie jest ustawiony, zarówno nowe, jak i stare wiadomości są przechowywane na potrzeby przyszłej wysyłki.

Jeśli urządzenie nie jest połączone z FCM, wiadomość jest przechowywana do czasu nawiązania połączenia (z ponownym uwzględnieniem reguł dotyczących klucza zwinięcia). Po nawiązaniu połączenia FCM prześle na urządzenie wszystkie oczekujące wiadomości. Jeśli urządzenie nigdy więcej nie zostanie połączone (na przykład, jeśli zostało zresetowane do ustawień fabrycznych), wiadomość ostatecznie wygaśnie i zostanie usunięta z pamięci FCM. Domyślny limit czasu to 4 tygodnie, chyba że ustawiono flagę time_to_live.

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

Aby uzyskać więcej informacji o dostarczaniu wiadomości na platformach Android i Apple, skorzystaj z  FCMpanelu raportów, który zawiera informacje o liczbie wiadomości wysłanych i otwartych na urządzeniach Apple i Android oraz dane o wyświetleniach (powiadomieniach wyświetlanych użytkownikom) aplikacji na Androida.

W przypadku urządzeń z Androidem z włączoną opcją wysyłania wiadomości przez kanał bezpośredni, 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 z danymi, klient otrzyma wywołanie zwrotne onDeletedMessages(). Aplikacja może wtedy odpowiednio zareagować, zwykle prosząc o pełną synchronizację z serwera aplikacji.

Gdy FCM próbuje dostarczyć wiadomość na urządzenie, a aplikacja została odinstalowana, FCM od razu odrzuca tę wiadomość i unieważnia token rejestracji. Kolejne próby wysłania wiadomości do tego urządzenia spowodują błąd NotRegistered.

Ograniczanie liczby żądań i limity

Naszym celem jest zawsze dostarczanie wszystkich wiadomości wysyłanych za pomocą FCM. Jednak przesyłanie wszystkich wiadomości może czasami powodować niekorzystne wrażenia użytkowników. W innych przypadkach musimy wyznaczać granice, aby mieć pewność, że FCM zapewnia skalowalny serwis dla wszystkich nadawców. Rodzaje limitów i kwot opisane w tej sekcji pomagają nam zachować równowagę między tymi ważnymi czynnikami.

Ograniczanie przesyłania wiadomości w dół łańcucha

W interfejsie HTTP w wersji 1 wprowadzono limity na projekt i 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 dużym natężeniu.

Nagłe zmiany w natężeniu ruchu mogą powodować błędy związane z przekroczeniem limitu. W przypadku przekroczenia limitu system zwraca kod stanu HTTP 429 (QUOTA_EXCEEDED), dopóki limit nie zostanie uzupełniony w nastę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 na ścieżce w dół dotyczy liczby wiadomości, a nie żądań.
• Błędy klienta (kod stanu HTTP 400–499) są zliczane (z wyjątkiem kodu 429).
• Limity są ustalane na minuty, ale nie są one dopasowane do zegara.

Limity

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

1. Otwórz konsolę Google Cloud.
2. Kliknij 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 ruchu.
• Stosujesz sprawdzone metody wysyłania wiadomości na dużą skalę.

Jeśli spełniasz te kryteria, możesz przesłać prośbę o zwiększenie limitu kwoty o maksymalnie 25%, a FCM dołoży wszelkich starań, aby spełnić Twoją prośbę (nie możemy zagwarantować zwiększenia limitu).

Jeśli potrzebujesz większej puli wiadomości na niższym poziomie ze względu na zbliżający się termin lub tymczasowe zdarzenie, poproś o pulę z co najmniej 15-dniowym wyprzedzeniem, abyśmy mieli wystarczająco dużo czasu na rozpatrzenie prośby. W przypadku dużych zapytań (ponad 18 mln wiadomości na minutę) wymagane jest co najmniej 30-dniowe powiadomienie. 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 związanych z tematem

Szybkość dodawania i usuwania subskrypcji tematu jest ograniczona do 3000 zapytań na sekundę na projekt.

Informacje o częstotliwości wysyłania wiadomości znajdziesz w artykule Ograniczanie rozsyłania.

Ograniczanie wyjścia

Rozsyłanie wiadomości to proces wysyłania wiadomości na wiele urządzeń, np. gdy kierujesz reklamy na tematy i grupy lub używasz Edytora powiadomień, aby docierać do określonych odbiorców lub segmentów użytkowników.

Rozpowszechnianie wiadomości nie jest natychmiastowe, dlatego czasami może się zdarzyć, że rozpowszechnianie odbywa się równolegle. Ograniczamy liczbę równoczesnych rozsyłek wiadomości na projekt do 1000. Po tym czasie możemy odrzucić dodatkowe prośby o rozproszenie lub odłożyć ich realizację do czasu zakończenia rozprzestrzeniania, które już się rozpoczęło.

Na rzeczywistą osiągalną szybkość rozgałęzienia wpływa liczba projektów, które jednocześnie wysyłają żądania rozgałęzienia. Częstotliwość rozgałęzienia 10 tys. QPS w przypadku pojedynczego projektu nie jest rzadkością, ale ta liczba nie jest gwarantowana i jest wynikiem całkowitego obciążenia systemu. Pamiętaj, że dostępna pojemność rozgałęzienia jest dzielona między projekty, a nie między prośbami o rozgałęzienie. Jeśli więc w Twoim projekcie są 2 rozgałęzienia w toku, każde z nich będzie korzystać tylko z połowy dostępnej szybkości. Aby zmaksymalizować szybkość rozgałęzienia, zalecamy prowadzenie tylko 1 aktywnej operacji rozgałęzienia.

ograniczanie liczby wiadomości zwijanych,

Jak opisano powyżej, składane wiadomości to powiadomienia bez treści, które są przeznaczone do składania 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ć wysyłanie kolejnego żądania synchronizacji e-maili o kilka minut, aby urządzenie mogło synchronizować się z niższą średnią szybkością. Ograniczenie to jest wprowadzane wyłącznie w celu ograniczenia wpływu na zużycie baterii odczuwanego przez użytkownika.

Jeśli Twój przypadek użycia wymaga wysyłania dużej liczby wiadomości w krótkim czasie, wiadomości nieskładane mogą być odpowiednim wyborem. W takich wiadomościach uwzględnij treść, aby zmniejszyć zużycie baterii.

Liczba składanych wiadomości jest ograniczona do 20 wiadomości na aplikację na urządzeniu, z możliwością uzupełnienia o 1 wiadomość co 3 minuty.

Maksymalna częstotliwość wysyłania wiadomości na jedno urządzenie

W przypadku Androida możesz wysyłać maksymalnie 240 wiadomości na minutę i 5000 wiadomości na godzinę na jedno urządzenie. Wysoki próg ma na celu umożliwienie krótkotrwałych wzrostów ruchu, na przykład gdy użytkownicy szybko komunikują się w czacie. Ten limit zapobiega błędom w logika 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 portu 443, 5229 lub 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łyby się zdezaktualizować, co miałoby wpływ na komfort użytkowników. W idealnej sytuacji porty 5228–5230 i 443 powinny być dozwolone bez ograniczeń adresów IP. Jeśli jednak musisz ustawić ograniczenie adresów IP, dodaj do listy dozwolonych wszystkie adresy IP wymienione w pliku goog.json. Ta duża lista jest regularnie aktualizowana, dlatego zalecamy aktualizowanie reguł co miesiąc. Problemy spowodowane ograniczeniami dotyczącymi adresów IP w zaporze sieciowej są często sporadyczne i trudne do zdiagnozowania.

Oferujemy zestaw nazw domen, które można dodać do listy dozwolonych zamiast adresów IP. Te nazwy hostów znajdziesz poniżej. Jeśli zaczniemy używać dodatkowych nazw hostów, zaktualizujemy tę listę. Korzystanie z nazwy domeny w regułach zapory może, ale nie musi działać na Twoim urządzeniu z zaporą.

Porty TCP do otwarcia:

• 5228
• 5229
• 5230
• 443

Nazwy hostów do otwarcia:

• mtalk.google.com
• mtalk4.google.com
• mtalk-staging.google.com
• mtalk-dev.google.com
• alt1-mtalk.google.com
• alt2-mtalk.google.com
• alt3-mtalk.google.com
• alt4-mtalk.google.com
• alt5-mtalk.google.com
• alt6-mtalk.google.com
• alt7-mtalk.google.com
• alt8-mtalk.google.com
• android.apis.google.com
• device-provisioning.googleapis.com
• firebaseinstallations.googleapis.com

zapora sieciowa NAT lub zapora z kontrolą stanu pakietów:

Jeśli Twoja sieć korzysta z funkcji NAT (Network Address Translation) lub SPI (Stateful Packet Inspection), ustaw limit czasu na 30 minut lub dłuższy w przypadku połączeń przez porty 5228–5230. Dzięki temu możemy zapewnić niezawodną łączność, jednocześnie zmniejszając zużycie baterii urządzeń mobilnych użytkowników.

Interakcje z siecią VPN i możliwość jej obejścia

Firebase Cloud Messaging podejmuje różne działania, aby zapewnić niezawodność i jak najczęstszą dostępność połączenia wiadomości push od telefonu do serwera. Korzystanie z sieci VPN komplikuje ten proces.

Sieci VPN maskują informacje, których FCM potrzebuje do dostosowania połączenia, aby zmaksymalizować niezawodność i czas pracy na baterii. W niektórych przypadkach VPN-y aktywnie przerywają długotrwałe połączenia, co powoduje niewygodę użytkowników z powodu braku lub opóźnienia wiadomości albo wysokiego zużycia baterii. Gdy sieć VPN jest skonfigurowana tak, abyśmy mogli to zrobić, omijamy ją, korzystając z szyfrowanego połączenia (przez sieć podstawową Wi-Fi lub LTE), aby zapewnić niezawodność i oszczędność baterii. Korzystanie przez FCM z omijalnych sieci VPN jest specyficzne dla kanału FCM Push Notification. Inny ruch FCM, np. ruch związany z rejestracją, korzysta z sieci VPN, jeśli jest ona aktywna. Gdy połączenie FCMominie sieć VPN, traci dodatkowe korzyści, jakie zapewnia VPN, takie jak maskowanie adresu IP.

Różne sieci VPN mają różne metody kontrolowania, czy można je obejść. Instrukcje znajdziesz w dokumentacji konkretnej sieci VPN.

Jeśli sieć VPN nie jest skonfigurowana tak, aby można było ją ominąć, Firebase Cloud Messaging użyje sieci VPN, aby połączyć się z serwerem. Może to powodować opóźnienia w dostarczaniu wiadomości i większe zużycie baterii, ponieważ Cloud Messaging stara się utrzymać połączenie przez sieć VPN.

Dane logowania

W zależności od tego, które funkcje FCM chcesz zaimplementować, możesz potrzebować tych danych logowania z Twojego projektu Firebase: