Google 致力于为黑人社区推动种族平等。查看具体举措
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Informacje o wiadomościach FCM

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

Typy wiadomości

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

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

Powiadomienia zawierają predefiniowany zestaw widocznych dla użytkownika kluczy. 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 4KB, z wyjątkiem wysyłania wiadomości z konsoli Firebase, która narzuca limit 1024 znaków.

Użyj scenariusza Jak wysłać
Wiadomość z powiadomieniem FCM automatycznie wyświetla wiadomość na urządzeniach użytkowników końcowych w imieniu aplikacji klienckiej. Komunikaty powiadomień mają predefiniowany 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 zestawu Admin SDK lub FCM Server Protocols : ustaw klucz notification . Może mieć opcjonalny ładunek danych. Zawsze składane.

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

  2. Użyj edytora 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 wiadomości z danymi. Komunikaty z danymi zawierają tylko niestandardowe pary klucz-wartość bez zarezerwowanych nazw kluczy (patrz poniżej). W zaufanym środowisku, takim jak Cloud Functions lub serwer aplikacji, użyj pakietu Admin SDK lub FCM Server Protocols : ustaw tylko klucz data .

Użyj powiadomień, jeśli chcesz, aby FCM obsługiwał wyświetlanie powiadomienia w imieniu aplikacji klienckiej. Użyj wiadomości z danymi, jeśli chcesz przetwarzać wiadomości 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 lub do celów marketingowych i ponownego zaangażowania użytkowników możesz wysyłać powiadomienia za pomocą konsoli Firebase . Konsola Firebase zapewnia oparte na analizie testy A / B, które pomagają udoskonalać i ulepszać komunikaty marketingowe.

Aby programowo wysyłać powiadomienia przy użyciu 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. Na przykład tutaj jest powiadomienie w formacie JSON w aplikacji do obsługi wiadomości błyskawicznych. Użytkownik może spodziewać się wiadomości z tytułem „Portugalia kontra Dania” i tekstem „Świetne dopasowanie!” 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 zapoznać się z pełną listą predefiniowanych kluczy dostępnych do tworzenia wiadomości z powiadomieniami:

Wiadomości z danymi

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

Na przykład tutaj jest wiadomość w formacie JSON w tej samej aplikacji do komunikatorów, co powyżej, w której informacje są zawarte 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 lub wspólnego pola data , które jest interpretowane przez klientów na wszystkich platformach, które otrzymują komunikat. Na każdej platformie aplikacja kliencka otrzymuje ładunek danych w funkcji wywołania zwrotnego. :

Powiadomienia 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 edytorze powiadomień użyj pól danych niestandardowych 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 otrzymania.

  • Działając w tle , aplikacje odbierają ładunek powiadomienia w zasobniku powiadomień i obsługują ładunek danych tylko wtedy, gdy użytkownik kliknie powiadomienie.
  • Na pierwszym planie aplikacja 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 Firebase Admin SDK, jak i protokół FCM v1 HTTP pozwalają żądaniom wiadomości ustawić wszystkie pola dostępne w obiekcie message . To zawiera:

  • wspólny zestaw pól, które mają być interpretowane przez wszystkie wystąpienia aplikacji, które otrzymują komunikat.
  • zestawy pól specyficzne dla platformy, takie jak AndroidConfig i WebpushConfig , interpretowane tylko przez wystąpienia aplikacji uruchomione na określonej platformie.

Bloki specyficzne dla platformy zapewniają elastyczność dostosowywania wiadomości dla różnych platform, aby zapewnić, że są prawidłowo obsługiwane po odebraniu. Backend FCM weźmie pod uwagę wszystkie określone parametry i dostosuje komunikat do każdej platformy.

Kiedy używać wspólnych pól

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

  • Kierowanie na wystąpienia aplikacji na wszystkich platformach - iOS, Android i w przeglądarce
  • Wysyłanie wiadomości do tematów

Wszystkie wystąpienia aplikacji, niezależnie od platformy, mogą interpretować następujące typowe 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

Jeśli 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 iOS i sieci, ale nie do Androida, musisz użyć dwóch oddzielnych zestawów pól, jednego dla iOS i jednego dla sieci.

Gdy 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, ponieważ każda platforma może nieco inaczej interpretować tę wartość - na przykład czas wygaśnięcia jest ustawiany w systemie Android jako czas wygaśnięcia w sekundach, podczas gdy w iOS jest to data wygaśnięcia.

Przykład: powiadomienie 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 także przesyła pewne nadpisania specyficzne dla platformy. W szczególności żądanie:

  • ustawia długi czas życia na platformach Android i internetowych, jednocześnie ustawiając priorytet wiadomości APN (iOS) na niski
  • ustawia odpowiednie klawisze, aby zdefiniować wynik dotknięcia powiadomienia przez użytkownika w systemie Android i iOS - 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 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ń wysyłania zawierających treść wiadomości, zobacz Tworzenie żądań wysył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 w systemie iOS i w Internecie. Na przykład zachowanie wiadomości „zwijane” jest obsługiwane w systemie Android za pośrednictwem parametru collapse_key FCM, w systemie iOS za pośrednictwem apns-collapse-id , a w JavaScript / w Internecie za pośrednictwem Topic . Aby uzyskać szczegółowe informacje, zapoznaj się z opisami w tej sekcji i powiązaną dokumentacją referencyjną.

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

Wiadomość, której nie można zwijać, oznacza, że ​​każda wiadomość została dostarczona do urządzenia. Wiadomość, której nie można zwijać, dostarcza użytecznych treści, w przeciwieństwie do wiadomości zwijanej, takiej jak „ping” bez treści do aplikacji mobilnej w celu skontaktowania się z serwerem w celu pobrania danych.

Niektóre typowe przypadki użycia nierozwijanych wiadomości to wiadomości na czacie lub wiadomości krytyczne. Na przykład w aplikacji komunikatora chciałbyś 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. Po osiągnięciu limitu wszystkie zapisane wiadomości są odrzucane. Gdy urządzenie wróci do trybu online, otrzyma specjalny komunikat informujący o osiągnięciu limitu. Aplikacja może wtedy prawidłowo obsłużyć sytuację, zazwyczaj żądając pełnej synchronizacji z serwera aplikacji.

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

Typowymi przypadkami użycia zwijanych wiadomości są wiadomości, które nakazują aplikacji mobilnej synchronizację danych z serwera. Przykładem może być aplikacja sportowa, która aktualizuje użytkowników najnowszym wynikiem. Istotna jest tylko najnowsza wiadomość.

Aby oznaczyć wiadomość jako zwijaną w systemie Android, umieść parametr collapse_key w ładunku wiadomości. FCM pozwala na użycie maksymalnie czterech różnych kluczy zwijania na urządzenie z Androidem w dowolnym momencie. Innymi słowy, serwer FCM może jednocześnie przechowywać cztery różne zwijane wiadomości na urządzenie, 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 w temacie bez ładunku są domyślnie zwijane.

Którego powinienem użyć?

Zwijane wiadomości są lepszym wyborem z punktu widzenia wydajności, pod warunkiem, że Twoja aplikacja nie musi używać wiadomości, których nie można zwijać. Jeśli jednak używasz zwijanych wiadomości, pamiętaj, że FCM zezwala na używanie tylko czterech różnych kluczy zwijania przez serwer połączeń FCM w danym momencie na token rejestracji. Nie możesz przekroczyć tej liczby, bo 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 wiadomości z powiadomieniami, wszystkie wiadomości nie są domyślnie zwijane.
Składany Gdy pojawi się nowsza wiadomość, która sprawia, że ​​starsza, powiązana wiadomość jest nieistotna 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 na iOS
  • Topic w sieci
  • collapse_key w starszych protokołach (wszystkie platformy)

Ustawianie priorytetu wiadomości

Masz dwie opcje przypisywania priorytetu dostarczania do wiadomości przychodzących w systemie Android: normalny i wysoki priorytet. Dostarczanie wiadomości normalnych i wiadomości o wysokim priorytecie wygląda tak:

  • Normalny priorytet. Jest to domyślny priorytet wiadomości z danymi . Zwykłe wiadomości priorytetowe są dostarczane natychmiast, gdy aplikacja jest na pierwszym planie. Gdy urządzenie jest w trybie drzemki, dostawa może zostać opóźniona, aby oszczędzać baterię. W przypadku mniej pilnych wiadomości, takich jak powiadomienia o nowych e-mailach, synchronizacja interfejsu użytkownika lub synchronizacja danych aplikacji w tle, wybierz normalny priorytet dostarczania.

    Po otrzymaniu normalnej wiadomości priorytetowej w systemie Android, która żąda synchronizacji danych w tle dla Twojej aplikacji, możesz zaplanować zadanie w WorkManager, aby obsłużyć je, gdy sieć będzie dostępna.

  • Wysoki priorytet. FCM próbuje natychmiast dostarczyć wiadomości o wysokim priorytecie, pozwalając usłudze FCM obudzić uśpione urządzenie, gdy jest to konieczne, i uruchomić pewne ograniczone przetwarzanie (w tym bardzo ograniczony dostęp do sieci). Wiadomości o wysokim priorytecie generalnie powinny skutkować interakcją użytkownika z Twoją aplikacją lub jej powiadomieniami. Jeśli FCM wykryje wzorzec, w którym tego nie robią, Twoje wiadomości mogą zostać pozbawione priorytetów. W systemie Android P wprowadzono zasobniki gotowości aplikacji, które ograniczają liczbę wiadomości FCM o wysokim priorytecie, które możesz wysłać do aplikacji, a które nie powodują, że użytkownik korzysta z aplikacji ani nie wyświetla powiadomienia. Jeśli w odpowiedzi na wiadomość o wysokim priorytecie powiadomienie zostanie wyświetlone w sposób widoczny dla użytkownika, to przydział zasobnika w stanie gotowości aplikacji nie zostanie wykorzystany przez tę wiadomość.

    Ponieważ niewielka część populacji urządzeń mobilnych z Androidem korzysta z sieci o dużym opóźnieniu, unikaj otwierania połączenia z serwerami przed wyświetleniem powiadomienia. Oddzwonienie do serwera przed końcem dozwolonego czasu przetwarzania może być ryzykowne dla użytkowników w sieciach o dużym opóźnieniu. Zamiast tego umieść treść powiadomienia w wiadomości FCM i wyświetl ją natychmiast. Jeśli potrzebujesz zsynchronizować dodatkową zawartość aplikacji w systemie Android, możesz zaplanować zadanie w WorkManager, aby obsłużyć to w tle.

Oto przykład zwykłej wiadomości priorytetowej wysyłanej przez protokół FCM HTTP v1 w celu powiadomienia subskrybenta magazynu, że jest dostępna do pobrania nowa zawartość:

{
  "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 priorytetów wiadomości dla poszczególnych platform:

Ustawianie czasu życia wiadomości

FCM zwykle dostarcza wiadomości natychmiast po ich wysłaniu. Jednak nie zawsze jest to 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.

W takim przypadku 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, dla których spóźniona wiadomość może nigdy nie zostać dostarczona. Na przykład, jeśli wiadomość jest powiadomieniem o połączeniu przychodzącym lub czacie wideo, ma znaczenie tylko przez krótki czas, zanim połączenie zostanie zakończone. Lub jeśli wiadomość jest zaproszeniem na wydarzenie, jest bezużyteczna, jeśli została odebrana po zakończeniu wydarzenia.

W systemie Android i sieci / JavaScript możesz określić maksymalny czas życia wiadomości. Wartość musi obejmować okres 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 ustawiony maksymalny okres czterech tygodni.

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 nigdy nie ogranicza wiadomości z wartością czasu wygaśnięcia równą 0 sekund. Innymi słowy, FCM gwarantuje najlepszy wysiłek 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ć od razu, są odrzucane. Ponieważ jednak takie wiadomości nigdy nie są przechowywane, zapewnia to najlepsze opóźnienie dla wysyłania wiadomości z powiadomieniami.

Oto przykład żądania zawierającego czas 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"
      }
    }
  }
}

Otrzymywanie wiadomości od wielu nadawców

FCM umożliwia wielu stronom wysyłanie wiadomości do tej samej aplikacji klienckiej. Załóżmy na przykład, że aplikacja kliencka jest agregatorem artykułów z wieloma współautorami i każdy z nich powinien mieć możliwość wysłania wiadomości, gdy publikują nowy artykuł. Ta wiadomość może zawierać adres URL umożliwiający aplikacji klienckiej pobranie artykułu. Zamiast scentralizować wszystkie działania związane z wysyłaniem w jednym miejscu, FCM umożliwia każdemu z tych współpracowników wysyłanie własnych wiadomości.

Aby włączyć tę funkcję, upewnij się, że masz identyfikator nadawcy każdego nadawcy. Aplikacja kliencka żądając rejestracji wielokrotnie pobiera token, za każdym razem z innym ID nadawcy w polu odbiorcy, korzystając z metody pobierania tokena dla danej platformy:

Upewnij się, że nie dodajesz wielu identyfikatorów nadawcy do pojedynczego żądania tokena, ponieważ może to mieć nieprzewidywalne skutki. Wykonuj każde połączenie osobno, raz na identyfikator nadawcy.

Na koniec udostępnij token rejestracji odpowiednim nadawcom, aby mogli wysyłać wiadomości do aplikacji klienckiej przy użyciu własnych kluczy uwierzytelniania.

Pamiętaj, że istnieje limit 100 nadawców wielokrotnych.

Czas życia wiadomości

Gdy serwer aplikacji publikuje wiadomość w FCM i odbiera identyfikator wiadomości z powrotem, 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 ograniczeń dławienia, wiadomość jest dostarczana od razu.

Jeśli urządzenie jest podłączone, ale znajduje się w trybie drzemki, komunikat o niskim priorytecie jest przechowywany przez FCM, dopóki urządzenie nie jest w stanie uśpienia. I tutaj rolę odgrywa flaga collapse_key : jeśli istnieje już wiadomość z tym samym kluczem zwijania (i tokenem rejestracji) przechowywana i oczekująca na dostarczenie, stara wiadomość jest odrzucana, a jej miejsce zajmuje nowa wiadomość (czyli stara wiadomość zostanie zwinięta przez nową). Jeśli jednak klucz zwijania nie jest ustawiony, zarówno nowe, jak i stare wiadomości są przechowywane do przyszłego dostarczenia.

Jeśli urządzenie nie jest podłączone do FCM, wiadomość jest przechowywana do momentu nawiązania połączenia (ponownie z zachowaniem zasad klucza zwijania). Po ustanowieniu połączenia FCM dostarcza wszystkie oczekujące wiadomości do urządzenia. Jeśli urządzenie nigdy nie zostanie ponownie połączone (na przykład, jeśli zostało przywrócone 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 time_to_live flagę time_to_live .

Aby uzyskać lepszy wgląd w dostarczanie wiadomości:

    Aby uzyskać więcej informacji na temat dostarczania wiadomości w systemie Android lub iOS, zapoznaj się z panelem raportowania FCM , który rejestruje liczbę wiadomości wysłanych i otwartych na urządzeniach z systemem iOS i Android, a także dane dotyczące „wyświetleń” (powiadomień widzianych przez użytkowników) dla Androida aplikacje.

W przypadku urządzeń z Androidem z włączoną bezpośrednią komunikacją kanałową, 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 wysłania do niego ostatniej wiadomości z danymi, klient otrzyma wywołanie zwrotne onDeletedMessages () . Aplikacja może wtedy prawidłowo obsłużyć 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 NotRegistered błędem NotRegistered .

Ograniczanie i skalowanie

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

Ograniczanie zwijanych wiadomości

Jak opisano powyżej, zwijane wiadomości to powiadomienia bez treści zaprojektowane tak, aby zwijały się jedna na drugiej. W przypadku, gdy programista zbyt często powtarza ten sam komunikat do 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 poczty e-mail na jedno urządzenie, możemy opóźnić następne żądanie synchronizacji poczty e-mail o kilka minut, aby urządzenie mogło zsynchronizować się z mniejszą średnią szybkością. To dławienie jest wykonywane wyłącznie w celu ograniczenia wpływu baterii na użytkownika.

Jeśli Twój przypadek użycia wymaga wysokich wzorców wysyłania seryjnego, wówczas nierozwijalne wiadomości 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 zwijane wiadomości do serii 20 wiadomości na aplikację na urządzenie, przy czym jedna wiadomość jest uzupełniana co 3 minuty.

Ograniczanie przepustowości serwera XMPP

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

Dla każdego projektu FCM umożliwia równoległe 2500 połączeń.

Maksymalna szybkość przesyłania wiadomości do jednego urządzenia

Możesz wysłać do 240 wiadomości na minutę i 5000 wiadomości na godzinę do jednego urządzenia. Ten wysoki próg ma umożliwić krótkotrwałe wzrosty ruchu, na przykład gdy użytkownicy szybko wchodzą w interakcję na czacie. Ograniczenie to zapobiega błędom w wysyłaniu logiki przed przypadkowym rozładowaniem baterii urządzenia.

Limit wysyłanych wiadomości

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

Ograniczamy wysyłanie wiadomości na urządzenie do 1000 / minutę, aby chronić przed wyczerpaniem baterii w przypadku złego działania aplikacji.

Limit wiadomości w temacie

Współczynnik dodawania / usuwania subskrypcji tematu jest ograniczony do 3000 QPS na projekt.

Aby uzyskać współczynniki wysyłania wiadomości, zobacz Ograniczanie przepustowości .

Dławienie wentylatora

Fanout 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 reklam do odbiorców lub segmentów użytkowników.

Fanout wiadomości nie jest natychmiastowy, więc czasami masz jednocześnie kilka fanoutów. Ograniczamy liczbę jednoczesnych fanoutów wiadomości na projekt do 1000. Następnie możemy odrzucić dodatkowe żądania fanoutu lub odroczyć rozłożenie żądań do czasu zakończenia niektórych już trwających fanoutów.

Na rzeczywisty osiągalny współczynnik fanoutu ma wpływ liczba projektów, które jednocześnie żądają fanoutu. Wskaźnik fanoutu wynoszący 10 000 QPS dla pojedynczego projektu nie jest rzadkością, ale liczba ta nie jest gwarancją i jest wynikiem całkowitego obciążenia systemu. Należy zauważyć, że dostępna pojemność fanoutu jest podzielona na projekty, a nie na żądania. Tak więc, jeśli twój projekt ma dwa fanouty w toku, wtedy każdy fanout zobaczy tylko połowę dostępnego współczynnika fanoutów. Zalecanym sposobem maksymalizacji szybkości fanoutu jest posiadanie tylko jednego aktywnego fanoutu naraz.

Porty FCM i zapora sieciowa

Jeśli Twoja organizacja ma zaporę ogniową ograniczającą ruch do lub 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 zwykle używa portu 5228, ale czasami używa portu 5229 i 5230.

W przypadku połączeń wychodzących FCM nie zapewnia określonych adresów IP, ponieważ zakres adresów IP zmienia się zbyt często, a reguły zapory mogą się nieaktualne, co wpływa na wygodę użytkowników. Najlepiej byłoby umieścić na białej liście porty 5228-5230 bez ograniczeń adresów IP. Jeśli jednak musisz mieć ograniczenie adresu IP, umieść na białej liście wszystkie adresy IP wymienione w goog.json . Ta obszerna lista jest regularnie aktualizowana. Zaleca się aktualizowanie reguł co miesiąc. Problemy spowodowane przez ograniczenia adresów IP zapory są często sporadyczne i trudne do zdiagnozowania.

Porty do otwarcia dla wiadomości przychodzących:

  • 5228
  • 5229
  • 5230
  • 443

Porty umożliwiające połączenia wychodzące:

Jeden z nich (preferowana opcja nr 1):

  1. Brak ograniczeń IP
  2. Wszystkie adresy IP dla domen domyślnych.

    Aby pobrać aktualną listę tych adresów, postępuj zgodnie z instrukcjami opisanymi w sekcji Adresy IP dla domen domyślnych .

Translacja adresów sieciowych i / lub zapory ogniowe z pełną kontrolą pakietów:

Jeśli Twoja sieć implementuje translację adresów sieciowych (NAT) lub Stateful Packet Inspection (SPI), wprowadź 30-minutowy lub dłuższy limit czasu dla naszych 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.

Kwalifikacje

W zależności od zaimplementowanych funkcji FCM mogą być potrzebne następujące dane logowania z projektu Firebase:

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

Unikalny ciąg tokenu, który identyfikuje każde wystąpienie aplikacji klienta. Token rejestracji jest wymagany do przesyłania wiadomości z jednym urządzeniem i grupą urządzeń. Pamiętaj, że tokeny rejestracji muszą być trzymane w tajemnicy.

ID nadawcy Unikalna wartość liczbowa tworzona podczas tworzenia projektu Firebase, dostępna na karcie Komunikacja 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 obrócić tokeny dostępu, wykonaj kroki opisane w sekcji Autoryzacja wysyłania żądań .
Klucz serwera (dla starszych protokołów)

Klucz serwera, który upoważnia serwer aplikacji do dostępu do usług Google, w tym do wysyłania wiadomości za pośrednictwem starszych protokołów Firebase Cloud Messaging. Klucz serwera uzyskujesz podczas tworzenia projektu Firebase. Możesz go wyświetlić na karcie Komunikacja w chmurze w panelu Ustawienia konsoli Firebase.

Ważne: nie umieszczaj klucza serwera w żadnym miejscu w kodzie klienta. Ponadto upewnij się, że używasz tylko kluczy serwera do autoryzacji serwera aplikacji. Klucze Androida, iOS i przeglądarki są odrzucane przez FCM.