Catch up on everthing we announced at this year's Firebase Summit. Learn more

À propos des messages FCM

Firebase Cloud Messaging (FCM) offre une large gamme d'options et de capacités de messagerie. Les informations de cette page sont destinées à vous aider à comprendre les différents types de messages FCM et ce que vous pouvez en faire.

Types de messages

Avec FCM, vous pouvez envoyer deux types de messages aux clients :

  • Messages de notification, parfois considérés comme des « messages d'affichage ». Ceux-ci sont gérés automatiquement par le SDK FCM.
  • Les messages de données, qui sont gérés par l'application cliente.

Les messages de notification contiennent un ensemble prédéfini de clés visibles par l'utilisateur. Les messages de données, en revanche, ne contiennent que vos paires clé-valeur personnalisées définies par l'utilisateur. Les messages de notification peuvent contenir une charge utile de données facultative. La charge utile maximale pour les deux types de messages est de 4 000 octets, sauf lors de l'envoi de messages depuis la console Firebase, qui impose une limite de 1024 caractères.

Scénario d'utilisation Comment envoyer
Message de notification FCM affiche automatiquement le message sur les appareils des utilisateurs finaux au nom de l'application cliente. Les messages de notification ont un ensemble prédéfini de clés visibles par l'utilisateur et une charge utile de données facultative de paires clé-valeur personnalisées.
  1. Dans un environnement de confiance telles que les fonctions de notification Cloud ou votre serveur d'applications, utilisez le SDK d' administration ou les protocoles FCM serveur : Définissez la notification clé. Peut avoir une charge utile de données facultative. Toujours pliable.

    Voir quelques exemples de notifications d'affichage et d' envoyer des charges utiles de demande.

  2. Utilisez le Notifications compositeur : Entrez le texte du message, titre, etc., et envoyer. Ajoutez une charge utile de données facultative en fournissant des données personnalisées.
Message de données L'application cliente est responsable du traitement des messages de données. Les messages de données n'ont que des paires clé-valeur personnalisées sans nom de clé réservé (voir ci-dessous). Dans un environnement de confiance telles que les fonctions de data Cloud ou votre serveur d'applications, utilisez le SDK d' administration ou les protocoles FCM serveur : Définir les data clés seulement.

Utilisez des messages de notification lorsque vous souhaitez que FCM gère l'affichage d'une notification au nom de votre application cliente. Utilisez des messages de données lorsque vous souhaitez traiter les messages sur votre application cliente.

Le FCM peut envoyer un message de notification comprenant une charge utile de données facultative. Dans de tels cas, FCM gère l'affichage de la charge utile de notification et l'application cliente gère la charge utile de données.

Messages de notification

Pour tester ou pour le marketing et l' utilisateur réengagement, vous pouvez envoyer des messages de notification à l' aide de la console Firebase . La console Firebase fournit des analyses en fonction A / B test pour vous aider à affiner et améliorer les messages marketing.

Pour les messages de notification à l' aide du programme envoyer SDK Admin ou les protocoles de la FCM, définissez la notification clé avec l'ensemble prédéfini nécessaire d'options valeur clé pour la partie visible par l' utilisateur du message de notification. Par exemple, voici un message de notification au format JSON dans une application de messagerie instantanée. L'utilisateur peut s'attendre à voir un message avec le titre « Portugal contre Danemark » et le texte « grand match ! sur l'appareil :

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

Les messages de notification sont envoyés dans la barre de notification lorsque l'application est en arrière-plan. Pour les applications au premier plan, les messages sont gérés par une fonction de rappel.

Consultez la documentation de référence pour la liste complète des clés prédéfinies disponibles pour la création de messages de notification :

Messages de données

Définissez la clé appropriée avec vos paires clé-valeur personnalisées pour envoyer une charge utile de données à l'application cliente.

Par exemple, voici un message au format JSON dans la même application de messagerie instantanée comme ci - dessus, où l'information est encapsulé dans la commune des data clés et l'application cliente devrait interpréter le contenu:

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

L'utilisation de montre l'exemple ci - dessus du haut niveau, ou commun des data terrain, ce qui est interprété par les clients sur toutes les plateformes qui reçoivent le message. Sur chaque plate-forme, l'application cliente reçoit la charge utile des données dans une fonction de rappel.

Cryptage des messages de données

La couche de transport Android (voir l' architecture de la FCM ) utilise le chiffrement point à point. Selon vos besoins, vous pouvez décider d'ajouter un cryptage de bout en bout aux messages de données. FCM ne fournit pas de solution de bout en bout. Cependant, il existe des solutions externes disponibles , telles que Capillaire ou DTLS .

Messages de notification avec charge utile de données facultative

Que ce soit par programmation ou via la console Firebase, vous pouvez envoyer des messages de notification contenant une charge utile facultative de paires clé-valeur personnalisées. Dans le compositeur Notifications , utilisez les champs de données personnalisés dans les options avancées.

Le comportement de l'application lors de la réception de messages qui incluent à la fois des notifications et des charges utiles de données dépend de si l'application est en arrière-plan ou au premier plan, essentiellement, si elle est active ou non au moment de la réception.

  • Quand en arrière - plan, les applications reçoivent la charge utile de notification dans la barre de notification, et seulement gérer la charge utile de données lorsque l'utilisateur tape sur la notification.
  • Quand au premier plan, votre application reçoit un objet de message avec les deux charges utiles disponibles.

Voici un message au format JSON contenant à la fois la notification clé et les data clés:

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

Personnaliser un message sur toutes les plateformes

Le Firebase Administrateur SDK et le protocole HTTP FCM v1 à la fois permettre à vos demandes de messages pour tous les champs disponibles dans le message de l' objet. Ceci comprend:

  • un ensemble commun de champs à interpréter par toutes les instances d'application qui reçoivent le message.
  • ensembles de plate-forme spécifique à des domaines tels que AndroidConfig et WebpushConfig , interprétés uniquement par des exemples d'application en cours d' exécution sur la plate - forme spécifiée.

Les blocs spécifiques à la plate-forme vous offrent la possibilité de personnaliser les messages pour différentes plates-formes afin de garantir qu'ils sont correctement traités lors de leur réception. Le backend FCM prendra en compte tous les paramètres spécifiés et personnalisera le message pour chaque plate-forme.

Quand utiliser les champs communs

Utilisez des champs communs lorsque vous êtes :

  • Le ciblage des cas d'applications sur toutes les plateformes - Apple, Android et Web
  • Envoi de messages aux sujets

Toutes les instances d'application, quelle que soit la plate-forme, peuvent interpréter les champs communs suivants :

Quand utiliser des champs spécifiques à la plate-forme

Utilisez des champs spécifiques à la plate-forme lorsque vous souhaitez :

  • Envoyer des champs uniquement à des plates-formes particulières
  • Envoyer des champs spécifiques de la plate - forme , en plus des champs communs

Chaque fois que vous voulez envoyer des valeurs uniquement aux plates - formes particulières, ne pas utiliser des champs communs; utiliser des champs spécifiques à la plate-forme. Par exemple, pour envoyer une notification uniquement aux plates-formes Apple et au Web, mais pas à Android, vous devez utiliser deux ensembles de champs distincts, un pour Apple et un pour le Web.

Lorsque vous envoyez des messages spécifiques avec des options de livraison , utiliser des champs spécifiques de la plate - forme pour les régler. Vous pouvez spécifier différentes valeurs par plate-forme si vous le souhaitez. Cependant, même lorsque vous souhaitez définir essentiellement la même valeur sur toutes les plates-formes, vous devez utiliser des champs spécifiques à la plate-forme. En effet , chaque plate - forme peut interpréter la valeur légèrement différente, par exemple, le temps à vivre est mis sur Android comme un temps d'expiration en quelques secondes, alors que sur Apple , il est défini comme une date d'expiration.

Exemple : message de notification avec des options de livraison spécifiques à la plate-forme

La demande d'envoi v1 suivante envoie un titre et un contenu de notification communs à toutes les plates-formes, mais envoie également des dérogations spécifiques à la plate-forme. Concrètement, la demande :

  • définit une longue durée de vie pour les plates-formes Android et Web, tout en définissant la priorité des messages APN (plates-formes Apple) sur un paramètre faible
  • définit les touches appropriées pour définir le résultat d'un robinet d'utilisateur sur la notification sur Android et Apple - click_action et category , respectivement.
{
  "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"
       }
     }
   }
 }

Voir la documentation de référence v1 HTTP pour les détails complets sur les touches disponibles dans les blocs spécifiques de la plate - forme dans le corps du message. Pour plus d' informations sur la construction d' envoi des demandes contenant le corps du message, voir les demandes de construction d'envoi .

Options de livraison

FCM fournit un ensemble spécifique d'options de livraison pour les messages envoyés aux appareils Android et permet des options similaires sur les plates-formes Apple et le Web. Par exemple, le comportement de message "pliable" est pris en charge sur Android via la FCM collapse_key , sur Apple via apns-collapse-id et JavaScript / Web via Topic . Pour plus de détails, voir les descriptions dans cette section et la documentation de référence associée.

Messages non pliables et pliables

Un message non-pliable signifie que chaque message individuel est délivré à l'appareil. Un message non réductible fournit un contenu utile, par opposition à un message réductible comme un « ping » sans contenu à l'application mobile pour contacter le serveur afin de récupérer des données.

Certains cas d'utilisation typiques des messages non réductibles sont les messages de discussion ou les messages critiques. Par exemple, dans une application de messagerie instantanée, vous voudriez transmettre chaque message, car chaque message a un contenu différent.

Pour Android, il y a une limite de 100 messages qui peuvent être stockés sans s'effondrer. Si la limite est atteinte, tous les messages stockés sont supprimés. Lorsque l'appareil est de nouveau en ligne, il reçoit un message spécial indiquant que la limite a été atteinte. L'application peut alors gérer correctement la situation, généralement en demandant une synchronisation complète au serveur d'applications.

Un message pliable est un message qui peut être remplacé par un nouveau message si elle n'a pas encore été livré à l'appareil.

Les cas d'utilisation courants des messages réductibles sont les messages utilisés pour indiquer à une application mobile de synchroniser les données du serveur. Un exemple serait une application sportive qui met à jour les utilisateurs avec le dernier score. Seul le message le plus récent est pertinent.

Pour marquer un message comme pliable sur Android, incluez le collapse_key paramètre dans la charge utile du message. Par défaut, la clé de réduction est le nom du package d'application enregistré dans la console Firebase. Le serveur FCM peut stocker simultanément quatre messages réductibles différents par appareil, chacun avec une clé de repli différente. Si vous dépassez ce nombre, FCM ne conserve que quatre clés de réduction, sans aucune garantie quant à celles qui sont conservées.

Les messages de sujet sans charge utile sont réductibles par défaut.

Lequel dois-je utiliser ?

Les messages pliables sont un meilleur choix du point de vue des performances, à condition que votre application n'ait pas besoin d'utiliser des messages non pliables. Cependant, si vous utilisez des messages réductibles, n'oubliez pas que FCM n'autorise l'utilisation d'un maximum de quatre clés de réduction différentes par FCM par jeton d'enregistrement à un moment donné. Vous ne devez pas dépasser ce nombre, ou cela pourrait entraîner des conséquences imprévisibles.

Scénario d'utilisation Comment envoyer
Non pliable Chaque message est important pour l'application cliente et doit être transmis. À l'exception des messages de notification, tous les messages ne sont pas réductibles par défaut.
Pliant Lorsqu'un message plus récent rend un message plus ancien et connexe non pertinent pour l'application cliente, FCM remplace l'ancien message. Par exemple : des messages utilisés pour lancer une synchronisation de données à partir du serveur ou des messages de notification obsolètes. Définissez le paramètre approprié dans votre demande de message :
  • collapseKey sur Android
  • apns-collapse-id sur Apple
  • Topic sur le Web
  • collapse_key dans les protocoles existants (toutes les plateformes)

Définir la priorité d'un message

Vous avez deux options pour attribuer une priorité de livraison aux messages en aval sur Android : priorité normale et haute. La livraison des messages normaux et prioritaires fonctionne comme ceci :

  • Priorité normale. Ceci est la priorité par défaut pour les messages de données . Les messages prioritaires normaux sont livrés immédiatement lorsque l'application est au premier plan. Lorsque l'appareil est en mode Doze, la livraison peut être retardée pour économiser la batterie. Pour les messages moins urgents, tels que les notifications de nouvel e-mail, la synchronisation de votre interface utilisateur ou la synchronisation des données de l'application en arrière-plan, choisissez la priorité de livraison normale.

    Lors de la réception d' un message de priorité normale sur Android qui demande une synchronisation de données de base pour votre application, vous pouvez planifier une tâche avec WorkManager pour gérer lorsque le réseau est disponible.

  • Haute priorité. Le FCM tente de livrer immédiatement des messages de haute priorité, permettant au FCM de réveiller un périphérique en veille si nécessaire et d'exécuter un traitement limité (y compris un accès réseau très limité). Les messages à haute priorité devraient généralement entraîner une interaction de l'utilisateur avec votre application ou ses notifications. Si FCM détecte un modèle dans lequel ils ne le font pas, vos messages peuvent être dépriorisés. Android P introduit app seaux de secours qui limitent le nombre de messages prioritaires FCM vous pouvez envoyer à votre application qui ne conduisent pas à l'utilisateur en utilisant votre application ou l' affichage d' une notification. Si, en réponse à un message de haute priorité, une notification s'affiche d'une manière visible pour l'utilisateur, votre quota de buckets de veille d'application ne sera pas consommé par ce message.

    Étant donné qu'une petite partie de la population mobile Android se trouve sur des réseaux à latence élevée, évitez d'ouvrir une connexion à vos serveurs avant d'afficher une notification. Rappeler le serveur avant la fin du temps de traitement autorisé peut être risqué pour les utilisateurs sur les réseaux à haute latence. Au lieu de cela, incluez le contenu de la notification dans le message FCM et affichez-le immédiatement. Si vous devez synchroniser du contenu supplémentaire en application sur Android, vous pouvez planifier une tâche avec WorkManager pour gérer cela en arrière - plan.

Voici un exemple de message prioritaire normal envoyé via le protocole FCM HTTP v1 pour informer un abonné d'un magazine qu'un nouveau contenu est disponible au téléchargement :

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

Pour plus de détails spécifiques à la plate-forme sur la définition de la priorité des messages :

Définir la durée de vie d'un message

FCM délivre généralement les messages immédiatement après leur envoi. Cependant, cela peut ne pas toujours être possible. Par exemple, si la plate-forme est Android, l'appareil peut être éteint, hors ligne ou indisponible. Ou FCM peut intentionnellement retarder les messages pour empêcher une application de consommer des ressources excessives et d'affecter négativement la durée de vie de la batterie.

Lorsque cela se produit, FCM stocke le message et le transmet dès que possible. Bien que cela convienne dans la plupart des cas, il existe certaines applications pour lesquelles un message en retard pourrait aussi bien ne jamais être remis. Par exemple, si le message est un appel entrant ou une notification de chat vidéo, il n'a de sens que pendant une courte période avant la fin de l'appel. Ou si le message est une invitation à un événement, il est inutile s'il est reçu après la fin de l'événement.

Sur Android et Web/JavaScript, vous pouvez spécifier la durée de vie maximale d'un message. La valeur doit être une durée comprise entre 0 et 2 419 200 secondes (28 jours) et elle correspond à la période maximale pendant laquelle FCM stocke et tente de remettre le message. Les demandes qui ne contiennent pas ce champ ont par défaut une période maximale de quatre semaines.

Voici quelques utilisations possibles de cette fonctionnalité :

  • Appels entrants de chat vidéo
  • Événements d'invitation expirant
  • Événements du calendrier

Un autre avantage de la spécification de la durée de vie d'un message est que FCM ne limite jamais les messages avec une valeur de durée de vie de 0 seconde. En d'autres termes, FCM garantit le meilleur effort pour les messages qui doivent être livrés « maintenant ou jamais ». Gardez à l' esprit qu'une time_to_live valeur de 0 signifie des messages qui ne peuvent être livrés immédiatement sont mis au rebut. Cependant, comme ces messages ne sont jamais stockés, cela offre la meilleure latence pour l'envoi de messages de notification.

Voici un exemple de requête qui inclut le 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"
      }
    }
  }
}

Réception de messages de plusieurs expéditeurs

FCM permet à plusieurs parties d'envoyer des messages à la même application cliente. Par exemple, supposons que l'application cliente soit un agrégateur d'articles avec plusieurs contributeurs, et chacun d'eux devrait pouvoir envoyer un message lorsqu'il publie un nouvel article. Ce message peut contenir une URL afin que l'application cliente puisse télécharger l'article. Au lieu d'avoir à centraliser toutes les activités d'envoi en un seul endroit, FCM vous donne la possibilité de laisser chacun de ces contributeurs envoyer ses propres messages.

Pour activer cette fonction, assurez-vous de chaque expéditeur expéditeur ID . Lors de la demande d'inscription, l'application cliente récupère le jeton plusieurs fois, chaque fois avec un ID d'expéditeur différent dans le champ d'audience, en utilisant la méthode de récupération de jeton pour la plate-forme donnée :

Assurez - vous que vous ne pas ajouter plusieurs ID de l' expéditeur à une seule demande de jeton, car cela peut avoir des résultats imprévisibles. Passez chaque appel séparément, une fois par ID d'expéditeur.

Enfin, partagez le jeton d'enregistrement avec les expéditeurs correspondants, et ils pourront envoyer des messages à l'application cliente à l'aide de leurs propres clés d'authentification.

Notez qu'il y a une limite de 100 expéditeurs multiples.

Durée de vie d'un message

Lorsqu'un serveur d'applications publie un message sur FCM et reçoit un ID de message en retour, cela ne signifie pas que le message a déjà été remis à l'appareil. Cela signifie plutôt qu'il a été accepté pour livraison. Ce qu'il advient du message une fois qu'il est accepté dépend de nombreux facteurs.

Dans le meilleur des cas, si l'appareil est connecté au FCM, l'écran est allumé et il n'y a pas de restrictions de limitation, le message est livré immédiatement.

Si l'appareil est connecté mais dans Doze, un message de faible priorité est stocké par le FCM jusqu'à ce que l'appareil soit hors de Doze. Et c'est là le collapse_key drapeau joue un rôle: s'il y a déjà un message avec la même clé de l' effondrement (et le jeton d'enregistrement) enregistré et en attente de livraison, l'ancien message est rejeté et le nouveau message prend sa place (qui est, l'ancien message est réduit par le nouveau). Cependant, si la clé de réduction n'est pas définie, les nouveaux et les anciens messages sont stockés pour une livraison future.

Si l'appareil n'est pas connecté au FCM, le message est stocké jusqu'à ce qu'une connexion soit établie (en respectant à nouveau les règles de la clé de repli). Lorsqu'une connexion est établie, FCM transmet tous les messages en attente à l'appareil. Si l'appareil ne se reconnecte plus (par exemple, s'il a été réinitialisé aux paramètres d'usine), le message finit par expirer et est supprimé du stockage FCM. Le délai d' attente par défaut est de quatre semaines, à moins que le time_to_live est défini.

Pour obtenir plus d'informations sur la livraison d'un message :

    Pour obtenir une meilleure idée de la diffusion de messages sur les plateformes Android ou Apple, voir le tableau de bord des rapports FCM , qui enregistre le nombre de messages envoyés et ouvert sur les appareils Apple et Android, ainsi que des données pour « impressions » (notifications vues par les utilisateurs) pour Applications Android.

Pour les appareils Android avec messagerie directe activée, si l'appareil ne s'est pas connecté à FCM pendant plus d'un mois, FCM accepte toujours le message mais le supprime immédiatement. Si l'appareil se connecte dans les quatre semaines du dernier message de données que vous avez envoyé, votre client reçoit les onDeletedMessages () rappel. L'application peut alors gérer correctement la situation, généralement en demandant une synchronisation complète au serveur d'applications.

Enfin, lorsque FCM tente de transmettre un message à l'appareil et que l'application a été désinstallée, FCM supprime immédiatement ce message et invalide le jeton d'enregistrement. Les futures tentatives d'envoyer un message à ce dispositif se traduit par une NotRegistered erreur.

Limitation et mise à l'échelle

Notre objectif est de toujours livrer chaque message envoyé via FCM. Cependant, la livraison de chaque message entraîne parfois une mauvaise expérience utilisateur globale. Dans d'autres cas, nous devons fournir des limites pour garantir que FCM fournit un service évolutif pour tous les expéditeurs.

Limitation des messages pliable

Comme décrit ci-dessus, les messages réductibles sont des notifications sans contenu conçues pour s'effondrer les unes sur les autres. Dans le cas où un développeur répète trop fréquemment le même message à une application, nous retardons (régulons) les messages pour réduire l'impact sur la batterie d'un utilisateur.

Par exemple, si vous envoyez un grand nombre de nouvelles demandes de synchronisation d'e-mails à un seul appareil, nous pouvons retarder la prochaine demande de synchronisation d'e-mails de quelques minutes afin que l'appareil puisse se synchroniser à un taux moyen inférieur. Cet étranglement est fait strictement pour limiter l'impact de la batterie subi par l'utilisateur.

Si votre cas d'utilisation nécessite des modèles d'envoi en rafale élevée, les messages non réductibles peuvent être le bon choix. Pour de tels messages, assurez-vous d'inclure le contenu dans ces messages afin de réduire le coût de la batterie.

Nous limitons les messages rétractables à une rafale de 20 messages par application et par appareil, avec une recharge de 1 message toutes les 3 minutes.

Limitation du serveur XMPP

Nous limitons le débit auquel vous pouvez vous connecter aux serveurs FCM XMPP à 400 connexions par minute et par projet. Cela ne devrait pas être un problème pour la livraison des messages, mais c'est important pour assurer la stabilité de notre système.

Pour chaque projet, FCM permet 2500 connexions en parallèle.

Débit maximal de messages vers un seul appareil

Vous pouvez envoyer jusqu'à 240 messages/minute et 5 000 messages/heure à un seul appareil. Ce seuil élevé est destiné à permettre des rafales de trafic à court terme, par exemple lorsque les utilisateurs interagissent rapidement via le chat. Cette limite empêche les erreurs de logique d'envoi de vider par inadvertance la batterie d'un appareil.

Limite de messages en amont

Nous limitons les messages en amont à 1.500.000 / minute par projet pour éviter de surcharger les serveurs de destination en amont.

Nous limitons les messages en amont par appareil à 1 000/minute pour éviter l'épuisement de la batterie en cas de mauvais comportement de l'application.

Limite de messages de sujet

Le taux d'ajout/suppression d'abonnement à un sujet est limité à 3 000 RPS par projet.

Pour les taux de transmission de messages, voir Fanout Throttling .

Étranglement du fanout

Un message sortance est le processus d'envoyer un message à plusieurs appareils, tels que lorsque vous ciblez des sujets et des groupes, ou lorsque vous utilisez le Notifications compositeur à des publics cibles ou segments d'utilisateurs.

La distribution des messages n'est pas instantanée et vous avez donc parfois plusieurs distributions en cours simultanément. Nous limitons le nombre de déploiements de messages simultanés par projet à 1 000. Après cela, nous pouvons rejeter des demandes de déploiement supplémentaires ou différer le déploiement des demandes jusqu'à ce que certains des déploiements déjà en cours soient terminés.

Le taux de déploiement réel atteignable est influencé par le nombre de projets demandant des déploiements en même temps. Un taux de déploiement de 10 000 QPS pour un projet individuel n'est pas rare, mais ce nombre n'est pas une garantie et est le résultat de la charge totale sur le système. Il est important de noter que la capacité de distribution disponible est répartie entre les projets et non entre les demandes de distribution. Ainsi, si votre projet a deux sortances en cours, alors chaque sortance ne verra que la moitié du taux de sortance disponible. La méthode recommandée pour maximiser votre vitesse de déploiement est de n'avoir qu'un seul déploiement actif en cours à la fois.

Ports FCM et votre pare-feu

Si votre organisation dispose d'un pare-feu pour restreindre le trafic vers ou depuis Internet, vous devez le configurer pour permettre aux appareils mobiles de se connecter à FCM afin que les appareils de votre réseau reçoivent des messages. FCM utilise généralement le port 5228, mais il utilise parfois 443, 5229 et 5230.

Pour les appareils se connectant sur votre réseau, FCM ne fournit pas d'adresses IP spécifiques, car notre plage d'adresses IP change trop fréquemment et vos règles de pare-feu pourraient devenir obsolètes, ce qui aurait un impact sur l'expérience de vos utilisateurs. Idéalement, autorisez les ports 5228-5230 et 443 sans restrictions IP. Toutefois, si vous devez avoir une restriction IP, vous devez allowlist toutes les adresses IP répertoriées dans goog.json . Cette grande liste est mise à jour régulièrement, et il est recommandé de mettre à jour vos règles tous les mois. Les problèmes causés par les restrictions IP du pare-feu sont souvent intermittents et difficiles à diagnostiquer.

Nous proposons un ensemble de noms de domaine qui peuvent être mis sur liste d'autorisation au lieu d'adresses IP. Ces noms d'hôtes sont répertoriés ci-dessous. Si nous commençons à utiliser des noms d'hôtes supplémentaires, nous mettrons à jour la liste ici. L'utilisation de noms de domaine pour votre règle de pare-feu peut ou non être fonctionnelle dans votre périphérique de pare-feu.

Ports à ouvrir :

  • 5228
  • 5229
  • 5230
  • 443

Noms d'hôtes à ouvrir :

  • 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.clients.google.com
  • appareil-provisioning.googleapis.com

Pare-feu de traduction d'adresses réseau et/ou d'inspection de paquets avec état :

Si votre réseau implémente la traduction d'adresses réseau (NAT) ou l'inspection de paquets avec état (SPI), implémentez un délai d'attente de 30 minutes ou plus pour nos connexions sur les ports 5228-5230. Cela nous permet de fournir une connectivité fiable tout en réduisant la consommation de batterie des appareils mobiles de vos utilisateurs.

Crédits

Selon les fonctionnalités FCM que vous implémentez, vous aurez peut-être besoin des informations d'identification suivantes de votre projet Firebase :

Identifiant du projet Identifiant unique pour votre projet Firebase, utilisé dans les requêtes adressées au point de terminaison HTTP FCM v1. Cette valeur est disponible dans Paramètres de la console Firebase volet.
Jeton d'inscription

Une chaîne de jeton unique qui identifie chaque instance d'application cliente. Le jeton d'enregistrement est requis pour la messagerie d'un seul appareil et d'un groupe d'appareils. Notez que les jetons d'enregistrement doivent rester secrets.

Identifiant de l'expéditeur Une valeur numérique unique créé lorsque vous créez votre projet Firebase, disponible dans le nuage de messagerie onglet de la fenêtre Paramètres de la console Firebase. L'ID de l'expéditeur est utilisé pour identifier chaque expéditeur pouvant envoyer des messages à l'application cliente.
Jeton d'accès Un jeton OAuth 2.0 de courte durée qui autorise les requêtes à l'API HTTP v1. Ce jeton est associé à un compte de service qui appartient à votre projet Firebase. Pour créer et jetons un accès rotate, suivez les étapes décrites dans Authorize Envoyer des demandes .
Clé de serveur (pour les protocoles hérités)

Une clé de serveur qui autorise votre serveur d'applications à accéder aux services Google, y compris l'envoi de messages via les anciens protocoles Firebase Cloud Messaging. Vous obtenez la clé du serveur lorsque vous créez votre projet Firebase. Vous pouvez le voir dans le nuage de messagerie onglet de la fenêtre Paramètres de la console Firebase.

Important: ne comprennent pas la clé serveur partout dans votre code client. Assurez-vous également d'utiliser uniquement des clés de serveur pour autoriser votre serveur d'applications. Android, la plate-forme Apple et les clés de navigateur sont rejetées par FCM.