Firebase Cloud Messaging (FCM) oferuje szeroką gamę opcji i możliwości przesyłania wiadomości. Informacje zawarte na tej stronie mają pomóc Ci zrozumieć różne typy komunikatów FCM i dowiedzieć się, co możesz z nimi zrobić.
Typy wiadomości
Dzięki FCM możesz wysyłać do klientów dwa rodzaje wiadomości:
- Wiadomości z powiadomieniami, czasami nazywane „wiadomościami wyświetlanymi”. Są one obsługiwane automatycznie przez pakiet FCM SDK.
- Komunikaty danych obsługiwane przez aplikację kliencką.
Wiadomości powiadamiające zawierają predefiniowany zestaw kluczy widocznych dla użytkownika. Z kolei wiadomości zawierające dane zawierają tylko niestandardowe pary klucz-wartość zdefiniowane przez użytkownika. Komunikaty powiadomień mogą zawierać opcjonalny ładunek danych. Maksymalny ładunek obu typów wiadomości wynosi 4000 bajtów, z wyjątkiem wysyłania wiadomości z konsoli Firebase, która wymusza limit 1000 znaków.
| Użyj scenariusza | Jak wysłać | |
|---|---|---|
| Wiadomość powiadamiająca | FCM SDK wyświetla komunikat na urządzeniach użytkowników końcowych w imieniu aplikacji klienckiej, gdy działa ona w tle. W przeciwnym razie, jeśli aplikacja działa na pierwszym planie po otrzymaniu powiadomienia, kod aplikacji określa zachowanie. Wiadomości powiadamiające mają predefiniowany zestaw kluczy widocznych dla użytkownika i opcjonalny ładunek danych w postaci niestandardowych par klucz-wartość. |
|
| Wiadomość danych | Aplikacja kliencka odpowiada za przetwarzanie komunikatów z danymi. Komunikaty danych mają tylko niestandardowe pary klucz-wartość bez zastrzeżonych 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żyj komunikatów powiadomień, jeśli chcesz, aby zestaw SDK FCM obsługiwał automatyczne wyświetlanie powiadomień, gdy aplikacja działa w tle. Użyj komunikatów danych, jeśli chcesz przetwarzać komunikaty przy użyciu własnego kodu aplikacji klienckiej.
FCM może wysłać powiadomienie zawierające opcjonalny ładunek danych. W takich przypadkach FCM obsługuje wyświetlanie ładunku powiadomienia, a aplikacja kliencka obsługuje ładunek danych.
Powiadomienia
Do testowania lub w celach marketingowych i ponownego zaangażowania użytkowników możesz wysyłać powiadomienia za pomocą konsoli Firebase . Konsola Firebase zapewnia oparte na analizach testy A/B , które pomogą Ci udoskonalić i ulepszyć 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 powiadomienie w formacie JSON w aplikacji komunikatora. Użytkownik może spodziewać się komunikatu zatytułowanego „Portugalia kontra Dania” i tekstu „świetny mecz!” na urządzeniu:
{
"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ę predefiniowanych kluczy dostępnych do tworzenia komunikatów powiadomień można znaleźć w dokumentacji obiektu powiadomień protokołu HTTP v1 .
Wiadomości danych
Ustaw odpowiedni klucz za pomocą niestandardowych par klucz-wartość, aby wysłać ładunek danych do aplikacji klienckiej.
Na przykład oto wiadomość w formacie JSON w tej samej aplikacji komunikatora co powyżej, gdzie informacje są zawarte we wspólnym kluczu data i oczekuje się, że aplikacja kliencka zinterpretuje treść:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
} Powyższy przykład pokazuje użycie najwyższego poziomu, czyli wspólnego pola data , które jest interpretowane przez klientów na wszystkich platformach, które odbierają wiadomość. Na każdej platformie aplikacja kliencka odbiera ładunek danych w funkcji wywołania zwrotnego.
Szyfrowanie wiadomości z danymi
Warstwa transportowa systemu Android (patrz architektura FCM ) wykorzystuje szyfrowanie punkt-punkt. W zależności od potrzeb możesz zdecydować się na dodanie kompleksowego szyfrowania do wiadomości danych. FCM nie zapewnia kompleksowego rozwiązania. Dostępne są jednak rozwiązania zewnętrzne, takie jak Capillary lub DTLS .
Komunikaty powiadomień z opcjonalnym ładunkiem danych
Zarówno programowo, jak i za pośrednictwem konsoli Firebase, możesz wysyłać powiadomienia zawierające opcjonalny ładunek niestandardowych par klucz-wartość. W kreatorze powiadomień użyj niestandardowych pól danych w opcjach zaawansowanych .
Zachowanie aplikacji podczas odbierania wiadomości zawierających zarówno powiadomienia, jak i dane zależy od tego, czy aplikacja znajduje się w tle, czy na pierwszym planie — zasadniczo od tego, czy jest aktywna w momencie otrzymania.
- Aplikacje działające w tle otrzymują ładunek powiadomień na pasku powiadomień i obsługują ładunek danych tylko wtedy, gdy użytkownik dotknie powiadomienia.
- Gdy aplikacja znajduje się na pierwszym planie , otrzymuje obiekt komunikatu z dostępnymi obydwoma ładunkami.
Oto wiadomość w formacie JSON zawierająca 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 wiadomości na różnych platformach
Zarówno pakiet Firebase Admin SDK, jak i protokół HTTP FCM v1 umożliwiają żądaniom wiadomości ustawienie wszystkich pól dostępnych w obiekcie message . To zawiera:
- wspólny zestaw pól interpretowanych przez wszystkie instancje aplikacji, które odbierają wiadomość.
- zestawy pól specyficzne dla platformy, takie jak
AndroidConfigiWebpushConfig, interpretowane tylko przez instancje aplikacji działające na określonej platformie.
Bloki specyficzne dla platformy zapewniają elastyczność dostosowywania wiadomości dla różnych platform, aby zapewnić ich prawidłową obsługę po odebraniu. Backend FCM weźmie pod uwagę wszystkie określone parametry i dostosuje komunikat dla każdej platformy.
Kiedy używać typowych pól
Używaj typowych 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ć następujące wspólne pola:
Kiedy używać pól specyficznych dla platformy
Użyj pól specyficznych dla platformy, jeśli chcesz:
- Wysyłaj pola tylko na określone platformy
- Oprócz typowych pól wysyłaj pola specyficzne dla platformy
Jeśli chcesz wysyłać wartości tylko do określonych platform, nie używaj wspólnych pól; użyj pól specyficznych dla platformy. Na przykład, aby wysłać powiadomienie tylko do platform Apple i Internetu, ale nie do systemu Android, musisz użyć dwóch oddzielnych zestawów pól, jednego dla Apple i jednego dla Internetu.
Jeśli wysyłasz wiadomości z określonymi opcjami dostarczania , użyj pól specyficznych dla platformy, aby je ustawić. Jeśli chcesz, możesz określić różne wartości dla każdej platformy. Jednak nawet jeśli chcesz ustawić zasadniczo tę samą wartość na różnych platformach, musisz użyć pól specyficznych dla platformy. Dzieje się tak dlatego, że każda platforma może nieco inaczej interpretować tę wartość — na przykład czas wygaśnięcia w systemie Android jest ustawiany jako czas wygaśnięcia w sekundach, natomiast w Apple jako data wygaśnięcia.
Przykład: wiadomość z powiadomieniem z opcjami dostawy specyficznymi dla platformy
Następujące żądanie wysłania w wersji 1 wysyła wspólny tytuł powiadomienia i treść do wszystkich platform, ale wysyła także pewne zastąpienia specyficzne dla platformy. Konkretnie żądanie:
- ustawia długi czas życia dla platform Android i sieci Web, jednocześnie ustawiając priorytet wiadomości APN (platformy Apple) na niski
- ustawia odpowiednie klucze definiujące wynik dotknięcia powiadomienia przez użytkownika na Androidzie i 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"
}
}
}
}Pełne informacje na temat kluczy dostępnych w blokach specyficznych dla platformy w treści wiadomości można znaleźć w dokumentacji referencyjnej protokołu HTTP v1 . Aby uzyskać więcej informacji na temat tworzenia żądań wysłania zawierających treść wiadomości, zobacz Tworzenie żądań wysłania .
Opcje dostawy
FCM zapewnia określony zestaw opcji dostarczania wiadomości wysyłanych na urządzenia z systemem Android i umożliwia korzystanie z podobnych opcji na platformach Apple i w Internecie. Na przykład „zwijane” zachowanie wiadomości jest obsługiwane w systemie Android za pomocą collapse_key FCM, w systemie Apple za pośrednictwem apns-collapse-id oraz w JavaScript/Web za pośrednictwem Topic . Aby uzyskać szczegółowe informacje, zobacz opisy w tej sekcji i powiązaną dokumentację referencyjną.
Wiadomości niezwijane i składane
Wiadomość niezwijana oznacza, że każda pojedyncza wiadomość jest dostarczana do urządzenia. Wiadomość niezwijana dostarcza użyteczną treść, w przeciwieństwie do wiadomości zwijanej, takiej jak „ping” bez zawartości, do aplikacji mobilnej, aby skontaktować się z serwerem w celu pobrania danych.
Typowymi przypadkami użycia wiadomości niezwijalnych są wiadomości na czacie lub wiadomości krytyczne. Na przykład w aplikacji komunikatora chcesz dostarczyć każdą wiadomość, ponieważ każda wiadomość ma inną treść.
W przypadku Androida istnieje limit 100 wiadomości, które można przechowywać bez zwijania. Jeśli limit zostanie osiągnięty, wszystkie zapisane wiadomości zostaną odrzucone. Gdy urządzenie ponownie będzie online, otrzyma specjalny komunikat informujący o osiągnięciu limitu. Aplikacja może następnie prawidłowo poradzić sobie z sytuacją, zazwyczaj żądając pełnej synchronizacji z serwera aplikacji.
Wiadomość zwijana to wiadomość, którą można zastąpić nową, jeśli nie została jeszcze dostarczona na urządzenie.
Typowymi przypadkami użycia wiadomości zwijanych są wiadomości używane do informowania aplikacji mobilnej o konieczności synchronizacji danych z serwera. Przykładem może być aplikacja sportowa, która aktualizuje użytkowników najnowszymi wynikami. Tylko najnowsza wiadomość jest istotna.
Aby oznaczyć wiadomość jako zwijaną w systemie Android, dołącz parametr collapse_key do ładunku wiadomości. Domyślnie kluczem zwijania jest nazwa pakietu aplikacji zarejestrowana w konsoli Firebase. Serwer FCM może jednocześnie przechowywać cztery różne wiadomości zwijane na każdym urządzeniu, każdy z innym kluczem zwijania. Jeśli przekroczysz tę liczbę, FCM zachowa tylko cztery 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 powinienem użyć?
Wiadomości zwijane są lepszym wyborem z punktu widzenia wydajności, pod warunkiem, że aplikacja nie musi korzystać z wiadomości niezwijanych. Jeśli jednak używasz wiadomości zwijanych, pamiętaj, że FCM pozwala na użycie w danym momencie maksymalnie czterech różnych kluczy zwijania przez FCM na token rejestracji. Nie wolno przekraczać tej liczby, gdyż może to spowodować nieprzewidywalne konsekwencje.
| Użyj scenariusza | Jak wysłać | |
|---|---|---|
| Nieskładany | Każda wiadomość jest ważna dla aplikacji klienckiej i musi zostać dostarczona. | Z wyjątkiem powiadomień, domyślnie nie można zwijać wszystkich wiadomości. |
| Składany | Gdy pojawi się nowszy komunikat, który sprawia, że starszy, powiązany komunikat jest nieistotny 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 żądaniu wiadomości:
|
Ustawianie priorytetu wiadomości
Istnieją dwie możliwości przypisania priorytetu dostarczenia wiadomościom przesyłanym dalej: priorytet normalny i wysoki. Chociaż zachowanie różni się nieco w zależności od platformy, dostarczanie wiadomości o normalnym i wysokim priorytecie działa w następujący sposób:
Normalny priorytet. Wiadomości o normalnym priorytecie są dostarczane natychmiast, gdy aplikacja jest na pierwszym planie. W przypadku aplikacji działających w tle dostawa może być opóźniona. W przypadku wiadomości mniej wrażliwych na czas, takich jak powiadomienia o nowej wiadomości e-mail, synchronizacja interfejsu użytkownika lub synchronizacja danych aplikacji w tle, wybierz normalny priorytet dostarczania.
Wysoki priorytet. FCM próbuje natychmiast dostarczyć wiadomości o wysokim priorytecie, nawet jeśli urządzenie znajduje się w trybie drzemki. Wiadomości o wysokim priorytecie dotyczą treści wrażliwych na czas i widocznych dla użytkownika.
Oto przykład wiadomości o normalnym priorytecie wysyłanej za pośrednictwem protokołu FCM HTTP v1 w celu powiadomienia subskrybenta magazynu o dostępności nowej 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 szczegółów dotyczących ustawiania priorytetu wiadomości dotyczących konkretnej platformy:
Ustawianie czasu życia wiadomości
FCM zazwyczaj dostarcza wiadomości natychmiast po ich wysłaniu. Jednak nie zawsze może to być możliwe. Na przykład, jeśli platformą jest Android, urządzenie może być wyłączone, w trybie offline lub z innego powodu niedostępne. Lub FCM może celowo opóźniać wiadomości, aby zapobiec zużywaniu przez aplikację nadmiernych zasobów i negatywnemu wpływowi na żywotność baterii.
Gdy tak się stanie, FCM przechowuje wiadomość i dostarcza ją tak szybko, jak to możliwe. Chociaż w większości przypadków jest to w porządku, istnieją aplikacje, w przypadku których spóźniona wiadomość równie dobrze może nigdy nie zostać dostarczona. Na przykład, jeśli wiadomość jest powiadomieniem o połączeniu przychodzącym lub czacie wideo, ma ona znaczenie tylko przez krótki okres czasu, zanim połączenie zostanie zakończone. Lub jeśli wiadomość jest zaproszeniem na wydarzenie, otrzymanie jej po zakończeniu wydarzenia będzie bezużyteczne.
W przypadku Androida i Internetu/JavaScriptu możesz określić maksymalny czas życia wiadomości. Wartość musi mieć czas trwania od 0 do 2 419 200 sekund (28 dni) i odpowiada maksymalnemu okresowi czasu, przez jaki FCM przechowuje wiadomość i próbuje ją dostarczyć. Żądania niezawierające tego pola domyślnie mają maksymalny okres czterech tygodni.
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 komunikatu jest to, że FCM nie stosuje zwijanego ograniczania komunikatów do komunikatów o wartości czasu wygaśnięcia wynoszącej 0 sekund. FCM zapewnia najlepszą obsługę wiadomości, które muszą zostać dostarczone „teraz albo nigdy”. Należy pamiętać, że wartość time_to_live wynosząca 0 oznacza, że wiadomości, których nie można dostarczyć natychmiast, są odrzucane. Jednakże, ponieważ takie wiadomości nigdy nie są przechowywane, zapewnia to najlepsze opóźnienie w wysyłaniu powiadomień.
Oto przykład żądania zawierającego 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"
}
}
}
}Żywotność wiadomości
Kiedy serwer aplikacji wysyła wiadomość do FCM i otrzymuje z powrotem identyfikator wiadomości, nie oznacza to, że wiadomość została już dostarczona do urządzenia. Oznacza to raczej, że został przyjęty do dostawy. To, co stanie się z wiadomością po jej zaakceptowaniu, zależy od wielu czynników.
W najlepszym przypadku, jeśli urządzenie jest podłączone do FCM, ekran jest włączony i nie ma żadnych ograniczeń związanych z ograniczaniem przepustowości, wiadomość jest dostarczana od razu.
Jeśli urządzenie jest podłączone, ale znajduje się w trybie uśpienia, FCM przechowuje komunikat o niskim priorytecie do czasu, aż urządzenie wyjdzie z trybu uśpienia. I w tym miejscu flaga collapse_key odgrywa rolę: jeśli istnieje już wiadomość z tym samym kluczem zwinięcia (i tokenem rejestracji) przechowywana i oczekująca na dostarczenie, stara wiadomość jest odrzucana, a na jej miejsce zajmuje nowa wiadomość (to znaczy stara wiadomość jest zwinięta przez nową). Jeśli jednak klawisz zwijania nie jest ustawiony, zarówno nowe, jak i stare wiadomości są przechowywane w celu dostarczenia ich w przyszłości.
Jeśli urządzenie nie jest połączone z FCM, wiadomość jest przechowywana do czasu nawiązania połączenia (ponownie przestrzegając zasad klawisza zwijania). Po nawiązaniu połączenia FCM dostarcza do urządzenia wszystkie oczekujące wiadomości. Jeśli urządzenie nigdy więcej nie zostanie podłączone (na przykład po przywróceniu ustawień fabrycznych), komunikat ostatecznie upłynie i zostanie usunięty z pamięci FCM. Domyślny limit czasu wynosi cztery tygodnie, chyba że ustawiono flagę time_to_live .
Aby uzyskać lepszy wgląd w proces dostarczania wiadomości:
Aby uzyskać lepszy wgląd w dostarczanie wiadomości na platformach Android lub Apple, zobacz panel raportowania FCM , który rejestruje liczbę wiadomości wysłanych i otwartych na urządzeniach Apple i Android wraz z danymi dotyczącymi „wyświetleń” (powiadomień widzianych przez użytkowników) dla Aplikacje Android.
W przypadku urządzeń z systemem Android z włączoną funkcją przesyłania wiadomości w kanale bezpośrednim, jeśli urządzenie nie było połączone z FCM przez ponad miesiąc, FCM nadal akceptuje wiadomość, ale natychmiast ją odrzuca. Jeśli urządzenie połączy się w ciągu czterech tygodni od ostatniej wysłanej do niego wiadomości z danymi, Twój klient otrzyma wywołanie zwrotne onDeletedMessages() . Aplikacja może następnie prawidłowo poradzić sobie z sytuacją, zazwyczaj żądając pełnej synchronizacji z serwera aplikacji.
Wreszcie, gdy FCM próbuje dostarczyć wiadomość do urządzenia, a aplikacja została odinstalowana, FCM natychmiast odrzuca tę wiadomość i unieważnia token rejestracji. Przyszłe próby wysłania wiadomości do tego urządzenia powodują błąd NotRegistered .
Ograniczanie i skalowanie
Naszym celem jest zawsze dostarczenie każdej wiadomości wysłanej za pośrednictwem FCM. Jednak dostarczenie każdej wiadomości czasami skutkuje złym ogólnym doświadczeniem użytkownika. W innych przypadkach musimy wyznaczyć granice, aby zapewnić, że FCM zapewni skalowalną usługę dla wszystkich nadawców.
Zwijane ograniczanie wiadomości
Jak opisano powyżej, wiadomości zwijane to powiadomienia pozbawione treści, zaprojektowane tak, aby zwijały się jedna na drugiej. W przypadku, gdy programista zbyt często powtarza ten sam komunikat w aplikacji, opóźniamy (ograniczamy) komunikaty, aby zmniejszyć wpływ na baterię użytkownika.
Na przykład, jeśli wyślesz dużą liczbę nowych żądań synchronizacji e-maili do jednego urządzenia, możemy opóźnić następne żądanie synchronizacji e-maili o kilka minut, aby urządzenie mogło synchronizować się z niższą średnią szybkością. Ograniczanie to ma na celu wyłącznie ograniczenie wpływu baterii na użytkownika.
Jeśli Twój przypadek użycia wymaga wzorców wysyłania dużej liczby serii, właściwym wyborem mogą być wiadomości niezwijane. W przypadku takich wiadomości pamiętaj o dołączeniu ich treści, aby zmniejszyć koszt baterii.
Ograniczamy zwijane wiadomości do serii 20 wiadomości na aplikację na urządzenie, z uzupełnianiem 1 wiadomości co 3 minuty.
Ograniczanie serwera XMPP
Ograniczamy szybkość łączenia się z serwerami FCM XMPP do 400 połączeń na minutę na projekt. Nie powinno to stanowić problemu w dostarczaniu wiadomości, ale jest ważne dla zapewnienia stabilności systemu. Dla każdego projektu FCM umożliwia 2500 połączeń równoległych.
W przypadku przesyłania wiadomości wychodzących za pomocą XMPP, FCM ogranicza przesyłanie wiadomości wychodzących do 1 500 000 na minutę na projekt, aby uniknąć przeciążenia serwerów docelowych przesyłania danych.
Ograniczamy prędkość przesyłania wiadomości na urządzenie do 1000/minutę, aby chronić baterię przed zużyciem baterii w wyniku złego działania aplikacji.
Maksymalna szybkość wiadomości do jednego urządzenia
W przypadku systemu Android możesz wysłać do 240 wiadomości na minutę i 5000 wiadomości na godzinę na jedno urządzenie. Ten wysoki próg ma umożliwiać krótkotrwałe wzrosty ruchu, np. gdy użytkownicy szybko wchodzą w interakcję na czacie. Ten limit zapobiega błędom wysyłania logiki i przypadkowemu rozładowaniu baterii urządzenia.
W przypadku iOS zwracamy błąd, gdy szybkość przekracza limity APN.
Limit wiadomości tematycznych
Współczynnik dodawania/usuwania subskrypcji tematycznej jest ograniczony do 3000 QPS na projekt.
Aby zapoznać się z szybkością wysyłania wiadomości, zobacz Ograniczanie fanoutów .
Ograniczanie wentylatorów
Rozdzielanie wiadomości to proces wysyłania wiadomości do wielu urządzeń, np. gdy kierujesz reklamy na tematy i grupy lub gdy używasz narzędzia do tworzenia powiadomień w celu kierowania wiadomości do odbiorców lub segmentów użytkowników.
Rozdzielanie wiadomości nie jest natychmiastowe i czasami zdarza się, że jednocześnie trwa wiele rozwinięć. Ograniczamy liczbę jednoczesnych fanoutów wiadomości na projekt do 1000. Następnie możemy odrzucić dodatkowe prośby o fanouty lub odłożyć ich fanouty do czasu zakończenia niektórych z już trwających fanoutów.
Na rzeczywistą osiągalną liczbę fanoutów wpływa liczba projektów żądających fanoutów w tym samym czasie. Częstość fanoutów wynosząca 10 000 QPS dla pojedynczego projektu nie jest rzadkością, ale liczba ta nie jest gwarancją i wynika z całkowitego obciążenia systemu. Należy zauważyć, że dostępna pojemność fanoutu jest dzielona pomiędzy projektami, a nie pomiędzy żądaniami fanoutu. Tak więc, jeśli w Twoim projekcie trwają dwa fanouty, wówczas w każdym fanoutie będzie widoczna tylko połowa dostępnego współczynnika fanoutów. Zalecanym sposobem zmaksymalizowania szybkości rozgałęziania jest posiadanie tylko jednego aktywnego rozgałęzienia w danym momencie.
Porty FCM i zapora sieciowa
Jeśli Twoja organizacja posiada zaporę sieciową ograniczającą ruch do i z Internetu, musisz ją skonfigurować tak, aby zezwalała urządzeniom mobilnym na łączenie się z FCM, aby urządzenia w Twojej sieci mogły odbierać wiadomości. FCM zazwyczaj 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 udostępnia 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 będzie miało wpływ na wygodę użytkowników. Najlepiej umieścić na liście dozwolonych porty 5228-5230 i 443 bez ograniczeń IP. Jeśli jednak musisz mieć ograniczenie adresu IP, powinieneś umieścić na liście dozwolonych wszystkie adresy IP wymienione w goog.json . Ta obszerna lista jest regularnie aktualizowana i zaleca się aktualizowanie reguł co miesiąc. Problemy spowodowane ograniczeniami adresów IP zapory sieciowej są często sporadyczne i 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 listę tutaj. Używanie nazw domen w regule zapory może, ale nie musi, działać w urządzeniu zapory.
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 z translacją adresów sieciowych i/lub stanową inspekcją pakietów:
Jeśli Twoja sieć implementuje translację adresów sieciowych (NAT) lub stanową inspekcję pakietów (SPI), zastosuj 30-minutowy lub dłuższy limit czasu dla naszych połączeń na portach 5228-5230. Dzięki temu możemy zapewnić niezawodną łączność, jednocześnie zmniejszając zużycie baterii urządzeń mobilnych Twoich użytkowników.
Interakcje VPN i możliwość obejścia
Firebase Cloud Messaging podejmuje różne kroki, aby zapewnić, że połączenie wiadomości push z telefonu do serwera jest niezawodne i dostępne tak często, jak to możliwe. Korzystanie z VPN komplikuje ten wysiłek.
Sieci VPN maskują podstawowe informacje, których FCM potrzebuje, aby dostroić swoje połączenie, aby zmaksymalizować niezawodność i żywotność baterii. W niektórych przypadkach sieci VPN aktywnie przerywają długotrwałe połączenia, co powoduje złe doświadczenia użytkownika z powodu nieodebranych lub opóźnionych wiadomości lub wysokiego kosztu baterii. Gdy VPN jest skonfigurowany, aby nam to umożliwić, omijamy VPN, korzystając z szyfrowanego połączenia (przez sieć bazową Wi-Fi lub LTE), aby zapewnić niezawodne działanie i oszczędzanie baterii. Wykorzystanie przez FCM sieci VPN z możliwością obejścia jest specyficzne dla kanału powiadomień push FCM. Inny ruch FCM, taki jak ruch rejestracyjny, korzysta z VPN, jeśli jest aktywny. Kiedy połączenie FCM omija VPN, traci dodatkowe korzyści, jakie może zapewniać VPN, takie jak maskowanie IP.
Różne sieci VPN będą miały różne metody kontrolowania, czy można je ominąć. Instrukcje znajdziesz w dokumentacji konkretnej sieci VPN.
Jeśli sieć VPN nie jest skonfigurowana tak, aby można ją było ominąć, Firebase Cloud Messaging użyje sieci VPN w celu połączenia się z serwerem. Może to powodować okresy opóźnień w wysyłaniu wiadomości i większe zużycie baterii, ponieważ Cloud Messaging utrzymuje połączenie przez VPN.
Referencje
W zależności od tego, jakie funkcje FCM zaimplementujesz, możesz potrzebować następujących danych uwierzytelniających z projektu Firebase:
| Identyfikator projektu | Unikalny identyfikator projektu Firebase używany w żądaniach kierowanych do punktu końcowego HTTP FCM v1. Ta wartość jest dostępna w panelu Ustawienia konsoli Firebase . |
| Token rejestracyjny | Unikalny ciąg tokenu identyfikujący każdą instancję aplikacji klienckiej. Token rejestracyjny jest wymagany do przesyłania wiadomości na jednym urządzeniu i w grupie urządzeń. Należy pamiętać, że tokeny rejestracyjne muszą być utrzymywane w tajemnicy. |
| Identyfikator nadawcy | Unikalna wartość liczbowa utworzona podczas tworzenia projektu Firebase, dostępna na karcie Wiadomości w chmurze w panelu Ustawienia konsoli Firebase. Identyfikator nadawcy służy do identyfikowania każdego nadawcy, 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 do interfejsu API HTTP v1. Ten token jest powiązany z kontem usługi należącym do Twojego projektu Firebase. Aby utworzyć i obrócić tokeny dostępu, wykonaj kroki opisane w sekcji Autoryzuj żądania wysłania . |
| Klucz serwera (dla **przestarzałych** starszych protokołów) | Klucz serwera autoryzujący serwer aplikacji w celu uzyskania dostępu do usług Google, w tym wysyłania wiadomości za pośrednictwem przestarzałych starszych protokołów Firebase Cloud Messaging. Ważne: Nie dołączaj klucza serwera w żadnym miejscu kodu klienta. Pamiętaj też, aby do autoryzacji serwera aplikacji używać wyłącznie kluczy serwera. Android, platforma Apple i klucze przeglądarki są odrzucane przez FCM. |