Fase Jetpack Compose

Seperti toolkit UI pada umumnya, Compose merender frame melalui beberapa fase yang berbeda. Jika kita melihat sistem Android View, sistem ini memiliki tiga fase utama: pengukuran, tata letak, dan gambar. Compose sangat mirip, tetapi memiliki fase tambahan penting yang disebut komposisi di awal.

Komposisi dijelaskan di seluruh dokumen Compose kami, termasuk Paradigma Compose serta Status dan Jetpack Compose.

Tiga fase frame

Compose memiliki tiga fase utama:

1. Komposisi: UI apa yang akan ditampilkan. Compose menjalankan fungsi composable dan membuat deskripsi UI Anda.
2. Tata letak: Tempat untuk menempatkan UI. Tahap ini terdiri dari dua langkah: pengukuran dan penempatan. Elemen tata letak mengukur dan menempatkan dirinya sendiri serta elemen turunan apa pun dalam koordinat 2D, untuk setiap node dalam hierarki tata letak.
3. Gambar: Cara merender. Elemen UI menggambar ke dalam Canvas, biasanya layar perangkat.

Gambar 1. Tiga fase saat Compose mengubah data menjadi UI.

Urutan fase ini umumnya sama, memungkinkan data mengalir dalam satu arah dari komposisi ke tata letak hingga gambar untuk menghasilkan frame (juga dikenal sebagai aliran data searah). BoxWithConstraintsdan LazyColumn dan LazyRow merupakan pengecualian yang signifikan, ketika komposisi turunannya bergantung pada fase tata letak induk.

Anda dapat dengan aman berasumsi bahwa tiga fase ini terjadi hampir untuk setiap frame, tetapi untuk keperluan performa, Compose menghindari pekerjaan berulang yang akan menghitung hasil yang sama dari input yang sama di semua fase ini. Compose melewati fungsi composable jika dapat menggunakan kembali hasil sebelumnya, dan Compose UI tidak akan menata ulang atau menggambar ulang seluruh hierarki jika tidak perlu. Compose hanya melakukan pekerjaan minimum yang diperlukan untuk mengupdate UI. Pengoptimalan ini mungkin karena Compose melacak pembacaan status dalam berbagai fase.

Memahami fase-fase

Bagian ini menjelaskan cara tiga fase Compose dijalankan untuk composable secara lebih terperinci.

Komposisi

Pada fase komposisi, runtime Compose menjalankan fungsi composable dan menghasilkan struktur pohon yang merepresentasikan UI Anda. Hierarki UI ini terdiri dari yang berisi semua informasi yang diperlukan untuk fase berikutnya, seperti yang ditampilkan dalam video berikut:

Gambar 2. Hierarki yang mewakili UI Anda yang dibuat dalam komposisi fase sebelumnya.

Subbagian kode dan hierarki UI terlihat seperti berikut:

Gambar 3. Subbagian dari hierarki UI dengan kode yang sesuai.

Dalam contoh ini, setiap fungsi composable dalam kode dipetakan ke satu tata letak di hierarki UI. Dalam contoh yang lebih kompleks, composable dapat berisi logika dan alur kontrol, dan menghasilkan pohon yang berbeda dengan status yang berbeda.

Tata Letak

Pada fase tata letak, Compose menggunakan hierarki UI yang dihasilkan dalam fase komposisi sebagai input. Kumpulan node tata letak berisi semua informasi yang diperlukan untuk memutuskan ukuran dan lokasi setiap {i> node<i} dalam ruang 2D.

Gambar 4. Pengukuran dan penempatan setiap node tata letak di hierarki UI selama fase tata letak.

Selama fase {i>layout<i}, pohon dilalui menggunakan tiga langkah berikut algoritme:

1. Mengukur turunan: Node mengukur turunannya jika ada.
2. Menentukan ukuran sendiri: Berdasarkan pengukuran ini, node memutuskan sendiri ukuran.
3. Turunan tempat: Setiap node turunan ditempatkan relatif terhadap node sendiri posisi Anda.

Pada akhir fase ini, setiap node tata letak memiliki:

• width dan height yang ditetapkan
• Koordinat x, y di mana koordinat x, y harus digambar

Ingat kembali hierarki UI dari bagian sebelumnya:

Untuk pohon ini, algoritma bekerja sebagai berikut:

1. Row mengukur turunannya, Image dan Column.
2. Image diukur. Ia tidak memiliki turunan, jadi ia memutuskan sendiri dan melaporkan ukurannya kembali ke Row.
3. Berikutnya, Column diukur. Properti tersebut mengukur turunannya sendiri (dua Text composable) terlebih dahulu.
4. Text pertama diukur. Ia tidak memiliki turunan, jadi ia memutuskan ukurannya sendiri dan melaporkan ukurannya kembali ke Column.
   1. Text kedua diukur. Ia tidak memiliki turunan, jadi ia memutuskan ukurannya sendiri dan melaporkannya kembali ke Column.
5. Column menggunakan pengukuran turunan untuk menentukan ukurannya sendiri. Fungsi ini menggunakan lebar turunan maksimum dan jumlah tinggi turunannya.
6. Column menempatkan turunannya relatif terhadap dirinya sendiri, menempatkannya di bawah satu sama lain secara vertikal.
7. Row menggunakan pengukuran turunan untuk menentukan ukurannya sendiri. Fungsi ini menggunakan tinggi turunan maksimum dan jumlah lebar turunannya. Kemudian menempatkan untuk turunan-turunannya.

Perhatikan bahwa setiap node hanya dikunjungi satu kali. Runtime Compose hanya memerlukan satu melewati hierarki UI untuk mengukur dan menempatkan semua node, yang meningkatkan tingkat tinggi. Ketika jumlah {i>node<i} dalam pohon meningkat, waktu yang dihabiskan menjelajahinya meningkat secara linier. Sebaliknya, jika setiap {i>node<i} dikunjungi beberapa kali, waktu traversal meningkat secara eksponensial.

Gambar

Dalam fase menggambar, pohon itu akan dilalui lagi dari atas ke bawah, dan setiap node menggambar dirinya sendiri di layar secara bergantian.

Gambar 5. Fase menggambar menggambar piksel di layar.

Menggunakan contoh sebelumnya, konten hierarki digambar dengan cara berikut:

1. Row menggambar konten apa pun yang mungkin ada di dalamnya, seperti warna latar belakang.
2. Image akan menggambar dirinya sendiri.
3. Column akan menggambar dirinya sendiri.
4. Text pertama dan kedua masing-masing akan digambar.

Gambar 6. Hierarki UI dan representasi yang digambar.

Pembacaan status

Saat Anda membaca nilai status snapshot selama salah satu fase yang tercantum di atas, Compose akan otomatis melacak tindakan yang dilakukan saat nilai dibaca. Pelacakan ini memungkinkan Compose mengeksekusi ulang pembaca saat nilai status berubah, dan merupakan dasar dari kemampuan observasi status di Compose.

Status biasanya dibuat menggunakan mutableStateOf(), lalu diakses melalui salah satu dari dua cara berikut: dengan langsung mengakses properti value, atau menggunakan delegasi properti Kotlin. Anda dapat membaca hal tersebut lebih lanjut di Status dalam composable. Untuk tujuan panduan ini, "pembacaan status" merujuk ke salah satu metode akses yang setara tersebut.

// State read without property delegate.
val paddingState: MutableState<Dp> = remember { mutableStateOf(8.dp) }
Text(
    text = "Hello",
    modifier = Modifier.padding(paddingState.value)
)
PhasesSnippets.kt

// State read with property delegate.
var padding: Dp by remember { mutableStateOf(8.dp) }
Text(
    text = "Hello",
    modifier = Modifier.padding(padding)
)
PhasesSnippets.kt

Di balik layar delegasi properti, fungsi "pengambil" dan "penyetel" digunakan untuk mengakses dan memperbarui value Status. Fungsi pengambil dan penyetel ini hanya dipanggil saat Anda mereferensikan properti sebagai nilai, bukan saat dibuat, itulah sebabnya dua cara di atas setara.

Setiap blok kode yang dapat dieksekusi ulang saat status baca berubah adalah cakupan mulai ulang. Compose melacak perubahan nilai status dan memulai ulang cakupan dalam berbagai fase.

Pembacaan status bertahap

Seperti disebutkan di atas, ada tiga fase utama pada Compose, dan Compose melacak status apa yang dibaca di setiap tahap. Hal ini memungkinkan Compose hanya memberi tahu fase tertentu yang perlu melakukan pekerjaan untuk setiap elemen UI Anda yang terpengaruh.

Catatan: Jika instance status dibuat dan disimpan memiliki sedikit dampak pada fasenya, instance hanya diperlukan ketika nilai status dibaca.

Mari pelajari setiap fase dan jelaskan apa yang terjadi saat nilai status dibaca yang ada di dalamnya.

Fase 1: Komposisi

Pembacaan status dalam fungsi @Composable atau blok lambda memengaruhi komposisi dan mungkin fase berikutnya. Saat nilai status berubah, recomposer menjadwalkan eksekusi ulang semua fungsi composable yang membaca nilai status tersebut. Perhatikan bahwa runtime dapat memutuskan untuk melewati beberapa atau semua fungsi composable jika input belum berubah. Lihat Melewati jika input belum berubah untuk informasi selengkapnya.

Bergantung pada hasil komposisi, Compose UI menjalankan fase menggambar dan tata letak. Android mungkin melewati fase ini jika konten tetap sama dan ukuran serta tata letak tidak akan berubah.

var padding by remember { mutableStateOf(8.dp) }
Text(
    text = "Hello",
    // The `padding` state is read in the composition phase
    // when the modifier is constructed.
    // Changes in `padding` will invoke recomposition.
    modifier = Modifier.padding(padding)
)
PhasesSnippets.kt

Fase 2: Tata Letak

Fase tata letak terdiri dari dua langkah: pengukuran dan penempatan. Langkah pengukuran menjalankan lambda pengukuran yang diteruskan ke composable Layout, metode MeasureScope.measure dari antarmuka LayoutModifier, dan seterusnya. Langkah penempatan menjalankan blok penempatan fungsi layout, blok lambda Modifier.offset { … }, dan seterusnya.

Pembacaan status selama setiap langkah ini memengaruhi tata letak dan kemungkinan fase menggambar. Saat nilai status berubah, Compose UI akan menjadwalkan fase tata letak. Compose UI juga menjalankan fase menggambar jika ukuran atau posisi telah berubah.

Lebih tepatnya, langkah pengukuran dan langkah penempatan memiliki cakupan mulai ulang terpisah. Artinya, pembacaan status pada langkah penempatan tidak memanggil kembali langkah pengukuran tersebut sebelumnya. Namun, kedua langkah ini sering kali terkait, sehingga pembacaan status pada langkah penempatan dapat memengaruhi cakupan mulai ulang lainnya yang termasuk dalam langkah pengukuran.

var offsetX by remember { mutableStateOf(8.dp) }
Text(
    text = "Hello",
    modifier = Modifier.offset {
        // The `offsetX` state is read in the placement step
        // of the layout phase when the offset is calculated.
        // Changes in `offsetX` restart the layout.
        IntOffset(offsetX.roundToPx(), 0)
    }
)
PhasesSnippets.kt

Fase 3: Menggambar

Pembacaan status selama menggambar kode memengaruhi fase menggambar. Contoh umumnya meliputi Canvas(), Modifier.drawBehind, dan Modifier.drawWithContent. Saat nilai status berubah, Compose UI hanya menjalankan fase menggambar.

var color by remember { mutableStateOf(Color.Red) }
Canvas(modifier = modifier) {
    // The `color` state is read in the drawing phase
    // when the canvas is rendered.
    // Changes in `color` restart the drawing.
    drawRect(color)
}
PhasesSnippets.kt

Mengoptimalkan pembacaan status

Saat Compose melakukan pelacakan pembacaan status yang dilokalkan, kita dapat meminimalkan jumlah pekerjaan yang dilakukan dengan membaca setiap status dalam fase yang sesuai.

Mari kita lihat contoh berikut. Di sini, kita memiliki Image() yang menggunakan pengubah offset untuk mengimbangi posisi tata letak akhirnya, sehingga menghasilkan efek paralaks saat pengguna men-scroll.

Box {
    val listState = rememberLazyListState()

    Image(
        // ...
        // Non-optimal implementation!
        Modifier.offset(
            with(LocalDensity.current) {
                // State read of firstVisibleItemScrollOffset in composition
                (listState.firstVisibleItemScrollOffset / 2).toDp()
            }
        )
    )

    LazyColumn(state = listState) {
        // ...
    }
}
PhasesSnippets.kt

Kode ini berfungsi, tetapi menghasilkan performa yang tidak optimal. Seperti yang ditulis, kode membaca nilai status firstVisibleItemScrollOffset dan meneruskannya ke fungsi Modifier.offset(offset: Dp). Saat pengguna men-scroll, nilai firstVisibleItemScrollOffset akan berubah. Seperti yang kita ketahui, Compose melacak setiap pembacaan status sehingga dapat memulai ulang (memanggil kembali) kode pembacaan, yang dalam contoh ini adalah konten dari Box.

Ini adalah contoh status yang sedang dibaca dalam fase komposisi. Hal ini tidak selalu buruk, dan bahkan merupakan dasar rekomposisi, yang memungkinkan perubahan data memunculkan UI baru.

Dalam contoh ini meskipun tidak optimal, karena setiap peristiwa scroll akan mengakibatkan seluruh konten composable dievaluasi ulang, lalu diukur, ditata, dan digambar. Kita memicu fase Compose di setiap scroll meskipun apa yang ditampilkan tidak berubah, hanya tempat scroll ditampilkan. Kita dapat mengoptimalkan pembacaan status agar hanya memicu kembali fase tata letak.

Tersedia versi pengubah offset lain: Modifier.offset(offset: Density.() -> IntOffset).

Versi ini mengambil parameter lambda, tempat offset yang dihasilkan ditampilkan oleh blok lambda. Untuk menggunakannya, mari perbarui kode kita:

Box {
    val listState = rememberLazyListState()

    Image(
        // ...
        Modifier.offset {
            // State read of firstVisibleItemScrollOffset in Layout
            IntOffset(x = 0, y = listState.firstVisibleItemScrollOffset / 2)
        }
    )

    LazyColumn(state = listState) {
        // ...
    }
}
PhasesSnippets.kt

Mengapa performanya lebih baik? Blok lambda yang kita berikan ke pengubah dipanggil saat fase tata letak (khususnya, selama langkah penempatan fase tata letak), artinya, firstVisibleItemScrollOffset status tidak lagi dibaca selama komposisi. Karena Compose melacak saat status dibaca, perubahan ini berarti bahwa jika nilai firstVisibleItemScrollOffset berubah, Compose hanya perlu memulai ulang fase tata letak dan menggambar.

Catatan: Anda mungkin bertanya-tanya apakah mengambil parameter lambda dapat menambah biaya tambahan dibandingkan dengan mengambil nilai sederhana. Jawabannya ya. Namun, dalam kasus ini, manfaat membatasi pembacaan status ke fase tata letak akan melebihi biaya. Nilai firstVisibleItemScrollOffset berubah setiap frame selama scroll, dan dengan menunda pembacaan status ke fase tata letak, kita dapat menghindari rekomposisi selama ini.

Contoh ini bergantung pada berbagai pengubah offset agar dapat mengoptimalkan kode yang dihasilkan, tetapi ide umumnya adalah benar: coba lokalkan pembacaan status ke fase terendah yang memungkinkan, dengan memungkinkan Compose melakukan jumlah pekerjaan minimum.

Tentu saja, biasanya pembacaan status sangat diperlukan dalam fase komposisi. Meski begitu, ada kasus saat kita dapat meminimalkan jumlah rekomposisi dengan memfilter perubahan status. Untuk informasi selengkapnya tentang hal ini, lihat derivedStateOf: konversi satu atau beberapa objek status ke status lain.

Loop rekomposisi (dependensi fase siklus)

Sebelumnya, kita menyebutkan bahwa fase Compose selalu dipanggil dalam urutan yang sama, dan bahwa tidak ada cara untuk mundur saat berada dalam frame yang sama. Namun, hal itu tidak melarang aplikasi masuk ke loop komposisi di berbagai frame yang berbeda. Perhatikan contoh ini:

Box {
    var imageHeightPx by remember { mutableStateOf(0) }

    Image(
        painter = painterResource(R.drawable.rectangle),
        contentDescription = "I'm above the text",
        modifier = Modifier
            .fillMaxWidth()
            .onSizeChanged { size ->
                // Don't do this
                imageHeightPx = size.height
            }
    )

    Text(
        text = "I'm below the image",
        modifier = Modifier.padding(
            top = with(LocalDensity.current) { imageHeightPx.toDp() }
        )
    )
}
PhasesSnippets.kt

Di sini kita mengimplementasikan (dengan buruk) kolom vertikal, dengan gambar di bagian atas, lalu teks di bawahnya. Kita menggunakan Modifier.onSizeChanged() untuk mengetahui ukuran gambar yang telah diselesaikan, lalu menggunakan Modifier.padding() pada teks untuk menggesernya ke bawah. Konversi yang tidak wajar dari Px kembali ke Dp sudah menunjukkan bahwa kode memiliki beberapa masalah.

Masalah pada contoh ini adalah kita tidak sampai di tata letak "final" dalam satu frame. Kode ini mengandalkan beberapa frame yang terjadi, yang melakukan pekerjaan yang tidak perlu, dan menyebabkan UI melompat-lompat di layar untuk pengguna.

Mari kita lihat setiap frame untuk melihat apa yang terjadi:

Pada fase komposisi frame pertama, imageHeightPx memiliki nilai 0, dan terdapat teks pada Modifier.padding(top = 0). Kemudian, fase tata letak mengikuti, dan callback untuk pengubah onSizeChanged dipanggil. Ini adalah ketika imageHeightPx diperbarui ke tinggi gambar yang sebenarnya. Compose menjadwalkan rekomposisi untuk frame berikutnya. Pada fase menggambar, teks dirender dengan padding 0 karena perubahan nilai belum direfleksikan.

Kemudian, Compose memulai frame kedua yang dijadwalkan oleh perubahan nilai imageHeightPx. Statusnya dibaca dalam blok konten Box, dan dipanggil dalam fase komposisi. Kali ini, teks diberikan dengan padding yang cocok dengan tinggi gambar. Pada fase tata letak, kode memang menetapkan nilai imageHeightPx lagi, tetapi tidak ada rekomposisi yang dijadwalkan karena nilai tetap sama.

Pada akhirnya, kita mendapatkan padding yang diinginkan di teks, tetapi tidak optimal untuk menghabiskan frame tambahan guna meneruskan nilai padding kembali ke fase yang berbeda dan akan menghasilkan frame dengan konten yang tumpang-tindih.

Contoh ini mungkin terlihat rumit, tetapi berhati-hatilah dengan pola umum ini:

• Modifier.onSizeChanged(), onGloballyPositioned(), atau beberapa operasi tata letak lainnya
• Perbarui beberapa status
• Gunakan status tersebut sebagai input untuk pengubah tata letak (padding(),height(), atau yang serupa)
• Berpotensi berulang

Perbaikan untuk contoh di atas adalah dengan menggunakan primitif tata letak yang tepat. Contoh di atas dapat diterapkan dengan Column() sederhana, tetapi Anda mungkin memiliki contoh yang lebih kompleks yang memerlukan kustomisasi, dan akan memerlukan penulisan tata letak kustom. Lihat panduan Tata letak kustom untuk mengetahui informasi selengkapnya.

Prinsip umumnya di sini adalah memiliki satu sumber kebenaran untuk beberapa elemen UI yang harus diukur dan ditempatkan terkait dengan satu sama lain. Menggunakan primitif tata letak yang tepat atau membuat tata letak kustom berarti induk minimal berfungsi sebagai sumber tepercaya yang dapat mengoordinasikan hubungan antara beberapa elemen. Memperkenalkan status dinamis akan melanggar prinsip ini.