Sobre as mensagens do FCM

Firebase Cloud Messaging (FCM) oferece várias opções de mensagens e funções. As informações nesta página têm o objetivo de ajudar você a entender os diferentes tipos de mensagem do FCM e o que você pode fazer com elas.

Tipos de mensagem

Com o FCM, você pode enviar dois tipos de mensagens aos clientes:

• Mensagens de notificação, às vezes conhecidas como "mensagens de exibição". Elas são processadas automaticamente pelo SDK do FCM.
• Mensagens de dados, que são tratadas pelo app cliente.

As mensagens de notificação contêm um conjunto predefinido de chaves visíveis pelo usuário. As mensagens de dados, por outro lado, contêm somente pares de chave-valor personalizados definidos pelo usuário. As mensagens de notificação podem conter um payload de dados opcional. O payload máximo para ambos os tipos de mensagem é de 4096 bytes, exceto ao enviar mensagens do Console do Firebase, que impõe um limite de 1.000 caracteres.

	Cenário de uso	Como enviar
Mensagem de notificação	O SDK do FCM exibe a mensagem para os dispositivos dos usuários finais em nome do app cliente, quando ele está em execução em segundo plano. Se o app estiver em execução em primeiro plano quando a notificação for recebida, é o código do aplicativo que determina o comportamento. As mensagens de notificação têm um conjunto predefinido de chaves visíveis pelo usuário e um payload de dados opcional de pares de chave-valor personalizados.	Em um ambiente confiável, como o Cloud Functions ou o servidor do app, use o SDK Admin ou a API HTTP v1. Defina a chave notification. Pode ter payload de dados opcional. Sempre é recolhível. Veja alguns exemplos de notificações de exibição e envie payloads de solicitações. Use o Editor do Notificações: insira o texto da mensagem, o título etc. e envie. Adicione payload de dados opcional fornecendo dados personalizados.
Mensagem de dados	O app cliente é responsável pelo processamento de mensagens de dados. As mensagens de dados têm apenas pares de chave-valor personalizados sem nomes de chave reservados (veja abaixo).	Em um ambiente confiável, como o Cloud Functions ou o servidor do app, use o SDK Admin ou os protocolos do servidor do FCM. Na solicitação de envio, defina a chave data.

Use mensagens de notificação quando quiser que o SDK do FCM faça a exibição de uma notificação automaticamente quando seu app estiver em execução em segundo plano. Use mensagens de dados quando quiser processar as mensagens com seu próprio código de app cliente.

O FCM pode enviar uma mensagem de notificação que inclui um payload de dados opcional. Nesses casos, o FCM processa a exibição do payload da notificação e o app cliente processa o payload de dados.

Mensagens de notificação

Para fazer testes ou marketing e reengajamento do usuário, envie mensagens de notificação usando o Console do Firebase. O Console do Firebase fornece testes A/B com base em análise para ajudar a refinar e melhorar as mensagens de marketing.

Para enviar mensagens de notificação programaticamente usando o SDK Admin ou os protocolos do FCM defina a chave notification com o conjunto predefinido necessário de opções de chave-valor para a parte visível pelo usuário da mensagem de notificação. Por exemplo, esta é uma mensagem de notificação formatada em JSON em um aplicativo de mensagens instantâneas. O usuário verá uma mensagem com o título "Portugal x Dinamarca" e o texto "ótima partida!" no dispositivo:

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

As mensagens de notificação são entregues na bandeja de notificação quando o app está em segundo plano. Para apps em primeiro plano, as mensagens são processadas por uma função de retorno de chamada.

Consulte a documentação de referência do objeto de notificação HTTP v1 Protocol para ver a lista completa de chaves predefinidas disponíveis para criar mensagens de notificação.

Mensagens de dados

Defina a chave adequada com seus pares de chave-valor personalizados para enviar um payload de dados para o app cliente.

Não use palavras reservadas nos seus pares de chave-valor personalizados. As palavras reservadas incluem "from", "notification", "message_type" ou qualquer palavra que comece com "google" ou "gcm".

Por exemplo, aqui está uma mensagem formatada em JSON no mesmo app de mensagens instantâneas, em que as informações estão encapsuladas na chave data comum e espera-se que o app cliente interprete o conteúdo:

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

O exemplo acima mostra o uso do campo data de nível superior ou comum, que é interpretado por clientes em todas as plataformas que recebem a mensagem. Em cada plataforma, o app cliente recebe o payload dos dados em uma função de retorno de chamada.

Criptografia para mensagens de dados

A Camada de transporte do Android (consulte Arquitetura do FCM) usa criptografia de ponta a ponta. Dependendo da sua necessidade, é possível adicionar esse tipo de criptografia às mensagens de dados. O FCM não oferece uma solução completa. No entanto, há soluções externas disponíveis, como Capillary ou DTLS.

Mensagens de notificação com payload de dados opcional

Seja programaticamente ou por meio do Console do Firebase, você pode enviar mensagens de notificação que contenham um payload opcional de pares de chave-valor personalizados. No Editor do Notificações (em inglês), use os campos Dados personalizados nas Opções avançadas.

O comportamento do app que recebe mensagens com payloads de notificação e dados depende de o app estar em primeiro ou segundo plano. Ou seja, se está ou não ativo quando recebe as mensagens.

• Quando estão em segundo plano, os apps recebem o payload de notificação na bandeja de notificações e processam apenas o payload de dados quando o usuário toca na notificação.
• Quando estão em primeiro plano, os apps recebem um objeto de mensagem com os dois payloads disponíveis.

Esta é uma mensagem com formatação JSON que contém as chaves notification e data:

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

Como personalizar uma mensagem entre plataformas

O Firebase Admin SDK e o protocolo HTTP v1 do FCM permitem que as solicitações de mensagens configurem todos os campos disponíveis no objeto message. Incluindo:

• Um conjunto comum de campos a serem interpretados por todas as instâncias do app que recebem a mensagem.
• Conjuntos de campos específicos da plataforma, como AndroidConfig e WebpushConfig, interpretados apenas pelas instâncias do app em execução na plataforma especificada.

Os blocos específicos da plataforma oferecem flexibilidade para personalizar mensagens em plataformas diferentes, garantindo, assim, que elas sejam gerenciadas corretamente quando recebidas. O back-end do FCM considerará todos os parâmetros especificados e personalizará a mensagem para cada plataforma.

Quando usar campos comuns

Use campos comuns ao:

• segmentar instâncias de aplicativos em todas as plataformas: Apple, Android e Web;
• enviar mensagens para tópicos.

Todas as instâncias do app, independentemente da plataforma, podem interpretar os seguintes campos comuns:

• message.notification.title
• message.notification.body
• message.data

Quando usar campos específicos da plataforma

Use campos específicos da plataforma quando quiser:

• enviar campos apenas para plataformas específicas;
• enviar campos específicos da plataforma, além dos campos comuns.

Sempre que você quiser enviar valores apenas para plataformas específicas, não use campos comuns. Em vez disso, use campos específicos da plataforma. Por exemplo, para enviar uma notificação apenas para as plataformas Apple e Web, mas não para o Android, use dois conjuntos de campos separados, um para a Apple e outro para a Web.

Ao enviar mensagens com opções de entrega específicas, use os campos específicos da plataforma para configurá-las. É possível especificar valores diferentes por plataforma, se você quiser. No entanto, mesmo quando você quiser definir essencialmente o mesmo valor em todas as plataformas, é necessário usar campos específicos da plataforma. Isso ocorre porque o valor pode ser interpretado de maneira ligeiramente diferente dependendo da plataforma. Por exemplo, no Android, a vida útil é definida como um prazo de validade em segundos, enquanto que, na Apple, é definida como uma data de validade.

Exemplo: mensagem de notificação com opções de entrega específicas da plataforma

A solicitação de envio v1 a seguir envia o título e o conteúdo de uma notificação comum para todas as plataformas, mas também envia algumas modificações específicas da plataforma. Especificamente, a solicitação:

• define uma vida útil longa para as plataformas Android e Web, ao mesmo tempo que define a prioridade das mensagens dos APNs (plataformas Apple) com uma configuração baixa;
• indica as chaves adequadas para definir o resultado de um toque do usuário na notificação no Android e na Apple: click_action ecategory, 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"
       }
     }
   }
 }

Consulte a documentação de referência HTTP v1 para ver mais detalhes sobre as chaves disponíveis em blocos específicos da plataforma no corpo da mensagem. Para mais informações sobre como criar solicitações de envio que contenham o corpo da mensagem, consulte Criar solicitações de envio.

Opções de entrega

O FCM fornece um conjunto específico de opções de entrega para mensagens enviadas para dispositivos Android e permite opções semelhantes nas plataformas Apple e Web. Por exemplo, o comportamento de mensagem "recolhível" é aceito no Android via collapse_key do FCM, na Apple via apns-collapse-id e em JavaScript/Web via Topic. Para mais detalhes, veja as descrições nesta seção e a documentação de referência relacionada.

Mensagens recolhíveis e não recolhíveis

Uma mensagem não recolhível indica que cada mensagem individual é entregue ao dispositivo. Uma mensagem não recolhível entrega conteúdo útil, ao contrário de uma mensagem recolhível, que dá um ping sem conteúdo ao app para dispositivos móveis para entrar em contato com o servidor e recuperar dados.

O FCM não garante a ordem de entrega.

Alguns casos de uso típicos de mensagens não recolhíveis são as mensagens de bate-papo ou críticas. Por exemplo, em um app de mensagens instantâneas, é possível que você queira enviar todas as mensagens, porque cada mensagem tem conteúdo diferente.

No Android, há um limite de 100 mensagens que podem ser armazenadas sem serem recolhidas. Se o limite for atingido, todas as mensagens armazenadas serão descartadas. Quando o dispositivo está de volta on-line, recebe uma mensagem especial indicando que o limite foi atingido. O app pode então processar a situação da maneira correta, normalmente solicitando uma sincronização completa com o servidor do app.

Uma mensagem recolhível é uma mensagem que pode ser substituída por uma nova mensagem se ainda não tiver sido entregue ao dispositivo.

Um caso de uso comum das mensagens recolhíveis são as mensagens usadas para informar um aplicativo para dispositivos móveis que é preciso sincronizar dados do servidor. Um exemplo seria um app de esportes que atualiza os usuários com a pontuação mais recente. Somente a mensagem mais recente é relevante.

Para marcar uma mensagem como recolhível no Android, inclua o parâmetro collapse_key no payload dela. Por padrão, a chave de recolhimento é o nome do pacote do app registrado no Console do Firebase. O servidor do FCM pode armazenar simultaneamente quatro mensagens recolhíveis diferentes por dispositivo, cada uma com uma chave de recolhimento diferente. Se você exceder esse número, o FCM manterá somente quatro chaves de recolhimento, sem garantias de quais serão mantidas.

As mensagens de tópico sem payload são recolhíveis por padrão. As mensagens de notificação são sempre recolhíveis e ignoram o parâmetro collapse_key.

Qual devo usar?

As mensagens recolhíveis são uma escolha melhor do ponto de vista de desempenho, desde que o app não precise usar mensagens não recolhíveis. No entanto, se você usar mensagens recolhíveis, lembre-se de que o FCM só permite usar no máximo quatro chaves de recolhimento diferentes pelo FCM por token de registro em qualquer momento. Não exceda esse número ou poderá causar consequências imprevisíveis.

	Cenário de uso	Como enviar
Não recolhível	Toda mensagem é importante para o app cliente e precisa ser entregue.	Com exceção das mensagens de notificação, todas as mensagens são não recolhíveis por padrão.
Recolhível	Quando há uma mensagem mais recente que renderiza uma mais antiga, relacionada, mas irrelevante para o app cliente, o FCM substitui a mais antiga. Por exemplo: mensagens usadas para iniciar uma sincronização de dados do servidor ou mensagens de notificação desatualizadas.	Defina o parâmetro apropriado na sua solicitação de mensagem: collapseKey no Android apns-collapse-id na Apple Topic na Web collapse_key em protocolos legados (todas as plataformas)

Como definir a prioridade de uma mensagem

Você tem duas opções para atribuir a prioridade de entrega para mensagens downstream: prioridade normal e alta. Embora o comportamento seja um pouco diferente entre as plataformas, a entrega de mensagens de prioridade normal e alta funciona assim:

• Prioridade normal. As mensagens com prioridade normal são entregues imediatamente quando o app está em primeiro plano. Para apps em segundo plano, a entrega pode ser adiada. Para mensagens menos afetadas pelo tempo, como enviar notificações de novos e-mails, manter a sincronização da sua IU ou sincronizar os dados do app em segundo plano, escolha a prioridade normal de entrega.

• Prioridade alta. O FCM tenta enviar mensagens de prioridade alta imediatamente, mesmo quando o dispositivo está no modo Soneca. As mensagens de prioridade alta são voltadas para conteúdo visível ao usuário e urgente.

Ao enviar mensagens de dados para dispositivos Apple, a prioridade precisa ser definida como 5 ou a prioridade normal. Mensagens enviadas com prioridade alta são rejeitadas pelo back-end do FCM com o erro INVALID_ARGUMENT.

Veja um exemplo de uma mensagem de prioridade normal enviada por meio do protocolo HTTP v1 do FCM para notificar um assinante de revista que um novo conteúdo está disponível para download:

{
  "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 mais detalhes específicos da plataforma na definição da prioridade da mensagem:

• Documentação de APNs
• Definir e gerenciar a prioridade de mensagens (Android)
• Urgência em mensagens push da Web

Casos de uso de missão crítica

As APIs FCM não estão projetadas para alertas de emergência ou outras atividades de alto risco em que o uso ou a falha das APIs possa resultar em morte, ferimentos em pessoas ou ambientes (como operação de instalações nucleares, controle de tráfego aéreo ou de suporte vital). Qualquer uso desse tipo é expressamente proibido sob a Seção 4. a. 7 dos Termos de Serviço. Você é o único responsável por gerenciar a conformidade do app com os Termos e por qualquer dano resultante da não conformidade. O Google fornece as APIs "no estado em que se encontram" e se reserva o direito de desativá-las ou qualquer parte, recurso ou acesso a elas, por qualquer motivo e a qualquer momento, sem responsabilidade ou outra obrigação para com você ou seus usuários.

Definir a vida útil de uma mensagem

O FCM geralmente entrega mensagens imediatamente após elas terem sido enviadas. No entanto, isso nem sempre é possível. Por exemplo, se a plataforma for Android, o dispositivo poderá estar desligado, desconectado ou indisponível de alguma forma. O FCM pode atrasar mensagens intencionalmente para evitar que um app consuma recursos excessivos, o que prejudica a duração da bateria.

Quando isso acontece, o FCM armazena a mensagem e a entrega o quanto antes. Embora isso não seja um problema na maioria dos casos, em alguns apps é possível que as mensagens atrasadas não sejam entregues. Por exemplo, se a mensagem for uma notificação de chat por vídeo ou uma chamada recebida, ela só vai ser relevante por um breve período até o encerramento da chamada. Se a mensagem for um convite para um evento, ela será inútil se for recebida após o término do evento.

No Android e na Web/em JavaScript, é possível especificar a vida útil máxima de uma mensagem. O valor precisa ter a duração de 0 a 2.419.200 segundos (28 dias) e corresponde ao período máximo pelo qual o FCM armazena e tenta entregar a mensagem. Para as solicitações que não tiverem esse campo preenchido, será usado o valor padrão do período máximo de quatro semanas.

Veja aqui alguns usos possíveis para este recurso:

• Chamadas de bate-papo por vídeo recebidas
• Eventos de convite expirando
• Eventos da agenda

Outra vantagem de especificar a vida útil de uma mensagem é que o FCM não aplica o limite de mensagens colapsáveis a mensagens com um valor de vida útil de 0 segundos. O FCM lida com as mensagens que precisam ser entregues "agora ou nunca". Tenha em mente que um valor time_to_live de 0 significa que mensagens que não podem ser entregues imediatamente são descartadas. No entanto, como essas mensagens nunca são armazenadas, isso gera a melhor latência para o envio de mensagens de notificação.

Veja um exemplo de solicitação que inclui 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"
      }
    }
  }
}

Vida útil de uma mensagem

Quando um servidor do app publica uma mensagem para o FCM e recebe um ID de mensagem de volta, isso não significa que a mensagem já foi entregue ao dispositivo. Na verdade, significa que ela foi aceita para a entrega. O que acontece com a mensagem após a aceitação depende de muitos fatores.

Em uma situação ideal, se o dispositivo estiver conectado ao FCM, a tela estiver ativada e não houver restrições de limite, a mensagem será entregue imediatamente.

Se o dispositivo estiver conectado, mas no modo Soneca, uma mensagem de prioridade baixa é armazenada pelo FCM até o dispositivo sair desse modo. É nesse momento que a sinalização collapse_key desempenha um papel: se já houver uma mensagem com a mesma chave de recolhimento (e token de registro) armazenada e aguardando a entrega, a mensagem antiga será descartada e a nova tomará o lugar dela. Ou seja, a mensagem antiga será recolhida pela nova. No entanto, se a chave de recolhimento não estiver definida, as mensagens novas e antigas serão armazenadas para entrega posterior.

Se o dispositivo não estiver conectado ao FCM, a mensagem será armazenada até que uma conexão seja estabelecida (respeitando novamente as regras da chave de recolhimento). Quando uma conexão é estabelecida, o FCM entrega todas as mensagens pendentes ao dispositivo. Se o dispositivo não se reconectar (por exemplo, se for redefinido para os padrões de fábrica), a mensagem acabará expirando e será descartada do armazenamento do FCM. O tempo limite padrão é de quatro semanas, a menos que a sinalização time_to_live esteja definida.

Para mais informações sobre a entrega de uma mensagem:

Para mais informações sobre a entrega de mensagens no Android ou Apple, consulte o painel de geração de relatórios do FCM, que registra o número de mensagens enviadas e abertas em dispositivos Apple e Android, além de dados para "impressões" (notificações vistas pelos usuários) de apps Android.

Para dispositivos Android com mensagens de canal direto ativadas, se o dispositivo não estiver conectado ao FCM por mais de um mês, o FCM ainda vai aceitar a mensagem, mas vai descartá-la imediatamente. Se o dispositivo se conectar dentro de quatro semanas a partir da última mensagem de dados enviada a ele, o cliente receberá a callback onDeletedMessages(). O app pode então processar a situação da maneira correta, normalmente solicitando uma sincronização completa do servidor do app.

Por fim, se o FCM tentar entregar uma mensagem ao dispositivo e o app tiver sido desinstalado, o FCM vai descartar a mensagem imediatamente e invalidar o token de registro. As próximas tentativas de enviar uma mensagem a esse dispositivo resultarão em um erro NotRegistered.

Limitações e cotas

Nosso objetivo é sempre entregar todas as mensagens enviadas pelo FCM. No entanto, entregar cada uma delas nem sempre resulta em uma boa experiência para o usuário. Em outros casos, precisamos fornecer limites para garantir que o FCM proporcione um serviço escalonável para todos os remetentes. Os tipos de limites e cotas descritos nesta seção nos ajudará a equilibrar esses importantes fatores.

Observação: os limites discutidos nesta seção estão sujeitos a alterações.

Como limitar mensagens downstream

A API HTTP v1 introduziu cotas por projeto e por minuto para troca de mensagens downstream. A cota padrão de 600 mil mensagens por minuto abrange mais de 99% dos desenvolvedores do FCM e protege a estabilidade do sistema e minimiza o impacto de projetos com picos.

Padrões de tráfego com picos podem resultar em erros por exceder a cota. Em um cenário de excesso de cota, o sistema envia o código de status HTTP 429 (QUOTA_EXCEEDED) até que a cota seja restaurada no minuto seguinte. Respostas 429 também podem ser devolvidas em situações de sobrecarga. Por isso, é altamente recomendável processar os códigos 429 de acordo com as recomendações publicadas.

Algumas considerações:

• A cota downstream mede mensagens, não solicitações.
• Os erros do cliente (código de status HTTP 400-499) são contabilizados (exceto o 429).
• As cotas são por minuto, mas esses minutos não são alinhados ao relógio.

Como monitorar a cota

Você pode ver a cota, o uso e os erros no console do Google Cloud:

1. Acesse o console do Google Cloud
2. Selecione APIs e serviços
3. Na lista de tabelas, selecione API Firebase Cloud Messaging
4. Selecione QUOTA & SYSTEM LIMITS.

OBSERVAÇÃO: esses gráficos não estão alinhados com precisão ao tempo de minutos de cota, o que significa que erros 429 podem ser exibidos quando o tráfego parece estar abaixo da cota.

Como solicitar aumento de cota

Antes de solicitar um aumento de cota, verifique se:

• Seu uso é regularmente ≥ 80% da cota por pelo menos 5 minutos consecutivos por dia.
• Você tem uma taxa de erro do cliente menor que 5%, especialmente durante o pico de tráfego.
• Você segue as práticas recomendadas para enviar mensagens em grande escala.

Se você atender a esses critérios, poderá enviar uma solicitação de aumento de cota de até +25% e o FCM fará o possível para atender à solicitação (nenhum aumento pode ser garantido).

Se você precisar de uma cota maior de mensagens downstream devido a um lançamento iminente ou um evento temporário, solicite o aumento da cota com pelo menos 15 dias de antecedência para permitir que haja tempo suficiente para lidar com a solicitação. Para solicitações grandes (>18 milhões de mensagens por minuto), o aviso precisa ser enviado com pelo menos 30 dias de antecedência. Os lançamentos e as solicitações de eventos especiais ainda ficam sujeitos à taxa de erro do cliente e aos requisitos de práticas recomendadas.

Consulte também as perguntas frequentes sobre cotas de FCM.

Limite de mensagem do tópico

A taxa de adição/remoção de assinatura do tópico é limitada a 3.000 QPS por projeto.

Para taxas de envio de mensagens, consulte Limitação de Fanout.

Limitação de Fanout

O fanout de mensagens é o processo de enviar uma mensagem para vários dispositivos, como quando se segmenta tópicos e grupos ou usa o Editor do Notificações para públicos-alvo ou segmentos de usuários.

O fanout das mensagens não é instantâneo e, de vez em quando, poderão ocorrer várias fanouts em andamento ao mesmo tempo. Limitamos o número de fanouts de mensagens simultâneas por projeto a 1.000. Depois disso, poderemos rejeitar novas solicitações de fanout ou adiar o fanout das solicitações até que alguns dos fanouts em andamento sejam concluídos.

A taxa de fanout real conquistada é influenciada pelo número de projetos que solicitam fanouts ao mesmo tempo. Uma taxa de fanout de 10.000 QPS para um projeto individual não é incomum, mas esse número não é uma garantia. Ele é um resultado da carga total no sistema. A capacidade de fanout disponível é dividida entre os projetos e não entre as solicitações de fanout. Portanto, se o projeto tiver dois fanouts em andamento, cada um verá apenas metade da taxa de fanout disponível. A maneira recomendada de maximizar a velocidade de fanout é ter apenas um fanout ativo em andamento por vez.

Limitação de mensagens recolhíveis

Conforme descrito acima, as mensagens recolhíveis são notificações sem conteúdo projetadas para se sobrepor umas às outras. Caso um desenvolvedor repita a mesma mensagem para um aplicativo com muita frequência, adiaremos as mensagens (limitaremos) para reduzir o impacto na bateria de um usuário.

Por exemplo, se você enviar um grande número de novas solicitações de sincronização de e-mail para um único dispositivo, poderemos adiar a próxima solicitação de sincronização de e-mail por alguns minutos para que o dispositivo possa ser sincronizado com uma taxa média mais baixa. Essa limitação é realizada estritamente para limitar o impacto da bateria presenciado pelo usuário.

Se o caso de uso exigir altos padrões de envio, as mensagens não recolhíveis podem ser a escolha certa. Para essas mensagens, inclua o conteúdo delas para reduzir o custo da bateria.

Limitamos mensagens recolhíveis a uma alta taxa de 20 mensagens por aplicativo por dispositivo, com um novo envio de 1 mensagem a cada 3 minutos.

Limitação do servidor XMPP

Cuidado: o envio de mensagens, incluindo mensagens upstream com as APIs legadas XMPP e HTTP do FCM foi descontinuado em 20 de junho de 2023 e será removido em junho. de 2024. Se você estiver usando as APIs de envio legadas do FCM, recomendamos migrar para a API HTTP v1 ou usar o SDK Admin para criar solicitações de envio.

Limitamos a taxa que você pode conectar aos servidores XMPP do FCM a 400 conexões por minuto por projeto. Isso não deve ser um problema para a entrega de mensagens, mas é importante para garantir a estabilidade do sistema. Para cada projeto, o FCM permite 2.500 conexões em paralelo.

Para mensagens upstream com XMPP, o FCM limita as mensagens upstream a 1.500.000/minuto por projeto para evitar a sobrecarga de servidores de destino upstream.

Limitamos mensagens upstream por dispositivo a 1.000/minuto para proteger contra o consumo de bateria relacionado ao mau comportamento do aplicativo.

Taxa máxima de mensagens para um único dispositivo

No Android, é possível enviar até 240 mensagens/minuto e 5.000 mensagens/hora para um único dispositivo. O objetivo desse alto limite é permitir aumentos de tráfego em curto prazo, como quando os usuários estão interagindo rapidamente no chat. Esse limite evita que erros na lógica de envio esgotem sem querer a bateria de um dispositivo.

No iOS, um erro é retornado quando a taxa excede os limites dos APNs.

Cuidado: não envie mensagens regularmente perto dessa taxa máxima. Isso pode desperdiçar recursos dos usuários finais, e seu aplicativo pode ser marcado como abusivo.

Portas do FCM e seu firewall

Se sua organização tiver um firewall para restringir o tráfego, para ou da Internet, será necessário configurá-lo para permitir que os dispositivos móveis da sua rede se conectem com o FCM e recebam mensagens. Geralmente, o FCM usa a porta 5228, mas às vezes usa a 443, a 5229 e a 5230.

Para dispositivos que se conectam à rede, o FCM não fornece IPs específicos porque nosso intervalo de IPs muda com frequência e suas regras de firewall podem ficar desatualizadas e afetar a experiência dos usuários. O ideal é incluir na lista de permissões as portas de 5228 a 5230 e 443 sem restrições de IP. No entanto, se você tiver uma restrição de IP, será necessário colocar todos os endereços IP listados em goog.json na lista de permissões. Essa lista grande é atualizada regularmente. Recomendamos que você atualize as regras mensalmente. Problemas causados por restrições de IP do firewall são muitas vezes intermitentes e difíceis de diagnosticar.

Oferecemos um conjunto de nomes de domínios que podem ser incluídos na lista de permissões em vez de endereços IP. Esses nomes de host estão listados abaixo. Se começarmos a usar nomes de host adicionais, vamos atualizar a lista aqui. O uso de nomes de domínio para sua regra de firewall pode ou não ser funcional no dispositivo de firewall.

Portas TCP a serem abertas:

• 5228
• 5229
• 5230
• 443

Nomes de host a serem abertos:

• 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 com conversão de endereços de rede e/ou inspeção dos estados dos pacotes:

Caso sua rede implemente Conversão de endereços de rede (NAT, na sigla em inglês) ou Inspeção dos estados dos pacotes (SPI, na sigla em inglês), implemente um tempo limite de 30 minutos ou mais para nossas conexões nas portas 5228 a 5230. Com isso, podemos fornecer uma conectividade confiável, reduzindo o consumo de bateria dos dispositivos móveis dos usuários.

Observação: se você receber notificações por APNs, abra também as portas especificadas pela Apple (em inglês).

Interações e bypass de VPN

O Firebase Cloud Messaging realiza várias etapas para garantir que a conexão de mensagens push do smartphone para o servidor seja confiável e disponível com a maior frequência possível. O uso de uma VPN complica esse esforço.

As VPNs mascaram as informações que o FCM precisa para ajustar a conexão para maximizar a confiabilidade e duração da bateria. Em alguns casos, as VPNs interrompem ativamente as conexões de longa duração que resultam em uma experiência do usuário ruim devido a mensagens atrasadas ou um alto custo de bateria. Quando a VPN está configurada para permitir que ignoremos a VPN usando uma conexão criptografada (por meio da rede Wi-Fi ou LTE de base) para garantir uma experiência fácil e confiável. O uso de VPNs bypass pelo FCM é específico do canal de notificação push do FCM. Outro tráfego do FCM, como o de registro, usa a VPN se ela estiver ativa. Quando a conexão do FCM ignora a VPN, ela perde outros benefícios que a VPN pode oferecer, como máscara de IP.

VPNs diferentes têm métodos diferentes para controlar se elas podem ser ignoradas. Consulte a documentação específica da sua VPN para ver as instruções.

Se a VPN não estiver configurada para ser ignorada, o Firebase Cloud Messaging usará a rede VPN para se conectar ao servidor. Isso pode resultar em períodos em que as mensagens fiquem atrasadas e em mais uso da bateria, à medida que o Cloud Messaging trabalha para manter a conexão pela VPN.

Credenciais

Dependendo dos recursos do FCM implementados, as seguintes credenciais do projeto do Firebase podem ser necessárias:

ID do projeto	Um identificador exclusivo do projeto do Firebase usado em solicitações para o endpoint HTTP v1 do FCM. Esse valor está disponível no painel painel Configurações do Console do Firebase.
Token de registro	Uma string de token exclusiva que identifica cada instância do app cliente. O token de registro é necessário para mensagens para dispositivos únicos e grupos de dispositivos. Observe que os tokens de registro precisam ser mantidos em segredo.
Código do remetente	Um valor numérico exclusivo gerado quando você cria o projeto do Firebase. disponível na guia Cloud Messaging do painel Configurações do Console do Firebase. O ID do remetente é usado para identificar cada remetente que pode enviar mensagens ao app cliente.
Token de acesso	Um token OAuth 2.0 de curta duração que autoriza solicitações para a API HTTP v1. Esse token está associado a uma conta de serviço que pertence ao seu projeto do Firebase. Para criar e alternar tokens de acesso, siga as etapas descritas em Autorizar solicitações de envio.
Chave do servidor (para protocolos legados **descontinuados**)	Uma chave do servidor que autoriza o servidor do app a acessar os serviços do Google, inclusive o envio de mensagens pelos protocolos legados descontinuados do Firebase Cloud Messaging. Importante: não inclua a chave do servidor em nenhum lugar do código de cliente. Além disso, use apenas chaves de servidores para autorizar o servidor do app. As chaves das plataformas Android e Apple e do navegador serão rejeitadas pelo FCM.