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

Informazioni sui messaggi FCM

Firebase Cloud Messaging (FCM) offre un'ampia gamma di opzioni e funzionalità di messaggistica. Le informazioni in questa pagina hanno lo scopo di aiutarti a comprendere i diversi tipi di messaggi FCM e cosa puoi fare con loro.

Tipi di messaggi

Con FCM puoi inviare due tipi di messaggi ai clienti:

  • Messaggi di notifica, a volte pensati come "messaggi di visualizzazione". Questi vengono gestiti automaticamente dall'SDK di FCM.
  • Messaggi di dati, gestiti dall'app client.

I messaggi di notifica contengono un insieme predefinito di chiavi visibili all'utente. I messaggi di dati, al contrario, contengono solo le coppie chiave-valore personalizzate definite dall'utente. I messaggi di notifica possono contenere un payload di dati opzionale. Il payload massimo per entrambi i tipi di messaggio è di 4000 byte, tranne quando si inviano messaggi dalla console Firebase, che impone un limite di 1024 caratteri.

Usa scenario Come spedire
Messaggio di notifica FCM visualizza automaticamente il messaggio ai dispositivi dell'utente finale per conto dell'app client. I messaggi di notifica hanno un set predefinito di chiavi visibili all'utente e un payload di dati facoltativo di coppie chiave-valore personalizzate.
  1. In un ambiente di fiducia come ad esempio le funzioni cloud o il vostro application server, utilizzare l' SDK di amministrazione o dei Protocolli FCM Server : Impostare la notification chiave. Può avere un payload di dati opzionale. Sempre pieghevole.

    Vedere alcuni esempi di notifiche di visualizzazione e di richiesta di trasmissione carichi utili.

  2. Utilizzare il compositore Notifiche : Inserire il testo del messaggio, titolo, ecc, e inviare. Aggiungi un payload di dati opzionale fornendo dati personalizzati.
Messaggio dati L'app client è responsabile dell'elaborazione dei messaggi di dati. I messaggi di dati hanno solo coppie chiave-valore personalizzate senza nomi di chiavi riservati (vedi sotto). In un ambiente di fiducia come ad esempio le funzioni cloud o il vostro application server, utilizzare l' SDK di amministrazione o dei Protocolli FCM Server : Impostare il data unica chiave.

Utilizza i messaggi di notifica quando desideri che FCM gestisca la visualizzazione di una notifica per conto dell'app client. Utilizza i messaggi di dati quando desideri elaborare i messaggi sull'app client.

FCM può inviare un messaggio di notifica che include un payload di dati opzionale. In tali casi, FCM gestisce la visualizzazione del payload della notifica e l'app client gestisce il payload dei dati.

Messaggi di notifica

Per testare o per il marketing e user nuovo impegno, è possibile inviare messaggi di notifica mediante la console Firebase . La console Firebase fornisce analisi dei dati a base di A / B test per aiutare a rifinire e migliorare messaggi di marketing.

Per inviare messaggi di notifica a livello di codice utilizzando l'SDK di amministrazione o dei protocolli di FCM, impostare la notification chiave con la necessaria set predefinito di opzioni di valore-chiave per la parte visibile all'utente del messaggio di notifica. Ad esempio, ecco un messaggio di notifica in formato JSON in un'app di messaggistica istantanea. L'utente può aspettarsi di vedere un messaggio con il titolo "Portogallo vs Danimarca" e il testo "grande partita!" sul dispositivo:

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

I messaggi di notifica vengono recapitati nella barra delle notifiche quando l'app è in background. Per le app in primo piano, i messaggi vengono gestiti da una funzione di callback.

Consultare la documentazione di riferimento per l'elenco completo delle chiavi predefinite disponibili per la creazione di messaggi di notifica:

Messaggi di dati

Imposta la chiave appropriata con le tue coppie chiave-valore personalizzate per inviare un payload di dati all'app client.

Ad esempio, ecco un messaggio in formato JSON nella stessa app IM come sopra, in cui l'informazione è incapsulato nel comune data chiave e l'applicazione client è prevista per interpretare il contenuto:

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

Quanto sopra utilizzo esempio mostra il primo livello, o comune data campo, che viene interpretato dai clienti su tutte le piattaforme che ricevono il messaggio. Su ogni piattaforma, l'app client riceve il payload dei dati in una funzione di callback.

Crittografia per i messaggi di dati

Il livello di trasporto Android (vedi architettura FCM ) utilizza la crittografia point-to-point. A seconda delle tue esigenze, puoi decidere di aggiungere la crittografia end-to-end ai messaggi di dati. FCM non fornisce una soluzione end-to-end. Tuttavia, ci sono soluzioni esterne disponibili quali capillare o DTLS .

Messaggi di notifica con payload dati opzionale

Sia a livello di programmazione che tramite la console Firebase, puoi inviare messaggi di notifica che contengono un payload facoltativo di coppie chiave-valore personalizzate. Nel compositore di notifiche , utilizzare i campi di dati personalizzati in Opzioni avanzate.

Il comportamento dell'app durante la ricezione di messaggi che includono sia notifiche che payload di dati dipende dal fatto che l'app sia in background o in primo piano, in sostanza, se è attiva o meno al momento della ricezione.

  • Quando in background, le applicazioni ricevono il carico utile di notifica nella barra di notifica, e gestiscono solo il payload dati quando l'utente tocca sulla notifica.
  • Quando in primo piano, la vostra applicazione riceve un oggetto messaggio con entrambi carichi utili disponibili.

Qui è un messaggio in formato JSON contenente sia la notification chiave e il data chiave:

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

Personalizzazione di un messaggio su più piattaforme

Il Firebase Admin SDK e il protocollo HTTP FCM v1 sia permettono le richieste di messaggi per impostare tutti i campi disponibili nel message oggetto. Ciò comprende:

  • un insieme comune di campi per essere interpretato da tutte le istanze app che ricevono il messaggio.
  • set di piattaforma-specifici di campi, come AndroidConfig e WebpushConfig , interpretati solo da istanze app in esecuzione sulla piattaforma specificata.

I blocchi specifici della piattaforma offrono la flessibilità di personalizzare i messaggi per piattaforme diverse per garantire che vengano gestiti correttamente una volta ricevuti. Il backend FCM terrà conto di tutti i parametri specificati e personalizzerà il messaggio per ciascuna piattaforma.

Quando utilizzare i campi comuni

Usa i campi comuni quando:

  • Identificazione di istanze di app su tutte le piattaforme - Apple, Android, e web
  • Invio di messaggi agli argomenti

Tutte le istanze dell'app, indipendentemente dalla piattaforma, possono interpretare i seguenti campi comuni:

Quando utilizzare i campi specifici della piattaforma

Utilizza i campi specifici della piattaforma quando desideri:

  • Invia campi solo a piattaforme particolari
  • Invia campi piattaforma specifici in aggiunta ai campi comuni

Ogni volta che si desidera inviare i valori solo per piattaforme particolari, non utilizzare campi comuni; utilizzare campi specifici della piattaforma. Ad esempio, per inviare una notifica solo alle piattaforme Apple e al web ma non ad Android, è necessario utilizzare due set di campi separati, uno per Apple e uno per il web.

Quando si inviano messaggi con specifiche opzioni di consegna , i campi specifici delle piattaforme utilizzare per impostare loro. Se lo desideri, puoi specificare valori diversi per piattaforma. Tuttavia, anche quando si desidera impostare essenzialmente lo stesso valore tra piattaforme, è necessario utilizzare campi specifici della piattaforma. Questo perché ogni piattaforma può interpretare il valore in modo leggermente diverso, ad esempio, il time-to-live è impostato su Android come un tempo di scadenza in secondi, mentre su Apple è impostato come una data di scadenza.

Esempio: messaggio di notifica con opzioni di consegna specifiche della piattaforma

La seguente richiesta di invio v1 invia un titolo e un contenuto di notifica comuni a tutte le piattaforme, ma invia anche alcune sostituzioni specifiche della piattaforma. Nello specifico, la richiesta:

  • imposta un lungo tempo di vita per le piattaforme Android e Web, impostando la priorità dei messaggi APN (piattaforme Apple) su un valore basso
  • imposta i tasti appropriati per definire il risultato di un rubinetto utente sulla notifica su Android e Apple - click_action e category rispettivamente.
{
  "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"
       }
     }
   }
 }

Vedere la documentazione di riferimento v1 HTTP per dettaglio completo sui tasti disponibili in blocchi di piattaforma-specifici nel corpo del messaggio. Per ulteriori informazioni sulla creazione di richieste di trasmissione che contengono il corpo del messaggio, vedono Corporatura inviare richieste .

Opzioni di consegna

FCM fornisce una serie specifica di opzioni di consegna per i messaggi inviati a dispositivi Android e consente opzioni simili su piattaforme Apple e web. Ad esempio, "pieghevole" il comportamento messaggio è supportata su Android via di FCM collapse_key , su Apple tramite apns-collapse-id , e JavaScript / Web tramite Topic . Per i dettagli, vedere le descrizioni in questa sezione e la relativa documentazione di riferimento.

Messaggi non pieghevoli e pieghevoli

Un messaggio non comprimibile indica che ciascun messaggio viene consegnato al dispositivo. Un messaggio non comprimibile fornisce alcuni contenuti utili, al contrario di un messaggio comprimibile come un "ping" senza contenuto all'app mobile per contattare il server per recuperare i dati.

Alcuni casi d'uso tipici di messaggi non comprimibili sono messaggi di chat o messaggi critici. Ad esempio, in un'app di messaggistica istantanea, dovresti consegnare ogni messaggio, perché ogni messaggio ha un contenuto diverso.

Per Android esiste un limite di 100 messaggi che possono essere archiviati senza collassare. Se viene raggiunto il limite, tutti i messaggi archiviati vengono eliminati. Quando il dispositivo torna online, riceve un messaggio speciale che indica che il limite è stato raggiunto. L'app può quindi gestire correttamente la situazione, in genere richiedendo una sincronizzazione completa dal server dell'app.

Un messaggio pieghevole è un messaggio che può essere sostituito da un nuovo messaggio se deve ancora essere consegnati al dispositivo.

Un caso d'uso comune di messaggi comprimibili sono i messaggi utilizzati per indicare a un'app mobile di sincronizzare i dati dal server. Un esempio potrebbe essere un'app sportiva che aggiorna gli utenti con il punteggio più recente. Solo il messaggio più recente è rilevante.

Per contrassegnare un messaggio come comprimibile su Android, includere il collapse_key parametro nel payload messaggio. Per impostazione predefinita, la chiave di compressione è il nome del pacchetto dell'app registrato nella console Firebase. Il server FCM può memorizzare contemporaneamente quattro diversi messaggi comprimibili per dispositivo, ciascuno con una chiave di compressione diversa. Se si supera questo numero, FCM conserva solo quattro chiavi di compressione, senza garanzie su quali siano conservate.

I messaggi di argomento senza payload sono comprimibili per impostazione predefinita.

Quale dovrei usare?

I messaggi comprimibili sono una scelta migliore dal punto di vista delle prestazioni, a condizione che l'app non debba utilizzare messaggi non comprimibili. Tuttavia, se utilizzi messaggi comprimibili, ricorda che FCM consente a FCM di utilizzare solo un massimo di quattro chiavi di compressione diverse per token di registrazione in un dato momento. Non devi superare questo numero, o potrebbe causare conseguenze imprevedibili.

Usa scenario Come spedire
Non pieghevole Ogni messaggio è importante per l'app client e deve essere consegnato. Ad eccezione dei messaggi di notifica, tutti i messaggi non sono comprimibili per impostazione predefinita.
Collassabile Quando è presente un messaggio più recente che rende irrilevante per l'app client un messaggio correlato precedente, FCM sostituisce il messaggio precedente. Ad esempio: messaggi utilizzati per avviare una sincronizzazione dei dati dal server o messaggi di notifica obsoleti. Imposta il parametro appropriato nella tua richiesta di messaggio:
  • collapseKey su Android
  • apns-collapse-id su Apple
  • Topic sul Web
  • collapse_key nei protocolli legacy (tutte le piattaforme)

Impostare la priorità di un messaggio

Hai due opzioni per assegnare la priorità di consegna ai messaggi downstream su Android: normale e alta priorità. La consegna di messaggi con priorità normale e alta funziona in questo modo:

  • Priorità normale. Questa è la priorità predefinita per i messaggi di dati . I normali messaggi di priorità vengono recapitati immediatamente quando l'app è in primo piano. Quando il dispositivo è in modalità Doze, la consegna può essere ritardata per risparmiare la batteria. Per i messaggi meno urgenti, come le notifiche di nuovi messaggi di posta elettronica, il mantenimento della sincronizzazione dell'interfaccia utente o la sincronizzazione dei dati dell'app in background, scegli la priorità di consegna normale.

    Quando si riceve un messaggio di priorità normale su Android che richiede uno sfondo di sincronizzazione di dati per la vostra applicazione, è possibile pianificare un'attività con WorkManager di gestirlo quando la rete è disponibile.

  • Priorità alta. FCM tenta di fornire immediatamente messaggi ad alta priorità, consentendo a FCM di riattivare un dispositivo inattivo quando necessario e di eseguire alcune elaborazioni limitate (incluso l'accesso alla rete molto limitato). I messaggi ad alta priorità in genere dovrebbero comportare l'interazione dell'utente con la tua app o le sue notifiche. Se FCM rileva uno schema in cui non lo fa, i tuoi messaggi potrebbero essere privi di priorità. Android P introdotto app secchi standby che limitano il numero di messaggi ad alta priorità FCM è possibile inviare al vostro app che non comportano l'utente utilizzando la vostra applicazione o la visualizzazione di una notifica. Se, in risposta a un messaggio ad alta priorità, viene visualizzata una notifica in modo visibile all'utente, la quota del bucket in standby dell'app non verrà utilizzata da quel messaggio.

    Poiché una piccola parte della popolazione mobile Android si trova su reti ad alta latenza, evita di aprire una connessione ai tuoi server prima di visualizzare una notifica. Richiamare il server prima della fine del tempo di elaborazione consentito può essere rischioso per gli utenti su reti ad alta latenza. Invece, includi il contenuto della notifica nel messaggio FCM e visualizzalo immediatamente. Se avete bisogno di sincronizzazione per contenuti aggiuntivi in-app su Android, è possibile pianificare un'attività con WorkManager per gestire che in background.

Ecco un esempio di un normale messaggio di priorità inviato tramite il protocollo HTTP v1 di FCM per informare un abbonato di una rivista che è disponibile per il download nuovo contenuto:

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

Per ulteriori dettagli specifici della piattaforma sull'impostazione della priorità dei messaggi:

Impostare la durata di un messaggio

FCM di solito consegna i messaggi subito dopo che sono stati inviati. Tuttavia, questo potrebbe non essere sempre possibile. Ad esempio, se la piattaforma è Android, il dispositivo potrebbe essere spento, offline o altrimenti non disponibile. Oppure FCM potrebbe ritardare intenzionalmente i messaggi per evitare che un'app consumi risorse eccessive e influisca negativamente sulla durata della batteria.

Quando ciò accade, FCM archivia il messaggio e lo consegna non appena possibile. Anche se questo va bene nella maggior parte dei casi, ci sono alcune app per le quali un messaggio in ritardo potrebbe anche non essere consegnato. Ad esempio, se il messaggio è una chiamata in arrivo o una notifica di chat video, è significativo solo per un breve periodo di tempo prima che la chiamata venga terminata. Oppure se il messaggio è un invito a un evento, è inutile se ricevuto dopo che l'evento è terminato.

Su Android e Web/JavaScript, puoi specificare la durata massima di un messaggio. Il valore deve essere una durata compresa tra 0 e 2.419.200 secondi (28 giorni) e corrisponde al periodo di tempo massimo per il quale FCM archivia e tenta di recapitare il messaggio. Le richieste che non contengono questo campo per impostazione predefinita al periodo massimo di quattro settimane.

Ecco alcuni possibili usi di questa funzione:

  • Videochiamate chiamate in arrivo
  • Eventi di invito in scadenza
  • Eventi del calendario

Un altro vantaggio di specificare la durata di un messaggio è che FCM non limita mai i messaggi con un valore time-to-live di 0 secondi. In altre parole, FCM garantisce il massimo impegno per i messaggi che devono essere consegnati "ora o mai più". Tenete a mente che un time_to_live valore 0 indica messaggi che non possono essere consegnati immediatamente vengono scartati. Tuttavia, poiché tali messaggi non vengono mai archiviati, ciò fornisce la migliore latenza per l'invio di messaggi di notifica.

Ecco un esempio di una richiesta che include 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"
      }
    }
  }
}

Ricezione di messaggi da più mittenti

FCM consente a più parti di inviare messaggi alla stessa app client. Ad esempio, supponiamo che l'app client sia un aggregatore di articoli con più contributori e ognuno di essi dovrebbe essere in grado di inviare un messaggio quando pubblica un nuovo articolo. Questo messaggio potrebbe contenere un URL in modo che l'app client possa scaricare l'articolo. Invece di dover centralizzare tutte le attività di invio in un'unica posizione, FCM ti dà la possibilità di consentire a ciascuno di questi contributori di inviare i propri messaggi.

Per attivare questa funzione, assicurarsi di avere di ogni mittente ID del mittente . Quando si richiede la registrazione, l'app client recupera il token più volte, ogni volta con un ID mittente diverso nel campo audience, utilizzando il metodo di recupero token per la piattaforma specificata:

Assicurarsi di non aggiungere più ID mittente per una singola richiesta di token, come questo può avere risultati imprevedibili. Effettua ogni chiamata separatamente, una volta per ID mittente.

Infine, condividi il token di registrazione con i mittenti corrispondenti e saranno in grado di inviare messaggi all'app client utilizzando le proprie chiavi di autenticazione.

Si noti che esiste un limite di 100 mittenti multipli.

Durata di un messaggio

Quando un server app invia un messaggio a FCM e riceve un ID messaggio, non significa che il messaggio sia già stato recapitato al dispositivo. Piuttosto, significa che è stato accettato per la consegna. Ciò che accade al messaggio dopo che è stato accettato dipende da molti fattori.

Nella migliore delle ipotesi, se il dispositivo è connesso a FCM, lo schermo è acceso e non ci sono restrizioni di limitazione, il messaggio viene recapitato immediatamente.

Se il dispositivo è connesso ma in Doze, un messaggio a bassa priorità viene memorizzato da FCM fino a quando il dispositivo non esce da Doze. Ed è qui che il collapse_key bandiera ha un ruolo: se c'è già un messaggio con la stessa chiave di compressione (e Token di registrazione) memorizzati e in attesa per la consegna, il vecchio messaggio viene scartato e il nuovo messaggio prende il suo posto (che è, il vecchio messaggio viene compresso da quello nuovo). Tuttavia, se la chiave di compressione non è impostata, sia il nuovo che il vecchio messaggio vengono archiviati per la consegna futura.

Se il dispositivo non è connesso a FCM, il messaggio viene archiviato fino a quando non viene stabilita una connessione (sempre rispettando le regole della chiave di compressione). Quando viene stabilita una connessione, FCM consegna tutti i messaggi in sospeso al dispositivo. Se il dispositivo non viene mai più connesso (ad esempio, se è stato ripristinato alle impostazioni di fabbrica), il messaggio alla fine scade e viene eliminato dall'archivio FCM. Il timeout predefinito è di quattro settimane, a meno che il time_to_live è impostato bandiera.

Per avere maggiori informazioni sulla consegna di un messaggio:

    Per avere un quadro più chiaro la consegna dei messaggi su piattaforme Android o Apple, vedere la dashboard di reporting FCM , che registra il numero di messaggi inviati e aperto su dispositivi Apple e Android, insieme ai dati di "impressioni" (notifiche visti dagli utenti) per app Android.

Per i dispositivi Android con la messaggistica del canale diretto abilitata, se il dispositivo non si è connesso a FCM per più di un mese, FCM accetta comunque il messaggio ma lo scarta immediatamente. Se il dispositivo si connette entro quattro settimane l'ultimo messaggio di dati è stato inviato ad esso, il cliente riceve i onDeletedMessages) ( callback. L'app può quindi gestire correttamente la situazione, in genere richiedendo una sincronizzazione completa dal server dell'app.

Infine, quando FCM tenta di recapitare un messaggio al dispositivo e l'app è stata disinstallata, FCM elimina immediatamente il messaggio e invalida il token di registrazione. I tentativi futuri per inviare un messaggio a che i risultati dei dispositivi in un NotRegistered errore.

Limitazione e ridimensionamento

Il nostro obiettivo è consegnare sempre ogni messaggio inviato tramite FCM. Tuttavia, la consegna di ogni messaggio a volte si traduce in un'esperienza utente complessiva scadente. In altri casi, dobbiamo fornire dei limiti per garantire che FCM fornisca un servizio scalabile per tutti i mittenti.

Limitazione dei messaggi pieghevoli

Come descritto sopra, i messaggi comprimibili sono notifiche prive di contenuto progettate per comprimersi l'una sull'altra. Nel caso in cui uno sviluppatore ripeta lo stesso messaggio a un'app con troppa frequenza, ritardiamo (limitiamo) i messaggi per ridurre l'impatto sulla batteria dell'utente.

Ad esempio, se invii un numero elevato di nuove richieste di sincronizzazione e-mail a un singolo dispositivo, potremmo ritardare di alcuni minuti la successiva richiesta di sincronizzazione e-mail in modo che il dispositivo possa sincronizzarsi a una velocità media inferiore. Questa limitazione viene eseguita rigorosamente per limitare l'impatto della batteria sperimentato dall'utente.

Se il tuo caso d'uso richiede modelli di invio burst elevati, i messaggi non comprimibili potrebbero essere la scelta giusta. Per tali messaggi, assicurati di includere il contenuto in tali messaggi al fine di ridurre il costo della batteria.

Limitiamo i messaggi comprimibili a una raffica di 20 messaggi per app per dispositivo, con una ricarica di 1 messaggio ogni 3 minuti.

Limitazione del server XMPP

Limitiamo la velocità con cui puoi connetterti ai server FCM XMPP a 400 connessioni al minuto per progetto. Questo non dovrebbe essere un problema per la consegna dei messaggi, ma è importante per garantire la stabilità del nostro sistema.

Per ogni progetto FCM consente 2500 collegamenti in parallelo.

Velocità massima dei messaggi a un singolo dispositivo

Puoi inviare fino a 240 messaggi/minuto e 5.000 messaggi/ora a un singolo dispositivo. Questa soglia elevata ha lo scopo di consentire picchi di traffico a breve termine, ad esempio quando gli utenti interagiscono rapidamente tramite chat. Questo limite impedisce agli errori di invio della logica di scaricare inavvertitamente la batteria di un dispositivo.

Limite messaggi upstream

Limitiamo messaggi a monte a 1.500.000 / minuto per progetto per evitare di sovraccaricare i server di destinazione upstream.

Limitiamo i messaggi upstream per dispositivo a 1.000/minuto per evitare che la batteria si scarichi a causa del cattivo comportamento delle app.

Limite messaggi argomento

La velocità di aggiunta/rimozione dell'abbonamento all'argomento è limitata a 3.000 QPS per progetto.

Le tariffe dei messaggi di invio, vedere Fanout Throttling .

Limitazione fanout

Fanout messaggio è il processo di invio di un messaggio a più dispositivi, come ad esempio quando si target argomenti e gruppi, o quando si utilizza il compositore notifiche a destinatari o segmenti di utenti.

Il fanout dei messaggi non è istantaneo e quindi occasionalmente hai più fanout in corso contemporaneamente. Limitiamo il numero di fanout di messaggi simultanei per progetto a 1.000. Successivamente, potremmo rifiutare ulteriori richieste di fanout o posticipare il fanout delle richieste fino al completamento di alcuni dei fanout già in corso.

Il tasso di fanout effettivamente raggiungibile è influenzato dal numero di progetti che richiedono il fanout contemporaneamente. Un tasso di fanout di 10.000 QPS per un singolo progetto non è raro, ma quel numero non è una garanzia ed è il risultato del carico totale sul sistema. È importante notare che la capacità di fanout disponibile è suddivisa tra i progetti e non tra le richieste di fanout. Quindi, se il tuo progetto ha due fanout in corso, ogni fanout vedrà solo la metà del tasso di fanout disponibile. Il modo consigliato per massimizzare la velocità di fanout è di avere un solo fanout attivo in corso alla volta.

Porte FCM e firewall

Se la tua organizzazione dispone di un firewall per limitare il traffico da o verso Internet, devi configurarlo per consentire ai dispositivi mobili di connettersi con FCM in modo che i dispositivi sulla rete possano ricevere messaggi. FCM utilizza in genere la porta 5228, ma a volte utilizza 443, 5229 e 5230.

Per i dispositivi che si connettono alla tua rete, FCM non fornisce IP specifici perché il nostro intervallo IP cambia troppo frequentemente e le regole del tuo firewall potrebbero diventare obsolete, con ripercussioni sull'esperienza degli utenti. Idealmente, autorizzare le porte 5228-5230 e 443 senza restrizioni IP. Tuttavia, se è necessario disporre di una restrizione IP, si dovrebbe allowlist tutti gli indirizzi IP elencati in goog.json . Questo ampio elenco viene aggiornato regolarmente e si consiglia di aggiornare le regole su base mensile. I problemi causati dalle restrizioni IP del firewall sono spesso intermittenti e difficili da diagnosticare.

Offriamo una serie di nomi di dominio che possono essere autorizzati al posto degli indirizzi IP. Questi nomi host sono elencati di seguito. Se iniziamo a utilizzare nomi host aggiuntivi, aggiorneremo l'elenco qui. L'utilizzo di nomi di dominio per la regola del firewall potrebbe non funzionare o meno nel dispositivo firewall.

Porte da aprire:

  • 5228
  • 5229
  • 5230
  • 443

Nomi host da aprire:

  • mtalk.google.com
  • mtalk4.google.com
  • mtalk-staging.google.com
  • mtalk-dev.google.com
  • alt1-mtalk.google.com
  • alt2-mtalk.google.com
  • alt3-mtalk.google.com
  • alt4-mtalk.google.com
  • alt5-mtalk.google.com
  • alt6-mtalk.google.com
  • alt7-mtalk.google.com
  • alt8-mtalk.google.com
  • android.clients.google.com
  • device-provisioning.googleapis.com

Firewall Network Address Translation e/o Stateful Packet Inspection:

Se la tua rete implementa Network Address Translation (NAT) o Stateful Packet Inspection (SPI), implementa un timeout di 30 minuti o più per le nostre connessioni sulle porte 5228-5230. Questo ci consente di fornire una connettività affidabile riducendo il consumo della batteria dei dispositivi mobili dei tuoi utenti.

Credenziali

A seconda delle funzionalità FCM che implementi, potresti aver bisogno delle seguenti credenziali dal tuo progetto Firebase:

ID progetto Un identificatore univoco per il tuo progetto Firebase, utilizzato nelle richieste all'endpoint HTTP FCM v1. Questo valore è disponibile nel Firebase console Impostazioni riquadro.
Token di registrazione

Una stringa di token univoca che identifica ogni istanza dell'app client. Il token di registrazione è necessario per la messaggistica di un singolo dispositivo e di un gruppo di dispositivi. Tieni presente che i token di registrazione devono essere mantenuti segreti.

identità del mittente Un valore numerico univoco creato quando si crea il progetto di Firebase, disponibili nella cloud di messaggistica scheda del riquadro Firebase console Impostazioni. L'ID mittente viene utilizzato per identificare ogni mittente che può inviare messaggi all'app client.
Token di accesso Un token OAuth 2.0 di breve durata che autorizza le richieste all'API HTTP v1. Questo token è associato a un account di servizio che appartiene al tuo progetto Firebase. Per creare e accedere rotazione gettoni, seguire la procedura descritta nel Autorizzazione inviare richieste .
Chiave del server (per protocolli legacy)

Una chiave del server che autorizza il server dell'app per l'accesso ai servizi Google, incluso l'invio di messaggi tramite i protocolli legacy Firebase Cloud Messaging. Ottieni la chiave del server quando crei il tuo progetto Firebase. È possibile visualizzarlo nella cloud di messaggistica scheda del riquadro Firebase console Impostazioni.

Importante: Non includere la chiave del server ovunque nel codice del client. Inoltre, assicurati di utilizzare solo le chiavi del server per autorizzare il server dell'app. Le chiavi Android, della piattaforma Apple e del browser vengono rifiutate da FCM.