Hvis du er begyndt at udforske Android-verdenen, har du helt sikkert stødt på det evige dilemma med, hvordan man håndterer data i præsentationslaget. I lang tid var LiveData den ultimative værktøjslinje, men med Kotlin-rutinernes ankomst er der dukket langt mere kraftfulde og fleksible værktøjer op. Vi taler om StateFlow og SharedFlow , som i bund og grund er den naturlige udvikling til at håndtere datastrømme reaktivt og effektivt.
Sandheden er, at selvom de i starten kan virke som lignende koncepter, har hver især sit eget formål. At ønske, at skærmen skal huske, hvor nyhedsfeedet sluttede, er ikke det samme som at ønske at sende en hurtig notifikation om en Toast, der kun skal ses én gang. For at undgå forvirring, lad os gennemgå, hvordan disse hot streams fungerer , og hvorfor du bør overveje at udelade LiveData i dine moderne projekter.
Flow-konceptet: Koldt eller varmt?
For at forstå StateFlow og SharedFlow skal du først forstå forskellen på et koldt og et varmt flow. Et standardflow er koldt , hvilket betyder, at det er som en opskrift: intet sker, før nogen beslutter sig for at udføre det (kald `collect`). Problemet er, at hvis du har tre abonnenter, udføres producentens kode tre gange, hvilket kan dræne batteriet eller foretage overflødige API-anmodninger.
Det er her, hvor "hot streams" kommer ind i billedet. Både StateFlow og SharedFlow er strategisk "hot" , hvilket betyder, at producenten forbliver aktiv, uanset om nogen lytter. Dette giver flere indsamlere mulighed for at dele den samme datakilde , hvilket forhindrer appen i at udføre det samme arbejde gentagne gange – afgørende for at opretholde systemets fluiditet.
StateFlow: Den ideelle erstatning for LiveData
StateFlow er i bund og grund en tilstandscontainer. Dens primære funktion er, at den altid opretholder en aktuel værdi , som kan forespørges synkront ved hjælp af .value-egenskaben. Det er det perfekte værktøj til at administrere brugergrænsefladen, f.eks. om en skærm indlæses, eller om profildata er blevet opdateret.
I modsætning til LiveData kræver StateFlow en startværdi i sin konstruktør, hvilket eliminerer usikkerheden ved at have null-tilstande ved opstart. Derudover implementerer den sammenføjnings- og deduplikeringsadfærd : hvis du udsender den samme værdi to gange i træk, ignorerer flowet den simpelthen. Dette er fantastisk til at forhindre brugergrænsefladen i at opdateres unødvendigt, når dataene faktisk ikke er ændret.
For at implementere dette i en ViewModel er den bedste fremgangsmåde at bruge en privat MutableStateFlow fallback-egenskab og eksponere den som en uforanderlig StateFlow. Dette sikrer, at kun ViewModel kan ændre tilstanden, respekterer den ensrettede datastrøm og forhindrer visningen i at manipulere dataene.
SharedFlow: Begivenhedsbussen til unikke handlinger
Hvis StateFlow er til "state", er SharedFlow til "events". Forestil dig, at du vil vise en fejldialog eller navigere til en anden skærm. Hvis du bruger StateFlow, vil rotation af enheden få den nye indsamler til at modtage den sidste værdi, og hændelsen vil udløses igen – en alvorlig fejl. SharedFlow løser dette, fordi det kan konfigureres med en genafspilningsværdi på nul.
Dette flow er meget mere fleksibelt og giver os mulighed for at justere parametre som f.eks. overflow-bufferen . Hvis bufferen fyldes op, kan vi vælge at suspendere afsenderen eller kassere den ældste eller nyeste værdi. En vigtig fordel er, at SharedFlow giver dig mulighed for at sende gentagne værdier ; hvis du har brug for at sende den samme "Forbindelsesfejl"-meddelelse tre gange, vil SharedFlow gøre det uden tøven, hvorimod StateFlow filtrerer dem fra.
Teknisk sammenligning: StateFlow vs. SharedFlow vs. LiveData
For at undgå forvirring i et teknisk interview eller når du designer din arkitektur, er det vigtigt at overveje de kritiske punkter. LiveData er simpelt og styrer livscyklussen automatisk , men det er meget knyttet til Android. StateFlow og SharedFlow, som er en del af Kotlin Coroutines, er platformuafhængige , hvilket i høj grad forenkler enhedstestning og oprettelsen af rene domænelag.
- StateFlow: Tvinger en startværdi frem, har .value, deduplikerer værdier og er ideel til brugergrænsefladetilstande.
- Delt flowDen kræver ikke en startværdi, kan konfigureres med hensyn til afspilning og er den rigtige mulighed for flygtige begivenheder.
- LiveDataDen kræver ikke en startværdi, den er opmærksom på livscyklussen, men mindre kraftfuld i asynkrone transformationer.
Vigtigheden af sikker høst
En meget almindelig fejl er at udføre en `collect` inden for et simpelt coroutine-scope i aktiviteten. Dette er farligt, fordi flowet vil fortsætte med at behandle data, selv når appen er i baggrunden , hvilket kan forårsage nedbrud eller overdreven CPU-forbrug. Den moderne løsning er at bruge `repeatOnLifecycle(Lifecycle.State.STARTED)` API'en.
Denne funktion aktiverer indsamlingen, når visningen er synlig, og annullerer automatisk, når den når tilstanden STOPPET . For Jetpack Compose anbefales det at bruge `collectAsStateWithLifecycle()` , som integrerer denne logik nativt og sikrer, at applikationen er effektiv med enhedsressourcer.
Omdannelse af kolde strømme til varme
Nogle gange har vi et flow, der kommer fra en database (som Room) eller et repository, og det er koldt. For at gøre det varmt bruger vi operatorerne `stateIn` eller `shareIn` . Disse operatorer kræver et `CoroutineScope` og en opstartsstrategi. Den mest almindelige er `SharingStarted.WhileSubscribed(5000)`.
Denne konfiguration er genial, fordi den holder streamen aktiv, så længe der er abonnenter, og hvis skærmen er lukket, venter den 5 sekunder, før den stopper streamen. Dette er afgørende, så streamen ikke ødelægges og genskabes under en skærmrotation , og dermed undgås unødvendige anmodninger til serveren eller den lokale database.
At mestre disse værktøjer indebærer forståelse af, at tilstanden skal være persistent og dedupliceret ved hjælp af StateFlow, mens engangshandlinger skal flyde gennem SharedFlow. Ved at kombinere dette med livscyklusbevidsthed og koldflowtransformation ved hjælp af stateIn opnår vi en robust, fuldt reaktiv Android-arkitektur, der er optimeret til ydeevne i den virkelige verden på mobile enheder. Del denne vejledning og hjælp andre med at lære om dette emne.
