Firebase Cloud Messaging (FCM) Det er Googles tjeneste for å sende varsler og meldinger mellom servere og apper på Android, iOS og nettet. Tillater levering av synlige varsler og datameldinger gratis, med beregninger og segmentering når du bruker Firebase-konsollen, og med maksimal fleksibilitet ved integrering med HTTP v1 API eller Admin SDK.
Hvis du leter etter hva FCM er, hvordan det fungerer, hvilke typer meldinger det støtter, leveringsalternativer, kvoter, porter, sikkerhet, begrensninger og reelle alternativer (SNS, WebSocket/SSE, proprietære løsninger eller flerkanalsplattformer som EngageLab), her er en komplett guide med alt det viktigste å bestemme, implementere og operere i stor skala.
Hva er Firebase Cloud Messaging (FCM)?
FCM er Googles offisielle meldingsløsning på tvers av plattformer. integrert i Firebase. Den erstattet Google Cloud Messaging (GCM) og lar deg sende push-varsler og datameldinger til individuelle enheter, grupper eller abonnenter på et emne, enten fra din egen server, Cloud Functions eller Firebase-konsollen.
Den store attraksjonen er at det er gratis. på Firebase-abonnementer, noe som gjør det til det vanlige alternativet på inngangsnivå for mobil- og nettprosjekter. Den tilbyr også A/B-testing og segmentering. når du bruker varslingsredigereren.
Hvordan FCM fungerer
En typisk FCM-implementering har to deleret klarert miljø (for eksempel en backend-server eller Cloud Functions) som autentiserer, komponerer og sender meldingene; og en klientapp (Android, iOS eller nett) som mottar og behandler disse meldingene gjennom transporten av hver plattform.
Å sende, kan du bruke Admin SDK fra Firebase eller HTTP API v1For markedsføring, testing eller ad hoc-kommunikasjonsoppgaver, konsollen lar deg lage kampanjer med integrert segmentering og analyse.
Klientappen registrerer et enhetstoken og, der det er aktuelt, abonner på emnerBackend-systemet sender meldinger ved hjelp av det tokenet, en gruppe tokens eller et emne, og FCM. rute og levering i henhold til prioriteringsregler, tilgjengelighet og leveringsalternativer.
Meldingstyper i FCM
FCM forvalter to store familier av meldinger som du kan kombinere i henhold til din sak:
- Varslingsmeldingervises av SDK-en (hvis appen er i bakgrunnen) og eksponeres forhåndsdefinerte nøkler synlig for brukeren, med mulighet for å legge ved data.
- Datameldinger: inneholde tilpassede nøkkelverdipar under nøkkelen
datay appen din behandler dem alltid, i forgrunnen eller bakgrunnen.
Maksimal nyttelast er vanligvis 4096 byte., med mer restriktive grenser hvis du bruker konsollen. Hvis du ønsker absolutt kontroll over atferd, bruk datameldinger. Hvis du foretrekker at systemet viser varslingen når appen er i bakgrunnen, bruk varslingsmeldinger.
Varslingsmeldinger
Ideell for synlige annonser, kampanjer eller reengasjementI bakgrunnen viser systemet tittelen og brødteksten som er definert i notificationI forgrunnen, koden din bestemmer hva man skal gjøre når man mottar et varsel.
Du kan sende dem uten programmering ved hjelp av konsollen (segmentering, A/B-testing, planlegging), eller programmatisk med Admin SDK/API v1 som indikerer notification.title y notification.body, Og eventuelt mye data Tilleggs.
Datameldinger
De brukes til å få appen din til å gjøre akkurat det du trenger.I innsendingen plasserer du nøkkelverdi-parene under data y du unngår reserverte ord som for eksempel «fra», «varsel», «meldingstype» eller et hvilket som helst nøkkelord som starter med «google» eller «gcm».
PÃ¥ hver plattform vil du motta nyttelasten i en tilbakeringing. og du kan bestemme om du vil vise ditt eget varsel, synkronisere data, navigere til en bestemt skjerm osv.
SikkerhetslagetAndroid-transportbruk ende-til-ende-krypteringHvis saken din krever det end-to-end-kryptering, må du implementere det selv (det finnes tredjepartsløsninger som Capillary eller DTLS).
Varsler med valgfrie data
Kombiner varsling + data Det er veldig vanlig: FCM viser den synlige delen og appen din behandler dataeneI bakgrunnen ser brukeren varselet, og når appen trykker på det, leser den nyttelasten. dataI forgrunnen, du mottar begge lastene og du bestemmer flyten.
Bruk denne teknikken for dyplenker, kampanjesporing eller overføring av parametere til skjermen du åpner etter klikket. Prøv å holde sammenheng mellom det synlige budskapet og handlingen som du utfører neste gang.
Personalisering etter plattform
HTTP v1 API og Admin SDK lar deg definere vanlige og spesifikke felt. etter plattform: AndroidConfig, ApnsConfig, WebpushConfig. Så kan finjuster TTL, prioritet, overskrifter og oppførsel i hvert system.
Når man skal bruke vanlige felt: når du skyter på alle plattformene samtidig, eller temas. Når man skal bruke spesifikke: når du trenger leveringsmuligheter eller bestemte handlinger etter plattform (for eksempel click_action på Android og category hos Apple).
viktig detaljSelv om du ønsker samme verdi (f.eks. TTL) på flere plattformer, deklarer det i hver blokk fordi hver enkelt tolker det forskjellig (sekunder på Android vs. utløpsdato på APN-er).
Leveringsalternativer og atferdskontroll
FCM tilbyr kontroller for å justere ytelse, synlighet og forbruk: sammenleggbare meldinger, prioritet, levetider osv. Velg disse parameterne nøye. påvirker batteriet og brukeropplevelsen.
Skjulbare kontra ikke-skjulbare meldinger
Ikke-sammenleggbar– Hver melding teller og må leveres (f.eks. kritiske samtaler). På Android finnes det en grense på 100 meldinger i køen uten å kollapse; hvis den overskrider, blir de forkastet og klienten mottar påSlettedeMeldinger() slik at du kan synkronisere.
SammenleggbarHvis en ny nøkkel kommer med samme nøkkel før den forrige er levert, erstatter den forrigeNyttig for å oppdatere status (sportsresultater, merker, synkroniseringer). Bruk collapse_key på Android, apns-collapse-id hos Apple og Topic i Web/JS. FCM kan inneholde opptil 4 skjulte taster per token om gangen.
Meldingsprioritet
Normal: leveres i tide, og er i stand til å forsinkelse i bakgrunnenPasser for UI-synkronisering, nye e-poster eller innhold som ikke haster.
HøyFCM prøver å gi det fra seg umiddelbart, selv i hvilemodus. Reserver denne prioriteten for tidssensitivt innhold og synlig. Hos Apple, data må ha prioritet 5 (normal); sending av høye nivåer kan returnere INVALID_ARGUMENT.
Tid til å leve (TTL)
TTL begrenser hvor lenge FCM beholder meldingen hvis enheten ikke er tilgjengelig. På Android og Web kan du angi mellom 0 og 2.419.200 sekunder (28 dager). Med TTL 0 Det er ingen lagringsplass: enten kommer den nå, eller så blir den kastet og tilbyr lavest mulig latens i «nå eller aldri»-varsler.
Etuier som ikke er egnet for FCM
Ikke bruk FCM i nødstilfeller eller systemer med høy risiko. (livredning, flygekontroll osv.). API-ene leveres «som de er» og er ikke utformet for å garantere det servicenivået.
Faktisk leveringstid og statuser
Det at du mottar en meldings-ID betyr ikke at den allerede er på enheten., bare at FCM aksepterte det. Deretter avhenger det av tilkobling, hvilemodus, prioritet og kollaps før det når brukeren.
Hvis enheten er frakobletFCM lagrer meldingen, med respekt for TTL- og skjermingsnøklene. Ved ny tilkobling leverer den ventende meldinger. Hvis appen er avinstallert, FCM forkaster det som er igjen og ugyldiggjør tokenet; påfølgende innsendinger vil returneres NotRegistered.
Bestillingen er ikke garantert: FCM garanterer ikke ankomstsekvensenProgrammer appen din til å tolerere endring av rekkefølge og inkonsistente tilstander, noe som tvinger frem en full synkronisering før tegn som f.eks. onDeletedMessages().
Regulering (struping) og kvoter
For å beskytte plattformen og brukerens batteri, det finnes kvoter og grenser. Med HTTP v1 API er standardkvoten 600.000 XNUMX meldinger/minutt per prosjektHvis du overvinner det, vil du se HTTP 429 til neste minutt er gjenopprettet.
- Hva som teller: kvotetiltakene innlegg, ikke forespørsler; 4xx-feil teller også (unntatt 429). Kvote minutter de stemmer ikke overens nøyaktig med klokken, og GCP-grafikken er heller ikke justert på millimeteren.
- KvoteøkningerBe om skyss hvis du vanligvis er på ≥ 80% i minst 5 minutter/dag, med <5 % kundefeil og følge god praksis. For store topper (f.eks. >18 millioner meldinger/min), vennligst be om med 30 dager på forhånd.
- Distribusjonerer begrenset til 1.000 samtidige per prosjekt (kampanjer for emner, grupper eller segmenter). Den optimale tilnærmingen er én aktiv distribusjon om gangen for å maksimere hastigheten.
- Emneabonnementer: 3.000 QPS per prosjekt for tillegg/sletting.
- Sammenleggbar: toppbegrensning til 20 meldinger per app og enhet, med erstatning av 1 hvert 3. minutt.
- Pris per enhet (Android): før 240/min og 5.000/t til samme enhet. Ikke arbeid nær toppen: sløser med batteri og kan anses som voldelig.
Porter og brannmur kreves av FCM
Hvis du bruker en bedriftsbrannmur, må du tillate utgående mot FCM for at enheter skal kunne motta meldinger. Portene som skal åpnes er 5228, 5229, 5230 og 443.
Liste over anbefalte verter, inkluderer mtalk.google.com og varianter (alt1-alt8), samt verter som android.apis.google.com, enhetsklargjøring.googleapis.com y firebaseinstallations.googleapis.comDet er best å tillate dem per domene hvis nettverksutstyret ditt støtter det.
NAT/SPI: sette opp en timeout ≥30 minutter for 5228–5230-tilkoblinger, og opprettholder tilkoblingen uten å tappe batteriet med hyppige gjenoppkoblinger.
VPN-er og muligheten til å omgå dem
Noen VPN-er gjør det vanskelig å holde kontakten vedvarende og skjule signaler som FCM bruker for å optimalisere levering og forbruk. Hvis VPN-et tillater det, FCM kan hoppe over det ved hjelp av en direkte kryptert tilkobling (Wi-Fi/LTE), noe som forbedrer påliteligheten og batterilevetiden.
Når VPN ikke kan omgås, FCM vil bruke VPN-ruten, med mulig leveringsforsinkelser og høyere kostnader for gjenoppkoblinger. Sjekk VPN-dokumentasjonen din for å aktivere bypass på push-kanalen hvis mulig.
Legitimasjon og data du trenger
Å sende med HTTP v1 du trenger: Prosjekt-ID, kortvarig OAuth 2.0-tilgangstoken assosiert med en tjenestekonto, Og registreringstokener av målenhetene. Hvis du bruker eldre (foreldede) protokoller, vil servernøkkel, men det er ikke lenger den anbefalte ruten.
Avsender-ID-en identifiserer avsenderen som kan sende til appen din, og forblir synlig i Cloud Messaging-fanen i konsollen. Beskytt tokenene: er hemmeligheter som identifiserer appforekomster.
Implementeringsrute og god praksis
- Konfigurer SDK-enIntegrer Firebase og FCM i appen din i henhold til plattformens retningslinjer. Sørg for at be om tillatelse der det er aktuelt (nett/iOS) og administrere registreringstoken (rotasjon, fornyelse).
- Utvikle klientappenhåndterer tilbakeringinger av meldinger, emneabonnementer, dyplenker, forgrunnsvarsler og utholdenhet hvis du trenger å vise frem historikk.
- Utvikle serveren: bestem deg for om du vil bruke Admin SDK o HTTP v1, redskaper Autentisering, komposisjon, sendekøer og svarparsing (inkludert feil for tokenopprydding). Bruk i oppstrømsmeldingsscenarier XMPP (ikke egnet for Cloud Functions på grunn av den vedvarende tilkoblingen; du trenger din egen backend).
- Prøv med konsollenUnder utviklingen gjør Notification Composer det enkelt testmeldinger, segmentering og A/B-testing uten å skrive kode.
Casestudier: Xamarin.Android og XenMobile
Xamarin.AndroidDet finnes trinnvise veiledninger for legg til FCM og eksterne varsler, registrer budtjenesten, klargjør manifestere, administrere tokener og verifisere flyt med innsendinger fra konsollen. Det er en tydelig referanse for å se hele pipelinen.
XenMobile (Citrix)FCM anbefales for tvinge frem gjentilkoblinger av Android-enheter som svar på sikkerhetshandlinger eller implementeringer. Krever Nåværende sikker knutepunkt, Google Play Tjenester og konfigurer brannmur (443/5228-5230). Du kan bruke det gamle API-et frem til du migrerer, men migrering til HTTP v1 innebærer å bruke en JSON for tjenestekontoXenMobile-konsollen lar deg laste opp den filen og test med handlinger som selektiv sletting.
Fordeler, reelle begrensninger og driftskostnader
Advantagegratis, pålitelig, lavt forbruk Når den er riktig konfigurert, er den kompatibel med Android/iOS/Web og med markedsføringsverktøy (A/B, segmentering) fra konsollen.
begrensningerBegrenset kanalstøtte (Android/APN-er/nett) og uten produsentkanaler mye brukt i Asia (Huawei, OPPO, Vivo, etc.), mulig innvirkning på hastighet/levering i disse markedene, fravær av bedriftsfunksjoner standard (frekvenskontroll, avansert målretting, komplekse flerspråklige maler), avansert sikkerhet (granulær RBAC, IP-begrensning) og dedikert støtte (støttet av dokumenter og forum).
Skjulte kostnaderFor seriøse storskalakampanjer ender mange selskaper opp med å investere i tilpasset utvikling (segmentering, analyser, driftsmessige dashbord, kanalreserve, tidssoneoptimalisering), noe som øker kompleksiteten til vedlikehold og skalering.
Alternativer til FCM og når man skal velge hvert av dem
WebSocket/SSEde bidrar toveis sanntidskommunikasjon (eller enveiskjøring i SSE) ideell for chatter eller samarbeid der det er nødvendig umiddelbar synkroniseringDe krever mer kompleks backend og klient. For klassiske push-varsler med appen i bakgrunnen, FCM er vanligvis bedre.
Amazon SNSAWS-tjeneste med flerkanals (push, SMS, e-post, HTTP/HTTPS), integrasjon med CloudWatch og bedriftsfunksjoner (segmentering, sikkerhet). Betal per volumHvis du allerede bruker AWS og trenger omnikanalorkestrering, kan gi deg mer verdi i stor skala.
Egne systemermaksimal kontroll og tilpasning til unike krav, men med høye byggekostnader (6–12 måneder) og vedlikehold. Du må mestre push-protokoller (FCM/APN-er/produsentkanaler), køer, leveringsalgoritmer, analyse og sikkerhet.
EngageLab: kundeengasjementsplattform med flerkanals levering (FCM, APN-er og kanaler fra produsenter som Huawei, OPPO, Vivo, Honor, Meizu) og egne kanaler. Øk leveringsraten (spesielt i Asia), tilbyr avansert segmentering, maler, optimalisering etter tidssone, ende-til-ende-analyse, visuelle redigerere, frekvenskontroll med ett klikk, testmiljøer, integrert A/B, globale datasentre y 24/7 supportPrismodell etter DAU og volum med estimatorer for å unngå overraskelser.
Migrering fra eldre API-er til HTTP v1
Googles utgåtte eldre API-er, så du bør bruke HTTP v1 med autentisering gjennom Tjenestekonto og OAuth 2.0De forandrer seg formatet på meldingene (gjenstand message med blokker per plattform), den overskrifter og responshåndtering.
Anbefalt migreringsplanklargjør testmiljø, gradvis omdirigere trafikken (du kan bruke A/B til å sammenligne målinger), overvåke feil som 429, INVALID_ARGUMENT og ugyldige tokener, og migrasjonen slutter når stabilitet og levering er likeverdig eller bedre.
Selv om FCM dekker de fleste grunnleggende meldings- og varslingsbehov uten direkte kostnader, med finjustert leveringskontroll og tydelige kvoter, er det lurt å vurdere alternativer som SNS eller flerkanalspakker som EngageLab, eller budsjettere for ytterligere utvikling for å utfylle FCMs iboende begrensninger, hvis markedet ditt inkluderer enheter med leverandørkanaler eller krever ferdige bedriftsfunksjoner.