Membandingkan metrik Compose dan View

Jetpack Compose mempercepat pengembangan UI dan meningkatkan pengembangan Android. Namun, pertimbangkan bagaimana menambahkan Compose ke aplikasi yang ada dapat memengaruhi metrik seperti ukuran APK, build, dan performa runtime aplikasi.

Ukuran APK dan waktu build

Bagian ini membahas dampak terhadap ukuran APK dan waktu build dengan melihat aplikasi contoh Sunflower—aplikasi yang menunjukkan praktik terbaik dalam memigrasikan aplikasi berbasis View ke Compose.

Ukuran APK

Menambahkan library ke project Anda akan meningkatkan ukuran APK-nya. Hasil berikut adalah untuk APK rilis minimum setiap project dengan resource dan penyingkatan kode yang diaktifkan, yang menggunakan mode lengkap R8, dan diukur menggunakan APK Analyzer.

Tampilan saja View dan Compose Campuran Khusus Compose
Ukuran download 2.252 KB 3.034 KB 2.966 KB

Saat pertama kali menambahkan Compose ke Sunflower, ukuran APK meningkat dari 2.252 KB menjadi 3.034 KB—peningkatan 782 KB. APK yang dihasilkan terdiri dari build UI dengan campuran View dan Compose. Peningkatan ini dapat diperkirakan karena dependensi tambahan ditambahkan ke Sunflower.

Sebaliknya, saat Sunflower dimigrasikan ke aplikasi khusus Compose, ukuran APK turun dari 3.034 KB menjadi 2.966 KB—penurunan 68 KB. Penurunan ini disebabkan karena penghapusan dependensi View yang tidak digunakan, seperti AppCompat dan ConstraintLayout.

Waktu build

Menambahkan Compose akan meningkatkan waktu build aplikasi saat compiler Compose memproses composable di aplikasi Anda. Hasil berikut diperoleh menggunakan alat gradle-profiler mandiri, yang mengeksekusi build beberapa kali sehingga waktu build rata-rata dapat diperoleh untuk durasi build debug Sunflower:

gradle-profiler --benchmark --project-dir . :app:assembleDebug
Tampilan saja View dan Compose Campuran Khusus Compose
Rata-rata waktu build 299,47 md 399,09 md 342,16 md

Saat pertama kali menambahkan Compose ke Sunflower, waktu build rata-rata meningkat dari 299 ms menjadi 399 md—peningkatan 100 md. Durasi ini karena compiler Compose melakukan tugas tambahan untuk mengubah kode Compose yang ditentukan dalam project.

Sebaliknya, waktu build rata-rata turun menjadi 342 md, penurunan 57 md, saat migrasi Sunflower ke Compose selesai. Pengurangan ini dapat dikaitkan dengan beberapa faktor yang secara kolektif mengurangi waktu build seperti menghapus data binding, memigrasikan dependensi yang menggunakan kapt ke KSP, dan mengupdate beberapa dependensi ke versi terbarunya.

Ringkasan

Menggunakan Compose akan secara efektif meningkatkan ukuran APK aplikasi Anda dan juga meningkatkan performa waktu build aplikasi Anda karena proses kompilasi kode Compose. Namun, kompromi ini perlu dipertimbangkan dengan manfaat Compose, terutama terkait peningkatan produktivitas developer saat mengadopsi Compose. Misalnya, tim Play Store menemukan bahwa menulis UI memerlukan jauh lebih sedikit kode, terkadang hingga 50%, sehingga meningkatkan produktivitas dan kemampuan pemeliharaan kode.

Anda dapat membaca studi kasus lainnya di Menggunakan Compose untuk Tim.

Performa Runtime

Bagian ini membahas topik yang berkaitan dengan performa runtime di Jetpack Compose untuk membantu memahami perbandingan Jetpack Compose dengan performa sistem View, dan cara Anda dapat mengukurnya.

Rekomposisi cerdas

Saat sebagian UI Anda tidak valid, Compose akan mencoba merekomposisi bagian yang perlu diupdate saja. Baca selengkapnya tentang hal ini dalam dokumentasi Siklus proses composable dan fase Jetpack Compose.

Profil Dasar Pengukuran

Profil Dasar Pengukuran adalah cara yang sangat baik untuk mempercepat perjalanan pengguna umum. Menyertakan Profil Dasar Pengukuran di aplikasi Anda dapat meningkatkan kecepatan eksekusi kode sekitar 30% sejak peluncuran pertama dengan menghindari langkah interpretasi dan kompilasi tepat waktu (JIT) untuk jalur kode yang disertakan.

Library Jetpack Compose menyertakan Profil Dasar Pengukurannya sendiri dan Anda otomatis mendapatkan pengoptimalan ini saat menggunakan Compose di aplikasi. Namun, pengoptimalan ini hanya memengaruhi jalur kode dalam library Compose, jadi sebaiknya Anda menambahkan Profil Dasar Pengukuran ke aplikasi untuk mencakup jalur kode di luar Compose.

Perbandingan dengan sistem View

Jetpack Compose memiliki banyak peningkatan dibandingkan sistem View. Peningkatan ini dijelaskan di bagian berikut.

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 composable sederhana yang informasinya ditulis ke komposisi dengan cara yang dapat diputar ulang. Hal ini membantu mengurangi pelacakan status, alokasi memori, dan callback eksplisit hanya untuk composable yang memerlukan fitur tersebut, bukan memerlukannya oleh semua ekstensi dari jenis View yang ditentukan.

Selain itu, Compose menyediakan rekomposisi cerdas, yang memutar ulang hasil yang digambar sebelumnya jika Anda tidak perlu melakukan perubahan.

Meneruskan beberapa tata letak

ViewGroup tradisional memiliki banyak ekspresi yang cepat dalam API ukuran dan tata letaknya, sehingga membuatnya rentan terhadap 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 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.

Benchmark 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. Untuk mempelajari cara menggunakannya dengan Jetpack Compose, lihat project MacrobenchmarkSample.

Tim Jetpack Compose juga menggunakan Macrobenchmark untuk menangkap regresi yang dapat terjadi. Misalnya, lihat benchmark untuk kolom lambat 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.