Informazioni sui messaggi FCM

Firebase Cloud Messaging (FCM) offre un'ampia gamma di opzioni e funzionalità di messaggistica. Le informazioni riportate 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 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, gestiti dall'app client.

I messaggi di notifica contengono un insieme predefinito di chiavi visibili all'utente. I messaggi di dati, invece, 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 è 4096 byte, tranne quando si inviano 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. In caso contrario, se l'app è in esecuzione in primo piano al momento della ricezione della notifica, il codice dell'app determina il comportamento. I messaggi di notifica hanno un insieme predefinito di chiavi visibili all'utente e un payload di dati facoltativo di coppie chiave/valore personalizzate.

  1. In un ambiente attendibile come Cloud Functions o il tuo server app, utilizza l'SDK Admin o l'API HTTP v1. Imposta la chiave notification. Può avere un payload di dati facoltativo. Sempre comprimibili.

    Consulta alcuni esempi di notifiche di visualizzazione e invia i payload delle richieste.

  2. Utilizza il Editor di notifiche: inserisci il testo del messaggio, il titolo e così via e invia. Aggiungi un payload facoltativo fornendo dati personalizzati.
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 di seguito). In un ambiente attendibile come Cloud Functions o il tuo server app, utilizza l'SDK Admin o i Protocolli del 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 l'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 della notifica e l'app client gestisce il payload di 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 dall'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 vengono 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 coppie chiave-valore personalizzate per inviare un payload di dati all'app client.

Ad esempio, di seguito è riportato un messaggio in formato JSON nella stessa app di messaggistica istantanea di cui sopra, 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 di dati in una funzione di callback.

Crittografia per i 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 di dati facoltativi

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 sia i payload di notifica sia quelli di dati dipende dal fatto che l'app sia in background o in primo piano, ovvero se è attiva o meno al momento della ricezione.

  • In background, le app ricevono il payload della 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. È incluso quanto segue:

  • un insieme comune di campi da interpretare da tutte le istanze dell'app che ricevono il messaggio.
  • insiemi di campi specifici della piattaforma, come AndroidConfig e WebpushConfig, 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 delle istanze di app su tutte le piattaforme: Apple, Android e web
  • Invio di messaggi per argomenti

Tutte le istanze di 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 campi solo a piattaforme specifiche
  • Invia campi specifici della piattaforma oltre a quelli comuni

Quando vuoi inviare valori solo a piattaforme specifiche, non utilizzare i campi comuni, ma quelli specifici della piattaforma. Ad esempio, per inviare una notifica solo alle piattaforme Apple e al web, ma non ad Android, devi utilizzare due insiemi distinti 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 se 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 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 invio 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:

  • imposta un TTL (time-to-live) lungo per le piattaforme Android e web, impostando al contempo la priorità dei messaggi APN (piattaforme Apple) su un'impostazione bassa
  • imposta le chiavi appropriate per definire il risultato del tocco di un utente sulla notifica su Android e Apple, rispettivamente click_action e category.
{
  "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 HTTP v1 per informazioni dettagliate 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 comprimibili e non comprimibili

Un messaggio non comprimibile indica che ogni singolo messaggio viene recapitato sul dispositivo. Un messaggio non comprimibile fornisce alcuni contenuti utili, rispetto a 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 quelli critici. Ad esempio, in un'app di messaggistica istantanea, vuoi 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 può quindi gestire la situazione correttamente, 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 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 è un'app sportiva 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 collasso è 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 collasso, senza alcuna garanzia su quali vengano conservate.

I messaggi topic 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 al massimo quattro chiavi di compressione diverse da FCM per token di registrazione in un determinato momento. Non devi superare questo numero, altrimenti potresti provocare conseguenze imprevedibili.

Scenario d'uso Come inviare
Non comprimibile Ogni messaggio è importante per l'app client e deve essere comunicato. 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 устаревших. Imposta il parametro appropriato nella richiesta di messaggio:
  • collapseKey su Android
  • apns-collapse-id su Apple
  • Topic sul web
  • collapse_key nei protocolli precedenti (tutte le piattaforme)

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 sia leggermente diverso su tutte le piattaforme, l'invio di messaggi con priorità normale e alta funziona come segue:

  • Priorità normale. I messaggi con priorità normale vengono inviati immediatamente quando l'app è in primo piano. Per le app in background, l'invio potrebbe subire un ritardo. 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 inviare immediatamente i messaggi di alta priorità anche se il dispositivo è in modalità Sospensione. I messaggi con priorità elevata sono destinati a contenuti visibili agli utenti e urgenti.

Ecco un esempio di messaggio con priorità normale inviato tramite il protocollo HTTP v1 di FCM per notificare a un abbonato di 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 ulteriori dettagli specifici della piattaforma sull'impostazione della priorità dei messaggi:

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 (ad esempio 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 ritirarle, qualsiasi parte o funzionalità o il tuo accesso, per qualsiasi motivo e in qualsiasi momento, senza responsabilità o altri obblighi 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 questi casi, FCM archivia il messaggio e lo invia 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 notifica di chiamata in arrivo o di videochiamata, è significativo 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. Per le richieste che non contengono questo campo viene utilizzato per impostazione predefinita il periodo massimo di quattro settimane.

Ecco alcuni possibili utilizzi di questa funzionalità:

  • Chiamate in arrivo di chat video
  • Eventi di inviti in scadenza
  • Eventi nel 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 TTL di 0 secondi. FCM esegue la gestione secondo il criterio del massimo impegno per i messaggi che devono essere recapitati "ora o mai più". 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 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 un server dell'app pubblica un messaggio su FCM e riceve un ID messaggio, non significa che il messaggio sia già stato recapitato sul dispositivo. Significa invece che è stata accettata per la consegna. Che cosa succede 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 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à presente un messaggio con la stessa chiave di chiusura (e lo stesso token di registrazione) memorizzato e 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 collapse non è impostata, sia i messaggi nuovi che quelli precedenti vengono archiviati per l'invio futuro.

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 mai più (ad esempio, se sono stati ripristinati i dati di fabbrica), il messaggio scade e viene eliminato dall'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 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 elimina immediatamente. Se il dispositivo si connette entro quattro settimane dall'ultimo messaggio di dati che hai inviato, il tuo 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 inviare un messaggio al dispositivo e l'app è stata disinstallata, FCM lo ignora immediatamente 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 tutti i messaggi inviati tramite FCM. Tuttavia, a volte l'invio di ogni messaggio 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 i messaggi di downstream. La quota predefinita di 600.000 messaggi al minuto copre oltre il 99% degli sviluppatoriFCM, proteggendo al contempo la stabilità del sistema e minimizzando l'impatto dei progetti con picchi di traffico.

I pattern di traffico con picchi possono causare errori di quota superata. 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, pertanto ti consigliamo vivamente di gestirle in base ai consigli pubblicati.

Ricorda:

  • La quota downstream misura i messaggi, non le richieste.
  • Vengono conteggiati gli errori client (codici di stato HTTP 400-499) (esclusi i codici 429).
  • Le quote sono calcolate in base ai minuti, ma questi minuti non sono allineati all'orologio.

Quota di monitoraggio

Puoi visualizzare quota, utilizzo ed errori in Google Cloud Console:

  1. Vai alla console Google Cloud
  2. Seleziona API e servizi.
  3. Dall'elenco della tabella, seleziona API Firebase Cloud Messaging.
  4. 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:

  • Il tuo utilizzo è regolarmente ≥ 80% della quota per almeno 5 minuti consecutivi al giorno.
  • Il rapporto di errori client è inferiore al 5%, in particolare 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 (>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 di messaggi per argomento

La frequenza di aggiunta/rimozione delle iscrizioni agli argomenti è limitata a 3000 QPS per progetto.

Per le frequenze di invio dei messaggi, consulta Ritardo 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 creazione di notifiche per scegliere come target segmenti di pubblico o utenti.

La distribuzione dei messaggi non è istantanea, pertanto a volte sono in corso più distribuzioni contemporaneamente. Il numero di fanout di messaggi contemporaneamente per progetto è limitato a 1000. Dopodiché, potremmo rifiutare ulteriori richieste di fanout o posticipare il fanout delle richieste 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. Un tasso di fanout di 10.000 QPS per un singolo progetto non è insolito, 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 metà della frequenza di fanout disponibile. Il modo consigliato per massimizzare la velocità di fanout è avere un solo fanout attivo alla volta.

Regolazione della frequenza dei messaggi comprimibili

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 successiva richiesta di sincronizzazione email di alcuni minuti in modo che il dispositivo possa sincronizzarsi a una frequenza media inferiore. Questa limitazione viene eseguita esclusivamente per limitare l'impatto sulla batteria percepito dall'utente.

Se il tuo caso d'uso richiede pattern di invio con picchi elevati, i messaggi non comprimibili potrebbero essere la scelta giusta. Per questi messaggi, assicurati di includere i contenuti al loro interno per ridurre il consumo della batteria.

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

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 picchi di traffico a breve termine, ad esempio quando gli utenti interagiscono rapidamente tramite chat. Questo limite impedisce che errori nella logica di invio causino inavvertitamente lo scaricamento della batteria su un dispositivo.

Per iOS, viene restituito un errore quando la frequenza supera i limiti degli APN.

Le porte FCM 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 del firewall potrebbero non essere aggiornate, con ripercussioni sull'esperienza degli utenti. Idealmente, inserisci nella lista consentita le porte 5228-5230 e 443 senza limitazioni IP. Tuttavia, se devi applicare una limitazione 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 inizieremo 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 la Network Address Translation (NAT) o la Stateful Packet Inspection (SPI), implementa un timeout di almeno 30 minuti per le nostre connessioni tramite le porte 5228-5230. In questo modo possiamo offrire una connettività affidabile riducendo al contempo il consumo della batteria dei dispositivi mobili degli utenti.

Interazioni e possibilità di bypass delle VPN

Firebase Cloud Messaging adotta vari passaggi per garantire che la connessione di messaggistica push dal telefono al server sia affidabile e disponibile il più spesso possibile. L'utilizzo 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. Quando la VPN è configurata per consentircelo, aggiriamo la VPN utilizzando una connessione criptata (tramite la rete di base Wi-Fi o LTE) per garantire un'esperienza affidabile e rispettosa della batteria. L'utilizzo di VPN aggirabili da parte di FCM è specifico per il canale di notifica push di FCM. L'altro 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 tua VPN specifica.

Se la VPN non è configurata per essere aggirata, Firebase Cloud Messaging userà la rete VPN per connettersi al server. Ciò potrebbe comportare periodi di tempo in cui i messaggi vengono ritardati e un maggiore utilizzo della batteria mentre Cloud Messaging lavora 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 FCM v1. Questo valore è disponibile nel riquadro Impostazioni della console Firebase.
Token di registrazione

Una stringa token univoca che identifica ogni istanza dell'app client. Il token di registrazione è obbligatorio per i messaggi di gruppo e per i singoli dispositivi. Tieni presente che i token di registrazione devono essere tenuti 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 appartenente 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 i protocolli precedenti **ritratte**)

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 del server nel 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.