Composition: esensi, pembangunan pohon UI di Compose

Apa itu Composition di Jetpack Compose

Composition — adalah proses eksekusi fungsi Composable, yang menghasilkan representasi internal antarmuka pengguna dalam bentuk pohon node. Setiap node dari pohon ini sesuai dengan komponen bawaan (Text, Button, Image) atau panggilan fungsi Composable kustom. Composition tidak langsung membuat objek View Android — ia membangun deskripsi abstrak yang kemudian diproses oleh fase Layout dan Drawing.

Ciri utama Composition adalah kemampuan restart ulang (restartability). Setiap fungsi Composable dalam komposisi dapat dijalankan ulang kapan saja jika parameter masukannya atau objek status yang dibacanya berubah. Sistem tidak merestart seluruh pohon — hanya fungsi yang benar-benar bergantung pada data yang berubah.

Secara teknis, Composition dikelola melalui Composer — mesin internal yang disematkan kompiler Kotlin ke dalam setiap fungsi Composable. Composer menulis ke dalam slot (grup posisi) informasi tentang fungsi mana yang dipanggil, dengan parameter apa, dan dalam urutan apa. Pada panggilan berikutnya, Composer membandingkan data baru dengan data yang disimpan dan memutuskan untuk merestart.

Bagaimana pohon UI dibangun dalam proses Composition

Proses pembangunan pohon UI dimulai dengan pemanggilan metode setContent di dalam Activity atau Fragment. Metode ini membuat Composition awal dan memulai eksekusi fungsi Composable akar. Kemudian setiap fungsi Composable bersarang menambahkan node-nya ke pohon, membentuk hierarki: Row berisi Text dan Button, Column berisi Image dan Card, dan seterusnya.

Setiap node pohon mendapatkan kunci posisi unik, berdasarkan posisinya dalam kode sumber. Kunci ini digunakan untuk mengidentifikasi node pada eksekusi berulang. Kunci posisi adalah alasan mengapa urutan pemanggilan fungsi Composable tidak boleh bergantung pada kondisi: jika dalam satu eksekusi dipanggil A -> B, dan pada eksekusi berikutnya B -> A, Compose tidak akan dapat mencocokkan node lama dan baru.

@Composable
fun AppScreen() {
    Column {                     // Node Column (posisi 1)
        HeaderSection()            // Node HeaderSection (posisi 2)
        ContentSection()           // Node ContentSection (posisi 3)
        FooterSection()            // Node FooterSection (posisi 4)
    }
}

@Composable
fun HeaderSection() {
    Row {                       // Node Row (posisi 2.1)
        Text("Judul")         // Node Text (posisi 2.2)
        Icon(...)                // Node Icon (posisi 2.3)
    }
}

Dalam contoh ini, setiap panggilan mendapatkan posisi berdasarkan urutan dalam kode. Column (posisi 1) berisi tiga node anak (posisi 2, 3, 4). HeaderSection menambahkan dua node anak lagi (2.1, 2.2, 2.3). Jika dalam rek komposisi berikutnya ContentSection dipanggil sebelum HeaderSection, Composer tidak akan dapat mencocokkan node dengan benar — maka aturannya: urutan pemanggilan fungsi Composable harus stabil.

Manajemen status di Composition

Status di Composition dikelola melalui objek bertipe State<T>. Ketika fungsi Composable membaca nilai dari State melalui properti delegasi (by), ia mendaftarkan ketergantungan pada State tersebut. Saat nilai berubah, semua fungsi yang membaca State ini ditandai untuk dijalankan ulang pada fase komposisi berikutnya.

Mekanisme pendaftaran ketergantungan disebut sistem snapshot. Setiap kali State berubah, snapshot mencatat semua perubahan dan memberi tahu Composer fungsi mana yang bergantung pada State ini. Penting untuk dipahami: membaca State dalam kode non-Composable (misalnya dalam lambda onClick) tidak mendaftarkan ketergantungan — hanya pembacaan di dalam fungsi Composable atau dalam lambda yang dijalankan dalam konteks komposisi.

Sistem snapshot bekerja secara transaksional: beberapa perubahan State dalam satu peristiwa digabungkan menjadi satu transaksi, mencegah beberapa rek komposisi. Ini sangat penting dalam pemrosesan gestur: selama satu gerakan, beberapa objek State berubah, tetapi Compose hanya menjalankan satu rek komposisi.

@Composable
fun StateExample() {
    var text by remember { mutableStateOf("Hello") }
    var isVisible by remember { mutableStateOf(true) }

    Column {
        Text(text)  // mendaftarkan ketergantungan pada text

        if (isVisible) {  // mendaftarkan ketergantungan pada isVisible
            TextField(value = text, onValueChange = { text = it })
        }

        Button(onClick = { isVisible = !isVisible }) {
            Text(if (isVisible) "Sembunyikan" else "Tampilkan")
        }
    }
}

Perubahan text menyebabkan rek komposisi hanya pada Column, Text, dan TextField. Button dan kondisi isVisible tetap tidak berubah. Isolasi rek komposisi semacam ini adalah keunggulan utama Compose dibandingkan sistem yang menggambar ulang seluruh layar. Setiap fungsi Composable hanya melacak objek State yang dibacanya secara langsung.

Composition vs Recomposition: perbedaan utama

Composition (komposisi) dan Recomposition (rek komposisi) — adalah dua mode eksekusi fungsi Composable yang berbeda. Composition terjadi satu kali saat pembuatan layar: sistem menjalankan semua fungsi Composable dengan nilai awal dan membangun pohon UI awal. Recomposition terjadi berkali-kali saat perubahan data: sistem merestart hanya fungsi yang bergantung pada status yang berubah.

Mode Composition mengaktifkan semua node pohon, mengalokasikan slot untuk setiap fungsi, mendaftarkan semua turunan. Recomposition bekerja secara selektif: Composer membandingkan nilai parameter baru dan lama dari setiap fungsi, dan jika tidak berubah — fungsi tidak dijalankan (skipping).

Composition dan Recomposition berbeda dalam biaya. Composition pertama lebih mahal, karena memerlukan pembangunan pohon lengkap dan alokasi slot. Recomposition lebih murah, terutama jika sebagian besar fungsi stabil — parameternya dibandingkan dengan equals, dan Compose melewatkan panggilannya. Untuk kinerja maksimal, harus diupayakan agar sesedikit mungkin fungsi yang terkena rek komposisi.

CompositionLocal: mengirimkan data melalui pohon

CompositionLocal — mekanisme pengiriman data implisit melalui pohon komposisi. Ini memecahkan masalah ketika parameter harus dikirimkan melalui puluhan fungsi Composable bersarang yang tidak menggunakannya secara langsung. Alih-alih rantai parameter eksplisit, data diatur di tingkat atas dan dibaca di fungsi bersarang mana pun melalui CompositionLocal.current.

Tema MaterialTheme — contoh CompositionLocal yang paling terkenal. Semua komponen Compose membaca warna, tipografi, dan bentuk melalui MaterialTheme.colorScheme, MaterialTheme.typography, MaterialTheme.shapes, tanpa menerimanya melalui parameter. Pengembang dapat membuat CompositionLocal sendiri untuk data seperti pengguna saat ini, pengaturan lokalisasi, atau konfigurasi layar.

Batasan penting: CompositionLocal tidak boleh digunakan untuk data yang sering berubah (posisi gulir, teks di bidang input). Komponen yang membaca CompositionLocal di-restart setiap kali nilai berubah, oleh karena itu untuk data dinamis lebih baik menggunakan parameter eksplisit atau State. CompositionLocal optimal untuk data konfigurasi yang jarang atau tidak pernah berubah.

val LocalUser = compositionLocalOf<User?> { null }

@Composable
fun AppRoot(user: User, content: @Composable () -> Unit) {
    CompositionLocalProvider(LocalUser.provides(user)) {
        content()
    }
}

@Composable
fun UserAvatar() {
    val user = LocalUser.current  // membaca tanpa parameter eksplisit
    AsyncImage(model = user?.avatarUrl, contentDescription = "Avatar")
}

CompositionLocalProvider menciptakan lingkup visibilitas, di dalamnya LocalUser.current mengembalikan nilai yang ditetapkan. UserAvatar membaca pengguna tanpa pengiriman parameter eksplisit melalui fungsi perantara. Ini sangat berharga dalam hierarki dalam di mana data hanya diperlukan di beberapa node daun.