Sobre as mensagens do FCM

Firebase Cloud Messaging (FCM) oferece uma ampla gama de opções e recursos de mensagens. As informações nesta página têm como objetivo ajudá-lo a compreender os diferentes tipos de mensagens do FCM e o que você pode fazer com elas.

Tipos de mensagens

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

• Mensagens de notificação, às vezes chamadas de “mensagens de exibição”. Eles são tratados automaticamente pelo SDK do FCM.
• Mensagens de dados, que são tratadas pelo aplicativo cliente.

As mensagens de notificação contêm um conjunto predefinido de chaves visíveis ao usuário. As mensagens de dados, por outro lado, contêm apenas pares de valores-chave personalizados definidos pelo usuário. As mensagens de notificação podem conter uma carga útil de dados opcional. A carga máxima para ambos os tipos de mensagem é de 4.000 bytes, exceto ao enviar mensagens do console do Firebase, que impõe um limite de 1.000 caracteres.

	Usar cenário	Como enviar
Mensagem de notificação	O SDK do FCM exibe a mensagem aos dispositivos do usuário final em nome do aplicativo cliente quando ele está em execução em segundo plano. Caso contrário, se o aplicativo estiver em execução em primeiro plano quando a notificação for recebida, o código do aplicativo determinará o comportamento. As mensagens de notificação têm um conjunto predefinido de chaves visíveis ao usuário e uma carga de dados opcional de pares chave-valor personalizados.	Em um ambiente confiável, como Cloud Functions ou seu servidor de aplicativos, use o SDK Admin ou a API HTTP v1 . Defina a chave notification . Pode ter carga útil de dados opcional. Sempre dobrável. Veja alguns exemplos de notificações de exibição e envio de cargas de solicitação. Use o compositor de notificações : insira o texto da mensagem, o título, etc., e envie. Adicione carga de dados opcional fornecendo dados personalizados.
Mensagem de dados	O aplicativo cliente é responsável pelo processamento de mensagens de dados. As mensagens de dados têm apenas pares de valores-chave personalizados, sem nomes de chaves reservados (veja abaixo).	Em um ambiente confiável, como Cloud Functions ou seu servidor de aplicativos, use o SDK Admin ou os protocolos de servidor FCM . Na solicitação de envio, defina a chave data .

Use mensagens de notificação quando quiser que o SDK do FCM lide com a exibição automática de uma notificação quando seu aplicativo estiver sendo executado em segundo plano. Use mensagens de dados quando quiser processar as mensagens com seu próprio código de aplicativo cliente.

O FCM pode enviar uma mensagem de notificação incluindo uma carga de dados opcional. Nesses casos, o FCM trata da exibição da carga útil da notificação e o aplicativo cliente lida com a carga útil dos dados.

Mensagens de notificação

Para testes ou para marketing e reengajamento do usuário, você pode enviar mensagens de notificação usando o Firebase console . O console do Firebase oferece testes A/B baseados em análises para ajudar você a refinar e melhorar as mensagens de marketing.

Para enviar mensagens de notificação programaticamente usando o SDK Admin ou os protocolos FCM, defina a chave notification com o conjunto predefinido necessário de opções de valor-chave para a parte visível do usuário da mensagem de notificação. Por exemplo, aqui está uma mensagem de notificação no formato JSON em um aplicativo de mensagens instantâneas. O utilizador poderá esperar ver uma mensagem com o título “Portugal vs. Dinamarca” e o texto “ótimo jogo!” 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 aplicativo está em segundo plano. Para aplicativos em primeiro plano, as mensagens são tratadas por uma função de retorno de chamada.

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

Mensagens de dados

Defina a chave apropriada com seus pares de valores-chave personalizados para enviar uma carga de dados ao aplicativo cliente.

Certifique-se de não usar nenhuma palavra reservada em seus pares de valores-chave personalizados. As palavras reservadas incluem "from", "notification", "message_type" ou qualquer palavra que comece com "google" ou "gcm".

Por exemplo, aqui está uma mensagem no formato JSON no mesmo aplicativo de mensagens instantâneas acima, onde as informações são encapsuladas na chave data comum e espera-se que o aplicativo 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 pelos clientes em todas as plataformas que recebem a mensagem. Em cada plataforma, o aplicativo cliente recebe a carga de dados em uma função de retorno de chamada.

Criptografia para mensagens de dados

A camada de transporte do Android (ver arquitetura FCM ) usa criptografia ponto a ponto. Dependendo das suas necessidades, você pode decidir adicionar criptografia ponta a ponta às mensagens de dados. O FCM não fornece uma solução ponta a ponta. No entanto, existem soluções externas disponíveis, como Capilar ou DTLS .

Mensagens de notificação com carga útil de dados opcional

Tanto de forma programática quanto por meio do console do Firebase, você pode enviar mensagens de notificação que contêm uma carga opcional de pares de valores-chave personalizados. No compositor de notificações , use os campos de dados personalizados em opções avançadas .

O comportamento do aplicativo ao receber mensagens que incluem cargas úteis de notificação e de dados depende se o aplicativo está em segundo plano ou em primeiro plano - essencialmente, se ele está ativo ou não no momento do recebimento.

• Quando estão em segundo plano , os aplicativos recebem a carga de notificação na bandeja de notificações e só processam a carga de dados quando o usuário toca na notificação.
• Quando estiver em primeiro plano , seu aplicativo receberá um objeto de mensagem com ambas as cargas disponíveis.

Aqui está uma mensagem no formato JSON contendo a chave notification e a chave data :

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

Personalizando uma mensagem entre plataformas

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

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

Os blocos específicos da plataforma oferecem flexibilidade para personalizar mensagens para diferentes plataformas, garantindo que elas sejam tratadas corretamente quando recebidas. O backend do FCM levará em consideração todos os parâmetros especificados e personalizará a mensagem para cada plataforma.

Quando usar campos comuns

Use campos comuns quando você:

• Direcionando instâncias de aplicativos em todas as plataformas — Apple, Android e web
• Enviando mensagens para tópicos

Todas as instâncias do aplicativo, 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:

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

Sempre que desejar enviar valores apenas para plataformas específicas, não utilize campos comuns; use campos específicos da plataforma. Por exemplo, para enviar uma notificação apenas para plataformas Apple e web, mas não para Android, você deve usar dois conjuntos separados de campos, um para Apple e outro para web.

Ao enviar mensagens com opções de entrega específicas, use campos específicos da plataforma para defini-las. Você pode especificar valores diferentes por plataforma, se desejar. No entanto, mesmo quando quiser definir essencialmente o mesmo valor entre plataformas, você deverá usar campos específicos da plataforma. Isso ocorre porque cada plataforma pode interpretar o valor de maneira um pouco diferente – por exemplo, o tempo de vida é definido no Android como um tempo de expiração em segundos, enquanto na Apple é definido como uma data de expiração.

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

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

• define um longo tempo de vida para plataformas Android e Web, enquanto define a prioridade de mensagens de APNs (plataformas Apple) para uma configuração baixa
• define as teclas apropriadas para definir o resultado de um toque do usuário na notificação no Android e Apple - 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 do HTTP v1 para obter detalhes completos sobre as chaves disponíveis em blocos específicos da plataforma no corpo da mensagem. Para obter 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 em plataformas Apple e na web. Por exemplo, o comportamento de mensagem "recolhível" é suportado no Android por meio collapse_key do FCM, na Apple por meio de apns-collapse-id e em JavaScript/Web por meio de Topic . Para obter detalhes, consulte as descrições nesta seção e a documentação de referência relacionada.

Mensagens não recolhíveis e recolhíveis

Uma mensagem não recolhível indica que cada mensagem individual é entregue ao dispositivo. Uma mensagem não recolhível fornece algum conteúdo útil, em oposição a uma mensagem recolhível, como um "ping" sem conteúdo para o aplicativo móvel entrar em contato com o servidor para buscar dados.

A FCM não garante a ordem de entrega.

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

Para Android existe um limite de 100 mensagens que podem ser armazenadas sem colapsar. Se o limite for atingido, todas as mensagens armazenadas serão descartadas. Quando o dispositivo estiver online novamente, ele receberá uma mensagem especial indicando que o limite foi atingido. O aplicativo pode então lidar com a situação adequadamente, normalmente solicitando uma sincronização completa do servidor do aplicativo.

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 de mensagens recolhíveis são mensagens usadas para instruir um aplicativo móvel a sincronizar dados do servidor. Um exemplo seria um aplicativo de esportes que atualiza os usuários com os resultados mais recentes. Apenas a mensagem mais recente é relevante.

Para marcar uma mensagem como recolhível no Android, inclua o parâmetro collapse_key na carga útil da mensagem. Por padrão, a chave de recolhimento é o nome do pacote do aplicativo registrado no console do Firebase. O servidor 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á apenas quatro chaves de recolhimento, sem garantias sobre quais serão mantidas.

Mensagens de tópico sem carga útil são recolhíveis por padrão. As mensagens de notificação são sempre recolhíveis e ignorarão o parâmetro collapse_key .

Qual devo usar?

Mensagens recolhíveis são uma escolha melhor do ponto de vista de desempenho, desde que seu aplicativo 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 um máximo de quatro chaves de recolhimento diferentes sejam usadas pelo FCM por token de registro a qualquer momento. Você não deve exceder esse número, ou isso poderá causar consequências imprevisíveis.

	Usar cenário	Como enviar
Não dobrável	Cada mensagem é importante para o aplicativo cliente e precisa ser entregue.	Exceto as mensagens de notificação, todas as mensagens não podem ser recolhidas por padrão.
Dobrável	Quando há uma mensagem mais recente que torna uma mensagem relacionada mais antiga irrelevante para o aplicativo 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 na Apple Topic na Web collapse_key em protocolos legados (todas as plataformas)

Definir a prioridade de uma mensagem

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

• Prioridade normal. Mensagens de prioridade normal são entregues imediatamente quando o aplicativo está em primeiro plano. Para aplicativos em segundo plano, a entrega pode atrasar. Para mensagens menos urgentes, como notificações de novos e-mails, manter sua IU sincronizada ou sincronizar dados de aplicativos em segundo plano, escolha a prioridade de entrega normal.

• Prioridade máxima. O FCM tenta entregar mensagens de alta prioridade imediatamente, mesmo se o dispositivo estiver no modo Soneca. Mensagens de alta prioridade são para conteúdo sensível ao tempo e visível ao usuário.

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

Aqui está um exemplo de mensagem de prioridade normal enviada por meio do protocolo FCM HTTP v1 para notificar um assinante de revista de que 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 obter mais detalhes específicos da plataforma sobre como definir a prioridade das mensagens:

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

Definir a vida útil de uma mensagem

O FCM geralmente entrega as mensagens imediatamente após serem enviadas. No entanto, isso nem sempre é possível. Por exemplo, se a plataforma for Android, o dispositivo poderá estar desligado, off-line ou indisponível de outra forma. Ou o FCM pode atrasar intencionalmente as mensagens para evitar que um aplicativo consuma recursos excessivos e afete negativamente a vida útil da bateria.

Quando isso acontece, o FCM armazena a mensagem e a entrega assim que possível. Embora isso seja bom na maioria dos casos, existem alguns aplicativos para os quais uma mensagem atrasada pode nunca ser entregue. Por exemplo, se a mensagem for uma chamada recebida ou uma notificação de bate-papo por vídeo, ela será significativa apenas por um curto período de tempo antes de a chamada ser encerrada. Ou se a mensagem for um convite para um evento, será inútil se for recebida após o término do evento.

No Android e Web/JavaScript, você pode especificar a vida útil máxima de uma mensagem. O valor deve ter uma duração de 0 a 2.419.200 segundos (28 dias) e corresponde ao período máximo de tempo durante o qual o FCM armazena e tenta entregar a mensagem. As solicitações que não contêm esse campo têm como padrão o período máximo de quatro semanas.

Aqui estão alguns usos possíveis para esse recurso:

• Chamadas recebidas de bate-papo por vídeo
• Eventos de convite expirados
• Eventos do calendário

Outra vantagem de especificar a vida útil de uma mensagem é que o FCM não aplica a limitação de mensagens recolhíveis a mensagens com um valor de tempo de vida de 0 segundos. O FCM oferece o melhor tratamento para mensagens que devem ser entregues "agora ou nunca". Lembre-se de que um valor time_to_live igual a 0 significa que as mensagens que não podem ser entregues imediatamente serão descartadas. Entretanto, como essas mensagens nunca são armazenadas, isso proporciona a melhor latência para o envio de mensagens de notificação.

Aqui está 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 de aplicativo posta uma mensagem no FCM e recebe um ID de mensagem de volta, isso não significa que a mensagem já foi entregue ao dispositivo. Em vez disso, significa que foi aceito para entrega. O que acontece com a mensagem depois que ela é aceita depende de muitos fatores.

Na melhor das hipóteses, se o dispositivo estiver conectado ao FCM, a tela estiver ligada e não houver restrições de limitação, a mensagem será entregue imediatamente.

Se o dispositivo estiver conectado, mas em Soneca, uma mensagem de baixa prioridade será armazenada pelo FCM até que o dispositivo saia do Soneca. E é aí que o sinalizador collapse_key desempenha um papel: se já houver uma mensagem com a mesma chave de colapso (e token de registro) armazenada e aguardando entrega, a mensagem antiga será descartada e a nova mensagem tomará seu lugar (ou seja, a mensagem antiga a mensagem é recolhida pela nova). No entanto, se a chave de recolhimento não for definida, as mensagens novas e antigas serão armazenadas para entrega futura.

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 nunca mais for conectado (por exemplo, se tiver sido redefinido para os padrões de fábrica), a mensagem eventualmente expirará e será descartada do armazenamento do FCM. O tempo limite padrão é de quatro semanas, a menos que o sinalizador time_to_live esteja definido.

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

Para obter mais informações sobre a entrega de mensagens nas plataformas Android ou Apple, consulte o painel de relatórios do FCM , que registra o número de mensagens enviadas e abertas em dispositivos Apple e Android, juntamente com dados de "impressões" (notificações vistas pelos usuários) para Aplicativos 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 aceitará a mensagem, mas a descartará imediatamente. Se o dispositivo se conectar dentro de quatro semanas após a última mensagem de dados enviada a ele, seu cliente receberá o retorno de chamada onDeletedMessages() . O aplicativo pode então lidar com a situação adequadamente, normalmente solicitando uma sincronização completa do servidor do aplicativo.

Por fim, quando o FCM tenta entregar uma mensagem ao dispositivo e o aplicativo é desinstalado, o FCM descarta a mensagem imediatamente e invalida o token de registro. Tentativas futuras de enviar uma mensagem para esse dispositivo resultam em um erro NotRegistered .

Limitação e dimensionamento

Nosso objetivo é sempre entregar todas as mensagens enviadas via FCM. No entanto, entregar todas as mensagens às vezes resulta em uma experiência geral ruim para o usuário. Noutros casos, precisamos de estabelecer limites para garantir que o FCM fornece um serviço escalável para todos os remetentes.

Nota: Os limites discutidos nesta seção estão sujeitos a alterações.

Limitação de mensagens recolhíveis

Conforme descrito acima, as mensagens recolhíveis são notificações sem conteúdo projetadas para serem recolhidas umas sobre as outras. Caso um desenvolvedor repita a mesma mensagem para um aplicativo com muita frequência, atrasamos (aceleramos) as mensagens para reduzir o impacto na bateria do 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 atrasar a próxima solicitação de sincronização de e-mail em alguns minutos para que o dispositivo possa sincronizar a uma taxa média mais baixa. Esse afogamento é feito estritamente para limitar o impacto da bateria sofrido pelo usuário.

Se o seu caso de uso exigir padrões de envio de alta velocidade, mensagens não recolhíveis podem ser a escolha certa. Para essas mensagens, certifique-se de incluir o conteúdo delas para reduzir o custo da bateria.

Limitamos as mensagens recolhíveis a um máximo de 20 mensagens por aplicativo e por dispositivo, com recarga de 1 mensagem a cada 3 minutos.

Limitação do servidor XMPP

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

Limitamos a taxa de conexão aos servidores FCM XMPP a 400 conexões por minuto por projeto. Isto 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 sobrecarregar os servidores de destino upstream.

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

Taxa máxima de mensagens para um único dispositivo

Para Android, você pode enviar até 240 mensagens/minuto e 5.000 mensagens/hora para um único dispositivo. Esse limite alto destina-se a permitir picos de tráfego de curto prazo, como quando os usuários estão interagindo rapidamente por chat. Esse limite evita que erros no envio de lógica esgotem inadvertidamente a bateria de um dispositivo.

Para iOS, retornamos um erro quando a taxa excede os limites de APNs.

Cuidado: Não envie rotineiramente mensagens próximas dessa taxa máxima. Isso pode desperdiçar recursos dos usuários finais e seu aplicativo pode ser marcado como abusivo.

Limite de mensagens do tópico

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

Para taxas de envio de mensagens, consulte Fanout Throttling .

Limitação de fanout

Fanout de mensagens é o processo de envio de uma mensagem para vários dispositivos, como quando você segmenta tópicos e grupos ou quando usa o Editor do Notificações para segmentar públicos ou segmentos de usuários.

O fanout de mensagens não é instantâneo e, ocasionalmente, você tem vários fanouts em andamento simultaneamente. Limitamos o número de fanouts de mensagens simultâneos por projeto a 1.000. Depois disso, podemos rejeitar solicitações de fanout adicionais ou adiar o fanout das solicitações até que alguns dos fanouts já em andamento sejam concluídos.

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

Portas FCM e seu firewall

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

Para dispositivos conectados à sua rede, o FCM não fornece IPs específicos porque nosso intervalo de IP muda com muita frequência e suas regras de firewall podem ficar desatualizadas, impactando a experiência dos usuários. Idealmente, coloque na lista de permissões as portas 5228-5230 e 443 sem restrições de IP. No entanto, se você precisar de uma restrição de IP, deverá colocar na lista de permissões todos os endereços IP listados em goog.json . Esta grande lista é atualizada regularmente e é recomendável atualizar suas regras mensalmente. Os problemas causados ​​pelas restrições de IP do firewall costumam ser intermitentes e difíceis de diagnosticar.

Oferecemos um conjunto de nomes de domínio 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, atualizaremos a lista aqui. O uso de nomes de domínio para sua regra de firewall pode ou não funcionar em seu dispositivo de firewall.

Portas TCP a serem abertas:

• 5228
• 5229
• 5230
• 443

Nomes de host para abrir:

• 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
• provisionamento de dispositivos.googleapis.com
• firebaseinstallations.googleapis.com

Firewalls de tradução de endereços de rede e/ou inspeção de pacotes com estado:

Se sua rede implementar Network Address Translation (NAT) ou Stateful Packet Inspection (SPI), implemente um tempo limite de 30 minutos ou mais para nossas conexões nas portas 5228-5230. Isso nos permite fornecer conectividade confiável e, ao mesmo tempo, reduzir o consumo de bateria dos dispositivos móveis dos seus usuários.

Observação: se você estiver recebendo notificações por APNs, certifique-se de também ter aberto as portas especificadas pela Apple .

Interações VPN e capacidade de bypass

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

As VPNs mascaram as informações subjacentes que o FCM precisa para ajustar sua conexão para maximizar a confiabilidade e a vida útil da bateria. Em alguns casos, as VPNs interrompem ativamente conexões de longa duração, resultando em uma experiência ruim para o usuário devido a mensagens perdidas ou atrasadas ou ao alto custo da bateria. Quando a VPN está configurada para permitir isso, ignoramos a VPN usando uma conexão criptografada (através da rede básica Wi-Fi ou LTE) para garantir uma experiência confiável e com baixo consumo de bateria. O uso de VPNs contornáveis ​​pelo FCM é específico para o canal de notificação push do FCM. Outro tráfego FCM, como o tráfego de registro, utiliza a VPN se estiver ativa. Quando a conexão FCM ignora a VPN, ela perde benefícios adicionais que a VPN pode oferecer, como o mascaramento de IP.

Diferentes VPNs terão métodos diferentes para controlar se podem ou não ser contornadas. Consulte a documentação da sua VPN específica para obter instruções.

Se a VPN não estiver configurada para ser ignorável, o Firebase Cloud Messaging usará a rede VPN para se conectar ao servidor. Isso pode resultar em períodos de atraso nas mensagens e em maior uso da bateria, pois o Cloud Messaging trabalha para manter a conexão pela conexão VPN.

Credenciais

Dependendo dos recursos do FCM que você implementar, talvez sejam necessárias as seguintes credenciais do seu projeto do Firebase:

ID do projeto	Um identificador exclusivo para seu projeto do Firebase, usado em solicitações para o endpoint HTTP FCM v1. 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 aplicativo cliente. O token de registro é necessário para mensagens de dispositivos únicos e de grupos de dispositivos. Observe que os tokens de registro devem ser mantidos em segredo.
ID do remetente	Um valor numérico exclusivo criado quando você cria seu 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 para o aplicativo 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 **obsoletos**)	Uma chave de servidor que autoriza o servidor do seu aplicativo a acessar os serviços do Google, incluindo o envio de mensagens por meio dos protocolos legados obsoletos do Firebase Cloud Messaging. Importante: Não inclua a chave do servidor em nenhum lugar do código do cliente. Além disso, certifique-se de usar apenas chaves de servidor para autorizar o servidor de seu aplicativo. As chaves do Android, da plataforma Apple e do navegador são rejeitadas pela FCM.