Når vi dykker ned i udvikling med Jetpack Compose , er det normalt at blive lidt overrasket i starten over tanken om, at komponerbare funktioner kan udføres flere gange og i en hvilken som helst rækkefølge. Grundlæggende set er det at indtaste en komponerbar funktion som at gå på lava : du kan ikke bare køre hvilken som helst kode derinde, for hvis du gør det, kan du ende med at starte ti Toasts i træk eller udløse analysehændelser, hver gang skærmen flimrer.
For at undgå dette kaos tilbyder Compose det, der kaldes sideeffekter. Disse er kontrollerede og sikre miljøer , hvor vi kan placere logik, der ikke er relateret til tegningen af grænsefladen, og dermed sikre, at koden udføres præcis, når vi ønsker det, og ikke når frameworket beslutter at omkomponere elementet.
Mastering af LaunchedEffect til asynkrone opgaver
Hvis du har brug for at starte en coroutine, der lever så længe dit element er på skærmen, er LaunchedEffect din bedste ven . Denne funktion starter en suspenderet kodeblok, så snart det komponerbare element kommer ind i kompositionen, og vigtigst af alt annullerer den automatisk opgaven, hvis elementet forsvinder fra visningen.
En vigtig detalje er de nøgler, vi sender. Hvis værdien af en nøgle ændres, annulleres effekten og genstartes fra bunden . Dette er fantastisk til animationer, der afhænger af en variabel , eller til at indlæse data fra en API, når bruger-ID'et ændres. Men hvis du vil have, at noget kun kører én gang i løbet af komponentens levetid, kan du sende `Unit` eller `true` som en parameter.
Nogle gange har vi brug for at udføre en suspenderingsfunktion, men vi er ikke inde i kompositionen; i stedet har vi at gøre med en brugerhændelse, såsom et klik på en knap . I disse tilfælde kan vi ikke bruge `LaunchedEffect`. Løsningen er `rememberCoroutineScope` , som giver os et scope, der er knyttet til kompositionens livscyklus, men som vi kan udløse manuelt ved hjælp af `scope.launch`.
Undgå unødvendige genstarter med rememberUpdatedState
Der er vanskelige situationer, hvor vi har en langvarig effekt, og vi ikke ønsker, at den genstarter, selvom nogle variabler ændrer sig. Det er her, rememberUpdatedState kommer ind i billedet. Dette værktøj giver os mulighed for at registrere den seneste version af en lambda-funktion eller -værdi uden at LaunchedEffect genstarter nedtællingen eller processen.
Dette er især nyttigt i indlæsningsskærme eller splash-skærme. Forestil dig, at du har en timer, der skal give dig besked, når tiden er gået. Hvis callback-funktionen ændres, mens timeren kører, behøver du ikke længere at nulstille forsinkelsen . Du ønsker blot, at den seneste version af funktionen skal udføres, når den er færdig.
Synkronisering og oprydning: SideEffect og DisposableEffect
Det handler ikke kun om korutiner. Nogle gange har vi bare brug for, at Compose fortæller et eksternt bibliotek, at noget er ændret. SideEffect kører efter hver vellykket rekomposition . Det er det perfekte værktøj til at synkronisere brugergrænsefladen med objekter, der ikke administreres af Compose, f.eks. opdatering af en brugeregenskab i en Firebase-analysetjeneste.
På den anden side efterlader nogle effekter et spor og skal ryddes for at forhindre hukommelseslækager. Til dette bruger vi DisposableEffect . I modsætning til sine modstykker kræver denne, at vi inkluderer en onDispose- blok til sidst. Dette er det ideelle sted at afregistrere livscyklusobservatører eller forhindre hukommelseslækager, når man lukker enhedssensorabonnementer.
- Simpel synkronisering: SideEffect til at opdatere eksterne tilstande.
- Ressourcestyring: DisposableEffect for at undgå hukommelseslækager.
- Datastrømme: snapshotFlow til at konvertere Compose-tilstande til Kotlin-flows.
Tilstandsoptimering med derivedStateOf og produceState
Når vi har en konstant skiftende tilstand, såsom rullepositionen på en liste, kan vi ende med overdreven omkomponering, der dræber ydeevnen. For at løse dette er derivedStateOf løsningen . Det opretter en afledt tilstand, der kun udløser omkomponering, når det endelige resultat ændres, og fungerer på samme måde som et "distinct until change"-filter.
Det er en almindelig fejl at bruge den til at sammenkæde to simple strenge; i så fald er det et unødvendigt spild af ressourcer. Du bør reservere den til tærskelbaserede beregninger , såsom at vise en "tilbage til toppen"-knap kun når du effektivt administrerer lister med LazyColumn , og indekset for det første synlige element er større end nul.
For dem, der kommer fra LiveData eller Flow og ønsker at konvertere disse data til noget, Compose forstår, er produceState vejen frem . Det starter en coroutine, der kan udsende værdier til et State-objekt. I bund og grund indpakker det datahentningslogikken og eksponerer den som en reaktiv tilstand, som brugergrænsefladen nemt kan observere.
Hvis du arbejder med dataflows i ViewModel-laget, anbefales det at bruge `collectAsStateWithLifecycle` . Denne funktion er bedre end grundlæggende dataindsamling, fordi den er opmærksom på Android-livscyklussen, stopper indsamlingen, når appen er i baggrunden, og sparer batteri og hukommelse på en intelligent måde .
At have fuld kontrol over bivirkninger betyder at vide, hvordan man vælger det rigtige værktøj til hver opgave, uanset om det er at indkapsle tilstand i containerklasser for at lette testning eller bruge brugerdefinerede Saves med rememberSaveable for at forhindre datatab, når enheden roteres. I sidste ende handler det om at opretholde en ensrettet datastrøm og sikre, at forretningslogik ikke forstyrrer grænsefladen, der gengiver den.
