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, kompilacja i wydajność w czasie działania.

Rozmiar pliku 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 każdego projektu z włączonym zmniejszaniem zasobów i kodu, w pełnym trybie R8, zmierzonego za pomocą APK Analyzer.

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 użytkownika 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 aplikacji Sunflower:

gradle-profiler --benchmark --project-dir . :app:assembleDebug

Gdy po raz pierwszy dodano Compose do Sunflower, średni czas kompilacji wzrósł z 299 ms do 399 ms, czyli o 100 ms. Wynika to 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, po zakończeniu migracji 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 skutecznie zwiększy rozmiar pliku APK aplikacji, a także wydłuży czas kompilacji aplikacji ze względu na proces 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 przypadku znajdziesz w artykule Wdrażanie Compose w zespołach.

Wydajność w czasie działania

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 widoków

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ć jawną 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 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 efektywnie obsługiwać głębokie drzewa interfejsu. Jeśli potrzebujesz kilku pomiarów, Compose ma pomiary wewnętrzne.

Wyświetl wydajność uruchamiania

System widoków musi rozwinąć układy XML, gdy po raz pierwszy wyświetla dany układ. W Jetpack Compose ten koszt jest eliminowany, ponieważ układy są pisane w języku Kotlin i kompilowane tak jak reszta aplikacji.

Testowanie Compose

W Jetpack Compose 1.0 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 używa też Macrobenchmark do wykrywania wszelkich regresji, które mogą wystąpić. Aby śledzić regresje, możesz na przykład sprawdzić test porównawczy dla kolumny Lazy i jego panel.

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 1.0 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.