Firebase Cloud Messaging (FCM) offre una vasta gamma di opzioni e funzionalità di messaggistica. Le informazioni contenute in questa pagina hanno lo scopo di aiutarti a comprendere i diversi tipi di messaggi FCM e le relative operazioni.
Tipi di messaggi
Con FCM puoi inviare ai clienti due tipi di messaggi:
- Messaggi di notifica, a volte considerati "messaggi di visualizzazione". Questi vengono gestiti automaticamente dall'SDK FCM.
- Messaggi di dati, che vengono 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 facoltativo. Il payload massimo per entrambi i tipi di messaggi è di 4096 byte, tranne per l'invio di messaggi dalla console Firebase, che applica un limite di 1000 caratteri.
| Scenario d'uso | Come inviare | |
|---|---|---|
| Messaggio di notifica | L'SDK FCM mostra il messaggio sui dispositivi degli utenti finali per conto dell'app client quando è in esecuzione in background. Altrimenti, se l'app è in esecuzione in primo piano quando riceve la notifica, il comportamento è determinato dal codice dell'app. I messaggi di notifica hanno un insieme predefinito di chiavi visibili all'utente e un payload di dati facoltativo di coppie chiave/valore personalizzate. |
|
| Messaggio di dati | L'app client è responsabile dell'elaborazione dei messaggi di dati. I messaggi di dati hanno solo coppie chiave-valore personalizzate senza nomi di chiave riservati (vedi di seguito). | In un ambiente attendibile come
Cloud Functions
o il tuo server di app, utilizza
l'SDK Admin o i
protocolli server FCM. Nella richiesta di invio, imposta la chiave data.
|
Utilizza i messaggi di notifica quando vuoi che l'SDK FCM gestisca la visualizzazione automatica di una notifica quando la tua app è in esecuzione in background. Utilizza i messaggi di dati quando vuoi elaborare i messaggi con il tuo codice dell'app client.
FCM può inviare un messaggio di notifica che include un payload facoltativo di dati. In questi casi, FCM gestisce la visualizzazione del payload delle notifiche, mentre l'app client gestisce il payload dei dati.
Messaggi di notifica
Per i test o per il marketing e il ricoinvolgimento degli utenti, puoi inviare messaggi di notifica utilizzando la console Firebase. La console Firebase fornisce test A/B basati su dati e analisi per aiutarti a perfezionare e migliorare i messaggi di marketing.
Per inviare messaggi di notifica in modo programmatico utilizzando l'SDK Admin o i protocolli FCM, imposta la chiave notification con l'insieme predefinito necessario di opzioni chiave-valore per la parte visibile all'utente del messaggio di notifica. Ad esempio, di seguito è riportato un messaggio di notifica in formato JSON in un'app di messaggistica istantanea. L'utente si aspetta di vedere sul dispositivo un messaggio con il titolo "Portogallo vs Danimarca" e il testo "Grande partita!":
{
"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 sono gestiti da una funzione di callback.
Consulta la documentazione di riferimento dell'oggetto di notifica del protocollo HTTP v1 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 di messaggistica immediata precedente, in cui le informazioni sono incapsulate nella chiave data comune e l'app client dovrebbe interpretare i contenuti:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
}
L'esempio riportato sopra mostra l'utilizzo del campo di primo livello o comune data, interpretato dai client 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 dei messaggi di dati
Il livello di trasporto di Android (vedi Architettura FCM) utilizza la crittografia punto a punto. 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, sono disponibili soluzioni esterne come Capillary o DTLS.
Messaggi di notifica con payload facoltativo di dati
Sia tramite programmazione che tramite la console Firebase, puoi inviare messaggi di notifica contenenti un payload facoltativo di coppie chiave/valore personalizzate. Nel Editor di notifiche, utilizza i campi Dati personalizzati in Opzioni avanzate.
Il comportamento dell'app quando riceve messaggi che includono payload di notifica e dati dipende dal fatto che l'app si trovi in background o in primo piano, ovvero dal fatto che sia attiva o meno al momento della ricezione.
- Quando sono in background, le app ricevono il payload di notifica nella barra delle notifiche e gestiscono il payload dei dati solo quando l'utente tocca la notifica.
- Quando è in primo piano, l'app riceve un oggetto messaggio con entrambi i payload disponibili.
Ecco un messaggio in formato JSON contenente sia la chiave notification sia la chiave data:
{
"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
Sia il protocollo HTTP Firebase Admin SDK sia il protocollo HTTP FCM 1.0 consentono alle richieste di messaggio di impostare tutti i campi disponibili nell'oggetto
message. Sono inclusi:
- un insieme comune di campi da interpretare da tutte le istanze dell'app che ricevono il messaggio.
- insiemi di campi specifici della piattaforma, come
AndroidConfigeWebpushConfig, interpretati solo dalle istanze dell'app in esecuzione sulla piattaforma specificata.
I blocchi specifici della piattaforma ti offrono la flessibilità di personalizzare i messaggi per piattaforme diverse per assicurarti che vengano gestiti correttamente al momento della ricezione. Il backend FCM prenderà in considerazione tutti i parametri specificati e personalizzerà il messaggio per ogni piattaforma.
Quando utilizzare i campi comuni
Utilizza i campi comuni quando:
- Targeting di istanze di app su tutte le piattaforme: Apple, Android e web
- Invio di messaggi per 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 vuoi:
- Invia campi solo a piattaforme particolari
- Invia campi specifici della piattaforma oltre a quelli comuni
Ogni volta che vuoi inviare valori solo a piattaforme particolari, non utilizzare campi comuni, ma specifici della piattaforma. Ad esempio, per inviare una notifica solo alle piattaforme Apple e al web, ma non ad Android, devi utilizzare due insiemi di campi distinti, uno per Apple e uno per il web.
Quando invii messaggi con opzioni di recapito specifiche, utilizza i campi specifici della piattaforma per impostarle. Se vuoi, puoi specificare valori diversi per piattaforma. Tuttavia, anche se vuoi impostare sostanzialmente lo stesso valore per più piattaforme, devi utilizzare campi specifici per piattaforma. Questo perché ogni piattaforma potrebbe interpretare il valore in modo leggermente diverso. Ad esempio, il TTL è impostato su Android come data e ora di scadenza in secondi, mentre su Apple è impostato come data di scadenza.
Esempio: messaggio di notifica con opzioni di recapito specifiche della piattaforma
La seguente richiesta di invio v1 invia un titolo e contenuti comuni della notifica a tutte le piattaforme, ma invia anche alcune sostituzioni specifiche per piattaforma. Nello specifico, la richiesta:
- consente di impostare una durata lunga per le piattaforme Android e web e di impostare la priorità dei messaggi degli APN (piattaforme Apple) su un valore basso
- imposta i tasti appropriati per definire il risultato del tocco dell'utente sulla notifica su Android e Apple, rispettivamente
click_actionecategory.
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Match update",
"body":"Arsenal goal in added time, score is now 3-0"
},
"android":{
"ttl":"86400s",
"notification"{
"click_action":"OPEN_ACTIVITY_1"
}
},
"apns": {
"headers": {
"apns-priority": "5",
},
"payload": {
"aps": {
"category": "NEW_MESSAGE_CATEGORY"
}
}
},
"webpush":{
"headers":{
"TTL":"86400"
}
}
}
}
Consulta la documentazione di riferimento per HTTP v1 per tutti i dettagli sulle chiavi disponibili nei blocchi specifici della piattaforma nel corpo del messaggio. Per ulteriori informazioni sulla creazione di richieste di invio che contengono il corpo del messaggio, consulta la sezione Creare richieste di invio.
Opzioni di consegna
FCM fornisce un insieme specifico di opzioni di recapito per i messaggi inviati ai dispositivi Android e consente opzioni simili sulle piattaforme Apple e sul web. Ad esempio, il comportamento dei messaggi "comprimibili" è supportato su
Android tramite collapse_key di FCM, su Apple tramite
apns-collapse-id e su JavaScript/web tramite Topic. Per maggiori dettagli, consulta le descrizioni in questa sezione e la documentazione di riferimento correlata.
Messaggi non comprimibili e comprimibili
Un messaggio non comprimibile indica che ogni singolo messaggio viene recapitato al dispositivo. Un messaggio non comprimibile fornisce alcuni contenuti utili, a differenza di un messaggio comprimibile come un "ping" senza contenuti all'app mobile per contattare il server e recuperare i dati.
Alcuni casi d'uso tipici dei messaggi non comprimibili sono i messaggi di chat o i messaggi critici. Ad esempio, in un'app di messaggistica istantanea, vorrai inviare ogni messaggio, perché ogni messaggio ha contenuti diversi.
Per Android esiste un limite di 100 messaggi che possono essere archiviati senza essere chiusi. Se viene raggiunto il limite, tutti i messaggi archiviati vengono eliminati. Quando il dispositivo è di nuovo online, riceve un messaggio speciale che indica che è stato raggiunto il limite. L'app è quindi in grado di gestire la situazione correttamente, in genere richiedendo una sincronizzazione completa al server delle app.
Un messaggio comprimibile è un messaggio che può essere sostituito da un nuovo messaggio se non è ancora stato recapitato sul dispositivo.
Un caso d'uso comune dei messaggi comprimibili è quello di indicare a un'app mobile di sincronizzare i dati dal server. Un esempio potrebbe essere un'app di sport che aggiorna gli utenti con il punteggio più recente. Solo il messaggio più recente è pertinente.
Per contrassegnare un messaggio come comprimibile su Android, includi il parametro collapse_key nel payload del 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 superi questo numero, FCM conserva solo quattro chiavi di compressione, senza alcuna garanzia di quali vengono conservate.
I messaggi argomento senza payload sono comprimibili per impostazione predefinita. I messaggi di notifica
sono sempre comprimibili e ignorano il parametro collapse_key.
Quale dovrei usare?
I messaggi comprimibili sono una scelta migliore dal punto di vista del rendimento, a condizione che la tua app non debba utilizzare messaggi non comprimibili. Tuttavia, se utilizzi messaggi comprimibili, ricorda che FCM consente l'utilizzo di un massimo di quattro chiavi di compressione diverse da FCM per token di registrazione in un dato momento. Non devi superare questo numero, altrimenti potresti provocare conseguenze imprevedibili.
| Scenario di utilizzo | Come inviare | |
|---|---|---|
| Non comprimibile | Ogni messaggio è importante per l'app client e deve essere inviato. | Ad eccezione dei messaggi di notifica, tutti i messaggi non sono comprimibili per impostazione predefinita. |
| Comprimibile | Quando esiste un messaggio più recente che rende un messaggio correlato meno recente irrilevante per l'app client, FCM sostituisce il messaggio meno recente. Ad esempio: messaggi utilizzati per avviare una sincronizzazione dei dati dal server o messaggi di notifica obsoleti. | Imposta il parametro appropriato nella richiesta di messaggi:
|
Impostare la priorità di un messaggio
Hai due opzioni per assegnare la priorità di recapito ai messaggi a valle: prioritaria e normale. Sebbene il comportamento differisca leggermente tra le piattaforme, l'invio di messaggi con priorità normale e alta funziona come segue:
Priorità normale. I messaggi con priorità normale vengono recapitati immediatamente quando l'app è in primo piano. Per le app in background, l'invio potrebbe subire ritardi. Per i messaggi meno urgenti, come le notifiche di nuove email, il mantenimento della sincronizzazione dell'interfaccia utente o la sincronizzazione dei dati dell'app in background, scegli la priorità di invio normale.
Priorità elevata. FCM tenta di consegnare immediatamente i messaggi ad alta priorità anche se il dispositivo è in modalità di sospensione. I messaggi con priorità elevata riguardano contenuti visibili agli utenti e sensibili al fattore tempo.
Ecco un esempio di messaggio con priorità normale inviato tramite il protocollo FCM HTTP v1 per informare un abbonato a una rivista che è possibile scaricare nuovi contenuti:
{
"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:
- Documentazione relativa agli APN
- Impostare e gestire la priorità dei messaggi (Android)
- Urgenza dei messaggi push web
Casi d'uso critici
Le API FCM non sono progettate per avvisi di emergenza o altre attività ad alto rischio in cui l'utilizzo o il malfunzionamento delle API potrebbe causare morte, lesioni personali o danni ambientali (ad esempio il funzionamento di impianti nucleari, il controllo del traffico aereo o i sistemi salvavita). Qualsiasi utilizzo di questo tipo è espressamente vietato ai sensi della Sezione 4. a. 7 dei Termini di servizio. Sei l'unico responsabile della gestione della conformità della tua app ai Termini, nonché di eventuali danni derivanti dalla non conformità. Google fornisce le API "così come sono" e si riserva il diritto di interrompere le API o qualsiasi parte o funzionalità o il tuo accesso alle API, per qualsiasi motivo e in qualsiasi momento, senza responsabilità o altre obbligazioni nei tuoi confronti o nei confronti dei tuoi utenti.
Impostazione della durata di un messaggio
FCM in genere consegna i messaggi immediatamente dopo che sono stati inviati. Tuttavia, questa operazione potrebbe non essere sempre possibile. Ad esempio, se la piattaforma è Android, il dispositivo potrebbe essere spento, offline o non disponibile per altri motivi. In alternativa, FCM potrebbe ritardare intenzionalmente i messaggi per impedire a un'app di consumare risorse eccessive e influire negativamente sulla durata della batteria.
In questo caso, FCM archivia il messaggio e lo consegna non appena possibile. Anche se nella maggior parte dei casi non è un problema, per alcune app un messaggio in ritardo potrebbe non essere mai recapitato. Ad esempio, se il messaggio è una chiamata in arrivo o una notifica di videochiamata, avrà senso solo per un breve periodo di tempo prima che la chiamata venga terminata. In alternativa, se il messaggio è un invito a un evento, è inutile se ricevuto dopo la fine dell'evento.
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 cui FCM memorizza e tenta di inviare il messaggio. Le richieste che non contengono questo campo vengono impostate sul periodo massimo di quattro settimane per impostazione predefinita.
Ecco alcuni possibili usi di questa funzionalità:
- Chiamate in arrivo di chat video
- Eventi di invito in scadenza
- Eventi nel calendario
Un altro vantaggio di specificare la durata di un messaggio è che FCM non applica la limitazione dei messaggi comprimibile ai messaggi con un valore di durata pari a 0 secondi.
FCM offre la migliore gestione possibile dei messaggi che devono essere recapitati "ora o mai". Tieni presente che un valore time_to_live pari a 0 indica che i messaggi che non possono essere recapitati immediatamente vengono eliminati. Tuttavia, poiché questi messaggi non vengono mai archiviati, viene offerta la latenza migliore per l'invio di messaggi di notifica.
Ecco un esempio di 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"
}
}
}
}
Durata di un messaggio
Quando un server di app pubblica un messaggio su FCM e riceve un ID messaggio, non significa che il messaggio sia già stato recapitato al dispositivo. Significa invece che è stata accettata per la consegna. Ciò che accade al messaggio dopo essere stato accettato dipende da molti fattori.
Nella migliore delle ipotesi, se il dispositivo è connesso a FCM, lo schermo è acceso e non ci sono limitazioni di throttling, il messaggio viene recapitato immediatamente.
Se il dispositivo è connesso, ma in modalità Sospensione, un messaggio con priorità bassa viene memorizzato da FCM finché il dispositivo non esce dalla modalità Sospensione. Ed è qui che entra in gioco il flag collapse_key: se è già memorizzato un messaggio con la stessa chiave di chiusura (e lo stesso token di registrazione) in attesa di invio, il vecchio messaggio viene ignorato e il nuovo messaggio ne prende il posto (ovvero il vecchio messaggio viene chiuso dal 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 memorizzato fino a quando non viene stabilita una connessione (rispettando sempre le regole delle chiavi di collasso). Quando viene stabilita una connessione, FCM invia tutti i messaggi in attesa al dispositivo. Se il dispositivo non si connette più (ad esempio se è stato ripristinato i dati di fabbrica), il messaggio scade e viene eliminato dallo spazio di archiviazione FCM. Il timeout predefinito è di quattro settimane,
a meno che non sia impostato il flag time_to_live.
Per saperne di più sulla consegna di un messaggio:
Per saperne di più sull'invio dei messaggi sulle piattaforme Android o Apple, consulta la FCMdashboard dei report, che registra il numero di messaggi inviati e aperti su dispositivi Apple e Android, nonché i dati relativi alle "impressioni" (notifiche visualizzate dagli utenti) per le app per Android.
Per i dispositivi Android in cui è attiva la messaggistica diretta del canale, se il dispositivo non si connette a FCM per più di un mese, FCM accetta comunque il messaggio, ma lo elimina immediatamente. Se il dispositivo si connette entro quattro settimane dall'ultimo messaggio con i dati che gli hai inviato, il client riceve il callback ondeletedMessages(). L'app può quindi gestire la situazione correttamente, in genere richiedendo una sincronizzazione completa dal server dell'app.
Infine, quando FCM tenta di consegnare un messaggio al dispositivo e
l'app è stata disinstallata, FCM elimina subito il messaggio e
invalida il token di registrazione. I tentativi futuri di inviare un messaggio a quel
dispositivo generano un errore NotRegistered.
Rallentamento e quote
Il nostro obiettivo è consegnare sempre ogni messaggio inviato tramite FCM. Tuttavia, la consegna di ogni messaggio a volte comporta un'esperienza utente complessiva scadente. In altri casi, dobbiamo fornire dei limiti per garantire che FCM fornisca un servizio scalabile per tutti i mittenti. I tipi di limiti e quote descritti in questa sezione ci aiutano a bilanciare questi fattori importanti.
Limitazione dei messaggi downstream
L'API HTTP v1 ha introdotto quote per progetto e per minuto per la messaggistica a valle. La quota predefinita di 600.000 messaggi al minuto copre oltre il 99% degli sviluppatori di FCM, proteggendo al contempo la stabilità del sistema e riducendo al minimo l'impatto dei progetti con picchi.
Modelli di traffico piccante possono comportare errori di superamento della quota. In uno scenario di superamento della quota, il sistema restituisce il codice di stato HTTP 429 (QUOTA_EXCEEDED) finché la quota non viene reintegrata nel minuto successivo. Le risposte 429 possono essere restituite anche in situazioni di sovraccarico, quindi ti consigliamo vivamente di gestire errori 429 in base ai consigli pubblicati.
Ricorda:
- La quota downstream misura i messaggi, non le richieste.
- Vengono conteggiati gli errori del client (codice di stato HTTP 400-499) (esclusi gli errori 429).
- Le quote sono al minuto, ma i minuti in questione non sono allineati all'orologio.
Quota di monitoraggio
Puoi visualizzare quota, utilizzo ed errori in Google Cloud Console:
- Vai alla console Google Cloud
- Seleziona API e servizi.
- Dall'elenco della tabella, seleziona API Firebase Cloud Messaging.
- Seleziona QUOTA E LIMITI DI SISTEMA.
NOTA: questi grafici non sono esattamente allineati ai minuti di quota, il che significa che i codici 429 potrebbero essere pubblicati quando il traffico sembra essere inferiore alla quota.
Richiesta di aumento della quota
Prima di richiedere un aumento della quota, assicurati che:
- L'utilizzo è regolarmente ≥ 80% della quota per almeno 5 minuti consecutivi al giorno.
- Hai una percentuale di errori del client < 5%, soprattutto durante i picchi di traffico.
- Rispetta le best practice per l'invio di messaggi su larga scala.
Se soddisfi questi criteri, puoi inviare una richiesta di aumento della quota fino al +25% e FCM farà ogni sforzo pratico per soddisfare la richiesta (non è possibile garantire alcun aumento).
Se hai bisogno di una quota di messaggistica a valle maggiore a causa di un lancio imminente o di un evento temporaneo, richiedi la quota con almeno 15 giorni di anticipo per consentire tempo sufficiente per gestire la richiesta. Per le richieste di grandi dimensioni (più di 18 milioni di messaggi al minuto), sono necessari almeno 30 giorni di preavviso. I lanci e le richieste di eventi speciali sono comunque soggetti al rapporto di errori del client e ai requisiti delle best practice.
Consulta anche le domande frequenti sulle quote di FCM.
Limite messaggi argomento
La velocità di aggiunta/rimozione delle sottoscrizioni di argomenti è limitata a 3000 QPS per progetto.
Per le velocità di invio dei messaggi, vedi Limitazione del fan-out.
Limitazione del fanout
Il fanout dei messaggi è il processo di invio di un messaggio a più dispositivi, ad esempio quando scegli come target argomenti e gruppi o quando utilizzi il compositore notifiche per scegliere come target segmenti di pubblico o segmenti di utenti.
Il fanout dei messaggi non è istantaneo, di conseguenza a volte potresti avere più fanout in corso contemporaneamente. Limitiamo il numero di fanout simultanei di messaggi per progetto a 1000. Dopodiché, potremmo rifiutare altre richieste di fanout o rimandare il fanout fino al completamento di alcuni dei fanout già in corso.
La percentuale di fanout effettivamente raggiungibile è influenzata dal numero di progetti che richiedono fanout contemporaneamente. Non è raro trovare una percentuale di fanout di 10.000 QPS per un singolo progetto, ma questo 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, per ogni fanout verrà visualizzata solo la metà del tasso di fanout disponibile. Il modo consigliato per massimizzare la velocità di fanout è di avere in corso un solo fanout attivo alla volta.
Limitazione dei messaggi comprimibile
Come descritto sopra, i messaggi comprimibili sono notifiche senza contenuti progettate per essere compresse una sopra l'altra. Se uno sviluppatore ripete lo stesso messaggio a un'app troppo spesso, ritardiamo (limitiamo) i messaggi per ridurre l'impatto sulla batteria di un utente.
Ad esempio, se invii un numero elevato di nuove richieste di sincronizzazione email a un singolo dispositivo, potremmo ritardare la richiesta di sincronizzazione email successiva di alcuni minuti in modo che il dispositivo possa sincronizzarsi a una frequenza media inferiore. Questa limitazione viene eseguita rigorosamente per limitare l'impatto sulla batteria subita dall'utente.
Se il tuo caso d'uso richiede pattern di invio con picchi elevati, i messaggi non comprimibili potrebbero essere la scelta giusta. Assicurati di includere i contenuti di questi messaggi al fine di ridurre i costi della batteria.
Limitiamo i messaggi comprimibili a una serie di 20 messaggi per app e per dispositivo, con una ricarica di 1 messaggio ogni 3 minuti.
Limitazione del server XMPP
Limitiamo la frequenza di connessione 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 sistema. Per ogni progetto, FCM consente 2500 connessioni in parallelo.
Per la messaggistica upstream con XMPP, FCM limita i messaggi upstream a 1.500.000 al minuto per progetto per evitare di sovraccaricare i server di destinazione upstream.
Limitiamo i messaggi upstream per dispositivo a 1000 al minuto per evitare il consumo eccessivo della batteria da prestazioni scadenti dell'app.
Frequenza massima dei messaggi per un singolo dispositivo
Per Android, puoi inviare fino a 240 messaggi al minuto e 5000 messaggi all'ora a un singolo dispositivo. Questa soglia elevata è pensata per consentire burst di traffico a breve termine, ad esempio quando gli utenti interagiscono rapidamente tramite chat. Questo limite impedisce che gli errori di invio della logica si scarichino inavvertitamente la batteria di un dispositivo.
Per iOS, viene restituito un errore quando la frequenza supera i limiti degli APN.
FCM porte e il firewall
Se la tua organizzazione dispone di un firewall per limitare il traffico verso o da internet, devi configurarlo in modo da consentire ai dispositivi mobili di connettersi a FCM affinché i dispositivi della tua rete possano ricevere messaggi. FCM in genere utilizza 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 spesso e le regole firewall potrebbero diventare obsolete, influenzando l'esperienza degli utenti. Idealmente, inserisci nella lista consentita le porte 5228-5230 e 443 senza limitazioni IP. Tuttavia, se devi avere una limitazione relativa agli IP, devi inserire nella lista consentita tutti gli indirizzi IP elencati in goog.json. Questo ampio elenco viene aggiornato regolarmente e ti consigliamo di aggiornare le regole su base mensile. I problemi causati dalle limitazioni IP del firewall sono spesso intermittenti e difficili da diagnosticare.
Offriamo un insieme di nomi di dominio che possono essere inseriti nella lista consentita anziché indirizzi IP. Questi nomi host sono elencati di seguito. Se iniziamo a utilizzare altri nomi host, aggiorneremo l'elenco qui. L'utilizzo di nomi di dominio per la regola del firewall può o meno essere funzionale nel dispositivo firewall.
Porte TCP 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.apis.google.com
- device-provisioning.googleapis.com
- firebaseinstallations.googleapis.com
Firewall con Network Address Translation e/o ispezione approfondita dei pacchetti:
Se la tua rete implementa Network Address Translation (NAT) o Stateful Packet Inspector (SPI), implementa un timeout di almeno 30 minuti per le nostre connessioni sulle porte 5228-5230. In questo modo possiamo offrire una connettività affidabile riducendo al contempo il consumo della batteria dei dispositivi mobili dei tuoi utenti.
Interazioni e bypassabilità VPN
Firebase Cloud Messaging adotta varie misure per garantire che la connessione dei messaggi push dal telefono al server sia affidabile e disponibile il più spesso possibile. L'uso di una VPN complica questo sforzo.
Le VPN mascherano le informazioni sottostanti di cui FCM ha bisogno per ottimizzare la connessione al fine di massimizzare l'affidabilità e la durata della batteria. In alcuni casi le VPN rompono attivamente le connessioni di lunga durata, con un conseguente peggioramento dell'esperienza utente a causa di messaggi persi o in ritardo o di un elevato consumo della batteria. Se la VPN è configurata in modo da consentire questa operazione, la aggiriamo utilizzando una connessione criptata (tramite Wi-Fi o LTE di rete di base), in modo da garantire un'esperienza affidabile e che dura la batteria. L'utilizzo di VPN aggirabili da parte di FCM è specifico per il canale di notifica push di FCM. Il traffico FCM, ad esempio il traffico di registrazione, utilizza la VPN se è attiva. Quando la connessione FCM aggira la VPN, perde i vantaggi aggiuntivi che la VPN potrebbe offrire, come il mascheramento IP.
VPN diverse avranno metodi diversi per controllare se possono essere aggirate o meno. Per istruzioni, consulta la documentazione della VPN specifica.
Se la VPN non è configurata per essere aggirata, Firebase Cloud Messaging userà la rete VPN per connettersi al server. Ciò potrebbe causare periodi di tempo in cui i messaggi subiscono ritardi e un maggiore utilizzo della batteria, in quanto Cloud Messaging lavora per mantenere la connessione tramite la connessione VPN.
Credenziali
A seconda delle funzionalità di FCM implementate, potrebbero essere necessarie le seguenti credenziali del progetto Firebase:
| ID progetto | Un identificatore univoco per il progetto Firebase, utilizzato nelle richieste all'endpoint HTTP FCM v1. Questo valore è disponibile nel riquadro Impostazioni della console Firebase. |
| Token di registrazione | Una stringa di token univoca che identifica ogni istanza dell'app del client. Il token di registrazione è obbligatorio per la messaggistica su dispositivi singoli e gruppi di dispositivi. Tieni presente che i token di registrazione devono essere mantenuti segreti. |
| ID mittente | Un valore numerico univoco creato quando crei il progetto Firebase, disponibile nella scheda Cloud Messaging della console Firebase 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 ruotare i token di accesso, segui i passaggi descritti in Autorizzare le richieste di invio. |
| Chiave server (per protocolli legacy **deprecati**) | Una chiave server che autorizza il server dell'app per l'accesso ai servizi Google, inclusa l'invio di messaggi tramite i protocolli legacy Firebase Cloud Messaging ritirati. Importante: non includere la chiave server in nessun punto del codice client. Inoltre, assicurati di utilizzare solo le chiavi del server per autorizzare il tuo server app. Le chiavi Android, della piattaforma Apple e del browser vengono rifiutate da FCM. |