Belajar Mobile Developer - Performance & Profiling

#Pendahuluan

Fitur lengkap tidak berarti apa-apa jika aplikasi terasa lambat. Di episode 15 ini kita belajar performance & profiling: mengapa layar terasa "laggy", bagaimana mengukur secara objektif, dan tools apa saja yang dipakai profesional untuk menemukan akar masalah. Performa adalah bagian dari UX — pengguna tidak akan memaafkan aplikasi yang janky meski fiturnya hebat.

Mengapa topik ini menantang? Karena masalah performa hampir selalu kontekstual: lambat di satu device, cepat di device lain. Tanpa pengukuran (profiling), kita hanya menebak — dan menebak jarang benar.

#Memahami Rendering & Frame

Layar di-refresh 60 (atau 120) kali per detik. Setiap refresh adalah satu frame; aplikasi punya waktu ±16ms (60Hz) untuk menghasilkan frame:

┌──────────────────────────────┐
│ Frame budget = 16.6ms (60Hz) │
│ UI thread        ───► render  │
│ Main queue   (layout+draw)    │
│ Kegagalan budget = jank/drop  │
└──────────────────────────────┘

Jank terjadi saat frame melampaui budget — pengguna melihat "tersendat". Sumber jank paling umum: kerja berat di main thread (parsing JSON besar, render list panjang tanpa virtualisasi, layout tidak perlu).

#Sumber Masalah Performa

#1. Rendering

• List panjang dirender semua: gunakan LazyColumn/FlatList/ListView/LazyVStack (virtualisasi).
• Recomposition/rebuild berlebihan: state berubah di parent, semua child ikut render.
• Layout yang mahal: menampung banyak widget/view tanpa perlu.

Virtualisasi list di Compose

// BURUK: Column + for → semua item di-render
// BAIK: LazyColumn → hanya item terlihat
LazyColumn {
    items(workouts, key = { it.id }) { workout ->
        WorkoutRow(workout)
    }
}

#2. Memory

Memory leak = objek tidak bisa dibebaskan GC karena masih direferensikan. Gejala: aplikasi membengkak, kemudian OS membunuhnya (OutOfMemory crash). Penyebab umum: observer/listener tidak di-unregister, Context disimpan statis, coroutine/timer tidak dibatalkan.

Potensi leak: ViewModel tidak membatalkan kerja

// BURUK: scope global, berjalan setelah ViewModel mati
val job = CoroutineScope(Dispatchers.IO).launch { ... }
 
// BAIK: scope yang mati bersama ViewModel
viewModelScope.launch { ... }

#3. Baterai

Baterai boros biasanya karena: lokasi di-polling terus-menerus, wakelock yang tidak dilepas, network sering, atau background service berlebihan (episode 14). Android menyediakan Battery Historian/Battery section di Profiler; iOS punya Energy Log.

#Tools Profiling per Stack

#Android Studio Profiler & Perfetto

Android Studio Profiler menampilkan CPU, memory, network, energy secara live. Untuk analisis dalam, Perfetto (trace system) menangkap aktivitas seluruh sistem:

adb shell perfetto -o /data/misc/perfetto-traces/trace -t 10s \
  sched freq idle atrace gfx view am wm
adb pull /data/misc/perfetto-traces/trace ./trace.perfetto-trace

Buka file di ui.perfetto.dev untuk melihat timeline frame, komposisi, dan proses yang bekerja.

#Xcode Instruments

Di iOS, Instruments adalah toolkit: Time Profiler (CPU), Allocations & Leaks (memory), Core Animation (rendering). Jalankan lewat Product → Profile (⌘I):

let start = CFAbsoluteTimeGetCurrent()
let items = workouts.filter { $0.isToday }
print("filter: \(CFAbsoluteTimeGetCurrent() - start)s")

#Flutter DevTools & RN

• Flutter DevTools (flutter run + keyboard shortcut) menyediakan Performance overlay, Memory, CPU profiler. Metrik kunci: build time per widget & frame raster.
• RN/Expo: React DevTools + Profiler untuk render time, dan Hermes sampling profiler (npx react-native-profiler).

flutter run --profile   → jalankan di mode profil
devtools → Performance  → lihat UI & Raster thread

#Metrik Baseline

Buat baseline sebelum mengoptimasi: FPS rata-rata, frame drop, startup time (cold start), memory puncak. Tanpa baseline, kalian tidak tahu apakah optimasi berhasil.

#Praktik: Profiling Halaman Beranda Fitku

Langkah nyata saat Fitku terasa lambat:

1. Rekam trace (Perfetto / Instruments / DevTools) saat UI terasa jank
2. Identifikasi frame yang drop → cek thread yang mem-block
3. Baca call stack pada momen drop → temukan fungsi mahal
4. Perbaiki (virtualisasi, cache, lepas observer)
5. Rekam ulang → bandingkan baseline

#Common Pitfalls Performance

• Mengoptimalkan sebelum mengukur: perbaiki berdasarkan angka, bukan feeling.
• Hanya menguji di emulator: emulator ≠ device asli (thermal, storage I/O).
• Mengabaikan cold start: startup lama = kesan pertama buruk. Audit Application.onCreate, inisialisasi berat ditunda.
• Menyalakan semua logging di produksi: log berlebihan menghabiskan CPU & storage.
• Tidak memakai key/reusableIdentifier pada list: reuse view gagal → GC bekerja keras.

#Penutup

Pada episode 15 ini, kalian telah menguasai dasar optimasi:

• Rendering vs frame budget 16ms; jank = frame melewati budget.
• Sumber masalah: rendering, memory leaks, dan baterai — dengan pola perbaikannya.
• Tools: Profiler/Perfetto (Android), Instruments (iOS), DevTools (Flutter), React Profiler (RN).
• Workflow: baseline → rekam → identifikasi → perbaiki → ukur ulang.

Di episode 16 selanjutnya kita jamin kualitas: Testing Mobile — unit test, widget/UI tests, dan e2e (Detox/Maestro/Appium) untuk membangun test suite Fitku. Sampai jumpa!