Porównanie danych tworzenia i wyświetlania

Jetpack Compose przyspiesza tworzenie interfejsu i usprawnia proces tworzenia aplikacji na Androida. Weź jednak pod uwagę, jak dodanie Compose do istniejącej aplikacji może wpłynąć na dane, takie jak rozmiar pliku APK aplikacji, kompilacja i wydajność w czasie działania.

Rozmiar pakietu APK i czas kompilacji

W tej sekcji omówimy wpływ na rozmiar pliku APK i czas kompilacji na przykładzie przykładowej aplikacji Sunflower, która pokazuje sprawdzone metody migracji aplikacji opartej na widokach do Compose.

Rozmiar pliku APK

Dodanie bibliotek do projektu zwiększa rozmiar pliku APK. Poniższe wyniki dotyczą zminimalizowanego pliku APK wersji każdego projektu z włączonym zmniejszaniem zasobów i kodu, w pełnym trybie R8, zmierzonego za pomocą APK Analyzer.

Tylko wyświetlenia Widoki mieszane i Compose Tylko tworzenie
Rozmiar do pobrania 2252 KB 3034 KB 2966 KB

Po pierwszym dodaniu Compose do Sunflower rozmiar pliku APK wzrósł z 2252 KB do 3034 KB, czyli o 782 KB. Wygenerowany plik APK zawierał interfejs utworzony z użyciem widoków i Compose. Można się było tego spodziewać, ponieważ do aplikacji Sunflower dodano dodatkowe zależności.

Z kolei po przeniesieniu aplikacji Sunflower do wersji korzystającej wyłącznie z Compose rozmiar pliku APK zmniejszył się z 3034 KB do 2966 KB, czyli o 68 KB. Ten spadek był spowodowany usunięciem nieużywanych zależności widoku, takich jak AppCompat i ConstraintLayout.

Czas tworzenia kompilacji

Dodanie Compose wydłuża czas kompilacji aplikacji, ponieważ kompilator Compose przetwarza elementy kompozycyjne w aplikacji. Te wyniki zostały uzyskane za pomocą samodzielnego narzędzia gradle-profiler, które wykonuje kompilację kilka razy, aby można było uzyskać średni czas kompilacji do debugowania Sunflower:

gradle-profiler --benchmark --project-dir . :app:assembleDebug
Tylko wyświetlenia Widoki mieszane i Compose Tylko tworzenie
Średni czas kompilacji 299,47 ms 399,09 ms 342,16 ms

Gdy po raz pierwszy dodano Compose do Sunflower, średni czas kompilacji wzrósł z 299 ms do 399 ms, czyli o 100 ms. Ten czas wynika z tego, że kompilator Compose wykonuje dodatkowe zadania, aby przekształcić kod Compose zdefiniowany w projekcie.

Z kolei średni czas kompilacji spadł do 342 ms, czyli o 57 ms, gdy zakończono migrację aplikacji Sunflower do Compose. To skrócenie czasu kompilacji można przypisać kilku czynnikom, które wspólnie skracają czas kompilacji, takim jak usunięcie wiązania danych, migracja zależności, które używają kapt do KSP, oraz aktualizacja kilku zależności do najnowszych wersji.

Podsumowanie

Wdrożenie Compose spowoduje zwiększenie rozmiaru pliku APK aplikacji, a także wydłuży czas kompilacji kodu Compose. Te kompromisy należy jednak zestawić z korzyściami, jakie daje Compose, zwłaszcza w zakresie zwiększenia produktywności deweloperów po wdrożeniu Compose. Na przykład zespół Sklepu Play odkrył, że pisanie interfejsu wymaga znacznie mniej kodu, czasem nawet o 50%, co zwiększa produktywność i ułatwia utrzymanie kodu.

Więcej studiów przypadków znajdziesz w artykule Wdrażanie Compose w zespołach.

Wydajność środowiska wykonawczego

Ta sekcja zawiera tematy związane z wydajnością środowiska wykonawczego w Jetpack Compose, które pomogą Ci zrozumieć, jak Jetpack Compose wypada w porównaniu z wydajnością systemu widoku i jak możesz ją mierzyć.

Inteligentne rekompozycje

Gdy części interfejsu są nieprawidłowe, Compose próbuje ponownie skomponować tylko te części, które wymagają aktualizacji. Więcej informacji na ten temat znajdziesz w dokumentacji dotyczącej cyklu życia funkcji kompozycyjnych i etapów Jetpack Compose.

Profile podstawowe

Profile Baseline to doskonały sposób na przyspieszenie typowych ścieżek użytkownika. Dołączenie profilu Baseline do aplikacji może zwiększyć szybkość wykonywania kodu o około 30% od pierwszego uruchomienia, ponieważ pozwala uniknąć etapów interpretacji i kompilacji JIT w przypadku dołączonych ścieżek kodu.

Biblioteka Jetpack Compose zawiera własny profil podstawowy, a gdy używasz Compose w aplikacji, automatycznie korzystasz z tych optymalizacji. Te optymalizacje wpływają jednak tylko na ścieżki kodu w bibliotece Compose, dlatego zalecamy dodanie do aplikacji profilu podstawowego, aby uwzględnić ścieżki kodu poza Compose.

Porównanie z systemem View

Jetpack Compose ma wiele ulepszeń w porównaniu z systemem 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 lub ImageView, wymaga alokacji pamięci, jawnego śledzenia stanu i różnych wywołań zwrotnych, aby obsługiwać wszystkie przypadki użycia. Ponadto właściciel niestandardowego elementu View musi wdrożyć jednoznaczną logikę, aby zapobiec ponownemu rysowaniu, gdy nie jest to konieczne – na przykład w przypadku powtarzalnego przetwarzania danych.

Jetpack Compose rozwiązuje ten problem na kilka sposobów. Compose nie ma jawnych obiektów, które można aktualizować, do rysowania widoków. Elementy interfejsu to proste funkcje typu „composable”, których informacje są zapisywane w kompozycji w sposób umożliwiający ich odtworzenie. Pomaga to ograniczyć śledzenie stanu, alokację pamięci i wywołania zwrotne tylko do tych funkcji kompozycyjnych, które wymagają tych funkcji, zamiast wymagać ich we wszystkich rozszerzeniach danego typu View.

Ponadto Compose zapewnia inteligentne rekompozycje, odtwarzając wcześniej narysowany wynik, jeśli nie musisz wprowadzać zmian.

Wiele przebiegów układu

Tradycyjne klasy ViewGroup mają wiele możliwości ekspresji w interfejsach API do pomiaru i układu, co sprawia, że są podatne na wielokrotne przejścia układu. Te wielokrotne przebiegi układu mogą powodować wykładniczy wzrost pracy, jeśli są wykonywane w określonych zagnieżdżonych punktach hierarchii widoków.

Jetpack Compose wymusza pojedynczy przebieg układu dla wszystkich funkcji kompozycyjnych układu za pomocą umowy API. Dzięki temu Compose może wydajnie obsługiwać głębokie drzewa interfejsu. Jeśli potrzebujesz kilku pomiarów, Compose ma pomiary wewnętrzne.

Wyświetlanie wydajności uruchamiania

System widoków musi rozwinąć układy XML, gdy po raz pierwszy wyświetla dany układ. W Jetpack Compose nie ma tego kosztu, ponieważ układy są pisane w Kotlinie i kompilowane tak jak reszta aplikacji.

Testowanie Compose

W Jetpack Compose występują znaczne różnice między wydajnością aplikacji w trybach debug i release. Aby uzyskać reprezentatywne czasy, podczas profilowania aplikacji zawsze używaj kompilacji release zamiast debug.

Aby sprawdzić, jak działa kod Jetpack Compose, możesz użyć biblioteki Jetpack Macrobenchmark. Aby dowiedzieć się, jak używać go z Jetpack Compose, zapoznaj się z projektem MacrobenchmarkSample.

Zespół Jetpack Compose również używa Macrobenchmark do śledzenia regresji i sprawdzania wydajności widoków w różnych wersjach. Szczegółowe testy porównawcze uruchamiania i przewijania, które porównują Compose i widoki w aplikacji Pokedex typu open source, znajdziesz w sekcji Testy porównawcze Hero.

Instalacja profilu Compose

Jetpack Compose jest biblioteką niepowiązaną, więc nie korzysta z Zygote, który wstępnie wczytuje klasy i elementy rysowalne pakietu UI Toolkit systemu widoków. Jetpack Compose wykorzystuje instalację profilu w przypadku kompilacji do publikacji. Instalatory profili umożliwiają aplikacjom określanie krytycznego kodu, który ma być kompilowany z wyprzedzeniem (AOT) w momencie instalacji. Compose dostarcza reguły instalacji profilu, które skracają czas uruchamiania i ograniczają zacinanie się aplikacji Compose.