Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

O wiadomościach FCM

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, takich jak funkcje w chmurze lub serwera aplikacji, należy użyć Admin SDK lub te protokoły FCM serwera : ustawienie notification kluczy. Może mieć opcjonalny ładunek danych. Zawsze składany.

    Zobacz kilka przykładów wyświetlaj powiadomienia i zapytanie Wyślij ładunków.

  2. Użyj kompozytora Powiadomienia : Wprowadź tekst wiadomości, tytuł, itd., I wysłać. Dodaj opcjonalny ładunek danych, podając dane niestandardowe.
Wiadomość z danymi Aplikacja kliencka jest odpowiedzialna za przetwarzanie komunikatów danych. Komunikaty danych zawierają tylko niestandardowe pary klucz-wartość bez zarezerwowanych nazw kluczy (patrz poniżej). W zaufanym środowisku, takich jak funkcje w chmurze lub serwera aplikacji, należy użyć Admin SDK lub te protokoły FCM Server : Ustawia data wyłącznie kluczy.

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

Do badań lub marketingu i ponownego zaangażowania użytkownika, można wysyłać powiadomienia za pomocą konsoli Firebase . Konsola Firebase zapewnia analityczne oparte testy A / B , które pomogą Ci udoskonalić i poprawić wiadomości marketingowych.

Programowo wysyłać powiadomienia wykorzystaniem Admin SDK lub protokoły FCM, ustaw notification klucz wraz z niezbędnym zestawem predefiniowanych opcji klucz-wartość dla użytkownika widoczne części powiadomienia. 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 wiadomość w formacie JSON w tej samej aplikacji IM jak wyżej, gdzie informacja jest zawarta we wspólnym data klucza i aplikacji klienckiej oczekuje zinterpretować treść:

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

Powyższy przykład pokazuje, korzystanie z najwyższego poziomu, lub wspólnego data pola, co jest interpretowane przez klientów na wszystkich platformach, które otrzymują wiadomość. Na każdej platformie aplikacja kliencka odbiera ładunek danych w funkcji wywołania zwrotnego.

Szyfrowanie wiadomości z danymi

Warstwa transportowa Android (patrz architekturę FCM ) wykorzystuje szyfrowanie 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. Jednakże, istnieją rozwiązania, takie jak zewnętrzne dostępne Kapilara lub 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 kompozytora powiadomień , użyj pola danych zwyczaj 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.

  • Kiedy w tle, aplikacje otrzymują właściwe powiadomienia na pasku powiadomień, a obsługiwać tylko ładunek danych, gdy użytkownik kliknie na zgłoszenia.
  • Kiedy na pierwszym planie, aplikacja odbiera obiekt wiadomość z obu ładunków dostępnych.

Oto wiadomość w formacie JSON zawierający zarówno notification klucz i data klucza:

{
  "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

Firebase Admin SDK i protokół HTTP FCM v1 zarówno umożliwić wnioski wiadomość ustawić wszystkie pola dostępne w message obiektu. To zawiera:

  • wspólny zestaw pól powinny być interpretowane przez wszystkich instancji aplikacji, które otrzymują wiadomość.
  • Zestawy danej platformy dziedzinach, takich jak AndroidConfig i WebpushConfig , interpretowane wyłącznie przez instancje aplikacji uruchomionych na określonym platformy.

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 instancje aplikacji na wszystkich platformach - iOS, Android, i internetowych
  • 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
  • Wyślij platformy konkretnych pól oprócz wspólnych pól

Gdy chcesz wysłać wartości tylko do konkretnych platform, nie używać wspólnych pól; użyj pól specyficznych dla platformy. Na przykład, aby wysłać powiadomienie tylko do systemu iOS i sieci Web, ale nie do systemu Android, musisz użyć dwóch oddzielnych zestawów pól, jednego dla systemu iOS i jednego dla sieci Web.

Podczas wysyłania wiadomości z konkretnych opcji dostawy , pola platformy szczególne zastosowanie do ich ustawiania. 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. To dlatego, że każda platforma może zinterpretować wartość nieco inaczej, na przykład, czas do zamieszkania jest ustawiony na Androida jako czas ważności w sekundach, a na iOS jest ona ustawiona jako data ważności.

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 (iOS)
  • ustawia odpowiednie klawisze aby określić wynik kranu użytkownika na powiadomienia na Androida i iOS - click_action i category , odpowiednio.
{
  "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 HTTP v1 dokumentację referencyjną dla pełnego szczegółów na temat klawiszy dostępnych w danej platformy bloków w treści wiadomości. Aby uzyskać więcej informacji na temat budowania zapytań Wyślij które zawierają treść wiadomości, zobacz Budowa wysyłania żądań .

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, „składany” zachowanie wiadomość jest obsługiwana na Androida przez FCM w collapse_key na iOS poprzez apns-collapse-id , oraz JavaScript / Web poprzez Topic . Szczegółowe informacje można znaleźć w opisach w tej sekcji i powiązanej dokumentacji referencyjnej.

Wiadomości nieskładane i składane

Nie-składany komunikatu oznacza, że każdy komunikat jest dostarczane 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.

Składane wiadomość jest wiadomością, która może zostać zastąpiona przez nową wiadomość, jeśli jeszcze mają być dostarczone 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 składany na Androida, obejmują collapse_key parametru w polu danych wiadomości. Domyślnie kluczem zwijania 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.

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 iOS
  • Topic w sieci
  • collapse_key w protokołach starszych (wszystkie platformy)

Ustawianie priorytetu wiadomości

Masz dwie opcje przypisywania priorytetu dostarczania do wiadomości odebranych w systemie Android: normalny i wysoki priorytet. Dostarczanie wiadomości o normalnym i wysokim priorytecie działa tak:

  • Normalny priorytet. To jest domyślny priorytet dla komunikatów danych . Normalne wiadomości priorytetowe są dostarczane natychmiast, gdy aplikacja jest na pierwszym planie. Gdy urządzenie jest w trybie drzemki, dostawa może być opóźniona w celu oszczędzania baterii. 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.

    Po otrzymaniu wiadomości normalny priorytet na Androida, które żąda synchronizację danych w tle dla aplikacji, można zaplanować zadanie z WorkManager poradzić, gdy sieć jest dostępna.

  • Wysoki priorytet. FCM próbuje natychmiast dostarczyć komunikaty o wysokim priorytecie, umożliwiając usłudze FCM wybudzenie urządzenia uśpionego w razie potrzeby i uruchomienie ograniczonego przetwarzania (w tym bardzo ograniczonego dostępu do sieci). Wiadomości o wysokim priorytecie zazwyczaj 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ą stracić priorytet. Android P wprowadzono aplikacji gotowości wiadra , które ograniczają liczbę FCM wiadomości o wysokim priorytecie można wysyłać do aplikacji, które nie skutkują użytkownikowi korzystanie z aplikacji lub wyświetlania powiadomienia. Jeśli w odpowiedzi na komunikat o wysokim priorytecie powiadomienie zostanie wyświetlone w sposób widoczny dla użytkownika, przydział zasobnika w trybie gotowości aplikacji nie zostanie wykorzystany przez ten komunikat.

    Ponieważ niewielka część populacji telefonów komórkowych z Androidem korzysta z sieci o dużym opóźnieniu, unikaj otwierania połączenia z serwerami przed wyświetleniem powiadomienia. Oddzwanianie do serwera przed upływem dozwolonego czasu przetwarzania może być ryzykowne dla użytkowników w sieciach o dużym opóźnieniu. Zamiast tego dołącz treść powiadomienia do wiadomości FCM i natychmiast ją wyświetl. Jeśli trzeba synchronizację zawartości dodatkowej w aplikacji na Androida, można zaplanować zadanie z WorkManager obsłużyć że w tle.

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”. Należy pamiętać, że time_to_live wartość 0 oznacza, że wiadomości nie mogą być dostarczane 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"
      }
    }
  }
}

Odbieranie wiadomości od wielu nadawców

FCM umożliwia wielu stronom wysyłanie komunikatów do tej samej aplikacji klienckiej. Załóżmy na przykład, że aplikacja kliencka jest agregatorem artykułów z wieloma współtwórcami, a każdy z nich powinien mieć możliwość wysłania wiadomości podczas publikowania nowego artykułu. Ta wiadomość może zawierać adres URL, dzięki któremu aplikacja kliencka może pobrać artykuł. Zamiast scentralizować całą aktywność związaną z wysyłaniem w jednym miejscu, FCM umożliwia każdemu z tych współtwórców wysyłanie własnych wiadomości.

Aby włączyć tę funkcję, upewnij się, że każdego nadawcy identyfikator nadawcy . Podczas żądania rejestracji aplikacja kliencka pobiera token wielokrotnie, za każdym razem z innym identyfikatorem nadawcy w polu odbiorców, korzystając z metody pobierania tokena dla danej platformy:

Upewnij się, że nie należy dodawać wiele identyfikatorów nadawcy do jednego wniosku tokena, jak to może 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ć komunikaty do aplikacji klienckiej przy użyciu własnych kluczy uwierzytelniania.

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

Ż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 to gdzie collapse_key flaga odgrywa rolę: jeśli istnieje już wiadomość z tym samym kluczem zwinięcia (i rejestracji tokena) przechowywane i oczekiwanie na dostawę, stara wiadomość jest usuwana i nowa wiadomość zajmuje swoje miejsce (czyli stary 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 wynosi cztery tygodnie, chyba że time_to_live flaga jest ustawiona.

Aby uzyskać więcej informacji na temat dostarczania wiadomości:

    Aby uzyskać lepszy wgląd w dostarczaniu wiadomości na Androida lub iOS, zobacz pulpit raportowania FCM , który rejestruje liczbę wiadomości wysłanych i otwartych na urządzeniach z systemem iOS i Android, wraz z danymi dla „wrażeń” (zgłoszenia widziane przez użytkowników) dla Androida aplikacje.

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 łączy w ciągu czterech tygodni od ostatniej wiadomości danych wysłanego do niego, klient odbiera onDeletedMessages () wywołania zwrotnego. 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, aby wysłać wiadomość do tej wynikami urządzenie w NotRegistered błędu.

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

Do jednego urządzenia możesz wysłać do 240 wiadomości na minutę i 5000 wiadomości na godzinę. 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.

Limit wiadomości wysyłanych

Ograniczamy wiadomości upstream na 1.500.000 / min na jeden projekt, aby uniknąć przeciążenia upstream serwery docelowe.

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.

Dla stóp wysyłania wiadomości, patrz Fanout dławienia .

dławienie fanoutów

Wiadomość fanout jest procesem wysyłania wiadomości do wielu urządzeń, takich jak w przypadku kierowania tematów i grup, lub podczas korzystania z kompozytorem powiadomień 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. Jednakże, jeśli trzeba mieć ograniczenie IP, należy allowlist 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 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.klienci.google.com
  • device-provisioning.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.

Referencje

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. Wartość ta jest dostępna w Firebase konsola Ustawienia panelu.
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 Unikalną wartością liczbową tworzone podczas tworzenia projektu Firebase, dostępną w chmurze Messaging karcie panelu Firebase konsola Ustawienia. 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 obracania dostęp tokeny, wykonaj kroki opisane w zezwolić na wysyłanie żądań .
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żna go zobaczyć w Cloud Messaging karcie panelu Firebase konsola Ustawienia.

Ważne: nie obejmują nigdzie klucza serwera w kodzie klienta. Upewnij się też, że do autoryzacji serwera aplikacji używasz tylko kluczy serwera. Klucze Androida, iOS i przeglądarki są odrzucane przez FCM.