Masalah kinerja dapat membuat pengembang bekerja lebih keras. Dalam posting blog ini, Anda dapat belajar dari masalah kinerja yang kami alami di Kraken dan bagaimana kami memulai perjalanan penerapan Arsitektur Baru untuk mengatasi masalah tersebut. Ya, ada kendala di sepanjang jalan. Kami belajar darinya, dan kami harap Anda juga bisa.
Arsitektur Baru akan menjadi standar, dimulai dari React Native 0.76 dan Expo SDK 52, rilis React Native dan Expo berikutnya. Fitur-fitur baru yang sedang dikembangkan akan diimplementasikan hanya untuk Arsitektur Baru dan beberapa pustaka sudah menghentikan dukungan untuk arsitektur lama. Anda harus benar-benar mulai berpikir untuk mengadopsinya jika Anda tidak ingin ketinggalan!
Ikhtisar arsitektur Kraken
Kraken adalah salah satu platform mata uang kripto terbesar, tepercaya, dan aman, dengan komunitas yang aktif dengan lebih dari 13 juta klien di seluruh dunia. Saat ini kami memiliki tiga aplikasi seluler dalam tahap produksi – semuanya ditulis dalam React Native dengan sejumlah pustaka dan komponen asli khusus dalam Swift/Kotlin, dan backend dalam Rust.
Meskipun kami tidak menggunakan rangkaian Expo lengkap karena alasan historis, kami telah mulai bermigrasi untuk menggunakan modul Expo melalui beberapa paket komunitas karena alasan pemeliharaan dan performa. Performa merupakan perhatian utama bagi kami, khususnya di aplikasi Pro kami, yang padat data dan penuh dengan bagan interaktif yang terus diperbarui melalui WebSockets. Hal ini membebani performa, khususnya pada perangkat Android kelas bawah. Jadi, untuk waktu yang lama kami terus memantau kemajuan Arsitektur Baru dan berharap hal itu akan meringankan beberapa masalah yang kami hadapi.
Di akhir perjalanan ini, kami mampu meningkatkan kinerja aplikasi kami secara signifikan di beberapa area:
Perender aplikasi lengkap: 1,3x lebih cepat
Perender layar beranda: 2,5x lebih cepat
Render layar aliran perdagangan: 5,3x lebih cepat
Dan masih banyak lagi…
Teruslah membaca untuk mempelajari perjalanan kami dan semua manfaat kinerja lainnya yang menyertainya.
Rencana adopsi Arsitektur Baru kami
Sasaran utama kami adalah meningkatkan kinerja di Android. Tindakan pertama yang kami lakukan adalah membuat bukti konsep cepat menggunakan Fabric agar dapat memperkirakan perolehannya. Meskipun basis kode kami cukup besar dan banyak dependensi, hal ini dilakukan cukup cepat dengan memanfaatkan lapisan interop lama dan menyingkirkan pustaka/komponen yang tidak kompatibel. Hasilnya adalah aplikasi yang terasa jauh lebih cepat yang didukung dengan metrik kinerja yang objektif.
Mengetahui bahwa ekosistem masih dalam fase migrasi dan memperkirakan adanya beberapa kendala, kami memutuskan untuk mengadopsi Arsitektur Baru secara bertahap guna mengurangi risiko rekayasa. Ini berarti beralih dari satu platform ke platform lain, satu aplikasi ke aplikasi lain, dan satu fitur arsitektur ke fitur lain. Rencana kami yang disederhanakan tampak seperti ini:
Perbarui pustaka komponen pihak ketiga dan migrasikan komponen internal untuk mendukung perender baru dan lama
Perbarui pustaka modul asli pihak ketiga dan migrasikan pustaka internal ke Modul Turbo Asli
Aktifkan mode tanpa jembatan
Hapus kompatibilitas mundur setelah diluncurkan sepenuhnya
Kendala kecepatan adopsi Arsitektur Baru
Dalam perjalanan adopsi bertahap kami, kami menemui beberapa kendala. Ini sudah bisa diduga. Di bagian ini, kami akan membahas masing-masing kendala dengan harapan dapat membantu tim lain mengatasinya dengan lebih cepat daripada kami.
Cepat
Tidak seperti Turbo Modules, komponen Fabric tidak secara resmi memiliki dukungan Swift. Ini mengecewakan karena basis kode kami menggunakan Swift dan kami tidak ingin kembali ke Objective-C. Dengan beberapa inspirasi dari pustaka Lottie (dan bantuan dari video dari Coding With Nobody), kami berhasil membuatnya berfungsi. Perlu dicatat bahwa Expo Modules memiliki dukungan Swift asli dan API yang bisa dibilang lebih bagus. Kami juga mengawasi proyek Nitro dari Marc Rousavy yang mungkin mendukung komponen Fabric di masa mendatang.
Pengerjaan batch otomatis
Pada beberapa layar, kami memperhatikan proses rendering yang terasa lebih lambat, terutama layar yang memerlukan banyak rendering seperti grafik interaktif.
Meskipun kami tidak sepenuhnya yakin dengan akar permasalahannya, kami menduga bahwa hal ini disebabkan oleh batching otomatis yang diperkenalkan di React 18, yang hanya didukung pada Arsitektur Baru. Teorinya adalah bahwa meskipun batching menyebabkan beban CPU yang lebih sedikit, batching juga melewatkan beberapa langkah perantara yang memberikan kesan lebih cepat. Pada akhirnya, komponen tersebut tidak dibangun dengan benar, jadi setelah refaktor dan migrasi untuk menggunakan Reanimated untuk interaksi yang sensitif terhadap kinerja, masalah tersebut terpecahkan.
Tanpa jembatan
Karena mode Bridgeless adalah bagian terbaru dari teka-teki Arsitektur Baru, kami ingin mengadopsi mode ini terakhir, meskipun ini adalah perubahan yang paling tidak mengganggu (terima kasih kepada mode interop yang hebat). Namun, rencana kami tidak berhasil karena Expo 51 tidak mendukung Fabric tanpa menggunakan mode Bridgeless. Ini menjadi masalah bagi kami karena kami menginginkan beberapa perbaikan di React Native 0.74 yang berarti kami harus mengadopsi Bridgeless sedikit lebih cepat dari yang direncanakan.
Secara keseluruhan tidak rumit, dengan satu pengecualian: CodePush akan segera dihentikan dan kami mengandalkan requestIdleCallback untuk beberapa metrik performa kami. Saat ini kami sedang dalam proses migrasi ke pembaruan Expo, tetapi sementara ini kami telah memperbaiki dukungan melalui patch-package/yarn patch dan membackport requestIdleCallback, yang didukung mulai dari 0.75.
Lapisan interop
Mode interop untuk komponen Old Renderer berfungsi dengan baik untuk sebagian besar komponen Android, tetapi untuk iOS kami menemukan bahwa terdapat masalah tata letak pada salah satu komponen asli internal kami. Bagaimanapun, ini bukanlah tujuan akhir yang kami inginkan, dan kami menyelesaikannya dengan memigrasikannya ke Fabric.
Pelindung
Di awal pengembangan, kami menyadari bahwa cabang yang berfungsi dengan baik dalam pengembangan tiba-tiba mogok dalam versi produksi dengan pesan kesalahan yang agak samar. Setelah menyelidiki, kami menemukan bahwa hal ini disebabkan oleh Proguard yang menghapus kelas dan metode pihak ketiga tertentu. Mungkin hal ini disebabkan oleh sifat Turbo Modules yang malas, yang membingungkan pengoptimal Proguard sehingga mengira bahwa mereka tidak digunakan. Setelah kami menemukan masalahnya, mudah saja untuk mengecualikan simbol-simbol tersebut agar tidak dihapus.
Peluncuran
Seperti yang disebutkan sebelumnya, kami ingin mengadopsi Arsitektur Baru secara bertahap sebisa mungkin. Idealnya, kami ingin melakukannya per layar, dan meskipun Arsitektur Baru didukung secara native, saat ini tidak didukung oleh React Navigation, jadi kami harus berhati-hati saat meluncurkan Fabric. Namun, karena lapisan interop, kami berhasil meluncurkan arsitektur baru di tingkat proyek.
guru besar
Meskipun kami memiliki banyak pengujian komponen menggunakan React Testing Library, sayangnya, pengujian tersebut tidak akan memberi kami keyakinan dalam mengadopsi perender baru; sebagai gantinya kami sangat bergantung pada pengujian ujung ke ujung otomatis kami di Maestro Cloud. Di sinilah kami menjalankan rangkaian kinerja kami untuk memberikan angka pasti sebelum memasuki tahap produksi.
Pengujian internal
Biasanya kami tidak bergantung pada pengujian manual, tetapi karena perubahan ini lebih berdampak dan tidak dapat dengan mudah dibatalkan dengan fitur yang ditandai, kami mendistribusikan versi secara internal agar orang-orang dapat menguji dan memverifikasi bahwa alur kerja mereka berfungsi seperti yang diharapkan. Ini sangat berguna untuk menemukan regresi rendering di layar khusus yang awalnya terlewatkan karena kurangnya pengujian visual.
“Pelepasan burung kenari”
Ketika kami yakin telah menguji sebanyak mungkin dengan dan tanpa otomatisasi, kami ingin menyajikannya kepada sejumlah kecil pengguna produksi. Kami biasanya menggunakan tanda fitur di LaunchDarkly untuk ini, tetapi karena sebagian besar bagian Arsitektur Baru adalah tanda kompilasi, ini bukanlah pilihan. Sebagai gantinya, kami memilih versi rilis canary yang lebih murah melalui peluncuran bertahap di Play Store.
Aplikasi kami dirilis setiap minggu, dan pada dasarnya setelah kami menganggap suatu rilis stabil dan diluncurkan sepenuhnya ke tahap produksi, kami akan menyajikan versi dengan Arsitektur Baru yang diaktifkan kepada sebagian kecil pengguna. Karena rilis bertahap di Play Store dapat dihentikan, kami dapat membatasi dampaknya terhadap pengguna jika terjadi bug atau kerusakan serius. Selain itu, peluncuran ke depan lebih cepat karena proses peninjauan yang umumnya lebih cepat.
Pemantauan klien nyata
Setelah aplikasi berada di tangan klien kami, kami secara ketat memantau stabilitas, kinerja, dan metrik produk/konversi.
Stabilitas melalui Sentry dan Play Store
Performa melalui Sentry dengan metrik khusus kami sendiri
Metrik produk terutama melalui Mixpanel
Hasil adopsi Arsitektur Baru
Stabilitas
Dalam beberapa build pertama kami, kami melihat sedikit penurunan stabilitas karena crash pada salah satu library pihak ketiga yang hanya ada pada Arsitektur Baru dan memengaruhi alur yang cukup langka. Setelah kami memperbaiki masalah ini, stabilitasnya setara dengan arsitektur lama dengan 99,9% sesi bebas crash.
Pertunjukan
Secara keseluruhan, data produksi kami menunjukkan bahwa waktu render menjadi jauh lebih cepat, tetapi dengan variabilitas yang besar antara layar yang berbeda. Kami juga memperhatikan bahwa peningkatan terbesar terlihat pada perangkat yang paling lambat – baik secara absolut maupun relatif – yang merupakan kejutan yang menyenangkan.
Namun, tidak semuanya berjalan lebih cepat: Cold start asli menjadi sedikit lebih lambat, yang agak mengejutkan mengingat migrasi kami ke Turbo Modules. Karena ukuran biner aplikasi meningkat dengan Arsitektur Baru yang diaktifkan, asumsi kami saat ini adalah bahwa hal ini disebabkan oleh bagian-bagian yang masih ada dari arsitektur lama. Kami berharap hal ini akan membaik di masa mendatang saat migrasi selesai sepenuhnya dan dengan inisiatif seperti pustaka dinamis gabungan tunggal milik Nicola.
React Native 0.76 akan dikirimkan dengan satu pustaka dinamis gabungan yang disebut `https://t.co/w2nNNDov97`: https://t.co/peZ08rvbtS
Hal ini memberikan penghematan ruang yang besar bagi pengguna serta peningkatan kinerja
—Nicolas (lahir 1975)
(@cortinico) 20 Agustus 2024
Secara keseluruhan, metrik kami yang paling penting dan lebih holistik yang berdampak pada pengguna yang disebut App Render Complete –yang mencakup boot asli, boot js, jaringan, dan rendering—telah ditingkatkan.
Ukuran
hal50
Hlm95
Render Aplikasi Selesai
1 lembar
1,3x
Render Layar Beranda
2x
2,5x
Render Layar Aliran Perdagangan
3,8x
5,3x
Mulai Dingin Asli
0,9x
0,7x
Navigasi Total Waktu Pemblokiran
1 lembar
1.1x
Langkah selanjutnya
Dengan Arsitektur Baru yang berhasil diterapkan, kami berupaya untuk lebih memanfaatkan kemampuan baru yang diperoleh, seperti:
Gunakan useDeferredValue untuk komponen yang sering diperbarui, tetapi kurang penting seperti ticker harga
Perbaiki contoh tata letak yang tidak beraturan dengan mengganti onLayout dengan panggilan pengukuran() yang sinkron
Paparkan pustaka Rust yang ada dari backend ke aplikasi melalui pengikatan JSI
Terima kasih
Nicola Corti dan tim React Native di Meta karena menyediakan sumber daya yang sangat berguna untuk mengadopsi arsitektur baru dan bersikap reseptif terhadap, serta dengan cepat menangani masukan.
Brent Vatne di Expo karena mendorong upaya membuat ekosistem bermigrasi ke arsitektur baru dan menjawab pertanyaan mendalam.
Seluruh tim Software Mansion yang telah melakukan tugas besar dalam migrasi banyak pustaka inti pihak ketiga seperti reanimated, gesture handler, screens dan svg.
Memulai dengan Kraken
Materi ini hanya untuk tujuan informasi umum dan bukan merupakan saran investasi atau rekomendasi atau ajakan untuk membeli, menjual, mempertaruhkan, atau menahan aset kripto apa pun atau untuk terlibat dalam strategi perdagangan tertentu. Kraken tidak membuat pernyataan atau jaminan apa pun, tersurat maupun tersirat, mengenai keakuratan, kelengkapan, ketepatan waktu, kesesuaian, atau validitas informasi tersebut dan tidak akan bertanggung jawab atas segala kesalahan, kelalaian, atau keterlambatan dalam informasi ini atau segala kerugian, cedera, atau kerusakan yang timbul dari tampilan atau penggunaannya. Kraken tidak dan tidak akan berupaya untuk menaikkan atau menurunkan harga aset kripto tertentu yang disediakannya. Beberapa produk dan pasar kripto tidak diatur, dan Anda mungkin tidak dilindungi oleh kompensasi pemerintah dan/atau skema perlindungan peraturan. Sifat pasar aset kripto yang tidak dapat diprediksi dapat menyebabkan hilangnya dana. Pajak mungkin harus dibayarkan atas setiap pengembalian dan/atau atas setiap peningkatan nilai aset kripto Anda dan Anda harus mencari nasihat independen tentang posisi perpajakan Anda. Pembatasan geografis mungkin berlaku.
Postingan tentang penerapan Arsitektur Baru secara bertahap oleh Kraken untuk memperbaiki masalah kinerja muncul pertama kali di Blog Kraken.
Sumber: Kraken
Postingan tentang adopsi bertahap Arsitektur Baru oleh Kraken untuk memperbaiki masalah kinerja muncul pertama kali di Crypto Breaking News.
