Studi Kasus

Grab Mengurangi ANR Sebesar 32% dan Meningkatkan Waktu Startup Sebesar 35% dengan R8 dan Pengoptimalan yang Dipandu Profil

Waktu baca: 5 menit

Grab adalah superapp terkemuka di Asia Tenggara, yang menawarkan layanan pengiriman, mobilitas, dan keuangan kepada jutaan pengguna di delapan negara melalui satu aplikasi. Dengan codebase berusia 10 tahun yang berisi lebih dari 10 juta baris kode dan ratusan library pihak ketiga yang dibuat menggunakan penyiapan Bazel dan Gradle hybrid, tim Grab menghadapi tiga tantangan yang terus berkembang: tingkat Aplikasi Tidak Merespons (ANR) yang tinggi, ukuran aplikasi yang terus bertambah seiring dengan penambahan layanan baru pada superapp, dan waktu startup yang perlahan meningkat dari tahun ke tahun.  Dengan mengaktifkan pengoptimalan R8, menyempurnakan aturan keep, serta menerapkan Profil Dasar Pengukuran dan Profil Startup, Grab mengurangi rasio ANR yang dirasakan pengguna sebesar 32%, memangkas ukuran download aplikasi sekitar 30%, dan meningkatkan waktu startup sebesar 35%.

Menghilangkan Lonjakan ANR Pasca-Rilis untuk Pengalaman Pengguna yang Lebih Lancar

Sebelum mengoptimalkan proses build-nya, Grab mengalami penundaan cold start dan lonjakan Aplikasi Tidak Merespons (ANR) segera setelah update baru, yang terutama disebabkan oleh overhead pembacaan banyak file DEX selama inisialisasi aplikasi. 

Meskipun Profil Cloud Google Play memberikan pengoptimalan untuk alur standar di seluruh basis pengguna, profil tersebut tidak mengoptimalkan semua jalur inisialisasi yang diperlukan untuk perjalanan penting pengguna Grab—seperti menginisialisasi grafik dependensi Dagger selama peluncuran aplikasi. Untuk alur kode yang tidak tercakup dalam distribusi awal, perangkat mengandalkan kompilasi JIT dan pengoptimalan latar belakang lokal selama beberapa hari berikutnya. Penerapan Profil Baseline kustom menyelesaikan masalah ini dengan menyediakan perjalanan penting pengguna ini langsung ke Profil Cloud Google Play, sehingga memperluas cakupan pengoptimalannya agar jalur utama ini segera dikompilasi ke kode mesin saat penginstalan 

ANDDM_Grab_Inline_Quote_ALT.png

"Kami terus mengalami lonjakan rasio ANR setiap kali merilis aplikasi mingguan," jelas Nguyen Van Minh, Lead Software Engineer di tim Passenger App Core Grab. 

Untuk menghilangkan ANR dan meningkatkan waktu startup, Grab menerapkan pengoptimalan R8, Profil Dasar Pengukuran, dan Profil Startup. Pengoptimalan yang dipandu profil bersama pengoptimal R8 memberikan peningkatan cold start langsung sebesar 12% dari R8 dan tambahan 15% dari Profil Dasar Pengukuran—mencapai waktu startup 27% lebih cepat dan secara efektif menghilangkan lonjakan ANR pasca-rilis.

Grab menjalankan pengoptimalan aplikasi ini dalam tiga fase strategis: mengaktifkan pengoptimalan R8 dalam mode kompatibilitas, beralih ke Mode Penuh R8, lalu menyempurnakan aturan keep dengan Configuration Analyzer dan menambahkan tata kelola CI/CD.

Fase 1: Mengaktifkan Pengoptimalan R8  (Diluncurkan pada 2025)

Pada tahap pertama ini, Grab beralih dari file Proguard default lama untuk mengadopsi proguard-android-optimize.txt, yang mengaktifkan pengoptimalan R8.  Karena codebase-nya sudah berusia lebih dari satu dekade dan berisi lebih dari 10 juta baris kode, pengaktifan pengoptimal memerlukan penanganan konfigurasi lama dan penggunaan refleksi.

Untuk memaksimalkan dampak fase ini, Grab merilis update aplikasi yang mengaktifkan mode Kompatibilitas R8 dengan Profil Dasar Pengukuran dan Profil Startup. Upaya gabungan ini menghasilkan pengurangan langsung sebesar 25% dalam rasio ANR yang Dirasakan Pengguna, pengurangan sebesar 16% dalam ukuran download aplikasi, dan peningkatan keseluruhan sebesar 27% dalam waktu cold start.

Fase 2: Mode Lengkap & Migrasi R8 (Diluncurkan pada 2026)

Diluncurkan sembilan bulan setelah peluncuran pertama, fase ini mengalihkan aplikasi ke Mode Lengkap R8, yang memungkinkan pengoptimalan lebih lanjut. Meskipun library standar seperti Retrofit, Firebase, dan Jetpack Compose berfungsi lancar dengan R8 menggunakan aturan bawaannya, migrasi codebase yang sangat besar lainnya dilakukan dengan menyelesaikan alur kode tertentu yang sangat bergantung pada refleksi:

Untuk bermigrasi ke mode R8 Full, tim mengadopsi aturan keep konsumen dari rilis Gson terbaru untuk memastikan penguraian JSON yang lancar. Mereka juga mengatasi tantangan pengoptimalan dengan proxy dinamis Java, yang menggunakan refleksi untuk menghasilkan implementasi antarmuka saat runtime. Karena R8 tidak dapat mendeteksi penggunaan runtime ini selama kompilasi, R8 akan menghapus atau mengganti nama class yang diperlukan, sehingga menyebabkan aplikasi error. Daripada menerapkan pengecualian luas yang akan memperbesar ukuran aplikasi, tim mengisolasi class tertentu yang mengandalkan refleksi dan menerapkan aturan keep yang sangat bertarget, sehingga menjaga stabilitas aplikasi dan efisiensi pengoptimalan

Pada akhirnya, Mode Lengkap R8 memberikan peningkatan yang signifikan dan berlipat ganda, termasuk pengurangan ukuran download aplikasi sebesar 14%, peningkatan waktu startup sebesar 10%, dan penurunan ANR yang dirasakan pengguna sebesar 10%. Setelah migrasi ke Mode Lengkap R8, codebase Grab mencapai skor Pengoptimalan R8 ini. 

  • Skor Pengoptimalan: 72%
  • Skor Penyingkatan: 73%
  • Skor Obfuscation: 79,6%

Skor ini memberikan masukan tentang konfigurasi R8 dan perlunya menyempurnakan aturan keep untuk memaksimalkan pengoptimalan R8. 

Fase 3: Penyempurnaan Aturan Keep 

Pada fase akhir perjalanan pengoptimalannya, Grab berfokus untuk membangun kesehatan codebase jangka panjang, pemantauan performa berkelanjutan, dan tata kelola kompilasi yang ketat. Untuk mengukur kebersihan aturan secara sistematis dan mencegah regresi konfigurasi di seluruh siklus rilis yang sedang berlangsung, tim mengintegrasikan R8 Configuration Analyzer ke dalam alur kerja evaluasi mereka. Alat ini memberikan visibilitas mendalam tentang seberapa efektif aturan mempertahankan Grab memungkinkan R8 mengoptimalkan, memperkecil, dan meng-obfuscate aplikasi.

Dengan membangun fondasi Mode Lengkap R8 dan secara metodis memangkas aturan keep lama, Grab mendapatkan peningkatan substansial di ketiga dimensi inti yang dievaluasi oleh penganalisis:

  • Skor Pengoptimalan: meningkat dari 72% menjadi 78,2%
  • Skor Penyingkatan: meningkat dari 73% menjadi 79,1%
  • Skor Obfuscation: meningkat dari 79,6% menjadi 81,7%

Selain meningkatkan skor diagnostik ini, fase penyempurnaan aturan keep khusus ini menghasilkan pengurangan ukuran download aplikasi tambahan sebesar ~3,6%. Yang lebih penting, pelacakan metrik ini memberi tim engineering data objektif yang diperlukan untuk menerapkan pengaman CI pra-penggabungan otomatis yang memastikan bahwa kode yang baru diperkenalkan mematuhi standar keep-rule yang ketat dan bahwa peningkatan performa yang diperoleh dengan susah payah tetap terlindungi dari waktu ke waktu.

Hasil

Peningkatan performa utama setelah peluncuran pengoptimal R8:

Fase PengoptimalanANRUkuranCold Start
Fase 1: Pengoptimal R8 (Diluncurkan pada 2025)~25% penguranganpengurangan 16%~27% peningkatan
Fase 2: Mode Penuh R8 (Diluncurkan pada 2026)pengurangan 10%penurunan 14%Peningkatan 10%
Pengoptimalan Aturan Keep-penurunan 3,6%-
Keseluruhan (Kumulatif)Pengurangan ~32,5%~30,4% pengurangan~35% peningkatan

Tantangan Teknis 

Mengaktifkan pengoptimal R8 di seluruh codebase Grab yang berusia satu dekade menimbulkan rintangan teknis utama dalam skala besar:

  • Pengujian: Akumulasi refleksi selama satu dekade menciptakan kasus ekstrem dalam pengoptimalan penuh. Karena pengujian menyeluruh di jutaan LOC tidak mungkin dilakukan, tim mengambil pendekatan inkremental dengan prioritas tinggi—khususnya memfokuskan pengujian pada kode yang dicakup oleh aturan keep yang dipersempit, dan secara iteratif menyempurnakan aturan tersebut untuk menargetkan hanya class, metode, atau kolom tertentu yang diperlukan untuk refleksi guna memaksimalkan pengoptimalan R8
  • Latensi build dan arsitektur hybrid: Sistem build hybrid Grab (Bazel untuk debug, Gradle untuk build rilis R8) berarti perubahan R8 eksperimental memerlukan waktu hingga 2 jam di CI jarak jauh. Untuk menjembatani kesenjangan masukan, Grab menyelaraskan build QA hariannya agar sesuai dengan perilaku R8 produksi dan mengotomatiskan pengumpulan artefak build CI utama seperti mapping.txt, configuration.txt untuk penyelidikan yang efisien.
  • Siklus proses debug yang lambat: Melacak penyebab utama di ratusan class yang dioptimalkan memberikan beban berat pada tim ramping. Grab mengatasi masalah ini dengan mengotomatiskan upload file pemetaan ke Firebase Crashlytics melalui Gradle dan memaketkan pemetaan deobfuskasi untuk Konsol Play, sehingga memungkinkan resolusi simbol yang instan dan akurat untuk masalah runtime

Dampak Kode Jangka Panjang dengan R8

Selain peningkatan performa langsung, mengaktifkan pengoptimal R8 memberikan keunggulan struktural permanen untuk codebase Grab yang sangat besar. Di Grab, tim menggunakan alat open source app-sizer untuk mengukur dampak R8 dan mengamati bahwa R8 secara permanen menurunkan biaya setiap baris kode dalam aplikasi dalam ukuran download.

ANDDM_Grab_Inline_Metric.png

Di era pengembangan yang didukung AI, saat volume kode berkembang pesat, pengoptimalan ini menjadi lebih penting. Tanpa R8, perluasan kode akan meningkatkan ukuran download secara proporsional. R8 memastikan bahwa tingkat perluasan kode yang sama mempertahankan jejak memori yang berkurang secara drastis.

Catatan: Metodologi: kontribusi Kotlin/Java app-sizer terhadap ukuran download aplikasi (perangkat representatif), dibagi dengan LOC Kotlin produksi (cloc; hanya set sumber utama; tidak termasuk modul pengujian, tiruan, dan contoh).

Pengelolaan Aturan dan Pedoman Keep

Untuk mencegah penurunan kualitas aturan dan mempertahankan pengoptimalan R8 dari waktu ke waktu, Grab berencana mengintegrasikan guardrail pra-penggabungan otomatis langsung ke pipeline CI mereka. Berdasarkan kebijakan ini, aturan penyimpanan baru sangat dibatasi dan aturan tambahan apa pun memerlukan justifikasi dan peninjauan eksplisit. Tim di Grab melacak skor pengoptimalan R8 di CI. Berdasarkan hal ini, tim berencana menggunakan metrik ini sebagai feedback loop berkelanjutan, sehingga regresi dapat diketahui sebelum penggabungan dan peningkatan pengoptimalan dipertahankan di setiap siklus rilis. 

R8-rules-score (1).png

Gambar 1: Dasbor CI yang melacak skor penyingkatan, pengoptimalan, dan obfuscation R8 dari waktu ke waktu dalam build Grab untuk secara proaktif menemukan dan mencegah regresi di seluruh rilis.

Kesimpulan 

Menghadapi tantangan codebase yang besar dan terus berkembang, tim Pax App Core Grab secara proaktif mengatasi peningkatan waktu startup dan lonjakan performa pasca-rilis dengan menerapkan Profil Dasar Pengukuran dan terus meningkatkan Konfigurasi R8. Tim ini mengurangi ANR yang dirasakan pengguna sekitar 32,5%, memangkas ukuran download aplikasi sekitar 30,3%, dan meningkatkan waktu cold start sekitar 35%, sekaligus meningkatkan efisiensi penskalaan codebase mereka secara mendasar.

Pengoptimalan ini memberikan pengalaman superapp yang lebih cepat dan stabil bagi jutaan pengguna di seluruh Asia Tenggara, sekaligus memberi engineer Grab alat untuk membangun fitur lebih cepat tanpa risiko peningkatan ukuran download yang cepat.

Untuk memulai dan mempelajari lebih lanjut R8, buka - d.android.com/r8.

Ditulis oleh:
Lanjutkan membaca