State i Jetpack Compose

Stan w aplikacji to dowolna wartość, która może się zmieniać z czasem. To bardzo szeroka definicja, która obejmuje wszystko, od bazy danych sal po zmienną w klasie.

Wszystkie aplikacje na Androida wyświetlają stan użytkownikowi. Oto kilka przykładów stanu w aplikacjach na Androida:

  • pasek powiadomień, który wyświetla się, gdy nie można nawiązać połączenia sieciowego;
  • Post na blogu i powiązane komentarze.
  • Animacje falowania przycisków, które odtwarzają się po kliknięciu przez użytkownika.
  • Naklejki, które użytkownik może rysować na obrazie.

Jetpack Compose pomaga jasno określić, gdzie i jak przechowujesz i wykorzystujesz stan w aplikacji na Androida. Ten przewodnik skupia się na połączeniu między stanem a elementami kompozycyjnymi oraz na interfejsach API, które oferuje Jetpack Compose do łatwiejszej współpracy ze stanem.

Stan i skład

Funkcja kompozytorna jest deklaratywna, więc jedynym sposobem na jej zaktualizowanie jest wywołanie tej samej funkcji kompozytowanej z nowymi argumentami. Te argumenty są reprezentacją stanu interfejsu użytkownika. Za każdym razem, gdy stan jest aktualizowany, następuje rekompozycja. W efekcie takie elementy jak TextField nie są aktualizowane automatycznie tak jak w wymiarach XML. Funkcja kompozycyjna musi mieć jawną informację o nowym stanie, aby mogła się odpowiednio zaktualizować.

@Composable
private fun HelloContent() {
    Column(modifier = Modifier.padding(16.dp)) {
        Text(
            text = "Hello!",
            modifier = Modifier.padding(bottom = 8.dp),
            style = MaterialTheme.typography.bodyMedium
        )
        OutlinedTextField(
            value = "",
            onValueChange = { },
            label = { Text("Name") }
        )
    }
}
StateOverviewSnippets.kt

Jeśli uruchomisz ten kod i spróbujesz wpisać tekst, nic się nie stanie. Dzieje się tak, ponieważ usługa TextField nie aktualizuje się sama – robi to, gdy zmieni się parametr value. Wynika to ze sposobu, w jaki działa kompozycja i rekompozycja w funkcji Compose.

Więcej informacji o pierwotnej i ponownej kompozycji znajdziesz w artykule Kompozycja – sposób myślenia.

Stan w funkcjach kompozytywnych

Funkcje składane mogą używać interfejsu remember API do przechowywania obiektu w pamięci. Wartość obliczona przez funkcję remember jest przechowywana w Kompozycji podczas początkowej kompozycji, a przechowywana wartość jest zwracana podczas ponownego komponowania. remember można używać do przechowywania zarówno obiektów zmiennych, jak i niezmiennych.

mutableStateOf tworzy observable MutableState<T>, który jest typem observable zintegrowanym z runtimem Compose.

interface MutableState<T> : State<T> {
    override var value: T
}

Wszelkie zmiany w funkcji value powodują ponowne kompozycje wszystkich funkcji kompozycyjnych odczytywanych przez value.

Istnieją 3 sposoby deklarowania obiektu MutableState w komponowalnym:

  • val mutableState = remember { mutableStateOf(default) }
  • var value by remember { mutableStateOf(default) }
  • val (value, setValue) = remember { mutableStateOf(default) }

Te deklaracje są równoważne i służą jako skróty składniowe do różnych zastosowań stanu. Wybierz ten, który generuje kod najłatwiejszy do odczytania w komponowalnym elemencie, który piszesz.

Składnia delegata by wymaga tych importów:

import androidx.compose.runtime.getValue
import androidx.compose.runtime.setValue

Zapamiętaną wartość możesz użyć jako parametru dla innych komponentów lub nawet jako logiki w oświadczeniach, aby zmienić wyświetlane komponenty. Jeśli na przykład nie chcesz wyświetlać powitania, jeśli jego nazwa jest pusta, użyj stanu w instrukcji if:

@Composable
fun HelloContent() {
    Column(modifier = Modifier.padding(16.dp)) {
        var name by remember { mutableStateOf("") }
        if (name.isNotEmpty()) {
            Text(
                text = "Hello, $name!",
                modifier = Modifier.padding(bottom = 8.dp),
                style = MaterialTheme.typography.bodyMedium
            )
        }
        OutlinedTextField(
            value = name,
            onValueChange = { name = it },
            label = { Text("Name") }
        )
    }
}
StateOverviewSnippets.kt

Funkcja remember pomaga zachować stan w przypadku rekompozycji, ale nie zachowuje stanu w przypadku zmian konfiguracji. W tym celu musisz użyć rememberSaveable. rememberSaveable automatycznie zapisuje wszystkie wartości, które można zapisać w Bundle. W przypadku innych wartości możesz przekazać obiekt wygaszacza niestandardowego.

Inne obsługiwane typy stanów

W komponowaniu nie musisz używać MutableState<T> do przechowywania stanu. Obsługuje on inne obserwowalne typy. Zanim odczytasz inny typ obserwowalny w komponencie, musisz go przekonwertować na State<T>, aby komponenty mogły się automatycznie ponownie skompilować po zmianie stanu.

Funkcja tworzenia wiadomości zawiera funkcje tworzące element State<T> na podstawie typowych dostrzegalnych typów używanych w aplikacjach na Androida. Zanim użyjesz tych integracji, dodaj odpowiednie elementy w sposób opisany poniżej:

  • Flow: collectAsStateWithLifecycle()

    collectAsStateWithLifecycle() zbiera wartości z Flow w sposób uwzględniający cykl życia, co pozwala aplikacji oszczędzać zasoby. Reprezentuje ona ostatnią wyemitowaną wartość z funkcji Compose State. Zalecamy korzystanie z tego interfejsu API do zbierania danych w aplikacjach na Androida.

    W pliku build.gradle (powinien być w wersji 2.6.0-beta01 lub nowszej) wymagana jest ta zależność:

KotlinOdlotowe
dependencies {
      ...
      implementation("androidx.lifecycle:lifecycle-runtime-compose:2.8.7")
}

dependencies {
      ...
      implementation "androidx.lifecycle:lifecycle-runtime-compose:2.8.7"
}

  • Flow: collectAsState()

    Funkcja collectAsState jest podobna do collectAsStateWithLifecycle, ponieważ zbiera też wartości z Flow i przekształca je w Utwórz State.

    Zamiast collectAsStateWithLifecycle, który jest przeznaczony tylko na Androida, używaj kodu niezależnego od platformy (collectAsState).

    Dodatkowe zależności nie są wymagane w przypadku collectAsState, ponieważ jest on dostępny w compose-runtime.

  • LiveData: observeAsState()

    observeAsState() zaczyna obserwować ten parametr LiveData i reprezentuje jego wartości za pomocą parametru State.

    W pliku build.gradle wymagana jest ta zależność:

KotlinGroovy
dependencies {
      ...
      implementation("androidx.compose.runtime:runtime-livedata:1.7.8")
}

dependencies {
      ...
      implementation "androidx.compose.runtime:runtime-livedata:1.7.8"
}
KotlinGroovy
dependencies {
      ...
      implementation("androidx.compose.runtime:runtime-rxjava2:1.7.8")
}

dependencies {
      ...
      implementation "androidx.compose.runtime:runtime-rxjava2:1.7.8"
}
KotlinOdlotowe
dependencies {
      ...
      implementation("androidx.compose.runtime:runtime-rxjava3:1.7.8")
}

dependencies {
      ...
      implementation "androidx.compose.runtime:runtime-rxjava3:1.7.8"
}

Stanowa a bezstanowa

Składowa, która używa remember do przechowywania obiektu, tworzy stan wewnętrzny, dzięki czemu składowa staje się stanowa. HelloContent jest przykładem kompozytu stanu, ponieważ przechowuje i modyfikuje stan name wewnętrznie. Jest to przydatne w sytuacjach, gdy wywołujący stan nie musi kontrolować stanu i może go używać bez konieczności samodzielnego zarządzania stanem. Jednak komponenty z wewnętrznym stanem są zwykle mniej wielokrotnego użytku i trudniejsze do przetestowania.

Bezstanowa usługa składana to usługa składana, która nie przechowuje żadnego stanu. Prostym sposobem na osiągnięcie stanu bezstanowego jest użycie hoistingu stanu.

Podczas tworzenia wielokrotnego użytku komponentów często chcesz udostępnić wersję z stanem i bezstanową tego samego komponentu. Wersja ze stanem jest wygodna dla wywołujących, którym stan nie jest potrzebny, a wersja bezstanowa jest niezbędna dla wywołujących, którzy muszą kontrolować stan lub go podnosić.

Przenoszenie stanu

Przenoszenie stanu w komponowalnym to wzór przenoszenia stanu do wywołującego komponentu, aby uczynić go stanem bezstanowym. Ogólny wzorzec podnoszenia stanu w Jetpack Compose polega na zastąpieniu zmiennej stanu 2 parametrami:

  • value: T: bieżąca wartość do wyświetlenia
  • onValueChange: (T) -> Unit: zdarzenie, które prosi o zmianę wartości, gdzie T to proponowana nowa wartość

Nie musisz jednak ograniczać się do onValueChange. Jeśli dla funkcji kompozycyjnej potrzebne są bardziej szczegółowe zdarzenia, zdefiniuj je za pomocą parametrów lambda.

Stan podniesiony w ten sposób ma kilka ważnych właściwości:

  • Jedno źródło danych: zmieniając stan zamiast go duplikować, zapewniamy, że istnieje tylko jedno źródło wiarygodnych danych. Pomaga to uniknąć błędów.
  • Opakowane: stan mogą modyfikować tylko komponenty stateful. Jest to całkowicie wewnętrzna zmiana.
  • Możliwość udostępniania: stan hostowany może być udostępniany wielu elementom składanym. Jeśli chcesz odczytać name w innej składanej, możesz to zrobić dzięki funkcji podnoszenia.
  • Intercepable: wywołujące bezstanowe funkcje kompozycyjne mogą ignorować lub modyfikować zdarzenia przed zmianą stanu.
  • Rozdzielone: stan bezstanowych komponentów może być przechowywany w dowolnym miejscu. Teraz można na przykład przenieść name do ViewModel.

W tym przykładzie wyodrębniasz name i onValueChange z HelloContent i przenosisz je w górę do kompozycji HelloScreen, która wywołuje HelloContent.

@Composable
fun HelloScreen() {
    var name by rememberSaveable { mutableStateOf("") }

    HelloContent(name = name, onNameChange = { name = it })
}

@Composable
fun HelloContent(name: String, onNameChange: (String) -> Unit) {
    Column(modifier = Modifier.padding(16.dp)) {
        Text(
            text = "Hello, $name",
            modifier = Modifier.padding(bottom = 8.dp),
            style = MaterialTheme.typography.bodyMedium
        )
        OutlinedTextField(value = name, onValueChange = onNameChange, label = { Text("Name") })
    }
}
StateOverviewSnippets.kt

Dzięki wyodrębnieniu stanu z poziomu HelloContent łatwiej jest analizować komponent, używać go ponownie w różnych sytuacjach i testować. Element HelloContent jest oddzielony od sposobu przechowywania stanu. Odłączenie oznacza, że jeśli zmodyfikujesz lub zastąpisz HelloScreen, nie musisz zmieniać sposobu implementacji HelloContent.

Wzór, w którym stan maleje, a liczba zdarzeń rośnie, nazywa się jednokierunkowym przepływem danych. W tym przypadku stan zmienia się z HelloScreen na HelloContent, a zdarzenia z HelloContent na HelloScreen. Dzięki jednokierunkowemu przepływowi danych możesz odłączyć komponenty, które wyświetlają stan w interfejsie, od części aplikacji, które przechowują i zmieniają stan.

Więcej informacji znajdziesz na stronie Gdzie przenieść stan.

Przywracanie stanu w sekcji Tworzenie

Interfejs rememberSaveable działa podobnie do interfejsu remember, ponieważ zachowuje stan podczas rekompozycji, a także podczas odtwarzania aktywności lub procesu za pomocą mechanizmu zapisanego stanu instancji. Dzieje się tak na przykład, gdy ekran jest obracany.

Sposoby przechowywania stanu

Wszystkie typy danych dodane do Bundle są zapisywane automatycznie. Jeśli chcesz zapisać coś, czego nie można dodać do Bundle, masz kilka możliwości.

Parcelize

Najprostszym rozwiązaniem jest dodanie do obiektu adnotacji @Parcelize. Obiekt staje się podzielny i można go spakować. Na przykład ten kod tworzy typ danych City, który można podzielić, i zapisuje go w stanie.

@Parcelize
data class City(val name: String, val country: String) : Parcelable

@Composable
fun CityScreen() {
    var selectedCity = rememberSaveable {
        mutableStateOf(City("Madrid", "Spain"))
    }
}
StateOverviewSnippets.kt

MapSaver

Jeśli z jakiegoś powodu @Parcelize nie jest odpowiedni, możesz użyć funkcji mapSaver, aby zdefiniować własną regułę konwertowania obiektu na zestaw wartości, które system może zapisać w atrybucie Bundle.

data class City(val name: String, val country: String)

val CitySaver = run {
    val nameKey = "Name"
    val countryKey = "Country"
    mapSaver(
        save = { mapOf(nameKey to it.name, countryKey to it.country) },
        restore = { City(it[nameKey] as String, it[countryKey] as String) }
    )
}

@Composable
fun CityScreen() {
    var selectedCity = rememberSaveable(stateSaver = CitySaver) {
        mutableStateOf(City("Madrid", "Spain"))
    }
}
StateOverviewSnippets.kt

ListSaver

Aby uniknąć konieczności definiowania kluczy mapy, możesz też użyć funkcji listSaveri jej indeksów jako kluczy:

data class City(val name: String, val country: String)

val CitySaver = listSaver<City, Any>(
    save = { listOf(it.name, it.country) },
    restore = { City(it[0] as String, it[1] as String) }
)

@Composable
fun CityScreen() {
    var selectedCity = rememberSaveable(stateSaver = CitySaver) {
        mutableStateOf(City("Madrid", "Spain"))
    }
}
StateOverviewSnippets.kt

Zmienne stanu w edytorze

Prostym przenoszeniem stanu można zarządzać w samych składanych funkcjach. Jeśli jednak pojawi się ilość stanu umożliwiającego śledzenie wzrostu lub pojawi się logika wykonywania funkcji kompozycyjnych, warto przekazać obowiązki logiczne i stanowe innym klasom: właścicielom stanów.

Aby dowiedzieć się więcej, zapoznaj się z dokumentacją dotyczącą przenoszenia stanu w Compose lub ogólniej ze stroną Trzymacze stanu i stan interfejsu użytkownika w przewodniku po architekturze.

Ponowne wywoływanie obliczeń pamiętania po zmianie kluczy

Interfejs API remember jest często używany razem z MutableState:

var name by remember { mutableStateOf("") }
StateOverviewSnippets.kt

W tym przypadku użycie funkcji remember sprawia, że wartość MutableState działa po zmianie kompozycji.

Ogólnie funkcja remember przyjmuje parametr calculation lambda. Gdy funkcja rememberzostaje uruchomiona po raz pierwszy, wywołuje funkcję lambda calculation i przechowuje jej wynik. Podczas rekompozycji funkcja remember zwraca ostatnio zapisaną wartość.

Oprócz stanu buforowania za pomocą funkcji remember możesz też przechowywać dowolny obiekt lub wynik operacji w kompozycji, której zainicjowanie lub obliczenie jest kosztowne. Możesz nie chcieć powtarzać tego obliczenia przy każdym ponownym sformułowaniu. Przykładem jest tworzenie obiektu ShaderBrush, który jest kosztowną operacją:

val brush = remember {
    ShaderBrush(
        BitmapShader(
            ImageBitmap.imageResource(res, avatarRes).asAndroidBitmap(),
            Shader.TileMode.REPEAT,
            Shader.TileMode.REPEAT
        )
    )
}
StateOverviewSnippets.kt

remember zapisuje wartość do momentu jej opuszczenia kompozycji. Istnieje jednak sposób na unieważnienie wartości z pamięci podręcznej. Interfejs API remember przyjmuje też parametr key lub keys. Jeśli którykolwiek z tych kluczy się zmieni, przy następnym tworzeniu funkcji ponownego tworzenia remember unieważni pamięć podręczną i ponownie wykonuje blok lambda obliczeń. Ten mechanizm umożliwia kontrolowanie czasu trwania obiektu w kompozycji. Obliczenie obowiązuje do momentu zmiany danych wejściowych, a nie do momentu, gdy zapamiętana wartość opuści Kompozycję.

Przykłady poniżej pokazują, jak działa ten mechanizm.

W tym fragmencie tworzymy komponent ShaderBrush, który służy jako tło do malowania w komponencie Box. remember przechowuje instancję ShaderBrush, ponieważ jej odtworzenie jest kosztowne, jak wyjaśniono wcześniej. Funkcja remember przyjmuje parametr avatarRes jako key1, czyli wybrany obraz tła. Jeśli avatarRes ulegnie zmianie, pędzel zostanie ponownie skomponowany z nowym obrazem i ponownie zastosowany do Box. Może się to zdarzyć, gdy użytkownik wybierze inny obraz jako tło z selektora.

@Composable
private fun BackgroundBanner(
    @DrawableRes avatarRes: Int,
    modifier: Modifier = Modifier,
    res: Resources = LocalContext.current.resources
) {
    val brush = remember(key1 = avatarRes) {
        ShaderBrush(
            BitmapShader(
                ImageBitmap.imageResource(res, avatarRes).asAndroidBitmap(),
                Shader.TileMode.REPEAT,
                Shader.TileMode.REPEAT
            )
        )
    }

    Box(
        modifier = modifier.background(brush)
    ) {
        /* ... */
    }
}
StateOverviewSnippets.kt

W następnym fragmencie kodu stan jest przeniesiony do zwykłej klasy uchwytu stanu MyAppState. Udostępnia on funkcję rememberMyAppState, która inicjuje wystąpienie klasy za pomocą funkcji remember. Udostępnianie takich funkcji w celu utworzenia instancji, która przetrwa przekompozycje, to częsty wzorzec w funkcji Compose. Funkcja rememberMyAppState otrzymuje parametr windowSizeClass, który służy jako parametr key dla remember. Jeśli ten parametr ulegnie zmianie, aplikacja musi ponownie utworzyć prostą klasę uchwytu stanu z najnowszą wartością. Może się tak zdarzyć, np. gdy użytkownik obróci urządzenie.

@Composable
private fun rememberMyAppState(
    windowSizeClass: WindowSizeClass
): MyAppState {
    return remember(windowSizeClass) {
        MyAppState(windowSizeClass)
    }
}

@Stable
class MyAppState(
    private val windowSizeClass: WindowSizeClass
) { /* ... */ }
StateOverviewSnippets.kt

Compose używa implementacji equals klasy, aby określić, czy klucz się zmienił, i unieważnić przechowywaną wartość.

Przechowywanie stanu za pomocą kluczy poza rekompozycją

Interfejs API rememberSaveable jest otoką wokół remember, która może przechowywać dane w Bundle. Ten interfejs API pozwala zachować stan nie tylko w przypadku rekompozycji, ale też odtwarzania aktywności i zakończenia procesu przez system. rememberSaveable otrzymuje parametry input w tym samym celu, w jakim remember otrzymuje parametry keys. Pamięć podręczna jest unieważniana, gdy zmieni się dowolny z danych wejściowych. Gdy następnym razem funkcja będzie ponownie kompilować blok lambda, rememberSaveable ponownie uruchomi blok lambda.

W tym przykładzie zmienna rememberSaveable przechowuje wartość zmiennej userTypedQuery, dopóki zmienna typedQuery nie ulegnie zmianie:

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}
StateOverviewSnippets.kt

Więcej informacji

Więcej informacji o stanie i Jetpack Compose znajdziesz w tych dodatkowych materiałach.

Próbki

Mir 2 poprawia wydajność renderowania dzięki użyciu biblioteki Frame Pacing

Mir 2: Return of the King to wysokiej jakości gra mobilna o postaciach z Legendy, która została autoryzowana przez Actoz Soft i oparta na silniku Unity. Ta gra nie tylko doskonale odtwarza wrażenia z Mir 2, koreańskiej gry fantasy typu MMORPG, ale

Kuro Games zmniejsza zużycie energii o 9,68% dzięki profilowaniu zużycia energii w Android Studio i ODPM w przypadku gry Wuthering Waves

Wuthering Waves to fabularna gra akcji z grafiką wysokiej jakości stworzona przez Kuro Games. Optymalizacja zużycia energii jest bardzo ważna, aby zapewnić użytkownikom najwyższą jakość wrażeń podczas długich sesji grania. Android Studio wprowadziło

Optymalizacja Godot Engine Vulkan na Androida

Godot Engine to popularny wieloplatformowy silnik gier typu open source, który zapewnia solidne wsparcie dla Androida. Godot może służyć do tworzenia gier praktycznie dowolnego gatunku. Umożliwia tworzenie grafiki 2D i 3D. Wersja 4 Godota wprowadziła

Ćwiczenia z programowania

Filmy

Blogi

Obecnie nie ma rekomendacji.

na swoje konto Google.