När vi dyker in i utveckling med Jetpack Compose är det normalt att bli lite förvånad till en början av tanken att komponerbara funktioner kan köras flera gånger och i valfri ordning. I grund och botten är det som att gå på lava att ange en komponerbar funktion : du kan inte bara köra vilken kod som helst där, för om du gör det kan du hamna i att starta tio Toasts i rad eller utlösa analyshändelser varje gång skärmen flimrar.
För att undvika detta kaos erbjuder Compose vad som kallas sidoeffekter. Det är kontrollerade och säkra miljöer där vi kan placera logik som inte är relaterad till att rita gränssnittet, vilket säkerställer att koden körs exakt när vi vill att den ska göra det och inte när ramverket bestämmer sig för att komponera om elementet.
Mastering LaunchedEffect för asynkrona uppgifter
Om du behöver starta en korutin som lever så länge ditt element visas på skärmen är LaunchedEffect din bästa vän . Den här funktionen startar ett pausat kodblock så snart det komponerbara elementet kommer in i kompositionen och, viktigast av allt, avbryter automatiskt den uppgiften om elementet försvinner ur sikte.
En viktig detalj är de nycklar vi skickar. Om värdet på en nyckel ändras avbryts effekten och startas om från början . Detta är utmärkt för animationer som är beroende av en variabel eller för att ladda data från ett API när användar-ID:t ändras. Men om du vill att något bara ska köras en gång under komponentens livstid kan du skicka `Unit` eller `true` som en parameter.
Ibland behöver vi köra en suspend-funktion, men vi är inte inuti kompositionen; istället har vi att göra med en användarhändelse, till exempel ett knappklick . I dessa fall kan vi inte använda `LaunchedEffect`. Lösningen är `rememberCoroutineScope` , vilket ger oss ett scope kopplat till kompositionens livscykel men som vi kan utlösa manuellt med `scope.launch`.
Undvik onödiga omstarter med rememberUpdatedState
Det finns knepiga situationer där vi har en långvarig effekt och vi inte vill att den ska starta om även om vissa variabler ändras. Det är här rememberUpdatedState kommer in i bilden. Det här verktyget låter oss hämta den senaste versionen av en lambda-funktion eller ett lambda-värde utan att LaunchedEffect startar om nedräkningen eller processen.
Detta är särskilt användbart vid laddningsskärmar eller välkomstskärmar. Tänk dig att du har en timer som behöver meddela dig när tiden är ute; om återuppringningsfunktionen ändras medan timern körs behöver du inte längre återställa fördröjningen , du vill helt enkelt att den senaste versionen av den funktionen ska köras när den är klar.
Synkronisering och rensning: SideEffect och DisposableEffect
Det handlar inte bara om koroutiner. Ibland behöver vi bara Compose för att informera ett externt bibliotek om att något har ändrats. SideEffect körs efter varje lyckad omkomposition . Det är det perfekta verktyget för att synkronisera UI-tillstånd med objekt som inte hanteras av Compose, till exempel att uppdatera en användaregenskap i en Firebase-analystjänst.
Å andra sidan lämnar vissa effekter spår och måste rensas för att förhindra minnesläckor. För detta använder vi DisposableEffect . Till skillnad från dess motsvarigheter kräver denna att vi inkluderar ett onDispose- block i slutet. Detta är den perfekta platsen för att avregistrera livscykelobservatörer eller förhindra minnesläckor när man stänger prenumerationer på enhetssensorer.
- Enkel synkronisering: SideEffect för att uppdatera externa tillstånd.
- Resurshantering: DisposableEffect för att undvika minnesläckor.
- Dataflöden: snapshotFlow för att konvertera Compose-tillstånd till Kotlin-flöden.
Tillståndsoptimering med derivedStateOf och produceState
När vi har ett ständigt föränderligt tillstånd, som till exempel en listas rullningsposition, kan vi få överdrivna omkompositioner som försämrar prestandan. För att lösa detta är derivedStateOf lösningen . Det skapar ett härlett tillstånd som bara utlöser omkomposition när slutresultatet ändras, och fungerar på samma sätt som ett "distinct until change"-filter.
Det är ett vanligt misstag att använda den för att sammanfoga två enkla strängar; i så fall är det ett onödigt slöseri med resurser. Du bör reservera den för tröskelbaserade beräkningar , som att visa en "tillbaka till toppen"-knapp endast när du effektivt hanterar listor med LazyColumn och indexet för det första synliga elementet är större än noll.
För de som kommer från LiveData eller Flow och vill konvertera den datan till något som Compose förstår, är produceState rätt väg att gå . Den startar en coroutine som kan ge värden till ett State-objekt. I huvudsak omsluter den datahämtningslogiken och exponerar den som ett reaktivt tillstånd som användargränssnittet enkelt kan observera.
Om du arbetar med dataflöden i ViewModel-lagret är den nuvarande rekommendationen att använda `collectAsStateWithLifecycle` . Den här funktionen är överlägsen grundläggande datainsamling eftersom den är medveten om Android-livscykeln, stoppar insamlingen när appen är i bakgrunden och intelligent sparar batteri och minne .
Att ha fullständig kontroll över biverkningar innebär att veta hur man väljer rätt verktyg för varje uppgift, oavsett om det handlar om att inkapsla tillstånd i containerklasser för att underlätta testning eller använda anpassade sparade funktioner med rememberSaveable för att förhindra dataförlust när enheten roteras. I slutändan handlar det om att upprätthålla ett enkelriktat dataflöde och säkerställa att affärslogiken inte stör gränssnittets renderingsprocessen.
