Ir para o console

Sobre as mensagens do FCM

O Firebase Cloud Messaging (FCM) oferece uma ampla gama de opções e recursos de mensagens. 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 mensagem 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 processadas 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 4 KB, exceto ao enviar mensagens do Console do Firebase, que impõe um limite de 1.024 caracteres.

Situação de uso Como enviar
Mensagem de notificação O FCM exibe automaticamente a mensagem para dispositivos do usuário final em nome do app cliente. 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.
  1. Em um ambiente confiável, como o Cloud Functions ou o servidor do aplicativo, use o SDK Admin ou os protocolos do servidor do FCM: configure a chave notification. Pode ter payload de dados opcional. Sempre é recolhível.
  2. 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. Em um ambiente confiável, como o Cloud Functions ou o servidor do aplicativo, use o SDK Admin ou os protocolos de servidor do FCM: configure somente a chave data.

Use mensagens de notificação quando quiser que o FCM faça a exibição de uma notificação em nome do app cliente. Use mensagens de dados quando quiser processar as mensagens no 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 atrair novamente o usuário, envie mensagens de notificação por meio do 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 com formatação JSON em um app 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 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. Por exemplo, esta é uma mensagem com formatação JSON no mesmo app de mensagens instantâneas citado acima, em que as informações são encapsuladas na chave data comum, e o app cliente precisa interpretar 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. :

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 SDK Admin do Firebase e o protocolo FCM v1 HTTP permitem que as solicitações de mensagens configurem todos os campos disponíveis no objeto message, como:

  • 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 a fim de garantir 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 quando ao:

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

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

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 iOS e Web, mas não para o Android, use dois conjuntos de campos separados, um para iOS 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, a vida útil é definida no Android como um período de validade em segundos, enquanto que no iOS é definido 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 do Android e da Web, ao mesmo tempo que define a prioridade da mensagem dos APNs (iOS) com uma configuração baixa;
  • define as chaves adequadas para definir o resultado de um toque do usuário na notificação no Android e no iOS: click_action e category, 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 envio

O FCM fornece um conjunto específico de opções de entrega para mensagens enviadas para dispositivos Android e permite opções semelhantes no iOS e na Web. Por exemplo, o comportamento de mensagem "recolhível" é aceito no Android via collapse_key no FCM, no iOS 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 aplicativo para dispositivos móveis para entrar em contato com o servidor e recuperar dados.

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. O FCM permite que no máximo quatro chaves de recolhimento diferentes por dispositivo Android sejam usadas pelo servidor do app em qualquer momento. Em outras palavras, 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.

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 que no máximo quatro chaves de recolhimento diferentes sejam usadas pelo servidor de conexão do FCM por token de registro em qualquer momento. Não exceda esse número ou poderá causar consequências imprevisíveis.

Situação 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 torna uma mensagem mais antiga e relacionada irrelevante para o app cliente, o FCM substitui a mensagem 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 no iOS
  • Topic na Web
  • collapse_key em protocolos legados (todas as plataformas)

Definir a prioridade de uma mensagem

Você tem duas opções para atribuir a prioridade de entrega para mensagens downstream no Android: prioridade normal e alta. A entrega de mensagens de prioridade normal e alta funciona da seguinte forma:

  • Prioridade normal. Essa é a prioridade padrão para mensagens de dados. As mensagens com prioridade normal são entregues imediatamente quando o app está em primeiro plano. Quando o dispositivo está no modo Soneca, a entrega pode ser adiada para economizar bateria. 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.

    Ao receber uma mensagem de prioridade normal no Android que solicite uma sincronização de dados em segundo plano para o aplicativo, é possível agendar uma tarefa com o WorkManager (em inglês) que lidará com ela quando a rede estiver disponível.

  • Prioridade alta. O FCM tenta enviar mensagens de prioridade alta imediatamente, permitindo que o serviço FCM ative um dispositivo em suspensão quando necessário e execute tarefas de processamento limitadas (inclusive acesso muito limitado à rede). As mensagens de prioridade alta devem resultar geralmente na interação do usuário com o app ou as notificações dele. Se o FCM detectar um padrão em que elas não precisam dessa interação, suas mensagens podem perder a prioridade. O Android P lançou intervalos de app em espera que limitam o número de mensagens de alta prioridade do FCM que você pode enviar ao seu app e que não resultam no uso do app nem na visualização de uma notificação pelo usuário. Se, em resposta a uma mensagem de alta prioridade, uma notificação for exibida de maneira visível para o usuário, a cota do intervalo de app em espera não será consumida por essa mensagem.

    Como uma pequena parcela dos dispositivos móveis Android funciona em redes de alta latência, evite abrir uma conexão com seus servidores antes de exibir uma notificação. Retornar uma chamada ao servidor antes de o tempo de processamento permitido terminar pode ser arriscado para usuários em redes de alta latência. Em vez disso, inclua o conteúdo da notificação na mensagem do FCM e exiba-o imediatamente. Para sincronizar conteúdo extra no aplicativo para Android, programe uma tarefa com o WorkManager (em inglês) para lidar com isso em segundo plano.

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

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 de alguma forma indisponível. 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 bate-papo por vídeo ou uma chamada recebida, ela só 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/no 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 nunca limita mensagens com um valor de vida útil de 0 segundos. Em outras palavras, o FCM garante a máxima atenção para as mensagens que precisam ser entregues sem atraso. Lembre-se de que um valor time_to_live de 0 indica que as mensagens que não puderem ser entregues imediatamente serã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 (vida útil, na sigla em inglês):

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

Como receber mensagens de vários remetentes

O FCM permite que várias entidades enviem mensagens para o mesmo app cliente. Por exemplo, suponha que o app cliente seja um agregador de artigos com vários colaboradores, e cada um deles poderá enviar uma mensagem quando publicar um novo artigo. Essa mensagem pode conter um URL para que o app cliente faça o download do artigo. Em vez de ter que centralizar toda a atividade de envio em um local, o FCM oferece a capacidade de deixar que cada colaborador envie as próprias mensagens.

Para ativar esse recurso, verifique se você tem o código de remetente de todos os remetentes. Ao solicitar o registro, o app cliente busca o token várias vezes, cada vez com um código de remetente diferente no campo do público por meio do método de recuperação de token da plataforma definida:

Não adicione vários IDs de remetente a uma única solicitação de token, porque isso pode gerar resultados imprevisíveis. Faça cada chamada separadamente, uma vez por código de remetente.

Por fim, compartilhe o token de registro com os remetentes correspondentes. Dessa forma, eles poderão enviar mensagens para o app cliente usando as próprias chaves de autenticação.

Lembre-se de que há um limite de 100 remetentes diferentes.

Vida útil de uma mensagem

Quando um servidor do app publica uma mensagem para o FCM e recebe um código 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, tanto a mensagem nova quanto a antiga 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 (novamente respeitando 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 seja definida.

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

  • Para Android e iOS: consulte o painel de relatórios do FCM (em inglês), que registra o número de mensagens enviadas e abertas em dispositivos iOS e Android, juntamente com dados de "impressões" (notificações vistas pelos usuários) para aplicativos para Android.
  • No Android: para ser notificado quando o aplicativo receber uma mensagem, use o recurso delivery_receipt_requested seguindo as diretrizes abaixo. Isso requer que você configure um servidor XMPP.

Para dispositivos Android e dispositivos iOS com canal direto ativado: se o dispositivo não se conectar ao FCM por mais de um mês, ele ainda aceitará a mensagem, mas a descartará imediatamente. Se o dispositivo se conectar dentro de quatro semanas a partir da última mensagem de dados enviada a ele, o cliente receberá o retorno de chamada onDeletedmensagens(). 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 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ção e escalonamento

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.

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

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 nosso sistema.

Taxa máxima de mensagens para um único dispositivo

É 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 de curto prazo, como quando os usuários estão interagindo rapidamente no bate-papo. Esse limite evita que erros no envio de lógica esgotem sem querer a bateria de um dispositivo.

Limite de mensagens upstream

Limitamos mensagens upstream a 15.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.

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 de Notificações no Console do Firebase.

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 sua velocidade de fanout é ter apenas um fanout ativo em andamento por vez.

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 se conectem com o FCM e, dessa forma, os dispositivos da sua rede recebam mensagens. Geralmente, o FCM usa a porta 5228, mas às vezes usa a 5229 e a 5230.

Para conexões de saída, 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, o que afetaria a experiência dos usuários. Idealmente, você precisa incluir as portas de 5228 a 5230 na lista de permissões sem restrições de IP. No entanto, se precisar de uma restrição de IP, você precisa incluir todos os endereços IP dos blocos IPv4 e IPv6 listados no ASN 15169 do Google na lista de permissões. Essa lista é bem grande, e é preciso planejar atualizações mensais nas suas regras. Problemas causados ​​por restrições de IP do firewall são muitas vezes intermitentes e difíceis de diagnosticar.

Portas a serem abertas para receber mensagens:

  • 5228
  • 5229
  • 5230

Portas para permitir conexões de saída:

Uma destas (recomendamos a primeira opção):

  1. Sem restrições de IP.
  2. Todos os endereços IP contidos nos blocos de IP listados no ASN 15169 do Google. Não se esqueça de atualizar essa lista pelo menos uma vez por mês.

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 seus usuários.

Credenciais

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

Código do projeto Um identificador exclusivo do seu projeto do Firebase usado em solicitações para o ponto de extremidade HTTP v1 do FCM. Esse valor está disponível no 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 se cria o projeto do Firebase, disponível na guia Cloud Messaging (em inglês) do painel Configurações do Console do Firebase. O código 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)

Uma chave do servidor que autoriza o servidor do app para acessar os serviços do Google, inclusive o envio de mensagens pelos protocolos legados do Firebase Cloud Messaging. Você recebe a chave do servidor quando você cria seu projeto do Firebase. Para visualizá-la, acesse a guia Cloud Messaging (em inglês) do painel Configurações do Console do Firebase.

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. Chaves Android, iOS e de navegador são recusadas pelo FCM.