Firebase Cloud Messaging (FCM) offre un'ampia 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 cosa puoi fare con loro.
Tipi di messaggi
Con FCM, puoi inviare due tipi di messaggi ai clienti:
- Messaggi di notifica, a volte chiamati "messaggi display". Questi vengono gestiti automaticamente dall'SDK 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 facoltativo. Il payload massimo per entrambi i tipi di messaggio è di 4096 byte, tranne quando vengono inviati messaggi dalla console Firebase, che impone un limite di 1000 caratteri.
| Scenario di utilizzo | Come inviare | |
|---|---|---|
| Messaggio di notifica | FCM L'SDK mostra il messaggio ai dispositivi degli utenti finali per conto dell'app client quando viene eseguita in background. Altrimenti, se l'app è in esecuzione in primo piano quando viene ricevuta 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 contengono solo coppie chiave-valore personalizzate senza nomi di chiavi riservati (vedi sotto). | In un ambiente attendibile come
Cloud Functions
o il server delle 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 di una notifica automaticamente 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 di dati facoltativo. In questi casi, FCM gestisce la visualizzazione del payload della notifica e l'app client gestisce il payload dei dati.
Messaggi di notifica
Per i test o per il marketing e il coinvolgimento degli utenti, puoi inviare messaggi di notifica utilizzando la Firebase console. La console Firebase fornisce test A/B basati su Analytics per aiutarti a perfezionare e migliorare i messaggi di marketing.
Per inviare messaggi di notifica a livello di programmazione 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, 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 - Danimarca" e il testo
"Partita fantastica!" 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.
Consulta la documentazione di riferimento relativa all'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 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 istantanea di cui sopra,
in cui le informazioni sono incapsulate nella chiave comune data e
l'app client deve interpretare il contenuto:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
}L'esempio precedente mostra l'utilizzo del campo data di primo livello o comune,
che viene interpretato dai client su tutte le piattaforme che ricevono il messaggio.
Su ogni piattaforma, l'app client riceve il payload di dati
in una funzione di callback.
Crittografia per i messaggi di dati
Il livello di trasporto Android (vedi l'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, sono disponibili soluzioni esterne come Capillary o DTLS.
Messaggi di notifica con payload di dati facoltativo
A livello di programmazione o tramite la console Firebase, puoi inviare messaggi di notifica che contengono un payload facoltativo di coppie chiave/valore personalizzate. Nel composer delle notifiche, utilizza i campi Dati personalizzati nelle Opzioni avanzate.
Il comportamento dell'app quando riceve messaggi che includono payload di notifica e dati dipende dal fatto che l'app sia in background o in primo piano, ovvero se è 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 di dati solo quando l'utente tocca la notifica.
- Quando è in primo piano, la tua 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
Firebase Admin SDK e il protocollo HTTP FCM v1 consentono entrambi alle richieste di messaggi di impostare tutti i campi disponibili nell'oggetto
message. È incluso quanto segue:
- un insieme comune di campi da interpretare da tutte le istanze dell'app che ricevono il messaggio.
- set di campi specifici della piattaforma, ad esempio
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 diverse piattaforme per assicurarti che vengano gestiti correttamente quando vengono ricevuti. 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 delle istanze delle 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 vuoi:
- Inviare i campi solo a piattaforme specifiche
- Invia campi specifici della piattaforma oltre a quelli comuni
Se vuoi inviare valori solo a piattaforme specifiche, non utilizzare campi comuni, ma campi specifici della piattaforma. Ad esempio, per inviare una notifica solo alle piattaforme Apple e al web, ma non ad Android, devi utilizzare due insiemi separati di campi, 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 quando vuoi impostare essenzialmente lo stesso valore su tutte le piattaforme, devi utilizzare campi specifici della piattaforma. Questo perché ogni piattaforma potrebbe interpretare il valore in modo leggermente diverso. Ad esempio, il time-to-live è impostato su Android come tempo di scadenza in secondi, mentre su Apple è impostato come data di scadenza.
Esempio: messaggio di notifica con opzioni di recapito specifiche per la piattaforma
La seguente richiesta di invio v1 invia un titolo e contenuti di notifica comuni a tutte le piattaforme, ma anche alcuni override specifici per la piattaforma. Nello specifico, la richiesta:
- imposta un valore time-to-live elevato per le piattaforme Android e web, mentre imposta la priorità dei messaggi APN (piattaforme Apple) su un valore basso
- imposta le chiavi appropriate per definire il risultato del tocco di un utente sulla notifica su Android e Apple, ovvero
click_actionecategoryrispettivamente.
{ "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 di HTTP v1 per informazioni dettagliate sulle chiavi disponibili nei blocchi specifici della piattaforma nel corpo del messaggio. Per saperne di più sulla creazione di richieste di invio che contengono il corpo del messaggio, consulta 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 su
piattaforme Apple e sul web. Ad esempio, il comportamento dei messaggi "comprimibili" è supportato su
Android tramite FCM's collapse_key, 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 comprimibili e non 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, vorresti consegnare ogni messaggio, perché ogni messaggio ha contenuti diversi.
Per Android, è possibile memorizzare fino a 100 messaggi senza comprimerli. 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 comprimibile è un messaggio che può essere sostituito da un nuovo messaggio se non è ancora stato recapitato al dispositivo.
Un caso d'uso comune dei messaggi comprimibili sono i messaggi utilizzati per comunicare a un'app mobile di sincronizzare i dati dal server. Un esempio è un'app di sport che aggiorna gli utenti con l'ultimo risultato. 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
registrata nella console Firebase. Il server FCM può
memorizzare contemporaneamente quattro diversi messaggi comprimibili per
dispositivo, ognuno con una chiave di compressione diversa. Se superi questo numero,
FCM conserva solo
quattro chiavi di compressione, senza alcuna garanzia su quali vengano conservate.
I messaggi dell'argomento senza payload sono comprimibili per impostazione predefinita. I messaggi di notifica
sono sempre comprimibili e ignorano il parametro collapse_key.
Quale devo utilizzare?
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 di utilizzare un massimo di quattro chiavi di compressione diverse da FCM per token di registrazione in un determinato momento. Non devi superare questo numero, altrimenti potrebbero verificarsi conseguenze imprevedibili.
| Scenario di utilizzo | Come inviare | |
|---|---|---|
| Non comprimibile | Ogni messaggio è importante per l'app client e deve essere recapitato. | Ad eccezione dei messaggi di notifica, tutti i messaggi non sono comprimibili per impostazione predefinita. |
| Comprimibile | Quando è presente 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 messaggio:
|
Impostare la priorità di un messaggio
Hai due opzioni per assegnare la priorità di consegna ai messaggi downstream: priorità normale e alta. Sebbene il comportamento vari leggermente tra le piattaforme, la distribuzione dei messaggi con priorità normale e alta funziona in questo modo:
Priorità normale. I messaggi con priorità normale vengono consegnati immediatamente quando l'app è in primo piano. Per le app in background, la consegna potrebbe subire ritardi. Per i messaggi meno urgenti, ad esempio le notifiche di nuove email, la sincronizzazione dell'interfaccia utente o la sincronizzazione dei dati delle app in background, scegli la priorità di distribuzione normale.
Priorità elevata. FCM tenta di recapitare immediatamente i messaggi ad alta priorità anche se il dispositivo è in modalità Doze. I messaggi con priorità elevata sono destinati a contenuti urgenti e visibili agli utenti.
Di seguito è riportato un esempio di messaggio con priorità normale inviato tramite il protocollo HTTP v1 FCM per comunicare a un abbonato a una rivista che sono disponibili nuovi contenuti da scaricare:
{
"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 maggiori dettagli specifici per la piattaforma sull'impostazione della priorità dei messaggi:
- Documentazione APN
- Impostare e gestire la priorità dei messaggi (Android)
- Urgenza dei messaggi push web
Casi d'uso critici per la vita
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 (come il funzionamento di impianti nucleari, il controllo del traffico aereo o i sistemi di supporto vitale). 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 e di eventuali danni derivanti dalla mancata 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 stesse, per qualsiasi motivo e in qualsiasi momento, senza responsabilità o altri obblighi nei tuoi confronti o nei confronti dei tuoi utenti.
Impostare la durata di un messaggio
FCM in genere recapita i messaggi immediatamente dopo l'invio. Tuttavia, potrebbe non essere sempre possibile. Ad esempio, se la piattaforma è Android, il dispositivo potrebbe essere spento, offline o non disponibile. 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 questi casi, FCM memorizza il messaggio e lo recapita non appena è possibile. Sebbene nella maggior parte dei casi non ci siano problemi, per alcune app un messaggio in ritardo potrebbe non essere mai recapitato. Ad esempio, se il messaggio è una notifica di chiamata o videochiamata in arrivo, è 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 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 recapitare il messaggio. Le richieste che non contengono questo campo hanno come periodo predefinito il periodo massimo di quattro settimane.
Ecco alcuni possibili utilizzi di questa funzionalità:
- Chiamate in arrivo con chat video
- Eventi di invito in scadenza
- Eventi di calendario
Un altro vantaggio della specifica della durata di un messaggio è che
FCM non applica la limitazione dei messaggi comprimibili ai messaggi con un
valore Time-to-live di 0 secondi.
FCM fornisce la gestione migliore possibile dei messaggi che devono essere
recapitati "ora o mai più". Tieni presente che un valore di time_to_live pari a 0 indica che i messaggi che non possono essere consegnati immediatamente vengono eliminati. Tuttavia,
poiché questi messaggi non vengono mai archiviati, ciò garantisce la migliore latenza per
l'invio di messaggi di notifica.
Ecco un esempio di richiesta che include il 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 il server di un'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 è stato accettato per la consegna. Ciò che accade al messaggio dopo l'accettazione dipende da molti fattori.
Nello scenario migliore, 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à Doze, un messaggio a bassa priorità viene memorizzato
da FCM finché il dispositivo non esce dalla modalità Doze. Ed è qui che entra in gioco il flag collapse_key: se è già presente un messaggio con la stessa chiave di compressione (e lo stesso token di registrazione) archiviato e in attesa di consegna, il vecchio messaggio viene eliminato e sostituito dal nuovo (ovvero, il vecchio messaggio viene compresso dal nuovo). Tuttavia, se la chiave di compressione non è impostata, sia i messaggi nuovi che quelli vecchi vengono archiviati per la consegna futura.
Se il dispositivo non è connesso a FCM, il messaggio viene memorizzato finché
non viene stabilita una connessione (rispettando di nuovo le regole della chiave di compressione). Quando viene stabilita una connessione, FCM invia tutti i messaggi in attesa al dispositivo. Se il dispositivo non si connette mai più
(ad esempio, se sono stati ripristinati i dati di fabbrica), il messaggio scade e
viene eliminato dallo spazio di archiviazione di FCM. Il timeout predefinito è di quattro settimane,
a meno che non sia impostato il flag time_to_live.
Per ottenere maggiori informazioni sulla consegna di un messaggio:
Per ottenere maggiori informazioni sulla distribuzione dei messaggi sulle piattaforme Android o Apple, consulta la dashboard dei report FCM, che registra il numero di messaggi inviati e aperti su dispositivi Apple e Android, insieme ai dati relativi alle "impressioni" (notifiche visualizzate dagli utenti) per le app per Android.
Per i dispositivi Android con la messaggistica diretta del canale 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 dall'ultimo messaggio di dati che gli hai inviato, il client riceve il callback onDeletedMessages(). 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 scarta immediatamente il messaggio e
invalida il token di registrazione. I tentativi futuri di inviare un messaggio a quel
dispositivo generano un errore NotRegistered.
Limitazione e quote
Il nostro obiettivo è consegnare sempre tutti i messaggi inviati tramite FCM. Tuttavia, la pubblicazione 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 al minuto per la messaggistica downstream. 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.
Pattern di traffico irregolari possono causare errori di quota superata. In uno scenario di superamento della quota, il sistema pubblica il codice di stato HTTP 429 (QUOTA_EXCEEDED) finché la quota non viene ricaricata nel minuto successivo. Le risposte 429 possono essere restituite anche in situazioni di sovraccarico, pertanto ti consigliamo vivamente di gestirle in base ai consigli pubblicati.
Ricorda:
- La quota downstream misura i messaggi, non le richieste.
- Gli errori client (codice di stato HTTP 400-499) vengono conteggiati (esclusi i codici 429).
- Le quote sono al minuto, ma questi minuti non sono allineati all'orologio.
Monitoraggio della quota
Puoi visualizzare quota, utilizzo ed errori su Google Cloud Console:
- Vai alla Google Cloud console
- Seleziona API e servizi.
- Dall'elenco delle tabelle, seleziona API Firebase Cloud Messaging.
- Seleziona QUOTA E LIMITI DI SISTEMA.
NOTA: questi grafici non sono allineati con precisione nel tempo ai minuti di quota, il che significa che potrebbero essere restituiti errori 429 quando il traffico sembra essere inferiore alla quota.
Richiesta di aumento della quota
Prima di richiedere un aumento della quota, assicurati che:
- Il tuo utilizzo è regolarmente ≥ 80% della quota per almeno 5 minuti consecutivi al giorno.
- Il rapporto di errori del client è inferiore al 5%, soprattutto durante il picco 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 a un massimo di +25% e FCM farà ogni sforzo pratico per soddisfare la richiesta (nessun aumento può essere garantito).
Se hai bisogno di una quota di messaggistica downstream maggiore a causa di un lancio imminente o di un evento temporaneo, richiedi la quota almeno 15 giorni prima per consentire un tempo sufficiente per gestire la richiesta. Per le richieste di grandi dimensioni (> 18 milioni di messaggi al minuto), è necessario un preavviso di almeno 30 giorni. 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 dei messaggi dell'argomento
La velocità di aggiunta/rimozione delle sottoscrizioni agli argomenti è limitata a 3000 QPS per progetto.
Per le tariffe di invio dei messaggi, consulta Limitazione del fanout.
Limitazione del fanout
La distribuzione di messaggi è il processo di invio di un messaggio a più dispositivi, ad esempio quando scegli come target argomenti e gruppi o quando utilizzi lo strumento di composizione delle notifiche per scegliere come target segmenti di utenti o pubblici.
La distribuzione dei messaggi non è istantanea, quindi a volte hai più distribuzioni in corso contemporaneamente. Il numero di fanout di messaggi simultanei per progetto è limitato a 1000. Dopodiché, potremmo rifiutare ulteriori richieste di fanout o posticipare il fanout delle richieste fino al completamento di alcuni fanout già in corso.
Il tasso di fanout effettivamente raggiungibile è influenzato dal numero di progetti che richiedono fanout contemporaneamente. Una frequenza di fanout di 10.000 QPS per un singolo progetto non è insolita, 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. Pertanto, se il tuo progetto ha due fanout in corso, ogni fanout vedrà solo la metà della velocità di fanout disponibile. Il modo consigliato per massimizzare la velocità di fanout è avere una sola distribuzione attiva alla volta.
Limitazione dei messaggi comprimibili
Come descritto sopra, i messaggi comprimibili sono notifiche senza contenuti progettate per comprimersi una sull'altra. Nel caso in cui uno sviluppatore ripeta 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 delle email a un singolo dispositivo, potremmo ritardare di qualche minuto la successiva richiesta di sincronizzazione delle email in modo che il dispositivo possa sincronizzarsi a una velocità media inferiore. Questa limitazione viene eseguita rigorosamente per limitare l'impatto sulla batteria riscontrato dall'utente.
Se il tuo caso d'uso richiede pattern di invio di burst elevati, i messaggi non comprimibili potrebbero essere la scelta giusta. Per questi messaggi, assicurati di includere i contenuti per ridurre il consumo della batteria.
Limitiamo i messaggi comprimibili a un burst di 20 messaggi per app per dispositivo, con un reintegro di 1 messaggio ogni 3 minuti.
Frequenza massima dei messaggi a 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 picchi di traffico a breve termine, ad esempio quando gli utenti interagiscono rapidamente tramite chat. Questo limite impedisce errori nella logica di invio che potrebbero scaricare inavvertitamente la batteria di un dispositivo.
Per iOS, restituiamo un errore quando la frequenza supera i limiti APN.
Porte FCM e firewall
Se la tua organizzazione dispone di un firewall per limitare il traffico verso o da internet, devi configurarlo per consentire ai dispositivi mobili di connettersi a FCM affinché i dispositivi sulla tua rete ricevano i messaggi. FCM in genere utilizza la porta 5228, ma a volte utilizza le porte 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 del firewall potrebbero diventare obsolete, influendo sull'esperienza degli utenti. Idealmente, consenti le porte 5228-5230 e 443 senza limitazioni IP. Tuttavia, se devi impostare una restrizione IP, devi autorizzare tutti gli indirizzi IP elencati in goog.json. Questo lungo 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é gli indirizzi IP. Questi nomi host sono elencati di seguito. Se inizieremo a utilizzare altri nomi host, aggiorneremo l'elenco qui. L'utilizzo di nomi di dominio per la regola firewall potrebbe funzionare o meno nel tuo 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 NAT (Network Address Translation) e/o SPI (Stateful Packet Inspection):
Se la tua rete implementa la conversione degli indirizzi di rete (NAT) o l'ispezione dei pacchetti con stato (SPI), implementa un timeout di 30 minuti o superiore per le nostre connessioni sulle porte 5228-5230. In questo modo possiamo fornire una connettività affidabile riducendo al contempo il consumo della batteria dei dispositivi mobili degli utenti.
Interazioni VPN e possibilità di bypass
Firebase Cloud Messaging adotta varie misure per garantire che la connessione di messaggistica push dallo smartphone al server sia affidabile e disponibile il più spesso possibile. L'utilizzo di una VPN complica questa operazione.
Le VPN mascherano le informazioni sottostanti necessarie a FCM per ottimizzare la connessione in modo da massimizzare l'affidabilità e la durata della batteria. In alcuni casi, le VPN interrompono attivamente le connessioni di lunga durata, con conseguente esperienza utente negativa a causa di messaggi mancanti o ritardati o di un elevato consumo della batteria. Quando la VPN è configurata per consentirci di farlo, la bypassiamo utilizzando una connessione criptata (tramite la rete di base Wi-Fi o LTE) per garantire un'esperienza affidabile e a basso consumo di batteria. L'utilizzo di VPN bypassabili da parte di FCM è specifico per il canale di notifiche push FCM. L'altro traffico FCM, ad esempio il traffico di registrazione, utilizza la VPN se è attiva. Quando la connessione FCM ignora la VPN, perde i vantaggi aggiuntivi che la VPN potrebbe fornire, come il mascheramento dell'IP.
VPN diverse avranno metodi diversi per controllare se possono essere bypassate o meno. Per istruzioni, consulta la documentazione della tua VPN specifica.
Se la VPN non è configurata per essere bypassabile, Firebase Cloud Messaging utilizzerà la rete VPN per connettersi al server. Ciò potrebbe comportare periodi di tempo in cui i messaggi vengono ritardati e potrebbe comportare un maggiore consumo della batteria poiché Cloud Messaging funziona per mantenere la connessione tramite la connessione VPN.
Credenziali
A seconda delle funzionalità di FCM che implementi, potresti aver bisogno delle seguenti credenziali del tuo progetto Firebase:
| ID progetto | Un identificatore univoco per il tuo progetto Firebase, utilizzato nelle richieste all'endpoint HTTP v1 di FCM. Questo valore è disponibile nel riquadro Firebase console Impostazioni. |
| Token di registrazione | Una stringa di token univoca che identifica ogni istanza dell'app client. Il token di registrazione è necessario per la messaggistica su un singolo dispositivo e su un gruppo 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 nel riquadro 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 del server che autorizza il server delle app ad accedere ai servizi Google, incluso l'invio di messaggi tramite i protocolli legacy Firebase Cloud Messaging ritirati. Importante: non includere la chiave del server in nessun punto del codice client. Inoltre, assicurati di utilizzare solo le chiavi del server per autorizzare il server delle app. Le chiavi per Android, la piattaforma Apple e i browser vengono rifiutate da FCM. |