Firebase Cloud Messaging (FCM) ofrece una amplia variedad de opciones de mensajería y capacidades. La información de esta página tiene por objetivo ayudarte a comprender los diferentes tipos de mensajes de FCM y lo que puedes hacer con ellos.
Tipos de mensajes
Con FCM, puedes enviar dos tipos de mensajes a los clientes:
- Mensajes de notificación, que a veces se consideran "mensajes de pantalla". El SDK de FCM maneja automáticamente estos mensajes.
- Mensajes de datos, que maneja la app cliente.
Los mensajes de notificación contienen un conjunto predefinido de claves visibles para el usuario. Los mensajes de datos, por el contrario, solo contienen pares clave-valor personalizados definidos por el usuario. Los mensajes de notificación pueden contener una carga útil de datos opcional. La carga útil máxima para ambos tipos de mensajes es de 4,096 bytes, excepto cuando se envían mensajes desde Firebase console. Esta consola aplica de manera forzosa un límite de 1,000 caracteres.
Caso de uso | Modo de envío | |
---|---|---|
Mensaje de notificación | El SDK de FCM muestra el mensaje en los dispositivos de los usuarios finales en nombre de la app cliente cuando se ejecuta en segundo plano. De lo contrario, si la app se está ejecutando en primer plano cuando se recibe la notificación, el código de la app determina el comportamiento. Los mensajes de notificación tienen un conjunto predefinido de claves visibles para el usuario y una carga de datos opcional de pares clave-valor personalizados. |
|
Mensaje de datos | La app cliente es responsable de procesar los mensajes de datos. Los mensajes de datos solo tienen pares clave-valor personalizados sin nombres de clave reservados (ver a continuación). | En un entorno de confianza, como
Cloud Functions
o tu servidor de apps, usa el
SDK de Admin o los
protocolos de servidor de FCM. En la solicitud de envío, configura la clave
data .
|
Si quieres que el SDK de FCM se encargue de mostrar una notificación automáticamente cuando tu app se ejecuta en segundo plano, usa mensajes de notificación. Si quieres procesar los mensajes con tu propio código de app cliente, usa mensajes de datos.
FCM puede enviar un mensaje de notificación que incluya una carga útil de datos opcional. En estos casos, FCM se encarga de mostrar la carga útil de notificaciones y la app cliente controla la carga útil de datos.
Mensajes de notificación
Para realizar pruebas, campañas de marketing y volver a generar la participación de los usuarios, puedes enviar mensajes de notificación con Firebase console. Firebase console proporciona pruebas A/B basadas en estadísticas para perfeccionar y mejorar los mensajes de marketing.
Para enviar mensajes de notificación de manera programática con el SDK de Admin o los
protocolos de FCM, configura la clave notification
con el
conjunto predefinido de opciones clave-valor necesarias para la parte del mensaje
de notificación que es visible para el usuario. Por ejemplo, el siguiente es un mensaje de notificación con formato JSON en una app de IM. El usuario debería ver un mensaje con el título “Portugal vs. Denmark” y el texto “great match!” en el dispositivo:
{ "message":{ "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...", "notification":{ "title":"Portugal vs. Denmark", "body":"great match!" } } }
Los mensajes de notificación se envían a la bandeja de notificación cuando la app se ejecuta en segundo plano. En el caso de las apps en primer plano, una función de devolución de llamada controla los mensajes.
Consulta la documentación de referencia del objeto de notificación del protocolo HTTP v1 para ver la lista completa de claves predefinidas disponibles para crear mensajes de notificación.
Mensajes de datos
Configura la clave apropiada con tus pares clave-valor personalizados para enviar una carga útil de datos a la app cliente.
Por ejemplo, el siguiente es un mensaje con formato JSON en la misma app de IM anterior, cuya información está encapsulada en la clave data
común y la app cliente debe interpretar el contenido:
{ "message":{ "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...", "data":{ "Nick" : "Mario", "body" : "great match!", "Room" : "PortugalVSDenmark" } } }
En el ejemplo anterior, se muestra el uso del campo común data
de nivel superior, que interpretan los clientes de todas las plataformas que reciben el mensaje.
En cada plataforma, la app cliente recibe la carga útil de datos
en una función de devolución de llamada.
Encriptación para mensajes de datos
La capa de transporte de Android (consulta la arquitectura de FCM) usa la encriptación de punto a punto. Según tus necesidades, puedes agregar encriptación de extremo a extremo a los mensajes de datos. FCM no proporciona una solución de extremo a extremo. Sin embargo, hay soluciones externas disponibles, como Capillary o DTLS.
Mensajes de notificación con carga útil de datos opcional
Puedes enviar mensajes de notificación que contengan una carga útil opcional de pares clave-valor personalizados, ya sea de forma programática o a través de Firebase console. En el Compositor de Notifications, usa los campos Datos personalizados en Opciones avanzadas.
El comportamiento de la app cuando recibe mensajes que incluyen cargas de notificaciones y de datos depende de si la app se encuentra en segundo plano o en primer plano; en otras palabras, si está activa o no cuando recibe los mensajes.
- Cuando está en segundo plano, la app recibe la carga de notificaciones en la bandeja de notificaciones y solo maneja la carga de datos cuando el usuario presiona la notificación.
- Cuando está en primer plano, la app recibe un objeto de mensaje con ambas cargas disponibles.
El siguiente mensaje con formato JSON contiene las claves notification
y data
:
{ "message":{ "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...", "notification":{ "title":"Portugal vs. Denmark", "body":"great match!" }, "data" : { "Nick" : "Mario", "Room" : "PortugalVSDenmark" } } }
Personaliza un mensaje en diferentes plataformas
El Firebase Admin SDK y el protocolo de HTTP v1 de FCM te permiten configurar
todos los campos disponibles del objeto
message
de las solicitudes de mensajes. Esto incluye lo siguiente:
- un conjunto común de campos que pueden interpretar todas las instancias de la app que reciben el mensaje
- conjuntos de campos específicos de la plataforma, como
AndroidConfig
yWebpushConfig
, que solo las instancias de la app que se ejecutan en la plataforma específica pueden interpretar
Los bloques específicos de la plataforma brindan la flexibilidad de personalizar mensajes para diferentes plataformas a fin de garantizar que se manejen correctamente cuando se reciben. El backend de FCM tendrá en cuenta todos los parámetros especificados y personalizará el mensaje para cada plataforma.
Cuándo usar campos comunes
Usa campos comunes en las siguientes circunstancias:
- Cuando quieras segmentar las instancias de la app a todas las plataformas: Apple, Android y la Web
- Cuando quieras enviar mensajes a temas
Todas las instancias de la app, independientemente de la plataforma, pueden interpretar los siguientes campos comunes:
Cuándo usar campos específicos de la plataforma
Usa campos específicos de la plataforma en las siguientes circunstancias:
- Cuando quieras enviar campos solo a plataformas específicas
- Cuando quieras enviar campos específicos de la plataforma además de campos comunes
Cuando desees enviar valores solo a plataformas específicas, no uses campos comunes, utiliza campos específicos de la plataforma en su lugar. Por ejemplo, para enviar una notificación solo a plataformas de Apple y a la Web, pero no a Android, debes usar dos conjuntos independientes de campos: uno para Apple y otro para la Web.
Cuando envíes mensajes con opciones de entrega específicas, usa campos específicos de la plataforma para configurarlas. Puedes especificar valores diferentes por plataforma si lo deseas. Sin embargo, debes usar campos específicos de la plataforma incluso cuando quieras configurar el mismo valor en distintas plataformas. Esto se debe a que cada plataforma puede interpretar el valor de manera levemente distinta. Por ejemplo, en Android, el tiempo de actividad se configura como un tiempo de vencimiento expresado en segundos, mientras que, en Apple, se configura como una fecha de vencimiento.
Ejemplo: mensaje de notificación con opciones de entrega específicas de la plataforma
La siguiente solicitud de envío v1 envía el mismo título de la notificación y el mismo contenido a todas las plataformas, pero también envía algunas anulaciones a plataformas específicas. En detalle, la solicitud realiza lo siguiente:
- Configura un tiempo de actividad prolongado para las plataformas Android y web, a la vez que establece la prioridad de los mensajes APNS (plataformas de Apple) en una opción baja.
- Configura las claves apropiadas para determinar la acción que se realizará cuando un usuario presione la notificación en Android y Apple (
click_action
ycategory
, respectivamente).
{ "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" } } } }
Consulta la documentación de referencia de HTTP v1 para obtener detalles sobre las claves disponibles en los bloques específicos de la plataforma en el cuerpo del mensaje. Para obtener más información sobre la creación de solicitudes de envío que contienen el cuerpo del mensaje, consulta cómo compilar solicitudes de envío.
Opciones de entrega
FCM proporciona un conjunto específico de opciones de entrega para los mensajes enviados a
dispositivos Android y habilita opciones similares en
plataformas de Apple y la Web. Por ejemplo, el comportamiento de los mensajes "contraíbles" es compatible con
Android a través de collapse_key
de FCM, con Apple a través de
apns-collapse-id
y con JavaScript/Web a través de Topic
. Para obtener detalles, consulta las descripciones de esta sección y la documentación de referencia relacionada.
Mensajes contraíbles y no contraíbles
Un mensaje no contraíble indica que cada mensaje individual se entrega al dispositivo. Un mensaje no contraíble entrega cierto contenido útil, a diferencia de un mensaje contraíble como un "ping" que no tiene contenido, destinado a comunicarse con el servidor y recuperar datos.
Algunos casos prácticos típicos de mensajes no contraíbles son los mensajes de chat o los mensajes críticos. Por ejemplo, en una app de IM, querrás enviar cada mensaje, ya que cada mensaje tiene un contenido diferente.
En Android, existe un límite de 100 mensajes que se pueden almacenar sin colapsar. Si se alcanza el límite, todos los mensajes almacenados se descartan. Cuando el dispositivo vuelve a estar en línea, recibe un mensaje especial que indica que se alcanzó el límite. Entonces, la app puede manejar la situación de manera adecuada, por lo general a través de una solicitud de sincronización completa desde el servidor de apps.
Un mensaje contraíble es un mensaje que se puede reemplazar por un mensaje nuevo si todavía no se ha enviado al dispositivo.
Un caso de uso común de los mensajes contraíbles son los mensajes que se utilizan para indicar a una app para dispositivos móviles que sincronice los datos del servidor. Un ejemplo sería una app de deportes que muestra marcadores actualizados a los usuarios. Solo el mensaje más reciente es relevante.
Para marcar un mensaje como contraíble en Android, incluye el parámetro
collapse_key
en
la carga útil del mensaje. Según la configuración predeterminada, la clave de contracción es el nombre del paquete de la app
registrado en Firebase console. El servidor de FCM puede
almacenar simultáneamente cuatro mensajes contraíbles diferentes por
dispositivo, cada uno con una clave de contracción diferente. Si excedes esta cantidad,
FCM únicamente conserva
cuatro claves de contracción, sin garantizar cuáles.
De forma predeterminada, se pueden contraer los mensajes por temas sin carga útil. Los mensajes de notificación
siempre se pueden contraer y, además, omitirán el parámetro collapse_key
.
¿Cuál debería usar?
Los mensajes contraíbles son una mejor opción desde el punto de vista del rendimiento, siempre que tu app no necesite usar mensajes no contraíbles. Sin embargo, si usas mensajes contraíbles, recuerda que FCM solo permite el uso de un máximo de cuatro claves de contracción por token de registro en cualquier momento para que FCM las utilice. No debes exceder esta cantidad, o podría causar consecuencias impredecibles.
Caso de uso | Modo de envío | |
---|---|---|
No contraíble | Cada mensaje es importante para la app cliente y debe entregarse. | Excepto para los mensajes de notificación, todos los mensajes son no contraíbles de forma predeterminada. |
Contraíble | Cuando hay un mensaje más reciente que procesa un mensaje más antiguo relacionado que es irrelevante para la app cliente, FCM reemplaza el mensaje más antiguo. Por ejemplo, los mensajes que se utilizan para iniciar una sincronización de datos del servidor o los mensajes de notificación desactualizados. | Determina el parámetro apropiado en tu solicitud de mensaje:
|
Configura la prioridad de un mensaje
Tienes dos opciones para asignar una prioridad de entrega a los mensajes descendentes: prioridad normal y alta. Aunque el comportamiento difiere levemente entre las plataformas, la entrega de mensajes con prioridad normal y alta funciona de la siguiente manera:
Prioridad normal. Los mensajes con prioridad normal se entregan de inmediato cuando la app está en primer plano. En el caso de las apps en segundo plano, es posible que se retrase la entrega. Para los mensajes menos urgentes, como las notificaciones de correos electrónicos nuevos, la sincronización de IU o la sincronización de datos de app en segundo plano, selecciona la prioridad de entrega normal.
Prioridad alta. FCM intenta entregar los mensajes de alta prioridad de inmediato, incluso si el dispositivo está en modo Descanso. Los mensajes con prioridad alta son para el contenido visible para los usuarios y sensible al tiempo.
A continuación, se muestra un ejemplo de un mensaje con prioridad normal enviado a través del protocolo de HTTP v1 de FCM para notificar a un suscriptor de una revista que existe contenido nuevo disponible para descargar:
{ "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" } } } }
Para obtener más detalles sobre la configuración de prioridad de los mensajes en diferentes plataformas, revisa los siguientes artículos:
- Documentación de APNS
- Configura y administra la prioridad de los mensajes (Android)
- Urgencia de los mensajes push web
Casos de uso de importancia vital
Las APIs de FCM no están diseñadas para alertas de emergencia ni otras actividades de alto riesgo en las que el uso o un fallo en las APIs podría provocar la muerte, lesiones personales o daños ambientales (como la operación de plantas nucleares, el control de tráfico aéreo o y los sistemas de soporte vital). Cualquier uso está expresamente prohibido en virtud de la Sección 4. a. 7 de las Condiciones del Servicio. Solo tú eres responsable de garantizar que la app cumpla con las Condiciones y de cualquier daño que se derive del incumplimiento. Google proporciona las APIs "tal como están", y se reserva el derecho de descontinuar las APIs o cualquier parte, función o acceso a ellos, por cualquier motivo y en cualquier momento sin responsabilidad ni ninguna otra obligación hacia ti o tus usuarios.
Configuración de la duración de un mensaje
Por lo general, FCM entrega los mensajes apenas se envían. Sin embargo, esto no siempre es posible. Por ejemplo, si la plataforma es Android, el dispositivo puede estar apagado, sin conexión o no disponible. O bien, FCM puede retrasar los mensajes de manera intencional para evitar que una app consuma recursos en exceso y perjudique la duración de la batería.
Cuando esto sucede, FCM almacena el mensaje y lo entrega tan pronto como sea factible. Esto es correcto en la mayoría de los casos. Sin embargo, para algunas apps, enviar un mensaje tarde es lo mismo que no entregarlo. Por ejemplo, si el mensaje es una notificación de llamada entrante o chat de video, solo es relevante durante un breve período antes de que finalice la llamada. Por otra parte, si el mensaje es una invitación a un evento, es inútil recibirlo una vez finalizado el evento.
En Android y Web/JavaScript, puedes especificar la duración máxima de un mensaje. El valor debe ser una duración de entre 0 y 2,419,200 segundos (28 días). Esto indicará el período máximo durante el cual FCM almacenará y tratará de entregar el mensaje. Las solicitudes que no contienen este campo reciben de forma predeterminada el período máximo de cuatro semanas.
A continuación, se muestran algunos usos posibles para esta función:
- Llamadas entrantes de chat de video
- Invitaciones a eventos vencidas
- Eventos del calendario
Otra ventaja de especificar la duración de un mensaje es que
FCM no aplica la regulación de mensajes contraíbles a los mensajes con un
valor de tiempo de actividad de 0 segundos.
FCM proporciona el mejor esfuerzo para administrar los mensajes que se deben
enviar "ahora o nunca". Ten en cuenta que un
valor time_to_live
de
0 significa que los mensajes que no se pueden entregar de inmediato se descartan. Sin embargo, dado que estos mensajes nunca se almacenan, esto proporciona la mejor latencia para enviar mensajes de notificación.
A continuación, se muestra un ejemplo de una solicitud que incluye el 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" } } } }
Duración de un mensaje
Cuando un servidor de apps publica un mensaje en FCM y recibe un ID de mensaje de vuelta, no significa que el mensaje ya se entregó al dispositivo. Más bien, significa que se aceptó para la entrega. Lo que sucede con el mensaje después de que se acepta depende de muchos factores.
En el mejor de los casos, si el dispositivo está conectado a FCM, la pantalla está encendida y no existen restricciones de regulación, el mensaje se entrega de inmediato.
Si el dispositivo está conectado, pero en modo Descanso, FCM almacena un mensaje con
prioridad baja hasta que el dispositivo sale del modo Descanso. Ahí
es cuando la marca collapse_key
cumple una función: Si ya existe
un mensaje con la misma clave de contracción (y el mismo token de registro) almacenado
y a la espera de
ser entregado, el mensaje antiguo se descarta y el mensaje nuevo ocupa su lugar
(es decir, el mensaje nuevo contrae el mensaje antiguo). Sin embargo, si no se configura la clave de contracción, tanto el mensaje nuevo como el antiguo se almacenan para su futuro envío.
Si el dispositivo no está conectado a FCM, el mensaje se almacena hasta
que se establece una conexión (una vez más, se respetan las reglas de las claves de contracción). Cuando
se establece una conexión, FCM entrega todos los mensajes pendientes al
dispositivo. Si el dispositivo nunca se vuelve a conectar
(por ejemplo, si se restableció la configuración de fábrica), el tiempo de espera del mensaje finalmente se agota y
se descarta del almacenamiento de FCM. El tiempo de espera predeterminado es de cuatro semanas,
a menos que se configure la marca time_to_live
.
Para obtener más información útil sobre la entrega de un mensaje, revisa lo siguiente:
Para obtener más información sobre la entrega de mensajes en plataformas de Android o Apple, consulta el panel de informes de FCM, que registra la cantidad de mensajes que se enviaron y abrieron en dispositivos Apple y Android, junto con los datos de "impresiones" (las notificaciones que ven los usuarios) en las apps para Android.
En el caso de los dispositivos Android que tienen habilitado el canal de mensajería directa, si el dispositivo no se conectó a FCM durante más de un mes, FCM acepta el mensaje de todas formas, pero lo descarta de inmediato. Si el dispositivo se conecta en un plazo de cuatro semanas desde el último mensaje de datos que le enviaste, tu cliente recibe la devolución de llamada onDeletedMessages(). Entonces, la app puede manejar la situación de manera adecuada, por lo general a través de una solicitud de sincronización completa desde el servidor de apps.
Por último, si FCM intenta entregar un mensaje al dispositivo y
la app se desinstaló, FCM descarta el mensaje de inmediato y
anula la validez del token de registro. Los intentos posteriores de enviar un mensaje a ese
dispositivo darán como resultado un error NotRegistered
.
Regulación y cuotas
Nuestro objetivo es entregar siempre cada mensaje que se envía mediante FCM. Sin embargo, cuando se entregan todos los mensajes, en ocasiones se genera una experiencia general deficiente para el usuario. En otros casos, debemos definir límites a fin de garantizar que FCM proporcione un servicio escalable para todos los remitentes. Los tipos de límites y cuotas descritos en esta sección nos ayudarán a equilibrar estos factores importantes.
Regulación de mensajes downstream
La API de HTTP v1 introdujo cuotas por proyecto y por minuto para la mensajería downstream. La cuota predeterminada de 600,000 mensajes por minuto abarca a más del 99% de los desarrolladores de FCM y, al mismo tiempo, protege la estabilidad del sistema y minimiza el impacto de los proyectos con aumentos bruscos.
Los patrones de tráfico con aumentos bruscos pueden generar errores de superación de la cuota. En una situación en la que se supera la cuota, el sistema entrega el código de estado HTTP 429 (CUOTA_EXCEEDED) hasta que se restablece la cuota en el siguiente minuto. También se pueden devolver 429 respuestas en situaciones de sobrecarga, por lo que se recomienda controlar los errores 429 de acuerdo con las recomendaciones publicadas.
Ten en cuenta lo siguiente:
- La cuota downstream mide los mensajes, no las solicitudes.
- Se cuentan los errores de cliente (código de estado HTTP 400-499) (excepto los errores 429).
- Las cuotas son por minuto, pero estos minutos no se alinean con la hora.
Supervisa la cuota
Puedes ver la cuota, el uso y los errores en la consola de Google Cloud:
- Ir a la consola de Google Cloud
- Selecciona APIs y servicios
- En la lista de tablas, selecciona API de Firebase Cloud Messaging
- Selecciona CUOTAS Y LÍMITES DEL SISTEMA.
NOTA: Estos gráficos no están alineados con precisión con los minutos de cuota, lo que significa que se pueden entregar errores 429 cuando el tráfico parece estar por debajo de la cuota.
Solicita un aumento de cuota
Antes de solicitar un aumento de la cuota, asegúrate de lo siguiente:
- Tu uso suele ser mayor o igual al 80% de la cuota durante al menos 5 minutos consecutivos por día.
- Tienes menos del 5% de proporción de errores de cliente, especialmente durante los períodos de tráfico máximo
- Sigues las prácticas recomendadas para enviar mensajes a gran escala.
Si cumples con estos criterios, puedes enviar una solicitud de aumento de cuota de hasta un 25%, y FCM hará todo lo posible para completar la solicitud (no se puede garantizar un aumento).
Si necesitas más cuota de mensajería downstream debido a un lanzamiento inminente o un evento temporal, solicita tu cuota con al menos 15 días de anticipación para permitir que haya tiempo suficiente para procesar la solicitud. Para las solicitudes grandes (más de 18 millones de mensajes por minuto), se requiere un aviso de al menos 30 días. Los lanzamientos y las solicitudes de eventos especiales aún están sujetos a la proporción de errores de cliente y a los requisitos de las prácticas recomendadas.
Consulta también las preguntas frecuentes sobre las cuotas de FCM.
Límite de los mensajes por temas
La tasa de adición o eliminación de suscripciones a temas se limita a 3,000 QPS por proyecto.
Consulta Regulación de la distribución para obtener información sobre las tasas de envío de mensajes.
Regulación de la distribución
La distribución de mensajes es el proceso de enviar mensajes a varios dispositivos, como cuando te orientas a temas y grupos, o usas el Compositor de Notifications para orientarte a públicos o segmentos de usuarios.
La distribución de mensajes no es una acción instantánea y rara vez habrá varias en curso simultáneamente. Limitamos a 1,000 la cantidad de distribuciones de mensajes simultáneas por proyecto. Cuando se alcance ese límite, es posible que rechacemos las solicitudes de distribución adicionales o aplacemos la distribución de las solicitudes hasta que se completen algunas que ya estén en curso.
La tasa real alcanzable de distribución varía según la cantidad de proyectos que soliciten distribuciones al mismo tiempo. No es inusual ver una tasa de distribución de 10,000 QPS en un proyecto individual, pero esa cantidad no se garantiza y proviene de la carga total del sistema. Cabe destacar que la capacidad de distribución disponible se divide entre los proyectos y no entre las solicitudes de distribución. Por lo tanto, si un proyecto tiene dos distribuciones en curso, cada una de estas solo podrá acceder a la mitad de la tasa de distribución disponible. Para maximizar la velocidad de distribución, se recomienda tener solo una distribución activa a la vez.
Regulación de mensajes contraíbles
Como se describió anteriormente, los mensajes contraíbles son notificaciones sin contenido diseñadas para contraerse una sobre otra. Si un desarrollador envía el mismo mensaje hacia una app con demasiada frecuencia, retrasaremos (regularemos) los mensajes a fin de disminuir el impacto sobre la batería del usuario.
Por ejemplo, si envías una gran cantidad de solicitudes de sincronización de correo electrónico nuevo a un solo dispositivo, es posible que retrasemos la siguiente solicitud unos minutos para que el dispositivo se pueda sincronizar a una tasa promedio más baja. La regulación se realiza exclusivamente para limitar el impacto sobre la batería del usuario.
Los mensajes no contraíbles pueden ser la opción adecuada si tu caso práctico requiere patrones de envío con picos de actividad elevados. Para tales mensajes, asegúrate de incluir el contenido en estos a fin de disminuir el consumo de batería.
Los mensajes contraíbles se limitan a picos de actividad de 20 mensajes por app y por dispositivo, con una reposición de 1 mensaje cada 3 minutos.
Regulación de servidores XMPP
Limitamos la tasa de conexiones a servidores XMPP de FCM a 400 por minuto y por proyecto. Esto no debería representar un problema para la entrega de mensajes, pero es importante a fin de garantizar la estabilidad del sistema. Para cada proyecto, FCM permite 2,500 conexiones paralelas.
Para los mensajes upstream con XMPP, FCM limita los mensajes upstream a 1,500,000 por minuto y por proyecto a fin de evitar la sobrecarga de los servidores de destino ascendentes.
Por dispositivo, el límite es de 1,000 por minuto a fin de evitar que el mal comportamiento de una app consuma la batería.
Tasa máxima de envío de mensajes a un solo dispositivo
En Android, puedes enviar hasta 240 mensajes por minuto y 5,000 mensajes por hora a un solo dispositivo. El propósito de este umbral alto es permitir que se produzcan aumentos de actividad de tráfico a corto plazo, como cuando los usuarios interactúan rápidamente por chat. Con este límite, se evita que se generen errores en los que la lógica de envío consume la batería de un dispositivo involuntariamente.
En iOS, se muestra un error cuando la tasa supera los límites de APNS.
Los puertos de FCM y el firewall
Si tu organización tiene un firewall para restringir el tráfico hacia o desde Internet, debes configurarlo para permitir que los dispositivos móviles se conecten con FCM de modo que los dispositivos en tu red puedan recibir mensajes. Por lo general, FCM utiliza el puerto 5228, pero en ocasiones utiliza los puertos 443, 5229 y 5230.
Para los dispositivos que se conectan a tu red, FCM no proporciona IPs específicas, ya que nuestro rango de IP cambia con demasiada frecuencia, y las reglas de tu firewall podrían quedar desactualizadas, lo que afectaría la experiencia de los usuarios. Lo ideal es incluir en la lista permitida los puertos del 5228 al 5230 y el 443 sin restricciones de IP. Sin embargo, si necesitas implementar una restricción de IP, debes incluir en la lista de entidades permitidas todas las direcciones IP enumeradas en goog.json. Esta lista grande se actualiza con frecuencia y se recomienda que actualices tus reglas de forma mensual. A menudo, los problemas causados por las restricciones de IP del firewall son intermitentes y difíciles de diagnosticar.
Ofrecemos un conjunto de nombres de dominio que se pueden incluir en la lista de entidades permitidas en lugar de las direcciones IP. Estos nombres de host se indican a continuación. Si comenzamos a usar nombres de host adicionales, actualizaremos la lista. Es posible que el uso de nombres de dominio para tu regla de firewall funcione o no en tu dispositivo de firewall.
Puertos TCP que se deben permitir:
- 5228
- 5229
- 5230
- 443
Nombres de host que se deben permitir:
- mtalk.google.com
- mtalk4.google.com
- mtalk-staging.google.com
- mtalk-dev.google.com
- alt1-mtalk.google.com
- alt2-mtalk.google.com
- alt3-mtalk.google.com
- alt4-mtalk.google.com
- alt5-mtalk.google.com
- alt6-mtalk.google.com
- alt7-mtalk.google.com
- alt8-mtalk.google.com
- android.apis.google.com
- device-provisioning.googleapis.com
- firebaseinstallations.googleapis.com
Firewalls de traducción de direcciones de red o inspección de paquetes con estado:
Si tu red implementa la traducción de direcciones de red (NAT) o la inspección de paquetes con estado (SPI), implementa un tiempo de espera de 30 minutos o más para nuestras conexiones a través de los puertos 5228, 5229 y 5230. Esto nos permite proporcionar una conectividad confiable y, al mismo tiempo, reducir el consumo de batería de los dispositivos móviles de los usuarios.
Interacciones de VPN y la capacidad de omitirlas
Firebase Cloud Messaging realiza varios pasos para garantizar que el envío de mensajes push del teléfono al servidor sea confiable y esté disponible con la mayor frecuencia posible. El uso de una VPN complica este esfuerzo.
Las VPNs enmascaran la información subyacente que FCM necesita para ajustar su conexión y maximizar la confiabilidad y la duración de batería. En algunos casos, las VPNs interrumpen de forma activa las conexiones de larga duración, lo que genera una mala experiencia del usuario debido a mensajes perdidos o retrasados, o a un alto costo de batería. Cuando la VPN está configurada para permitirnos hacerlo, omitimos la VPN con una conexión encriptada (a través de la red base Wi-Fi o LTE) para garantizar una experiencia confiable y con menos gasto de batería. El uso de FCM de las VPNs que pueden omitirse es específico del canal de notificaciones push de FCM. El resto del tráfico de FCM, como el tráfico de registro, usa la VPN si está activa. Cuando la conexión de FCM omite la VPN, pierde los beneficios adicionales que la VPN pueda proporcionar, como el enmascaramiento de IP.
Las diferentes VPNs tendrán distintos métodos para controlar si pueden omitir o no. Consulta la documentación de tu VPN específica para obtener instrucciones.
Si la VPN no está configurada para que se pueda omitir, Firebase Cloud Messaging usará la red de VPN para conectarse al servidor. Esto puede generar períodos en los que los mensajes se retrasan y puede provocar un mayor uso de batería, ya que Cloud Messaging trabaja para mantener la conexión a través de la conexión de VPN.
Credenciales
Según las funciones de FCM que implementes, es posible que necesites las siguientes credenciales de tu proyecto de Firebase:
ID del proyecto | Un identificador único para tu proyecto de Firebase, que se usa en las solicitudes al extremo HTTP v1 de FCM. Este valor está disponible en el panel Configuración de Firebase console. |
Token de registro | Una string de token único que identifica a cada instancia de la app cliente. El token de registro es obligatorio para la mensajería a dispositivos individuales y a grupos de dispositivos. Ten en cuenta que los tokens de registro se deben mantener en secreto. |
ID del remitente | Un valor numérico único que se genera cuando creas tu proyecto de Firebase disponible en la pestaña Cloud Messaging del panel Configuración de Firebase console. El ID de remitente se usa para identificar cada remitente que puede enviar mensajes a la app cliente. |
Token de acceso | Un token de OAuth 2.0 de corta duración que autoriza las solicitudes a la API de HTTP v1. Este token se asocia a una cuenta de servicio que pertenece a tu proyecto de Firebase. Para crear y rotar tokens de acceso, sigue los pasos que se describen en Autoriza solicitudes de envío. |
Clave de servidor (para protocolos heredados **obsoletos**) | Una clave de servidor que autoriza a tu servidor de apps a acceder a los servicios de Google, incluido el envío de mensajes a través de los protocolos heredados de Firebase Cloud Messaging obsoletos. Importante: No incluyas la clave de servidor en ninguna parte del código de cliente. Además, asegúrate de usar solo claves de servidor para autorizar tu servidor de apps. FCM rechaza las claves de Android, de las plataformas de Apple y del navegador. |