Join us in person and online for Firebase Summit on October 18, 2022. Learn how Firebase can help you accelerate app development, release your app with confidence, and scale with ease. Register now

O wiadomościach 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 mają pomóc w zrozumieniu różnych typów komunikatów FCM i tego, co można z nimi zrobić.

Typy wiadomości

Dzięki FCM możesz wysyłać do klientów dwa rodzaje wiadomości:

  • Powiadomienia, czasami nazywane „komunikatami wyświetlanymi”. Są one obsługiwane automatycznie przez FCM SDK.
  • Komunikaty danych obsługiwane przez aplikację kliencką.

Powiadomienia zawierają predefiniowany zestaw kluczy widocznych dla użytkownika. Z kolei wiadomości z danymi zawierają tylko niestandardowe pary klucz-wartość zdefiniowane przez użytkownika. Powiadomienia mogą zawierać opcjonalny ładunek danych. Maksymalny ładunek dla obu typów wiadomości to 4000 bajtów, z wyjątkiem wysyłania wiadomości z konsoli Firebase, która wymusza limit 1024 znaków.

Użyj scenariusza Jak wysłać
Wiadomość z powiadomieniem FCM automatycznie wyświetla komunikat na urządzeniach użytkowników końcowych w imieniu aplikacji klienckiej. Powiadomienia mają wstępnie zdefiniowany zestaw kluczy widocznych dla użytkownika i opcjonalny ładunek danych w postaci niestandardowych par klucz-wartość.
  1. W zaufanym środowisku, takim jak Cloud Functions lub serwer aplikacji, użyj pakietu Admin SDK lub protokołów serwera FCM : ustaw klucz notification . Może mieć opcjonalny ładunek danych. Zawsze składany.

    Zobacz kilka przykładów powiadomień dotyczących wyświetlania i wysyłania ładunków żądań.

  2. Użyj kompozytora powiadomień : wprowadź tekst wiadomości, tytuł itp. i wyślij. Dodaj opcjonalny ładunek danych, podając dane niestandardowe.
Wiadomość z danymi Aplikacja kliencka jest odpowiedzialna za przetwarzanie komunikatów danych. Wiadomości z danymi zawierają 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 : ustaw tylko klucz data .

Użyj komunikatów powiadomień, jeśli chcesz, aby FCM obsługiwał wyświetlanie powiadomienia w imieniu aplikacji klienckiej. Używaj komunikatów danych, gdy chcesz przetwarzać komunikaty w 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

W celach testowych, marketingowych i ponownego zaangażowania użytkowników możesz wysyłać powiadomienia za pomocą konsoli Firebase . Konsola Firebase zapewnia testy A/B oparte na analizach, które pomagają udoskonalać i ulepszać komunikaty marketingowe.

Aby programowo wysyłać wiadomości z powiadomieniami przy użyciu pakietu Admin SDK lub protokołów FCM, ustaw klucz notification z niezbędnym wstępnie zdefiniowanym zestawem opcji klucz-wartość dla części wiadomości widocznej dla użytkownika. Na przykład oto wiadomość z powiadomieniem w formacie JSON w aplikacji IM. Użytkownik może spodziewać się wiadomości zatytułowanej „Portugalia vs. Dania” i tekst „Dobry mecz!” na urządzeniu:

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

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

Zobacz dokumentację referencyjną, aby uzyskać pełną listę predefiniowanych kluczy dostępnych do tworzenia powiadomień:

Wiadomości z danymi

Ustaw odpowiedni klucz za pomocą niestandardowych par klucz-wartość, aby wysłać ładunek danych do aplikacji klienckiej.

Na przykład oto komunikat w formacie JSON w tej samej aplikacji IM, co powyżej, w której informacje są hermetyzowane we wspólnym kluczu data , a aplikacja kliencka ma zinterpretować zawartość:

{
  "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 odbierających 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 ) używa szyfrowania typu punkt-punkt. W zależności od potrzeb możesz zdecydować się na dodanie szyfrowania typu end-to-end do wiadomości z danymi. FCM nie zapewnia kompleksowego rozwiązania. Dostępne są jednak rozwiązania zewnętrzne, takie jak Capillary czy DTLS .

Powiadomienia z opcjonalnym ładunkiem danych

Zarówno programowo, jak i za pomocą konsoli Firebase możesz wysyłać powiadomienia zawierające opcjonalny ładunek niestandardowych par klucz-wartość. W układaczu Powiadomienia użyj pól danych Własne w Opcjach zaawansowanych .

Zachowanie aplikacji podczas odbierania wiadomości, które zawierają zarówno powiadomienia, jak i ładunki danych, zależy od tego, czy aplikacja działa w tle, czy na pierwszym planie — zasadniczo od tego, czy jest aktywna w momencie odbioru.

  • W tle aplikacje odbierają ładunek powiadomienia na pasku powiadomień i obsługują ładunek danych tylko wtedy, gdy użytkownik kliknie powiadomienie.
  • Na pierwszym planie aplikacja odbiera 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

Pakiet Firebase Admin SDK 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, które mają być interpretowane przez wszystkie wystąpienia aplikacji, które odbierają komunikat.
  • Zestawy pól specyficznych dla platformy, takie jak AndroidConfig i WebpushConfig , interpretowane tylko przez wystąpienia aplikacji działające na określonej platformie.

Bloki specyficzne dla platformy zapewniają elastyczność dostosowywania komunikatów 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 komunikat dla 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 web
  • 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 do określonych platform
  • Wysyłaj pola specyficzne dla platformy oprócz pól wspólnych

Zawsze, gdy chcesz wysł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.

Gdy wysyłasz wiadomości z określonymi opcjami dostarczania , użyj pól właściwych 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, ponieważ każda platforma może nieco inaczej interpretować wartość — na przykład czas wygaśnięcia jest ustawiony w systemie Android jako czas wygaśnięcia w sekundach, podczas gdy w Apple jest ustawiony jako data wygaśnięcia .

Przykład: wiadomość z powiadomieniem z opcjami dostawy specyficznymi dla platformy

Następujące żądanie wysyłania v1 wysyła wspólny tytuł powiadomienia i zawartość do wszystkich platform, ale także wysyła pewne zastąpienia specyficzne dla platformy. W szczególności prośba:

  • ustawia długi czas życia dla platform Android i Web, jednocześnie ustawiając niski priorytet wiadomości APNs (platformy Apple)
  • ustawia odpowiednie klawisze, aby zdefiniować wynik dotknięcia przez użytkownika powiadomienia w systemie Android i Apple — 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"
       }
     }
   }
 }

Zobacz dokumentację referencyjną HTTP v1, aby uzyskać szczegółowe informacje na temat kluczy dostępnych w blokach specyficznych dla platformy w treści wiadomości. 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 pozwala na podobne opcje na platformach Apple i w Internecie. Na przykład „zwijalne” zachowanie wiadomości jest obsługiwane w systemie Android za pośrednictwem funkcji collapse_key w FCM , w Apple za pośrednictwem apns-collapse-id , a w JavaScript/Web za pośrednictwem Topic . Szczegółowe informacje można znaleźć w opisach w tej sekcji i powiązanej dokumentacji referencyjnej.

Wiadomości nieskładane i składane

Wiadomość niemożliwa do zwijania oznacza, że ​​każda pojedyncza wiadomość jest dostarczana do urządzenia. Wiadomość, której nie można zwijać, zawiera przydatną treść, w przeciwieństwie do wiadomości zwijanej, takiej jak „ping” bez zawartości, do aplikacji mobilnej w celu skontaktowania się z serwerem w celu pobrania danych.

Niektóre typowe przypadki użycia wiadomości, których nie można zwijać, to wiadomości czatu lub wiadomości krytyczne. Na przykład w aplikacji IM chcesz dostarczyć każdą wiadomość, ponieważ każda wiadomość ma inną treść.

W przypadku systemu Android obowiązuje limit 100 wiadomości, które można przechowywać bez zwijania. Po osiągnięciu limitu wszystkie zapisane wiadomości są odrzucane. Gdy urządzenie wróci do trybu online, otrzymuje specjalny komunikat informujący o osiągnięciu limitu. Aplikacja może następnie prawidłowo obsłużyć sytuację, zazwyczaj żądając pełnej synchronizacji z serwera aplikacji.

Wiadomość zwijana to wiadomość, którą można zastąpić nową wiadomością, jeśli nie została jeszcze dostarczona do urządzenia.

Częstymi przypadkami użycia zwijanych wiadomości są wiadomości używane do informowania aplikacji mobilnej o synchronizowaniu danych z serwera. Przykładem może być aplikacja sportowa, która aktualizuje użytkowników o najnowsze wyniki. Tylko najnowsza wiadomość ma znaczenie.

Aby oznaczyć wiadomość jako zwijaną w systemie Android, dołącz parametr collapse_key do ładunku wiadomości. Domyślnie kluczem zwinięcia jest nazwa pakietu aplikacji zarejestrowana w konsoli Firebase. Serwer FCM może jednocześnie przechowywać cztery różne zwijalne komunikaty na urządzenie, każdy z innym kluczem zwinięcia. Jeśli przekroczysz tę liczbę, FCM zachowuje tylko cztery klucze zwinięcia, bez gwarancji, które z nich zostaną zachowane.

Wiadomości tematów 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 używać wiadomości, które nie są zwijane. Jeśli jednak używasz zwijalnych komunikatów, pamiętaj, że FCM zezwala na używanie przez FCM maksymalnie czterech różnych kluczy zwijania na token rejestracji w dowolnym momencie. Nie możesz przekroczyć tej liczby, ponieważ 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ń, wszystkie wiadomości nie są domyślnie zwijane.
Składany Gdy pojawia się nowszy komunikat, który renderuje starszy, powiązany komunikat 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:
  • collapseKey na Androida
  • apns-collapse-id w Apple
  • Topic w sieci
  • collapse_key w starszych protokołach (wszystkie platformy)

Ustawianie priorytetu wiadomości

Masz dwie opcje przypisywania priorytetu dostarczania do wiadomości odbiorczych: normalny i wysoki priorytet. Chociaż zachowanie różni się nieco na różnych platformach, dostarczanie wiadomości o normalnym i wysokim priorytecie działa w następujący sposób:

  • Normalny priorytet. Normalne wiadomości priorytetowe są dostarczane natychmiast, gdy aplikacja jest na pierwszym planie. W przypadku aplikacji działających w tle dostarczanie może być opóźnione. W przypadku mniej czasochłonnych wiadomości, takich jak powiadomienia o nowej poczcie e-mail, synchronizacja interfejsu użytkownika lub synchronizowanie 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 jest w trybie drzemki. Wiadomości o wysokim priorytecie dotyczą treści, które są wrażliwe na czas i widoczne dla użytkownika.

Oto przykład zwykłej wiadomości priorytetowej wysyłanej za pośrednictwem protokołu FCM HTTP v1 w celu powiadomienia prenumeratora magazynu, że nowa zawartość jest dostępna 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"
      }
    }
  }
}

Aby uzyskać więcej szczegółowych informacji na temat ustawiania priorytetu wiadomości dotyczących platformy:

Ustawianie żywotności wiadomości

FCM zwykle 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, offline lub w inny sposób niedostępne. Lub FCM może celowo opóźniać wiadomości, aby uniemożliwić aplikacji zużywanie nadmiernych zasobów i negatywny wpływ 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ść może równie dobrze 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 czas przed zakończeniem połączenia. Lub jeśli wiadomość jest zaproszeniem na wydarzenie, jest bezużyteczna, jeśli zostanie odebrana po zakończeniu wydarzenia.

W systemach Android i Web/JavaScript możesz określić maksymalny czas życia wiadomości. Wartość musi wynosić od 0 do 2419 200 sekund (28 dni) i odpowiada maksymalnemu okresowi, przez jaki FCM przechowuje i próbuje dostarczyć wiadomość. Żądania, które nie zawierają tego pola, mają domyślnie maksymalny okres czterech tygodni.

Oto kilka możliwych zastosowań tej funkcji:

  • Połączenia przychodzące na czacie wideo
  • Wydarzenia z zaproszeniami wygasają
  • Wydarzenia w kalendarzu

Kolejną zaletą określania okresu życia wiadomości jest to, że FCM nigdy nie ogranicza wiadomości o wartości czasu wygaśnięcia wynoszącej 0 sekund. Innymi słowy, FCM gwarantuje najlepsze starania w przypadku wiadomości, które muszą być dostarczone „teraz albo nigdy”. Pamiętaj, że wartość time_to_live równa 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 najlepsze opóźnienie wysyłania 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

Gdy serwer aplikacji opublikuje komunikat w FCM i odbierze identyfikator komunikatu, nie oznacza to, że komunikat został już dostarczony na urządzenie. Oznacza to raczej, że został przyjęty do dostawy. To, co dzieje się z wiadomością po jej przyjęciu, 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 ograniczeń ograniczania przepustowości, wiadomość jest dostarczana od razu.

Jeśli urządzenie jest podłączone, ale jest w trybie drzemki, komunikat o niskim priorytecie jest przechowywany przez FCM do czasu, aż urządzenie wyjdzie z trybu drzemki. I tu właśnie ważną rolę odgrywa flaga collapse_key : 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 nowa wiadomość zajmuje jej miejsce (czyli stara wiadomość jest zwinięta przez nową). Jeśli jednak klucz zwinięcia nie jest ustawiony, zarówno nowe, jak i stare wiadomości są przechowywane do przyszłego dostarczenia.

Jeśli urządzenie nie jest połączone z FCM, wiadomość jest przechowywana do momentu nawiązania połączenia (ponownie z poszanowaniem zasad klucza zwinięcia). Po nawiązaniu połączenia FCM dostarcza wszystkie oczekujące komunikaty do urządzenia. Jeśli urządzenie nigdy nie zostanie ponownie połączone (na przykład, jeśli zostało zresetowane do ustawień fabrycznych), komunikat w końcu przekroczy limit czasu i zostanie usunięty z pamięci FCM. Domyślny limit czasu to cztery tygodnie, chyba że ustawiona jest flaga time_to_live .

Aby uzyskać więcej informacji na temat 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łączonym kanałem komunikacji bezpośredniej, jeśli urządzenie nie łączyło się 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, klient otrzyma wywołanie zwrotne onDeletedMessages() . Aplikacja może następnie prawidłowo obsłużyć sytuację, zazwyczaj żądając pełnej synchronizacji z serwera aplikacji.

Wreszcie, gdy FCM próbuje dostarczyć komunikat do urządzenia, a aplikacja została odinstalowana, FCM od razu odrzuca tę wiadomość i unieważnia token rejestracji. Przyszłe próby wysłania wiadomości do tego urządzenia skutkują błędem NotRegistered .

Ograniczanie i skalowanie

Naszym celem jest zawsze dostarczanie każdej wiadomości wysłanej za pośrednictwem FCM. Jednak dostarczanie każdej wiadomości czasami powoduje pogorszenie ogólnego komfortu użytkownika. W innych przypadkach musimy określić granice, aby zapewnić, że FCM zapewnia skalowalną usługę dla wszystkich nadawców.

Zwijany dławienie wiadomości

Jak opisano powyżej, wiadomości zwijane to powiadomienia bez zawartości, które zwijają się jedna na drugiej. W przypadku, gdy programista zbyt często powtarza tę samą wiadomość w aplikacji, opóźniamy (dławimy) wiadomości, aby zmniejszyć wpływ na baterię użytkownika.

Na przykład, jeśli wyślesz dużą liczbę nowych żądań synchronizacji poczty e-mail do jednego urządzenia, możemy opóźnić kolejne żądanie synchronizacji poczty o kilka minut, aby urządzenie mogło synchronizować się z niższą średnią szybkością. To dławienie jest wykonywane wyłącznie w celu ograniczenia wpływu baterii odczuwanego przez użytkownika.

Jeśli Twój przypadek użycia wymaga dużych wzorców wysyłania serii, wiadomości nie zwijane mogą być właściwym wyborem. W przypadku takich wiadomości pamiętaj o uwzględnieniu treści w takich wiadomościach, aby zmniejszyć koszt baterii.

Ograniczamy wiadomości zwijane do serii 20 wiadomości na aplikację na urządzenie, przy czym 1 wiadomość jest uzupełniana co 3 minuty.

Ograniczanie przepustowości serwera XMPP

Ograniczamy szybkość połączenia z serwerami FCM XMPP do 400 połączeń na minutę na projekt. Nie powinno to stanowić problemu przy dostarczaniu wiadomości, ale jest ważne dla zapewnienia stabilności naszego systemu.

Dla każdego projektu FCM pozwala na 2500 połączeń równoległych.

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 na celu umożliwienie krótkotrwałych nagłych wzrostów ruchu, na przykład gdy użytkownicy szybko wchodzą w interakcję na czacie. Ten limit zapobiega przypadkowemu rozładowaniu baterii urządzenia przez błędy w wysyłaniu logiki.

W przypadku iOS zwracamy błąd, gdy szybkość przekracza limity APNs.

Limit wiadomości wysyłanych

Ograniczamy wysyłanie wiadomości do 1 500 000/minutę na projekt, aby uniknąć przeciążenia nadrzędnych serwerów docelowych.

Ograniczamy wysyłanie wiadomości na urządzenie do 1000/minutę, aby chronić przed rozładowaniem baterii w wyniku złego zachowania aplikacji.

Limit wiadomości na temat

Szybkość dodawania/usuwania subskrypcji tematów jest ograniczona do 3000 QPS na projekt.

Aby uzyskać informacje na temat szybkości wysyłania wiadomości, zobacz Ograniczanie Fanout .

dławienie fanoutów

Rozwijanie wiadomości to proces wysyłania wiadomości do wielu urządzeń, na przykład gdy kierujesz reklamy na tematy i grupy lub gdy używasz edytora powiadomień do kierowania do odbiorców lub segmentów użytkowników.

Rozwinięcie wiadomości nie jest natychmiastowe, więc czasami masz jednocześnie kilka rozsyłanych wiadomości. Ograniczamy liczbę jednoczesnych fanoutów wiadomości na projekt do 1000. Po tym możemy odrzucić dodatkowe prośby o fanouty lub odroczyć fanouty do czasu, gdy niektóre z już trwających fanoutów się zakończą.

Rzeczywisty osiągalny współczynnik fanoutów zależy od liczby projektów żądających fanoutów w tym samym czasie. Współczynnik fanoutu wynoszący 10 000 QPS dla pojedynczego projektu nie jest niczym niezwykłym, ale ta liczba nie jest gwarancją i jest wynikiem całkowitego obciążenia systemu. Ważne jest, aby pamiętać, że dostępna pojemność fanoutów jest podzielona między projekty, a nie między żądaniami fanoutów. Tak więc, jeśli twój projekt ma dwa fanouty w toku, to każdy fanout zobaczy tylko połowę dostępnego współczynnika fanoutów. Zalecanym sposobem maksymalizacji szybkości fanoutów jest posiadanie tylko jednego aktywnego fanoutu na raz.

Porty FCM i zapora sieciowa

Jeśli Twoja organizacja ma zaporę, która ogranicza ruch do lub z Internetu, musisz skonfigurować ją tak, aby zezwalała urządzeniom przenośnym 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 443, 5229 i 5230.

W przypadku urządzeń łączących się w Twojej sieci FCM nie zapewnia określonych adresów IP, ponieważ nasz zakres adresów IP zmienia się zbyt często, a reguły zapory sieciowej mogą stać się nieaktualne, wpływając na wygodę użytkowników. Idealnie, porty listy dozwolonych 5228-5230 i 443 bez ograniczeń IP. Jeśli jednak musisz mieć ograniczenie adresu IP, należy zezwolić na listę wszystkich adresów IP wymienionych w goog.json . Ta obszerna lista jest regularnie aktualizowana i zaleca się aktualizowanie reguł co miesiąc. Problemy spowodowane ograniczeniami IP zapory 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 tutaj listę. 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 typu Network Address Translation i/lub Stateful Packet Inspection:

Jeśli w Twojej sieci wdrożono translację adresów sieciowych (NAT) lub Stateful Packet Inspection (SPI), zaimplementuj 30-minutowy lub dłuższy limit czasu dla naszych połączeń przez porty 5228-5230. Dzięki temu możemy zapewnić niezawodną łączność przy jednoczesnym zmniejszeniu zużycia baterii urządzeń mobilnych użytkowników.

Kwalifikacje

W zależności od zaimplementowanych funkcji FCM możesz potrzebować następujących danych logowania z projektu Firebase:

Identyfikator projektu Unikalny identyfikator Twojego projektu Firebase używany w żądaniach do punktu końcowego HTTP FCM v1. Ta wartość jest dostępna w panelu Ustawienia konsoli Firebase .
Token rejestracji

Unikalny ciąg tokenu, który identyfikuje każde wystąpienie aplikacji klienckiej. Token rejestracji jest wymagany do przesyłania wiadomości dotyczących pojedynczego urządzenia i grupy urządzeń. Pamiętaj, że tokeny rejestracji muszą być utrzymywane w tajemnicy.

Identyfikator nadawcy Unikalna wartość liczbowa utworzona podczas tworzenia projektu Firebase, dostępna na karcie Komunikowanie się 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, które należy do Twojego projektu Firebase. Aby utworzyć i rotować tokeny dostępu, wykonaj czynności opisane w sekcji Autoryzacja żądań wysyłania .
Klucz serwera (dla starszych protokołów)

Klucz serwera, który upoważnia serwer Twojej aplikacji do dostępu do usług Google, w tym do wysyłania wiadomości przez starsze protokoły Firebase Cloud Messaging. Klucz serwera otrzymujesz podczas tworzenia projektu Firebase. Możesz go wyświetlić na karcie Cloud Messaging w panelu Ustawienia konsoli Firebase.

Ważne: Nie umieszczaj klucza serwera nigdzie w kodzie klienta. Upewnij się też, że do autoryzacji serwera aplikacji używasz tylko kluczy serwera. Klucze platformy Android, Apple i przeglądarki są odrzucane przez FCM.