Porównanie danych tworzenia i wyświetlania

Jetpack Compose przyspiesza tworzenie interfejsu użytkownika i ułatwia tworzenie aplikacji na Androida. Weź jednak pod uwagę, jak dodanie opcji Utwórz do istniejącej aplikacji może wpłynąć na takie dane jak rozmiar pliku APK aplikacji, kompilacja i wydajność działania.

Rozmiar pliku APK i czas kompilacji

W tej sekcji omawiamy wpływ na rozmiar pliku APK i czas kompilacji w przykładowej aplikacji Sunflower, która przedstawia sprawdzone metody przenoszenia aplikacji opartej na widokach do usługi Compose.

Rozmiar pliku APK

Dodanie bibliotek do projektu zwiększa rozmiar pliku APK. Poniższe wyniki dotyczą zmniejszonego pliku APK wersji każdego projektu z włączonym zmniejszaniem zasobów i kodu w trybie pełnego R8 i mierzonym przy użyciu Analizatora plików APK.

Tylko wyświetlenia Różne widoki danych i tworzenie wiadomości Tylko tworzenie
Rozmiar do pobrania 2252 KB 3034 KB 2966 KB

Przy pierwszym dodaniu funkcji tworzenia do Słonecznika rozmiar pliku APK wzrósł z 2252 KB do 3034 KB – to wzrost o 782 KB. Wygenerowany plik APK składał się z kompilacji interfejsu z kombinacją widoków danych i funkcji tworzenia wiadomości. Można się spodziewać wzrostu po dodaniu dodatkowych zależności do Słonecznika.

I odwrotnie – po migracji do aplikacji Sunflower do aplikacji przeznaczonej tylko do tworzenia wiadomości rozmiar pliku APK zmniejszył się z 3034 KB do 2966 KB, co jest spadkiem o 68 KB. Wynika to z usunięcia nieużywanych zależności widoków, takich jak AppCompat i ConstraintLayout.

Czas kompilacji

Dodanie opcji Compose wydłuża czas kompilacji aplikacji, ponieważ kompilator Compose przetwarza w niej kompozycje. Poniższe wyniki uzyskuje się za pomocą samodzielnego narzędzia gradle-profiler, które wykonuje kompilację kilka razy, aby można było uzyskać średni czas kompilacji na potrzeby debugowania w Sunflower:

gradle-profiler --benchmark --project-dir . :app:assembleDebug
Tylko wyświetlenia Różne widoki danych i tworzenie wiadomości Tylko tworzenie
Średni czas kompilacji 299,47 ms 399,09 ms 342,16 ms

Przy pierwszym dodaniu funkcji tworzenia do Słonecznika średni czas kompilacji wzrósł z 299 ms do 399 ms, co wzrost o 100 ms. Ten czas trwania zależy od tego, że kompilator Compose wykonuje dodatkowe zadania przekształcające kod tworzenia wiadomości zdefiniowany w projekcie.

I na odwrót: po zakończeniu migracji Sunflower do tworzenia wiadomości średni czas kompilacji skrócił się do 342 ms, czyli o 57 ms. Przyczyną tego ograniczenia jest kilka czynników, które łącznie skracają czas kompilacji. Są to na przykład usunięcie powiązania danych, przeniesienie zależności używających kapt do KSP oraz zaktualizowanie kilku zależności do najnowszych wersji.

Podsumowanie

Wdrożenie tej funkcji skutecznie zwiększy rozmiar pliku APK aplikacji oraz zwiększy jej czas kompilacji dzięki procesowi kompilacji kodu. Należy jednak wziąć pod uwagę zalety tworzenia wiadomości, zwłaszcza te związane ze wzrostem produktywności programistów po wprowadzeniu tej funkcji. Na przykład zespół Sklepu Play odkrył, że pisanie interfejsu użytkownika wymaga znacznie mniej kodu – czasami nawet do 50%, co zwiększa produktywność i łatwość obsługi kodu.

Więcej studiów przypadków znajdziesz w artykule o wdrażaniu tworzenia wiadomości w zespołach.

Wydajność środowiska wykonawczego

W tej sekcji omawiamy tematy związane z wydajnością środowiska wykonawczego w Jetpack Compose, aby pomóc Ci zrozumieć, jak Jetpack Compose wypada w porównaniu z wydajnością systemu w widoku, oraz jak ją zmierzyć.

Inteligentne zmienianie kompozycji

Gdy elementy interfejsu użytkownika są nieprawidłowe, funkcja tworzenia próbuje ponownie utworzyć tylko te fragmenty, które wymagają aktualizacji. Więcej informacji na ten temat znajdziesz w dokumentacji cyklu życia obiektów kompozycyjnych i etapów Jetpack Compose.

Profile podstawowe

Profile podstawowe to doskonały sposób na przyspieszenie typowych działań użytkowników. Uwzględnienie w aplikacji profilu podstawowego może przyspieszyć wykonywanie kodu o około 30% od pierwszego uruchomienia dzięki uniknięciu kroków interpretacji i kompilacji „just-in-time” (JIT) w przypadku uwzględnionych ścieżek kodu.

Biblioteka Jetpack Compose zawiera własny profil bazowy i te optymalizacje są automatycznie generowane, gdy używasz funkcji tworzenia wiadomości w aplikacji. Te optymalizacje mają jednak wpływ tylko na ścieżki kodu w bibliotece tworzenia, dlatego zalecamy dodanie profilu podstawowego do aplikacji, aby uwzględnić ścieżki kodu poza funkcją tworzenia.

Porównanie z systemem widoków

Jetpack Compose ma wiele ulepszeń w stosunku do systemu widoków. Te ulepszenia opisujemy w kolejnych sekcjach.

Wszystko rozszerza widok

Każdy element View, który wyświetla się na ekranie, np. TextView, Button czy ImageView, wymaga przydziałów pamięci, wyraźnego śledzenia stanu i różnych wywołań zwrotnych, aby obsługiwać wszystkie przypadki użycia. Dodatkowo właściciel niestandardowego elementu View musi zaimplementować jawną logikę, aby zapobiec ponownemu rysowaniu danych, gdy nie jest to konieczne, na przykład w przypadku powtarzającego się przetwarzania danych.

Jetpack Compose rozwiązuje ten problem na kilka sposobów. W komponencie nie ma obiektów, które można zaktualizować w widokach rysunków. Elementy interfejsu to proste funkcje kompozycyjne, które informacje są zapisywane w kompozycji w sposób umożliwiający powtórzenie. Pomaga to ograniczyć jawne śledzenie stanu, alokacje pamięci i wywołania zwrotne tylko w komponentach kompozycyjnych, które wymagają tych funkcji, a nie wymagają ich przez wszystkie rozszerzenia danego typu View.

Ponadto funkcja tworzenia wiadomości umożliwia inteligentną zmianę kompozycji, która w razie potrzeby odtwarza wcześniej narysowany wynik.

Wiele kart układu

Tradycyjne interfejsy API do pomiaru i układu mają dużą ekspresję, dzięki czemu są podatne na używanie wielu układów. Te wielokrotne przesłania układu mogą powodować wykładnicze działania, jeśli są wykonywane w określonych zagnieżdżonych punktach hierarchii widoku.

Jetpack Compose wymusza pojedyncze przekazywanie układu dla wszystkich funkcji kompozycyjnych układu w ramach umowy dotyczącej interfejsu API. Dzięki temu funkcja Compose może sprawnie obsługiwać głębokie drzewa interfejsu. Jeśli potrzebnych jest kilka pomiarów, funkcja tworzenia umożliwia pomiar wewnętrzne.

Wyświetlanie wyników uruchamiania

Gdy po raz pierwszy pokazujesz określony układ, system widoku musi zawyżać jego układy XML. Dzięki temu możesz zaoszczędzić pieniądze w Jetpack Compose, ponieważ układy są napisane w Kotlin i kompilowane tak jak reszta aplikacji.

Tworzenie analizy porównawczej

W Jetpack Compose 1.0 występują istotne różnice w działaniu aplikacji w trybach debug i release. Aby uzyskać reprezentatywny czas, do profilowania aplikacji zawsze używaj kompilacji release zamiast debug.

Aby sprawdzić wydajność kodu Jetpack Compose, możesz użyć biblioteki Jetpack Macrobenchmark. Aby dowiedzieć się, jak korzystać z tej funkcji w Jetpack Compose, przeczytaj projekt MacrobenchmarkSample.

Zespół Jetpack Compose korzysta też z narzędzia Macroporównanie, aby wychwytywać ewentualne regresje. Możesz na przykład wyświetlić test porównawczy dla leniwej kolumny i jej panel, aby śledzić regresje.

Utwórz instalację profilu

Jetpack Compose jest niedostępną biblioteką, dlatego nie korzysta z wersji Zygote, która wstępnie wczytuje klasy i elementy rysowalne w interfejsie użytkownika widoku. Jetpack Compose 1.0 korzysta z instalacji profilu na potrzeby kompilacji release. Instalatory profili pozwalają aplikacjom określać kluczowy kod, który jest kompilowany z wyprzedzeniem (AOT) podczas instalacji. Tworzenie reguł instalacji profilu statków, które skracają czas uruchamiania i zacinanie się w aplikacjach tworzenia.