Masjid Sejuta Pemuda — Performance Audit

Konteks

Masjid Sejuta Pemuda (MSP) adalah aplikasi mobile consumer yang menyatukan fitur ibadah harian (jadwal shalat, dzikir, Al-Quran), program donasi/wakaf, dan informasi event komunitas Muslim. Aplikasinya sudah live dan punya basis pengguna aktif, tapi kontraktor Flutter sebelumnya membangunnya dengan pendekatan cepat: banyak widget tanpa const, state management yang menerus ke parent, dan beberapa fitur yang seharusnya stateless tapi diimplementasi dengan setState di tree yang terlalu tinggi.

Tim klien menyadari aplikasinya terasa berat pada device low-end dan minta Banua Coder mengaudit, mendiagnosis, dan memperbaiki tanpa membongkar fitur yang sudah jalan.

Yang Kami Bangun

1. Diagnosis dengan Performance Overlay & Rebuild Rainbow

Sebelum mengubah satu baris kode pun, kami menyalakan dua tooling Flutter bawaan untuk mendapat bukti objektif:

• Performance Overlay menampilkan grafik frame time secara live. Di perangkat pengujian kami, max frame time menyentuh 62.8 ms — jauh di atas budget 16 ms untuk 60 fps. Banyak bar merah berarti banyak frame jank yang terlihat patah-patah oleh user.
• Rebuild Rainbow (widget rebuild visualizer) menggambar outline berwarna setiap kali widget di-rebuild. Yang kami lihat: garis warna menyala di hampir seluruh home screen, setiap detik. Itu artinya countdown timer waktu subuh tidak hanya merebuild dirinya sendiri — ia memicu rebuild seluruh tree di atasnya.

2. Iterasi 1 — const audit

Langkah pertama adalah pekerjaan paling mendasar: audit setiap widget statis yang seharusnya bisa pakai const constructor. Widget const di Flutter direuse dari frame ke frame tanpa rebuild, jadi menambahkan const di tempat yang tepat menurunkan jumlah pekerjaan setiap frame secara signifikan.

Hasil terlihat di overlay — frame time turun ke target 16 ms dan jank merah jauh berkurang. Tapi rebuild rainbow masih menunjukkan widget tree di-rebuild di area yang luas.

3. Iterasi 2 — encapsulate sections menjadi widget terpisah

Berikutnya kami pisahkan setiap section home screen (header dengan jadwal shalat, statistik komunitas, daftar program, shortcut) ke dalam widget sendiri. Tujuannya: membatasi jangkauan setState supaya kalau ada satu section yang berubah, dia tidak menyeret rebuild ke section lain.

Hasil: rebuild area menyempit, tapi countdown timer di dalam header masih memicu rebuild section header secara keseluruhan, termasuk widget yang seharusnya statis.

4. Iterasi 3 — text-rotator dan countdown widget custom

Inti masalah yang tersisa: paket text-rotator dan countdown yang dipakai kontraktor sebelumnya menggunakan setState di parent yang terlalu tinggi. Setiap detik, mereka memaksa parent rebuild, dan hasil rebuild itu menyebar ke semua child di section yang sama.

Solusinya: kami bangun ulang dua widget itu dari nol. Widget text-rotator custom dan countdown custom buatan kami punya internal state yang sepenuhnya isolated — perubahan teks atau angka countdown tidak pernah memicu rebuild ke parent. Hanya widget yang berisi teks itu sendiri yang ikut rebuild.

5. Hasil akhir — bukti di overlay yang sama

Kami menjalankan ulang aplikasi dengan Performance Overlay dan rebuild rainbow yang sama persis seperti di awal audit. Frame time stabil di bawah 16 ms (target 60 fps tercapai). Rebuild rainbow hanya menyala di widget countdown sub-second — sisa home screen tetap statis di setiap frame.

Dampak

Yang kami selesaikan bukan sekadar “aplikasi lebih cepat”. Yang lebih penting: tim klien sekarang punya bukti objektif — di overlay yang sama — bahwa aplikasinya telah memenuhi standar performa Flutter yang umum dipakai di industri (frame budget 16 ms, isolated rebuild). Mereka juga punya artefak proses (rekaman screen + dokumentasi) yang dapat mereka jadikan checklist internal saat mengembangkan fitur baru atau mengaudit kontraktor lain di masa depan.

Bagi Banua Coder, engagement ini adalah contoh nyata bagaimana Flutter performance debugging berbeda dari “menulis ulang aplikasi”: kami tidak mengganti fitur, tidak meredesign UI, tidak mengubah arsitektur backend. Kami hanya membaca apa yang sudah ada secara objektif lewat tooling Flutter, mengidentifikasi sumber jank dan rebuild loop dengan presisi, dan memperbaikinya dengan intervention minimum.