Memigrasikan aplikasi Google Play yang telah berusia dua dekade ke Jetpack Compose

Selamat datang semua!

Nama saya Jon.

Saya bergabung dengan Anda dari tim Google Play Store.

Ini rekan saya, Kirill.

Hari ini, kami akan membahas cara kami memindahkan banyak kode dari sistem View dan Fragment ke Compose.

Mari kita mulai.

Jadi, bagaimana adopsi tersebut berjalan dan seperti apa skalanya?

Jadi, untuk codebase aplikasi kami, codebase ini benar-benar berkembang secara organik sejak sekitar tahun 2007.

Kami memiliki beberapa juta baris kode produksi, 200 layar, dan 500 komponen UI unik yang digunakan di berbagai layar tersebut.

Pada tahun 2020, kami memutuskan, Anda tahu, kecepatan, keandalan, dan performa developer mulai tidak mencapai sasaran yang kami inginkan.

Jadi, kami memutuskan untuk mengadopsi stack teknologi UI modern.

Kami mengevaluasi berbagai library.

Kami juga memiliki beberapa teman di AndroidX yang berbicara dengan kami tentang Compose pada saat itu, dan kami memutuskan untuk mengadopsi Compose dan menjadi partner utama pertama Compose.

Bagaimana hasilnya?

Enam tahun kemudian, kini kami memiliki 97% tayangan pengguna dalam aplikasi Google Play Store di layar khusus Compose.

Maaf, semua pengembangan ponsel dan perangkat layar besar telah beralih ke Compose saja sejak tahun 2020.

Bahkan faktor bentuk kami yang diperluas, XR, TV, Auto, Wear, telah beralih ke Compose sejak 2025.

Compose telah menjadi pendukung yang sangat kuat atas kesuksesan tersebut dan alasan kami terus mengadopsi lebih banyak lagi.

Mereka memiliki suite pengujian yang sangat kuat dan komprehensif yang telah membantu kami mengadopsi versi baru Compose dua kali seminggu.

Dengan menggunakan build alfa dan API baru mereka, kami dapat memanfaatkan perbaikan bug baru, peningkatan performa baru, dan benar-benar mengeksplorasi beberapa API baru tersebut serta memberikan pengalaman pengguna baru.

Khususnya terkait performa, Compose benar-benar memberikan performa jank yang berkelanjutan untuk aplikasi kami di semua layar utama.

Halaman ini adalah halaman hasil penelusuran, halaman beranda, halaman detail.

Metrik ini sangat penting, performa, jank, dan latensi pemuatan, untuk bisnis kami dan juga untuk pengalaman pengguna kami.

Jadi, kami telah melihat peningkatan sebesar 30% selama 14 bulan terakhir.

Bagaimana perjalanan kisahnya sejauh ini?

Itulah yang sebenarnya ingin kita bahas di sini.

Jadi, mari kita bahas rencana migrasi.

Jadi, Play mengambil pendekatan multi-langkah.

Kami tidak ingin langsung terjun dan mempertaruhkan semuanya, bisa dibilang begitu.

Kami akhirnya mengambil beberapa langkah untuk memahami risiko, dampaknya terhadap bisnis kami, dan benar-benar membangun kepercayaan diri sebelum melakukan investasi penuh.

Jadi, saya akan menamainya: merangkak, berjalan, joging, dan berlari.

Jadi, tahap merangkak bagi kami adalah membangun pemahaman tentang Compose.

Kami memulai dengan halaman yang memiliki traffic rendah.

Ini bisa berupa halaman setelan, lisensi pihak ketiga, dan semacamnya.

Tujuan utama Anda adalah memahami library Compose.

Jadi, ini bisa menjadi latihan untuk membiasakan diri dengan Baris, Kolom, Teks, gambar, dan semua hal semacam ini.

Kemudian, Anda harus mulai membawa semua infrastruktur aplikasi dan memahami cara kerjanya dengan cara Compose.

Jadi, ini bisa berupa logging tayangan, logging klik, pembuatan tema, dan kami juga memperbaiki pemuatan data pada saat yang sama.

Jadi, semua hal ini.

Dan satu hal yang kami anggap berguna adalah memastikan bahwa semua layar kami terlihat konsisten, kami membuat beberapa pengujian unit dan pengujian fungsional untuk memeriksa bahwa objek tema kami di Compose dipetakan langsung ke gaya XML, tipografi, warna, dan semua hal ini.

Jadi, setelah kami membangun keakraban dan merasa nyaman, kami memutuskan untuk beralih ke berjalan.

Bagi kami, ini berarti mengambil komponen yang lebih kecil di layar dengan traffic yang sangat tinggi dan mengevaluasi seperti apa migrasi tersebut.

Sebaiknya ambil item yang ada di RecyclerView, sehingga Anda dapat memahami masalah kompatibilitas antara sistem View dan Compose, serta melihat performa pengukuran dan jank di sepanjang prosesnya.

Komponennya sendiri tidak harus terlalu kompleks, tetapi Anda benar-benar ingin memiliki sesuatu yang melatih tata letak, dan Anda tahu, Teks, gambar, hal-hal semacam itu, beberapa contoh berbeda dari yang biasa Anda lihat.

Satu hal yang harus Anda perhatikan dan mungkin Anda perkirakan di area ini adalah peningkatan jank dan latensi, yang akan sedikit, tetapi ini karena Anda sekarang menjalankan dua stack.

Anda memiliki stack rendering yang semuanya ada di Compose dan satu lagi yang ada di View.

Jadi, akan ada beberapa thrashing memori, beberapa pemuatan class tambahan, dan semua hal ini.

Namun, seiring Anda mengadopsi Compose, hal itu akan hilang.

Jika Anda benar-benar membutuhkannya untuk sementara waktu, Anda dapat melakukan sedikit pra-pemanasan layar tersebut untuk membantu menyelaraskannya dan mengurangi biaya tersebut dalam jangka pendek.

Jadi, setelah berjalan, kita beralih ke joging.

Jadi, ini adalah saat kita sudah sangat, sangat nyaman.

Daripada melakukan satu komponen di halaman dengan traffic tinggi, lakukan saja seluruh halaman dengan traffic tinggi.

Jadi, yang kami lakukan adalah tetap mempertahankan library navigasi dan menggunakan Fragmen, tetapi untuk setiap layar, implementasinya dilakukan sepenuhnya di Compose.

Kita baru saja membuat Fragmen menampilkan ComposeView itu sendiri.

Jadi, Anda dapat mengharapkan peningkatan latensi dan jank.

Anda tidak akan mengalami banyak thrashing memori dan pemuatan class yang saya bicarakan.

Compose sendiri juga melakukan beberapa tingkat penyimpanan ke dalam cache di tingkat ComposeView.

Jadi, jika Anda memiliki RecyclerView dengan banyak kartu yang terlihat konsisten dan mungkin memiliki ikon yang sama, semua penguraian ikon dan penggunaan resource tersebut akan dibagikan di antara semua elemen dalam ComposeView.

Jadi, setelah itu, kami beralih ke lari.

Jadi, inilah saatnya Anda benar-benar mengerahkan semua upaya.

Setelah sebagian besar traffic dari aplikasi Anda berada di Compose, kita naik satu level.

Jadi, di atas layar, kita memiliki Aktivitas.

Jadi, pindahkan ComposeView ke root Aktivitas.

Dan banyak kode Anda akan terlihat relatif mirip.

Anda masih mencoba melakukan petunjuk navigasi yang ingin Anda ucapkan, berpindah dari satu layar ke layar lainnya.

Namun, alih-alih melakukan transaksi Fragment, Anda akan memanggil fungsi Composable.

Anda dapat melakukannya di atas library Nav2 atau library Nav3, mana pun yang Anda pilih.

Kami tidak memigrasikan semua layar kami.

Kami sudah menyebutkan bahwa kami memiliki banyak fitur.

Jadi, kami telah membangun kompatibilitas Fragment, yang memungkinkan Anda memiliki layar berbasis Fragment dan memanfaatkan wrapper AndroidFragment Compose untuk melakukannya.

Sekali lagi, jank dan latensi penting bagi bisnis kami, jadi kami terus berupaya meningkatkan performa dan Anda akan terus melihat peningkatan karena sekarang kami memiliki caching di seluruh layar dan masalah thrashing memori ini jauh berkurang.

Namun, Anda juga mendapatkan kemampuan baru.

Kami memiliki contohnya di sebelah kanan dalam GIF ini, yang menunjukkan bahwa Anda dapat melakukan transisi elemen bersama antar-layar.

Jadi, kita memiliki gambar yang diperbesar saat Anda berpindah dari satu layar ke layar lainnya dan gambar tersebut memberikan kontinuitas.

Anda juga dapat memanfaatkan semua fleksibilitas animasi Compose saat melakukan seluruh transisi tersebut.

Selanjutnya, saya akan menyerahkan sesi ini kepada Kirill untuk membahas beberapa kemampuan lainnya.

Terima kasih, Jon.

Saya ingin membahas sedikit tentang topik yang sangat saya sukai, yaitu tema dan gaya untuk aplikasi Android, sesuatu yang telah saya lakukan selama beberapa waktu.

Di dunia View, ada kode Java dan kode Kotlin yang muncul setelahnya, lalu ada resource XML, resource seperti warna, string, dimensi, tata letak, serta tema dan gaya.

Cara kerjanya adalah semua resource XML ini dikompilasi ke tabel resource yang disertakan dalam APK, dan sifatnya cukup statis.

Ada API Resources.Theme.applyStyle yang dapat Anda gunakan secara dinamis saat runtime untuk menerapkan gaya kustom di atas hierarki UI.

Batasan utamanya adalah Anda harus melakukannya sebelum meng-inflate konten, yang berarti jika Anda ingin menerapkan gaya tersebut secara dinamis pada bagian UI yang ada, Anda harus menghapus dan membuat ulang seluruh Aktivitas, yang tidak baik untuk pengalaman pengguna.

Selain itu, karena menerapkan blok XML yang telah dikompilasi sebelumnya, akan sulit untuk menggabungkan beberapa overlay dinamis bersyarat di atas satu sama lain berdasarkan tanda eksperimen atau kebutuhan bisnis lainnya.

Sulit untuk membangun model mental yang tepat dari hierarki gaya di dunia XML tersebut.

Terakhir, tidak ada satu tampilan terpadu di Android Studio atau alat developer lainnya yang memungkinkan Anda menjembatani kesenjangan antara dunia Java, dunia kode, dan dunia XML.

Dan agak sulit untuk mengelola dan membangun model mental yang tepat serta men-debug mengapa gaya saya tidak diterapkan, mengapa saya mendapatkan warna yang salah, dan sebagainya.

Di dunia baru, di dunia Compose, khususnya untuk sistem Desain Material dan library Compose Material, tetapi juga untuk sistem desain lainnya, yang kita miliki adalah untuk sistem Desain Material, kita memiliki Composable MaterialTheme yang Anda terapkan ke bagian paling atas hierarki UI di layar, dan Anda juga dapat menerapkan MaterialTheme ini sebagai overlay pada bagian UI yang lebih kecil.

Jika Anda melihat layar di sebelah kanan, Anda dapat melihat Play Points Gold di bagian atas, yang merupakan kartu kecil di sini dengan indikator progres dan beberapa teks.

Kami menerapkan overlay Tema Material ini dengan skema warna kustom yang dihasilkan oleh library Material Color Utilities, yang tersedia di GitHub untuk Anda gunakan.

Kita meneruskan warna seperti kecokelatan, kuning, emas ini sebagai seed, dan warna ini menghasilkan spektrum penuh token warna material, primer di primer, sekunder di sekunder, yang kemudian kita gunakan di dalam implementasi kartu ini.

Hal ini menghadirkan kemampuan pembuatan tema dinamis yang lengkap ke tangan developer Android.

Semuanya dilakukan dalam kode, semuanya dilakukan di Kotlin, yang berarti jauh lebih mudah untuk membangun model mental yang tepat tentang cara semuanya beroperasi, dan jauh lebih mudah untuk di-debug.

Dan secara internal, overlay ini dilampirkan sebagai composition local ke node UI tertentu dalam hierarki Anda, tempat Anda memilih untuk menerapkannya.

Pertimbangan performa: membuat skema warna lengkap dengan library Material Color Utilities tidaklah gratis.

Hal ini memang disertai dengan overhead tertentu.

Jadi, jika Anda memiliki sesuatu yang cukup rumit dan memerlukan beberapa skema warna, semacam kotak bento, atau apa pun itu, bergantung pada kebutuhan produk Anda, dan Anda memiliki beberapa skema warna yang dihasilkan saat runtime, hal ini akan mulai bertambah, dan mulai menambah latensi dan jank.

Jadi, a, Anda ingin mulai mengukur pengaruhnya terhadap performa, dan b, Anda dapat mengalihkan sebagian overhead ini dari runtime ke waktu build.

Anda dapat menggunakan library Utilitas Warna Material yang sama pada waktu build untuk membuat skema warna tersebut terlebih dahulu berdasarkan kebutuhan branding atau kebutuhan produk Anda, dan mengalihkan overhead ini ke waktu build.

Untuk composition local yang saya sebutkan yang melacak lokasi persis overlay dalam hierarki hierarki UI, harganya jauh lebih murah, tetapi masih belum gratis.

Jadi, bergantung pada jumlah yang Anda gunakan, puluhan, ratusan, jumlahnya akan terus bertambah.

Dan pada titik tertentu, Anda mungkin ingin mulai melihat biaya dari semua komposisi lokal gabungan ini.

Dan ini adalah contoh dari apa yang saya sebutkan, seperti kemampuan pembuatan tema runtime dinamis yang sebenarnya dari Compose.

Di sini kita memiliki empat kuadran, visual yang sama, dan kartu acara yang sama.

Kita memiliki banner besar yang mencakup seluruh kartu, lalu kita memiliki label di kiri atas, tombol di kanan bawah, dan beberapa teks.

Dan di sisi kanan setiap kuadran, Anda akan melihat info tentang token warna yang digunakan sebagai spesifikasi desain untuk setiap elemen.

Implementasi kartu sama persis untuk keempatnya.

Satu-satunya perbedaan adalah overlay Tema Material yang menggabungkan kartu dibuat atau dikonfigurasi dengan skema warna yang dibuat secara dinamis berdasarkan warna dominan gambar: biru, ungu, kuning, dan merah.

Semua hal lainnya tetap sama.

Anda tidak perlu menghapus dan membuat ulang aktivitas.

Anda dapat menerapkannya secara bersyarat berdasarkan flag eksperimen, atau kebutuhan bisnis lainnya.

Dan ini jauh lebih dinamis, seperti yang sudah saya katakan, ini adalah dunia yang jauh lebih dinamis, benar-benar dinamis dalam menerapkan penyesuaian warna ke aplikasi Anda.

Sekarang, kembali ke Jon untuk bagian berikutnya.

Ya.

Jadi, itulah fleksibilitas lain yang dibicarakan Kirill.

Mari kita bahas keandalan dan kecepatan.

Jadi, membangun kode berkualitas tinggi dengan cepat adalah sesuatu yang dicari oleh semua developer dan bisnis.

Jadi, mari kita lihat bagaimana Compose membantu Play melakukan hal tersebut.

Jadi, pertama dan terpenting, saya tahu diagram besar, pertama dan terpenting kesederhanaan arsitektur memiliki manfaat besar bagi semua penulis dan pengelola kode, baik manusia maupun agen.

Saya tidak akan membahasnya terlalu dalam, tetapi salah satu model mental yang coba dihadirkan Compose adalah aliran data searah, dan hal ini benar-benar berdampak besar pada tim kami.

Bagi yang belum memahami cara kerjanya, dasarnya adalah Anda memiliki sumber data.

Sumber data menyediakan data.

Data tersebut mungkin diubah menjadi UI tertentu, yang kita output sebagai model UI.

Kemudian, Compose dapat dengan mudah mengamati hal tersebut hanya dengan memanggil properti nilai pada status tersebut.

Ini adalah semacam panah di sepanjang sisi atas diagram ini.

Kemudian, peristiwa mengalir ke arah yang berlawanan.

Jadi, jika pengguna mengklik tombol, tindakan ini akan kembali ke transformator UI, mengupdate sumber data, memunculkan nilai baru, menjalankan transformasi, dan Anda akan mendapatkan loop ini.

Jadi, semuanya berjalan melalui loop yang relatif sederhana ini.

Manfaat yang benar-benar kami lihat dari hal ini adalah membantu mengurangi waktu penyesuaian.

Tidak ada lagi pertanyaan seperti di mana semua panggilan ini terjadi ke thread utama atau dari thread lain ini.

Proses ini mengikuti satu loop umum.

Compose membuat pengamatan data menjadi sangat mudah, dan data memiliki jaminan konsistensi yang kuat di seluruh lapisan arsitektur.

Model mental ini telah mengurangi banyak percakapan tentang sumber kebenaran dalam tim kami dan sepenuhnya menghapus beberapa jenis kondisi race sekaligus.

Manfaat besar lainnya bagi kami adalah, dibandingkan dengan arsitektur model-view-controller yang kami miliki sebelumnya, eksekusi paralel sumber data dan transformasi UI menjadi sangat mudah.

Jadi, hal ini benar-benar meningkatkan latensi pemuatan kami di Store, Anda tahu, puluhan 50 md atau semacamnya.

Hal ini cukup mengesankan bagi kami.

Dipasangkan dengan aliran data searah, pendukung besar Compose lainnya adalah UI deklaratif.

Kirill sempat membahas hal ini.

Jadi, developer Play juga sangat menikmati hal ini.

Alur kontrol UI kini berada dalam satu file.

Kami memiliki contoh di sebelah kanan yang cukup mudah.

@Composable
fun PurchaseRow(onClick: () -> Unit, modifier: Modifier) {
  Row(modifier) {
    Text("20% off sale")
    if (LocalExpts.current.useButtonV2) {
      ButtonV2("Buy", onClick = onClick)
    } else {
      ButtonV1("Buy", onClick = onClick)
    }
  }
}

Kami beralih di antara dua penerapan tombol berdasarkan flag eksperimen.

Daripada harus membaca beberapa file tampilan atau, Anda tahu, file fragmen dan file XML, Anda cukup membacanya dari atas ke bawah, dan ini membuatnya jauh lebih sederhana.

Biaya composable bertingkat juga jauh lebih rendah daripada hierarki tampilan bertingkat, dan hal ini memungkinkan kami mengatur kode secara alami agar lebih mudah dibaca, tanpa perlu mengorbankan performa sedikit pun.

Manfaat lain yang kami lihat adalah callback siklus proses menjadi jauh lebih sederhana dan jumlahnya berkurang sehingga Anda tidak perlu khawatir.

Jadi, alih-alih memiliki siklus proses tampilan, siklus proses fragmen, siklus proses aktivitas, Anda mendapatkan disposable effect, Anda mendapatkan efek samping, dan bergantung pada tempat Anda menempatkannya, efek tersebut akan bertindak dengan cara yang sangat konsisten.

Jadi, hal itu sangat bermanfaat bagi kami.

Jadi, menurut saya, kedua perubahan arsitektur ini benar-benar menjadi dasar bagi LLM dan memungkinkannya menghasilkan kode yang cukup berkualitas tinggi.

Dan saya yakin banyak dari Anda yang mungkin telah mencoba atau melakukan ini dengan LLM favorit Anda.

Anda dapat mengambil screenshot yang dianotasi dengan warna dan tipografi, lalu memasukkannya ke dalam model. Model ini dapat menghasilkan baris, kolom, teks, dan tombol, serta melakukan tugasnya dengan cukup baik.

Namun, fitur ini memiliki batasan.

Dan yang benar-benar dilihat Play adalah Play tidak memahami codebase Anda, bukan?

AI tidak tahu komponen apa yang sudah Anda buat yang harus digunakan kembali, dan tidak tahu nama token desain.

Ini hanya memberi Anda warna dan string hard code.

Konten apa yang harus berasal dari perangkat, konten apa yang harus berasal dari server, atau bagaimana cara memastikan performanya baik saat menggunakan LazyList dan tidak hanya membuat kolom yang besar?

Jadi, yang kami lakukan untuk mengatasi beberapa masalah ini adalah memberi anotasi pada screenshot tersebut dengan sedikit lebih banyak metadata.

Jadi, nama UI, kotak pembatas agar kita tahu di mana komponen dimulai dan diakhiri, token desain untuk nama semantik warna dan tipografi, keterampilan, dan juga beberapa perintah untuk memberi tahu di mana komponen ini akan ditempatkan sehingga dapat mempertimbangkan performa tersebut.

Lalu, juga signature fungsi tingkat tinggi, sehingga Anda dapat memberi tahu konten mana yang dinamis dan mana yang statis.

Jadi, Anda akan mendapatkan sesuatu seperti yang kita miliki sebelumnya, yang beralih ke setelahnya.

Kami tidak menyertakan kotak pembatas di sini karena akan membuat diagram terlalu rumit.

Namun, Anda dapat melihat warna dan nama tipografi yang di-hardcode tersebut diganti dengan title large dan on surface.

Kita memiliki nama komponen seperti header kartu dan badge ikon yang ditandai dengan jelas.

Dengan begitu, file tersebut dapat ditemukan di codebase Anda.

Dan bagi kami, kami memiliki, Anda tahu, banyak di antaranya juga berasal dari library desain umum, yang akan dibahas Kirill sebentar lagi.

Jadi, Anda tidak perlu memberi label kustom pada semua produk ini setiap saat.

Anda memasangkannya dengan tanda tangan metode seperti yang ada di bagian bawah, OfferCard, dan kemudian, Anda tahu, judul, endDate, dan gambar semuanya bersifat dinamis.

Kita tidak boleh melakukan hard code pada hal tersebut.

Dan bersama dengan nama semantik tersebut, kita kini dapat beralih ke semua penerapan warna berbeda yang dibahas Kirill.

Dengan begitu, kita akan membuat lebih banyak kode.

Saya akan menyerahkan kembali kepada Kirill untuk membahas cara kami menjaga kualitas.

Ya.

Terima kasih, Jon.

Jadi, melanjutkan topik LLM dan pengembangan yang dibantu agen, pertama-tama kita mulai dari sisi desain UX.

Apa pun alat desain pilihan Anda, mungkin Figma, mungkin yang lain, Anda perlu memiliki template bersama yang digunakan oleh semua desainer yang memiliki token warna, token tipografi, token bentuk dari sistem desain pilihan Anda.

Mungkin Material.

Mungkin ini adalah sistem desainer kustom Anda.

Dan Anda ingin secara khusus untuk token warna, Anda ingin template tersebut memiliki dukungan bawaan untuk beralih antara mode terang dan gelap serta untuk beralih antara mode kontras normal, sedang, dan tinggi yang diperkenalkan di level Android beberapa tahun lalu.

Dengan begitu, desainer dapat beralih dengan cepat di antara berbagai kombinasi ini untuk melihat respons spesifikasi desain mereka.

Kemudian, saat desain diselesaikan dan diserahkan ke sisi implementasi, dalam pipeline ekspor tersebut, Anda ingin memiliki semacam kemampuan untuk melacak bahwa setiap warna, setiap elemen tipografi, setiap bentuk menggunakan token yang cocok, bukan nilai RGB, jenis font, atau ukuran font yang di-hardcode.

Dan terakhir, yang kami anggap sangat berguna dalam skala Google Play, kami memiliki, bahkan bukan puluhan, kami memiliki beberapa ratus komponen, cluster, kartu, penampung yang digunakan di berbagai layar yang kami miliki.

Kami merasa berguna untuk melacak semua ini di satu tempat, yang kami sebut katalog komponen, lalu melatih agen kustom pada katalog komponen tersebut.

Agen ini berguna saat Anda memulai layar baru, mungkin perjalanan pengguna baru, mungkin area produk baru, dan dari eksplorasi desain awal tersebut, mungkin slide, mungkin spesifikasi Figma, Anda dapat memasukkannya ke agen tersebut, dan agen tersebut akan membantu mengidentifikasi dengan cepat komponen mana yang sudah ada sehingga tidak perlu didesain ulang dan ditentukan ulang, sehingga tidak perlu diimplementasikan ulang dari awal.

Hal ini mengurangi biaya desain dan biaya implementasi secara signifikan.

Di sisi implementasi, kami sangat mengandalkan aturan Lint inti dan kustom.

Beberapa aturan Lint inti yang ingin saya sebutkan adalah FrequentlyChangingValueDetector yang membantu mengidentifikasi sumber rekomposisi yang tidak perlu, yang dapat menyebabkan latensi dan jank, dan yang lainnya adalah ScaffoldPaddingDetector untuk menandai kasus saat kita menggunakan composable Scaffold Compose Material, tetapi mengabaikan padding yang masuk.

Ini bukan sumber latensi dan jank, tetapi, dalam beberapa kasus, dapat menyebabkan ketidakselarasan tata letak yang sangat sulit di-debug, seperti, dalam kasus tertentu, seperti, layar penuh, atau melipat, membuka lipatan.

Terakhir, BoxWithConstraints, memiliki pertimbangan performa tertentu.

Mungkin diperlukan dua frame untuk menata letak semuanya dengan benar.

Kami tidak memblokirnya secara langsung, tetapi kami menandainya sebagai peringatan Lint sehingga developer yang mengerjakan layar tertentu tahu bahwa mereka membuat pilihan khusus untuk menggunakan BoxWithConstraints, atau mungkin mereka dapat memilih untuk menggunakan sesuatu yang lain untuk tata letak tertentu tersebut.

Untuk otomatisasi tema, sekali lagi, token warna, token tipografi, token bentuk.

Kami memiliki aturan Lint yang memblokir penggunaan warna hardcode dan tipografi hardcode.

Kami memiliki aturan Lint yang menandai penggunaan komponen Material 2.

Kami hanya ingin menggunakan Material 3, yang terbaru dan terbaik, termasuk komponen ekspresif baru yang diperkenalkan tahun lalu dan tahun ini.

Kami memiliki aturan Lint kustom yang mencegah orang membaca warna dari, misalnya, file XML lama.

Kami ingin menggunakan Compose-first dan Compose-only untuk layar baru.

Dan, composable Text, khususnya dalam sistem desain Material, memiliki penggantian untuk gaya dan warna.

Keduanya membaca dari warna konten lokal dan tipografi lokal, tetapi kita tidak ingin mengandalkan hal itu.

Kita ingin setiap teks menggunakan gaya tertentu, gaya tipografi, dan warna tertentu dari spesifikasi desain.

Jadi, itulah aturan Lint yang kami miliki.

Dan yang terakhir, sejalan dengan ScaffoldPaddingDetector, kami memiliki aturan Lint kustom yang menerapkan bahwa setiap fungsi Composable yang kami miliki menggunakan pengubah inputnya.

Sekali lagi, untuk mencegah, misalnya, penggunaan baru ditempatkan secara tidak benar, atau tidak menghormati latar belakang yang masuk, atau apa pun itu.

Dan ini adalah tiga poin utama yang ingin kami sampaikan dalam presentasi ini.

Pertama, saat ini, pada akhir tahun 2026, menurut kami, Compose adalah toolkit UI yang matang dan terbukti dalam skala besar.

Android sendiri mengutamakan Compose.

Awal tahun ini di Google I/O, kami mengumumkan bahwa semua library UI dan semua alur agen mengutamakan Compose.

Dan, seperti yang disebutkan Jon sebelumnya dalam presentasi, merangkak, berjalan, joging, dan berlari, sebaiknya Anda bermigrasi secara bertahap, terutama codebase besar, untuk mempercepat kecepatan alur developer dan alur agentic.

Terakhir, kami berterima kasih atas waktu Anda hari ini, dan dalam beberapa menit, saya dan Jon akan berada di luar untuk menjawab pertanyaan Anda.

Sekali lagi, terima kasih atas waktu Anda.