Jetpack Compose mempercepat pengembangan UI dan membuat engineer Android lebih produktif. Namun, menambahkan alat baru ke project memerlukan beberapa pertimbangan karena dapat memengaruhi APK, serta performa build dan runtime.
Ukuran APK dan waktu build
Di bagian ini, kami membandingkan dampak dari dua aplikasi yang berbeda saat menambahkan atau memigrasikan ke Jetpack Compose:
- Tivi sepenuhnya bermigrasi ke Compose, menghapus library Komponen AppCompat dan Desain Material.
- Sunflower
(cabang
compose_recyclerview) menambahkan Compose hanya menggunakannya untuk itemRecyclerView. Semua dependensi lain sama.
Ukuran APK
Menambahkan library ke project Anda akan memengaruhi ukuran APK. Mari kita lihat bagaimana Compose memengaruhi ukuran project yang disebutkan di atas. Hasil berikut untuk APK rilis minimum setiap project dengan resource dan penyingkatan kode yang diaktifkan, yang menggunakan mode lengkap R8, dan diukur menggunakan APK Analyzer.
Tivi menemukan pengurangan ukuran APK sebesar 46%, dari 4,49 MB menjadi 2,39 MB. Tivi juga menemukan penurunan metode sebesar 17% setelah sepenuhnya bermigrasi ke Compose. Baris XML kode menurun sebesar 76%.
Ukuran APK Sunflower meningkat 575 KB saat Compose ditambahkan ke project, dari 2407 KB menjadi 2982 KB. Karena Compose ini hampir tidak digunakan dalam cabang Sunflower tersebut, project tidak mendapatkan manfaat dari manfaat ukuran APK khusus Compose seperti menghapus dependensi AppCompat dari project.
Waktu build
Menggunakan project yang sama, mari kita ukur bagaimana Compose memengaruhi performa build.
Ini mempertimbangkan waktu build debug, yang merupakan waktu penting bagi Anda selama pengembangan.
Waktu build rata-rata Tivi sebelum bermigrasi ke Compose adalah 108,71 detik. Setelah sepenuhnya bermigrasi ke Compose, waktu build rata-rata turun menjadi 76,96 detik! Penurunan waktu build 29%. Pengurangan waktu ini sebagian besar dipengaruhi oleh kemampuan untuk menghapus data binding danEpoxy dari project yang menggunakan pemroses anotasi kapt, dan Hilt yang lebih cepat dalam AGP 7.0.
Namun, Sunflower mengalami peningkatan waktu mediannya sebesar 7,6%, dari 11,57 detik menjadi 12,45 detik.
Kesimpulan
Saat mulai menggunakan Compose di aplikasi, Anda dapat melihat peningkatan ukuran APK dan waktu build, yang akan menurun dan melampaui metrik asli setelah project dimigrasikan sepenuhnya ke Compose.
Performa Runtime
Bagian ini membahas topik yang berkaitan dengan performa runtime di Jetpack Compose, sehingga Anda dapat memahami perbandingan Jetpack Compose dengan performa sistem View, serta cara Anda dapat mengukurnya.
Rekomposisi cerdas
Saat sebagian UI Anda tidak valid, Compose akan melakukan yang terbaik untuk merekomposisi bagian yang perlu diupdate saja. Baca selengkapnya tentang topik ini dalam panduan Siklus proses composable.
Perbandingan dengan sistem View
Karena desain dan tutorial yang dipelajari dari sistem View, Jetpack Compose akan mengunggulinya.
Semuanya memperluas View
Setiap View yang digambar pada layar, seperti TextView, Button, atau
ImageView, memerlukan alokasi memori, pelacakan status eksplisit, dan berbagai
callback untuk mendukung semua penggunaan kasus. Selain itu, pemilik View kustom perlu
mengimplementasikan logika eksplisit untuk mencegah penggambaran ulang saat tidak diperlukan, misalnya
untuk pemrosesan data berulang.
Jetpack Compose menangani masalah ini dengan beberapa cara. Compose tidak memiliki objek eksplisit
yang dapat diperbarui untuk menggambar tampilan, elemen UI adalah fungsi sederhana
yang dapat dikomposisi dan informasinya ditulis ke Komposisi dengan cara yang dapat diputar ulang.
Cara ini membantu mengurangi pelacakan status, alokasi memori, dan callback eksplisit
hanya untuk komponen yang memerlukan fitur tersebut, bukan memerlukannya oleh
semua ekstensi dari jenis View yang ditentukan.
Selain itu, Compose menyediakan rekomposisi cerdas baru, yang memutar ulang hasil yang digambar sebelumnya jika tidak ada perubahan yang diperlukan.
Meneruskan beberapa tata letak
ViewGroup tradisional memiliki banyak ekspresi yang cepat dalam API ukuran dan tata letaknya, sehingga memudahkan untuk membuat beberapa penerusan tata letak. Beberapa penerusan tata letak ini dapat menyebabkan tugas eksponensial jika dilakukan pada titik bertingkat tertentu dalam hierarki tampilan.
Jetpack Compose menerapkan satu penerusan tata letak untuk semua composable tata letak melalui kontrak API-nya. Hal ini memungkinkan Compose menangani hierarki UI yang dalam secara efisien. Jika beberapa pengukuran diperlukan, Compose memiliki sistem khusus yang siap digunakan, yaitu pengukuran intrinsik.
Performa startup View
Sistem View perlu meng-inflate tata letak XML saat pertama kali menampilkan tata letak tertentu. Biaya ini disimpan di Jetpack Compose karena tata letak ditulis di Kotlin dan dikompilasi seperti aplikasi Anda yang lainnya.
Tolok Ukur Compose
Pada Jetpack Compose 1.0, ada perbedaan penting antara performa
aplikasi dalam mode debug dan release. Untuk pengaturan waktu representatif, selalu
gunakan build release saat membuat profil aplikasi, bukan debug.
Untuk memeriksa performa kode Jetpack Compose, Anda dapat menggunakan library Jetpack Macrobenchmark—lihat project MacrobenchmarkSample untuk mengetahui cara menggunakannya dengan Jetpack Compose. Tim Jetpack Compose juga menggunakannya untuk menangkap regresi yang dapat terjadi. Misalnya, lihat benchmark untuk kolom lambat ini dan dasbornya untuk melacak regresi.
Penginstalan profil Compose
Karena Jetpack Compose adalah library yang tidak dipaketkan, library ini tidak mendapatkan manfaat dari Zygote yang melakukan pramuat class dan drawable UI Toolkit sistem View. Jetpack Compose 1.0 menggunakan penginstalan profil untuk build rilis. Penginstal profil memungkinkan aplikasi menentukan kode penting yang akan dikompilasi dengan AOT pada waktu penginstalan. Compose mengirimkan aturan penginstalan profil yang mengurangi waktu startup dan jank di aplikasi Compose.