Informazioni sui messaggi FCM

Firebase Cloud Messaging (FCM) offre una vasta gamma di opzioni di messaggistica e capacità. 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 due tipi di messaggi ai clienti:

  • I messaggi di notifica, a volte chiamati "messaggi visualizzati". 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, invece, contengono solo le coppie chiave-valore personalizzate definite dall'utente. I messaggi di notifica possono contenere una e il tuo payload per i dati. 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 di utilizzo Come inviare
Messaggio di notifica L'SDK FCM mostra il messaggio ai 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 sono dotati di un insieme predefinito di chiavi visibili all'utente e di payload facoltativo di dati 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.

    Scopri alcuni esempi di visualizzare notifiche e inviare payload di richieste.

  2. Utilizza la Compositore notifiche: inserisci testo, titolo del messaggio e così via e invialo. Aggiungi un payload facoltativo fornendo i 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 automaticamente una notifica quando l'app è in esecuzione in background. Utilizza i messaggi di dati quando vuoi elaborarli con il tuo il proprio codice dell'app client.

FCM può inviare un messaggio di notifica con dati facoltativi il payload. 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 offre soluzioni basate su analisi Test A/B che ti aiutano 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 vengono gestiti 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 su per inviare un payload di dati all'app client.

Ad esempio, ecco un esempio un messaggio in formato JSON nella stessa app di messaggistica immediata precedente, le informazioni sono incapsulate nella chiave data comune l'app client deve 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 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 quali come Capillare o DTLS.

Messaggi di notifica con payload di dati facoltativi

Puoi inviare notifiche sia in modo programmatico sia tramite la console Firebase che contengono 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, la tua app riceve un messaggio con entrambi i payload disponibili.

Ecco un messaggio in formato JSON contenente sia il Il tasto notification e il tasto 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

Il protocollo HTTP Firebase Admin SDK e FCM v1 consentono entrambi i messaggi per impostare tutti i campi disponibili nel 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, ad esempio AndroidConfig e WebpushConfig, interpretati solo dalle istanze di app in esecuzione sulla piattaforma specificata.

I blocchi specifici per piattaforma ti offrono la flessibilità di personalizzare i messaggi per piattaforme diverse per garantire che vengano gestiti correttamente quando li ricevi. 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 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 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 impostarli. Puoi specificare valori diversi per piattaforma desiderato. 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 recapito specifiche della piattaforma

La seguente richiesta di invio v1 invia un titolo di notifica comune e contenuti su tutte le piattaforme, ma invia anche alcuni override specifici 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_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 per HTTP v1 per tutti i dettagli sulle chiavi disponibili in specifici per piattaforma nel corpo del messaggio. Per ulteriori informazioni creare inviare richieste che contengono il corpo del messaggio, vedi Crea richieste di invio.

Opzioni di consegna

FCM fornisce una serie specifica di opzioni di recapito per i messaggi inviati a sui dispositivi Android e consente opzioni simili web e piattaforme Apple. 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 sul 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 quelli critici. Ad esempio, in un'app di messaggistica immediata, vorrai recapitare 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 disponibile online, riceve un messaggio speciale che indica che il limite è stato raggiunto. L'app può quindi gestire la situazione correttamente, in genere richiedendo una sincronizzazione completa dal server dell'app.

Un messaggio comprimibile è un messaggio che potrebbe essere sostituito da nuovo messaggio, se deve essere ancora consegnato al 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 in il payload dei messaggi. Per impostazione predefinita, la chiave di collasso è il nome del pacchetto dell'app registrato nella console Firebase. Il server FCM può archiviare contemporaneamente quattro diversi messaggi comprimibili dispositivo, ognuno 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 argomento senza payload sono comprimibili per impostazione predefinita. 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 puoi superare questo numero oppure potrebbero causare conseguenze imprevedibili.

Scenario di utilizzo Come inviare
Non comprimibili Ogni messaggio è importante per l'app client e deve essere disponibili. Ad eccezione dei messaggi di notifica, tutti i messaggi non possono essere compressi predefinito.
Ripiegabili Quando c'è un messaggio più recente che restituisce un messaggio correlato meno recente irrilevante per l'app client, FCM sostituisce il messaggio precedente. Ad esempio: messaggi non aggiornati utilizzati per avviare una sincronizzazione dei dati dal server messaggi di notifica. Imposta il parametro appropriato nella richiesta di messaggi:
  • 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 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 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 fornire una priorità elevata messaggi immediati 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 FCM Protocollo HTTP v1 per inviare notifiche a una rivista sottoscrittore che i nuovi contenuti siano disponibili per il download:

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

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

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 di supporto vitale). Tale utilizzo è espressamente vietato ai sensi dei 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 relativo accesso, per qualsiasi motivo e in qualunque nel tempo, senza responsabilità o altri obblighi nei tuoi confronti o nei confronti dei tuoi utenti.

Impostazione della durata di un messaggio

FCM di solito recapita i messaggi subito 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. Oppure FCM potrebbe ritardare intenzionalmente i messaggi per evitare che un'app consumi risorse eccessive e che influisce sulla durata della batteria.

In questi casi, FCM archivia il messaggio e lo invia appena possibile. Nella maggior parte dei casi questo è un problema, ma esistono alcune app per un messaggio in ritardo potrebbe non essere mai recapitato. Ad esempio, se messaggio è una notifica di chiamata o videochiamata in arrivo, è rilevante 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 per creare un nuovo messaggio email. 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 consegnare 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 tramite chat video
  • Eventi di inviti in scadenza
  • Eventi nel calendario

Un altro vantaggio di specificare la durata di un messaggio è che FCM non applica la limitazione dei messaggi comprimibili ai messaggi con un un valore di durata pari a 0 secondi. FCM consente di gestire al meglio i messaggi che devono essere disponibili "ora o mai". Tieni presente che time_to_live valore di 0 significa che i messaggi che non possono essere recapitati immediatamente vengono eliminati. Tuttavia, poiché questi messaggi non vengono mai archiviati, questo offre la migliore latenza 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 dell'app pubblica un messaggio su FCM e riceve un ID messaggio, non significa che il messaggio sia già stato recapitato sul dispositivo. Piuttosto, significa che è stato accettato 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, viene memorizzato un messaggio a bassa priorità entro il giorno FCM fino a quando il dispositivo non disattiva la modalità Sospensione. e è in questo caso che gioca un ruolo il flag collapse_key: se è già archiviato un messaggio con la stessa chiave di compressione (e lo stesso token di registrazione) e in attesa consegna, il vecchio messaggio viene eliminato e quello nuovo sostituisce (vale a dire, il vecchio messaggio viene compresso da quello nuovo). Tuttavia, se la 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 viene stabilita una connessione (sempre nel rispetto delle regole delle chiavi di compressione). Quando viene stabilita una connessione, FCM invia tutti i messaggi in attesa al dispositivo. Se il dispositivo non si connette 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 ulteriori informazioni sul recapito dei messaggi sulle piattaforme Android o Apple, vedi dashboard dei report FCM, che registra le di messaggi inviati e aperti su dispositivi Apple e Android, insieme a dati per le "impressioni" (notifiche visualizzate dagli utenti) per le app 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 con i dati che gli 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 recapitare un messaggio al dispositivo e l'app è stata disinstallata, FCM elimina subito il messaggio e il token di registrazione non è valido. Tentativi futuri di inviare un messaggio a quell'utente restituisce un errore NotRegistered.

Limitazione e quote

Il nostro obiettivo è consegnare sempre ogni messaggio inviato 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 aiuta a trovare un equilibrio tra questi importanti fattori.

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 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 una quota superata il sistema visualizza il codice di stato HTTP 429 (QUOTA_EXCEEDED) fino a quando la quota verrà ricaricata entro un minuto. 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 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 nella console Google Cloud:

  1. Vai alla console Google Cloud
  2. Seleziona API e
  3. Dall'elenco delle tabelle, seleziona API Firebase Cloud Messaging
  4. Seleziona QUOTA & LIMITI DI SISTEMA.

NOTA: questi grafici non sono allineati precisamente al tempo con i minuti di quota, il che significa Possono essere inviati errori 429 quando il traffico risulta 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 per un massimo di +25% e FCM si adopereranno in modo 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), almeno È richiesto un preavviso di 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 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, come quando scegli come target argomenti e gruppi o quando utilizzi i Compositore notifiche per scegliere come target segmenti di pubblico o segmenti di utenti.

La distribuzione dei messaggi non è istantanea, pertanto a volte sono in corso più distribuzioni contemporaneamente. Limitiamo il numero di messaggi simultanei fanout per progetto fino a 1000. Dopodiché, potremmo rifiutare un ulteriore fanout o rinviare il fan-out delle richieste fino a quando fanout dei progressi completati.

La percentuale di fanout effettivamente raggiungibile è influenzata dal numero di progetti che richiedono fanout contemporaneamente. una velocità di fanout di 10.000 QPS per un progetto individuale non è raro, ma questo numero non è una garanzia ed è una risultato del carico totale sul sistema. È importante notare che la capacità di fanout disponibile è suddivisa tra i progetti e non tra le richieste di fanout. Quindi, se il tuo progetto ha due fanout in corso, ogni fanout verrà solo metà della percentuale 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 spiegato in precedenza, i messaggi comprimibili sono notifiche senza contenuti progettate si comprimano una sull'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.

Limitazione del server XMPP

Limitiamo la frequenza di collegamento ai server FCM XMPP a 400 connessioni al minuto per progetto. Questo non dovrebbe essere un problema per il recapito 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, limiti FCM messaggi upstream a 1.500.000 al minuto per progetto per evitare di sovraccaricare i server di destinazione upstream.

Limitiamo a 1000/minuto i messaggi in upstream per dispositivo per proteggerti dal consumo della batteria causato dal comportamento di app dannose.

Frequenza massima dei messaggi per un singolo dispositivo

Per Android, puoi inviare fino a 240 messaggi/minuto e 5000 messaggi/ora a una singola 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 alla logica di invio per evitare il consumo involontario della 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 del firewall potrebbero non essere aggiornate, con ripercussioni sull'esperienza degli utenti. Possibilmente, lista consentita porte 5228-5230 e 443 senza restrizioni 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. Utilizzo dei nomi di dominio per il firewall potrebbe non funzionare 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 con Network Address Translation e/o ispezione approfondita dei pacchetti:

Se la tua rete implementa Network Address Translation (NAT) o un pacchetto stateful Ispezione (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 possibilità di bypassare le VPN

Firebase Cloud Messaging adotta varie misure per assicurarsi che i messaggi push connessione telefono al server sia affidabile e disponibile tutte le volte che possibile. L'utilizzo di una VPN complica questo sforzo.

Le VPN mascherano le informazioni sottostanti che FCM ha bisogno di regolare la sua per massimizzare l'affidabilità 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 consentirci per farlo aggiriamo la VPN utilizzando una connessione crittografata (sulla rete di base Wi-Fi o LTE) per garantire un'affidabile funzionalità di ricarica un'esperienza senza intervento manuale. L'utilizzo di VPN ignorabili da parte di FCM è specifico per FCM canale di notifiche push. 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 è necessario per i messaggi di gruppo e per i singoli 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 mittente che può inviare messaggi all'app client.
Token di accesso Un token OAuth 2.0 di breve durata che autorizza le richieste a HTTP v1 tramite Google Cloud CLI o tramite l'API Compute Engine. Questo token è associato a un account di servizio che appartiene a nel tuo progetto Firebase. Per creare e ruotare i token di accesso, segui le passaggi descritti in Autorizzare le richieste di invio.
Chiave server (per protocolli legacy **deprecati**)

Un server che autorizza il server delle app per ai servizi Google, incluso l'invio di messaggi tramite deprecato Firebase Cloud Messaging protocolli legacy.

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.