Porównanie danych tworzenia i wyświetlania

Jetpack Compose przyspiesza tworzenie interfejsu i ulepsza proces tworzenia aplikacji na Androida. Pamiętaj jednak, że 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 aplikacji Sunflower, która pokazuje sprawdzone metody migracji aplikacji opartej na widokach do Compose.

Rozmiar pliku APK

Dodawanie bibliotek do projektu zwiększa rozmiar pliku APK. Poniższe wyniki dotyczą zminimalizowanych plików APK wersji każdego projektu z włączonym zmniejszaniem zasobów i kodu, które zostały uzyskane w trybie pełnym R8 i zmierzone za pomocą analizatora APK.

Tylko wyświetlenia Widok mieszany i tworzenie Tylko tworzenie
Rozmiar do pobrania 2252 KB 3034 KB 2966 KB

Po pierwszym dodaniu Compose do aplikacji 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 elementów View i Compose. Ten wzrost jest spodziewany, ponieważ do Sunflower dodano dodatkowe zależności.

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

Czas kompilacji

Dodanie Compose wydłuża czas kompilacji aplikacji, ponieważ kompilator Compose przetwarza funkcje kompozycyjne w aplikacji. Poniższe wyniki uzyskano za pomocą samodzielnego narzędzia gradle-profiler, które wykonuje kompilację kilka razy, aby uzyskać średni czas kompilacji wersji debugowania aplikacji Sunflower:

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

Gdy po raz pierwszy dodaliśmy Compose do Sunflower, średni czas kompilacji wzrósł z 299 ms do 399 ms, czyli o 100 ms. Ten czas jest spowodowany tym, ż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. Ten spadek można przypisać kilku czynnikom, które łącznie skracają czas kompilacji, takim jak usunięcie powiązań danych, migracja zależności, które używają kapt do KSP, oraz aktualizacja kilku zależności do najnowszych wersji.

Podsumowanie

Wprowadzenie Compose spowoduje zwiększenie rozmiaru pliku APK aplikacji, a także wydajności kompilacji aplikacji ze względu na proces kompilacji kodu Compose. Te kompromisy należy jednak rozważyć w kontekście zalet Compose, zwłaszcza w zakresie zwiększenia produktywności deweloperów po wdrożeniu Compose. Na przykład zespół Sklepu Play stwierdził, że pisanie interfejsu wymaga znacznie mniej kodu, czasami 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.

Wyniki w środowisku wykonawczym

W tej sekcji znajdziesz informacje o wydajności w czasie działania w Jetpack Compose, które pomogą Ci zrozumieć, jak Jetpack Compose wypada w porównaniu z wydajnością systemu widoków i jak możesz ją mierzyć.

Inteligentne przekomponowywanie

Gdy fragmenty interfejsu są nieprawidłowe, Compose próbuje ponownie skomponować tylko te fragmenty, które wymagają aktualizacji. Więcej informacji znajdziesz w dokumentacji Cykl życia funkcji kompozycyjnych i Fazy Jetpack Compose.

Profile podstawowe

Profile podstawowe to doskonały sposób na przyspieszenie typowych ścieżek użytkownika. Uwzględnienie w aplikacji profilu podstawowego może zwiększyć szybkość wykonywania kodu o około 30% od pierwszego uruchomienia, ponieważ pozwala uniknąć interpretacji i kompilacji JIT (just-in-time) w przypadku uwzględnionych ścieżek kodu.

Biblioteka Jetpack Compose zawiera własny profil bazowy, więc gdy używasz jej w aplikacji, automatycznie uzyskujesz te optymalizacje. Jednak wpływają one tylko na ścieżki kodu w bibliotece Compose, dlatego zalecamy dodanie do aplikacji profilu bazowego, aby obejmował ścieżki kodu poza Compose.

Porównanie z systemem View

Jetpack Compose ma wiele ulepszeń w porównaniu z systemem View. Te ulepszenia opisujemy w kolejnych sekcjach.

Wszystko rozszerza klasę View

Każdy element View wyświetlany na ekranie, np. TextView, Button lub ImageView, wymaga przydzielenia pamięci, jawnego śledzenia stanu i różnych wywołań zwrotnych, aby obsługiwać wszystkie przypadki użycia. Dodatkowo niestandardowy Viewwłaściciel musiViewwdrożyć wyraźną logikę, aby zapobiec ponownemu rysowaniu, gdy nie jest to konieczne, np. 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ć w przypadku widoków rysowania. Elementy interfejsu to proste funkcje, które można łączyć w kompozycje. Informacje o nich są zapisywane w kompozycji w sposób umożliwiający ich odtwarzanie. Pozwala to ograniczyć śledzenie stanu, alokację pamięci i wywołania zwrotne tylko do funkcji kompozycyjnych, które wymagają tych funkcji, zamiast wymagać ich od wszystkich rozszerzeń danego Viewtypu.

Dodatkowo Compose zapewnia inteligentne ponowne kompozycje, które odtwarzają wcześniej narysowany wynik, jeśli nie musisz wprowadzać zmian.

Wiele przepustek układu

Tradycyjne grupy ViewGroups mają wiele funkcji w interfejsach API pomiarów i układów, które sprawiają, że są podatne na wielokrotne przebiegi układu. Wielokrotne przebiegi układu mogą powodować wykładniczy wzrost nakładu pracy, jeśli są wykonywane w określonych zagnieżdżonych punktach w hierarchii widoków.

Jetpack Compose wymusza pojedyncze przejście układu w przypadku wszystkich funkcji kompozycyjnych układu za pomocą umowy interfejsu API. Dzięki temu Compose może wydajnie obsługiwać rozbudowane drzewa interfejsu. Jeśli potrzebujesz kilku pomiarów, w funkcji Tworzenie wiadomości dostępne są pomiarowe wartości wewnętrzne.

Wyświetlanie wydajności uruchamiania

System widoku musi rozwinąć układy XML, gdy po raz pierwszy wyświetla określony układ. Ten koszt jest zapisywany w Jetpack Compose, ponieważ układy są pisane w Kotlinie i kompilowane jak reszta aplikacji.

Testowanie wydajności Compose

W Jetpack Compose 1.0 występują zauważalne różnice w wydajności aplikacji w trybach debug i release. W przypadku reprezentatywnych czasów zawsze używaj wersji release zamiast debug podczas profilowania aplikacji.

Aby sprawdzić wydajność kodu Jetpack Compose, możesz użyć biblioteki Jetpack Macrobenchmark. Aby dowiedzieć się, jak używać jej z Jetpack Compose, zapoznaj się z projektem MacrobenchmarkSample.

Zespół Jetpack Compose używa też Macrobenchmark do wykrywania wszelkich regresji, które mogą wystąpić. Na przykład zapoznaj się z benchmarkiem dla leniwej kolumny i jego panelem, aby śledzić regresje.

Tworzenie instalacji profilu

Jetpack Compose to biblioteka niezależna od platformy, więc nie korzysta z Zygote, który wstępnie wczytuje klasy i elementy rysowalne pakietu UI Toolkit systemu View. Jetpack Compose 1.0 wykorzystuje instalację profilu w przypadku kompilacji wersji. Instalatory profili umożliwiają aplikacjom określanie kluczowego kodu, który ma być kompilowany z wyprzedzeniem (AOT) w momencie instalacji. Compose wysyła reguły profilu, które skracają czas uruchamiania i ograniczają zacinanie się aplikacji Compose.