Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Informazioni sui messaggi FCM

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

Tipi di messaggio

Con FCM, puoi inviare due tipi di messaggi ai client:

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

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

Usa lo scenario Come spedire
Messaggio di notifica FCM visualizza automaticamente il messaggio ai dispositivi degli utenti finali per conto dell'app client. I messaggi di notifica hanno un set predefinito di chiavi visibili all'utente e un payload di dati facoltativo di coppie chiave-valore personalizzate.
  1. In un ambiente affidabile come Cloud Functions o il tuo app server, usa Admin SDK o FCM Server Protocol : imposta la chiave di notification . Può avere un carico utile dei dati facoltativo. Sempre pieghevole.

    Guarda alcuni esempi di notifiche sul display e invia payload di richieste.

  2. Usa il compositore di notifiche : inserisci il testo del messaggio, il titolo, ecc. E invia. Aggiungi un payload di dati opzionale fornendo dati personalizzati.
Messaggio di dati L'app client è responsabile dell'elaborazione dei messaggi di dati. I messaggi di dati hanno solo coppie chiave-valore personalizzate senza nomi di chiavi riservate (vedi sotto). In un ambiente affidabile come Cloud Functions o il tuo app server, utilizza Admin SDK o FCM Server Protocol : imposta solo la chiave data .

Utilizza i messaggi di notifica quando desideri che FCM gestisca la visualizzazione di una notifica per conto della tua app client. Utilizza i messaggi di dati quando desideri elaborare i messaggi sulla tua app client.

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

Messaggi di notifica

Per i test o per il marketing e il reimpegno degli utenti, puoi inviare messaggi di notifica utilizzando la console Firebase . La console Firebase fornisce test A / B basati su analisi per aiutarti a perfezionare e migliorare i messaggi di marketing.

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

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

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

Consulta la documentazione di riferimento per l'elenco completo delle chiavi predefinite disponibili per i messaggi di notifica degli edifici:

Messaggi di dati

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

Ad esempio, ecco un messaggio in formato JSON nella stessa app di messaggistica istantanea come sopra, in cui le informazioni sono incapsulate nella chiave data comune e si prevede che l'app client interpreti 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 dei dati in una funzione di callback. :

Messaggi di notifica con payload dati opzionale

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

Il comportamento dell'app quando si ricevono messaggi che includono sia notifiche che payload di dati dipende dal fatto che l'app sia in background o in primo piano, essenzialmente, indipendentemente dal fatto che sia attiva o meno al momento della ricezione.

  • Quando sono in background , le app ricevono il payload di notifica nella barra delle notifiche e gestiscono il payload dei dati solo quando l'utente tocca la notifica.
  • Quando è in primo piano , l'app riceve un oggetto messaggio con entrambi i payload disponibili.

Ecco un messaggio in formato JSON contenente sia la chiave di notification che 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 . Ciò comprende:

  • un insieme comune di campi che deve essere interpretato da tutte le istanze dell'app che ricevono il messaggio.
  • set 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 offrono la flessibilità di personalizzare i messaggi per piattaforme diverse per garantire che vengano gestiti correttamente quando vengono ricevuti. Il backend FCM terrà conto di tutti i parametri specificati e personalizzerà il messaggio per ciascuna piattaforma.

Quando utilizzare i campi comuni

Usa campi comuni quando:

  • Targeting di istanze di app su tutte le piattaforme: iOS, Android e web
  • Invio di messaggi agli argomenti

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

Quando utilizzare i campi specifici della piattaforma

Utilizza i campi specifici della piattaforma quando desideri:

  • Invia campi solo a piattaforme particolari
  • Invia campi specifici della piattaforma oltre ai campi comuni

Ogni volta che desideri inviare valori solo a piattaforme particolari, non utilizzare campi comuni; utilizzare campi specifici della piattaforma. Ad esempio, per inviare una notifica solo a iOS e Web ma non ad Android, è necessario utilizzare due set di campi separati, uno per iOS e uno per il Web.

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

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

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

  • imposta un tempo di vita lungo per piattaforme Android e Web, mentre la priorità dei messaggi APN (iOS) è bassa
  • imposta le chiavi appropriate per definire il risultato del tocco di un utente sulla notifica su Android e iOS, 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 i dettagli completi 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, vedere Build Send Requests .

Opzioni di consegna

FCM fornisce un set specifico di opzioni di consegna per i messaggi inviati a dispositivi Android e consente opzioni simili su iOS e Web. Ad esempio, il comportamento dei messaggi "comprimibili" è supportato su Android tramite collapse_key di FCM, su iOS tramite apns-collapse-id e su JavaScript / Web tramite Topic . Per i dettagli, vedere le descrizioni in questa sezione e la relativa documentazione di riferimento.

Messaggi non comprimibili e comprimibili

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

Alcuni casi d'uso tipici di 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 un contenuto diverso.

Per Android esiste un limite di 100 messaggi che possono essere archiviati senza comprimersi. Se viene raggiunto il limite, tutti i messaggi memorizzati vengono scartati. Quando il dispositivo è di nuovo 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 può essere sostituito da un nuovo messaggio se deve ancora essere consegnato al dispositivo.

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

Per contrassegnare un messaggio come comprimibile su Android, includi il parametro collapse_key nel payload del messaggio. FCM consente l'utilizzo di un massimo di quattro chiavi di compressione diverse per dispositivo Android dal server dell'app in qualsiasi momento. In altre parole, il server FCM può memorizzare simultaneamente quattro diversi messaggi comprimibili per dispositivo, ciascuno con una chiave di compressione diversa. Se si supera questo numero, FCM conserva solo quattro chiavi di compressione, senza garanzie su quali vengono mantenute.

Quale dovrei usare?

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

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

Impostazione della priorità di un messaggio

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

  • Priorità normale. Questa è la priorità predefinita per i messaggi di dati . I messaggi con priorità normale vengono recapitati immediatamente quando l'app è in primo piano. Quando il dispositivo è in sospensione, la consegna potrebbe essere ritardata per risparmiare la batteria. Per i messaggi meno sensibili al tempo, come le notifiche di nuovi messaggi di posta elettronica, la sincronizzazione dell'interfaccia utente o la sincronizzazione dei dati delle app in background, scegli la priorità di consegna normale.

    Quando si riceve un normale messaggio di priorità su Android che richiede una sincronizzazione dei dati in background per l'app, è possibile pianificare un'attività con WorkManager per gestirla quando la rete è disponibile.

  • Priorità alta. FCM tenta di recapitare immediatamente messaggi ad alta priorità, consentendo al servizio FCM di riattivare un dispositivo inattivo quando necessario e di eseguire un'elaborazione limitata (incluso un accesso di rete molto limitato). I messaggi ad alta priorità in genere dovrebbero comportare l'interazione dell'utente con la tua app o le sue notifiche. Se FCM rileva uno schema in cui non lo fanno, i tuoi messaggi potrebbero non essere prioritari. Android P ha introdotto i bucket di standby delle app che limitano il numero di messaggi FCM ad alta priorità che puoi inviare alla tua app senza che l'utente utilizzi la tua app o visualizzi una notifica. Se, in risposta a un messaggio ad alta priorità, viene visualizzata una notifica in modo visibile all'utente, la quota del bucket di standby dell'app non verrà consumata da quel messaggio.

    Poiché una piccola parte della popolazione mobile Android si trova su reti ad alta latenza, evitare di aprire una connessione ai server prima di visualizzare una notifica. Richiamare il server prima della fine del tempo di elaborazione consentito può essere rischioso per gli utenti su reti ad alta latenza. Includere invece il contenuto della notifica nel messaggio FCM e visualizzarlo immediatamente. Se è necessario eseguire la sincronizzazione per ulteriori contenuti in-app su Android, è possibile pianificare un'attività con WorkManager per gestirla in background.

Di seguito è riportato un esempio di un normale messaggio prioritario inviato tramite il protocollo FCM HTTP v1 per notificare a un abbonato a una rivista che è disponibile un nuovo contenuto 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:

Impostazione della durata di un messaggio

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

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

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

Di seguito sono riportati alcuni possibili utilizzi di questa funzione:

  • Chiamate in arrivo tramite chat video
  • Eventi di invito in scadenza
  • Eventi del calendario

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

Ecco un esempio di una richiesta che include TTL:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    },
    "apns":{
      "headers":{
        "apns-expiration":"1604750400"
      }
    },
    "android":{
      "ttl":"4500s"
    },
    "webpush":{
      "headers":{
        "TTL":"4500"
      }
    }
  }
}

Ricezione di messaggi da più mittenti

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

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

Assicurati di non aggiungere più ID mittente a una singola richiesta di token, poiché ciò può avere risultati imprevedibili. Effettua ogni chiamata separatamente, una volta per ID mittente.

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

Tieni presente che esiste un limite di 100 mittenti multipli.

Durata di un messaggio

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

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

Se il dispositivo è connesso ma in Doze, un messaggio a bassa priorità viene memorizzato da FCM finché il dispositivo non è fuori da Doze. Ed è qui che il flag collapse_key gioca un ruolo: se c'è già un messaggio con la stessa chiave di compressione (e token di registrazione) memorizzato e in attesa di consegna, il vecchio messaggio viene scartato e il nuovo messaggio prende il suo posto (cioè il vecchio il messaggio viene compresso dal nuovo). Tuttavia, se la chiave di compressione non è impostata, i messaggi nuovi e vecchi vengono archiviati per la consegna futura.

Se il dispositivo non è connesso a FCM, il messaggio viene memorizzato fino a quando non viene stabilita una connessione (sempre rispettando le regole della chiave di compressione). Quando viene stabilita una connessione, FCM consegna tutti i messaggi in sospeso al dispositivo. Se il dispositivo non viene mai più connesso (ad esempio, se è stato ripristinato in fabbrica), il messaggio alla fine scade e viene scartato dalla memoria 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 avere maggiori informazioni sulla consegna dei messaggi su Android o iOS, consulta la dashboard dei rapporti FCM , che registra il numero di messaggi inviati e aperti su dispositivi iOS e Android, insieme ai dati per le "impressioni" (notifiche visualizzate dagli utenti) per Android app.

Per i dispositivi Android con messaggistica del canale diretta abilitata, se il dispositivo non è 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 inviatogli, il client riceve la richiamata 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 immediatamente il messaggio e invalida il token di registrazione. Tentativi futuri di inviare un messaggio a quel dispositivo NotRegistered un errore NotRegistered .

Limitazione e ridimensionamento

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

Limitazione del messaggio comprimibile

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

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

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

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

Limitazione del server XMPP

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

Per ogni progetto, FCM consente 2500 connessioni in parallelo.

Velocità massima dei messaggi su un singolo dispositivo

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

Limite di messaggi a monte

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

Limitiamo i messaggi upstream per dispositivo a 1.000 / minuto per proteggere dal consumo della batteria da comportamenti scorretti delle app.

Limite messaggio argomento

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

Per le tariffe di invio dei messaggi, vedere Fanout Throttling .

Fanout throttling

Il fanout dei messaggi è il processo di invio di un messaggio a più dispositivi, ad esempio quando si targetizzano argomenti e gruppi o quando si utilizza il compositore di notifiche per indirizzare gli utenti o i segmenti di utenti.

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

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

Porte FCM e firewall

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

Per le connessioni in uscita, FCM non fornisce IP specifici perché il nostro intervallo IP cambia troppo frequentemente e le regole del firewall potrebbero diventare obsolete e influire sull'esperienza degli utenti. Idealmente, inserirai le porte 5228-5230 nella whitelist senza restrizioni IP. Tuttavia, se è necessario disporre di una restrizione IP, è necessario inserire nella whitelist tutti gli indirizzi IP nei blocchi IPv4 e IPv6 elencati nell'ASN di Google 15169 . Questo è un lungo elenco e dovresti pianificare di aggiornare le tue regole mensilmente. I problemi causati dalle restrizioni IP del firewall sono spesso intermittenti e difficili da diagnosticare.

Porte da aprire per i messaggi in arrivo:

  • 5228
  • 5229
  • 5230
  • 443

Porte per consentire le connessioni in uscita:

Uno di questi (è preferibile l'opzione n. 1):

  1. Nessuna restrizione IP
  2. Tutti gli indirizzi IP contenuti nei blocchi IP elencati nell'ASN di Google del 15169 . Non dimenticare di aggiornarlo almeno una volta al mese.

Firewall di traduzione degli indirizzi di rete e / o Stateful Packet Inspection:

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

Credenziali

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

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

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

identità del mittente Un valore numerico univoco creato quando crei il tuo progetto Firebase, disponibile nella scheda Messaggistica cloud del riquadro Impostazioni della console Firebase. 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)

Una chiave del server che autorizza il server della tua app ad accedere ai servizi Google, incluso l'invio di messaggi tramite i protocolli legacy di Firebase Cloud Messaging. Ottieni la chiave del server quando crei il tuo progetto Firebase. Puoi visualizzarlo nella scheda Cloud Messaging del riquadro Impostazioni della console Firebase.

Importante: non includere la chiave del server in alcun punto del codice client. Inoltre, assicurati di utilizzare solo le chiavi del server per autorizzare il server delle app. Le chiavi Android, iOS e browser vengono rifiutate da FCM.