Etapy tworzenia i skuteczność
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Edytowanie ramki odbywa się w 3 etapach:
- Kompozycja: sposób tworzenia określa, co ma się wyświetlać. Uruchamia funkcje kompozycyjne
i tworzy drzewo UI.
- Układ: opcja Utwórz określa rozmiar i położenie każdego elementu w drzewie interfejsu.
- Rysunek: funkcja tworzenia renderuje poszczególne elementy interfejsu użytkownika.
Funkcja tworzenia wiadomości może w inteligentny sposób pominąć dowolną z tych faz. Załóżmy np., że 1 element graficzny zamienia się między 2 ikonami o tym samym rozmiarze. Ponieważ ten element nie zmienia rozmiaru i nie są dodawane ani usuwane żadne elementy drzewa UI, funkcja tworzenia może pominąć fazy kompozycji i układu, a następnie ponownie narysować ten element.
Błędy w kodowaniu mogą jednak utrudniać systemowi Compose określenie, które etapy może on bezpiecznie pominąć. W takim przypadku interfejs Compose uruchamia wszystkie 3 fazy, co może spowolnić działanie interfejsu użytkownika. Dlatego wiele sprawdzonych metod dotyczących wydajności pomaga w pominięciu etapów, które nie są potrzebne.
Więcej informacji znajdziesz w przewodniku Jetpack Compose Etapy.
Zasady ogólne
Oto kilka ogólnych zasad, których warto przestrzegać, aby poprawić skuteczność:
- Gdy tylko jest to możliwe, przenoś obliczenia z funkcji kompozycyjnych.
Może być konieczne ponowne uruchomienie funkcji kompozycyjnych po każdej zmianie interfejsu użytkownika. Każdy kod umieszczony w elemencie kompozycyjnym jest wykonywany ponownie (potencjalnie dla każdej klatki animacji). Ogranicz kod elementu kompozycyjnego tylko do tego, co jest potrzebne do skompilowania interfejsu użytkownika.
- Odkładaj odczyty stanu na jak najdłuższy czas. Przenosząc odczyt stanu do etapu podrzędnego lub późniejszego etapu komponowania, możesz zminimalizować kompozycję lub całkowicie pominąć etap kompozycji. W tym celu przekazuj funkcje lambda zamiast wartości stanu w przypadku często zmieniających się stanów i preferuj modyfikatory oparte na lambda w przypadku często zmieniającego się stanu. Przykład tej metody znajdziesz w sekcji Odkładaj odczyty tak najdłużej, jak to możliwe w artykule Zastosuj sprawdzone metody.
Dodatkowe materiały
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2025-07-27 UTC."],[],[],null,["# Compose phases and performance\n\nWhen Compose updates a frame, it goes through three phases:\n\n- **Composition:** Compose determines *what* to show. It runs composable functions and builds the UI tree.\n- **Layout:** Compose determines the size and placement of each element in the UI tree.\n- **Drawing:** Compose actually *renders* the individual UI elements.\n\nCompose can intelligently skip any of those phases if they aren't needed. For\nexample, suppose a single graphic element swaps between two icons of the same\nsize. Since this element isn't changing size, and no elements of the UI tree are\nbeing added or removed, Compose can skip over the composition and layout phases\nand redraw this one element.\n\nHowever, coding mistakes can make it hard for Compose to know which phases it\ncan safely skip, in which case Compose runs all three phases, which can slow\ndown your UI. So, many of the performance best practices are to help Compose\nskip the phases it doesn't need to do.\n\nFor more information, see the [Jetpack Compose Phases](/develop/ui/compose/phases) guide.\n\nGeneral principles\n------------------\n\nThere are a couple of broad principles to follow that can improve performance in\ngeneral:\n\n- **Whenever possible, move calculations out of your composable functions.** Composable functions might need to be rerun whenever the UI changes. Any code you put in the composable gets re-executed, potentially for every frame of an animation. Limit the composable's code to only what it needs to build the UI.\n- **Defer state reads for as long as possible.** By moving state reading to a child composable or a later phase, you can minimize recomposition or skip the composition phase entirely. You can do this by passing lambda functions instead of the state value for frequently changing state and by preferring lambda-based modifiers when you pass in frequently changing state. You can see an example of this technique in the [Defer reads as long as possible](/develop/ui/compose/performance/bestpractices#defer-reads) section of [Follow best practices](/develop/ui/compose/performance/bestpractices).\n\nAdditional Resources\n--------------------\n\n- **[App performance guide](/topic/performance/overview)**: Discover best practices, libraries, and tools to improve performance on Android.\n- **[Inspect Performance](/topic/performance/inspecting-overview):** Inspect app performance.\n- **[Benchmarking](/topic/performance/benchmarking/benchmarking-overview):** Benchmark app performance.\n- **[App startup](/topic/performance/appstartup/analysis-optimization):** Optimize app startup.\n- **[Baseline profiles](/baseline-profiles):** Understand baseline profiles."]]
