Nge-lag dalam pengembangan — apa itu, penyebab dan metode optimasi

Apa arti “nge-lag” dalam pengembangan mobile

Nge-lag — istilah informal yang digunakan pengguna untuk menggambarkan kinerja aplikasi yang secara subjektif lambat. Berbeda dengan lag yang muncul sebagai keterlambatan konstan, nge-lag adalah bekuan tidak teratur: aplikasi dapat bekerja sempurna selama beberapa detik, lalu “berpikir” selama 1–3 detik.

Karakteristik teknis fenomena

Dari sudut pandang profiling, nge-lag muncul sebagai serangkaian frame yang terlewat (jank) dengan keterlambatan puncak lebih dari 100 ms. Pada grafik FPS ini terlihat sebagai penurunan tajam: 60 → 20 → 55 → 10 frame per detik. Berbeda dengan lag dengan FPS rendah yang merata, nge-lag memiliki variabilitas yang jelas.

Persepsi pengguna

Ketika aplikasi nge-lag, pengguna tidak memahami logika perlambatan: layar dapat scroll dengan mulus, lalu tiba-tiba berhenti selama satu detik. Ini menyebabkan frustrasi dan mengurangi kepercayaan pada aplikasi. Menurut Google, 53% pengguna meninggalkan situs atau aplikasi jika pemuatan memakan waktu lebih dari 3 detik.

Penyebab perlambatan mendadak di aplikasi

Sifat tidak teratur dari nge-lag menunjukkan bahwa masalah disebabkan oleh faktor kejadian, bukan kelebihan beban konstan. Mari kita lihat skenario tipikal.

Pause GC saat alokasi objek

Di Android di lingkungan ART, pengumpulan sampah menghentikan semua thread aplikasi. Jika dalam kode banyak objek sementara dibuat — misalnya, setiap panggilan onBindViewHolder membuat String baru melalui konkatenasi — GC lebih sering dimulai. Pause dapat berlangsung 5–50 ms tergantung pada ukuran heap dan generasi objek. Pengguna merasakan ini sebagai “berpikir” mendadak.

Query SQL sinkron di thread UI

Room di Android dan Core Data di iOS mendukung query asinkron, tetapi pengembang sering memanggil getValue() atau menjalankan query melalui runBlocking untuk kesederhanaan. SELECT berat dengan join pada tabel 10.000 baris dapat memakan waktu 200–500 ms, sepenuhnya memblokir UI selama waktu itu.

Decoding gambar tanpa downscale

Memuat gambar kamera (12 Mp, 4000x3000 px) tanpa penskalaan memakan waktu hingga 200 ms untuk decoding ke Bitmap. Jika gambar dimuat secara asinkron tetapi tanpa pool thread dengan batasan, menjalankan 5–6 decoding secara bersamaan dapat membebani CPU secara berlebihan, menyebabkan perlambatan yang berpindah-pindah.

• Android — konkatenasi string dalam loop, pembuatan objek di jalur panas, Bitmap tanpa inSampleSize
• iOS — pool autorelease dengan banyak objek, imageWithContentsOfFile tanpa penskalaan, URLSession sinkron
• Cross-platform — parsing JSON di thread UI, memuat data di thread utama dengan menunggu respons server

Cara mendiagnosis bekuan di Android dan iOS

Diagnosis perlambatan tidak teratur lebih sulit daripada diagnosis lag konstan, karena masalah mungkin tidak muncul di setiap startup. Diperlukan pengumpulan statistik selama periode yang lebih lama.

Memory Profiler dengan pencatatan peristiwa GC

Android Studio Memory Profiler tidak hanya menunjukkan penggunaan memori, tetapi juga peristiwa GC: frekuensi, tipe (Concurrent, Full), durasi. Jika GC terjadi lebih dari 1 kali dalam 5 detik dalam keadaan diam — ini adalah tanda alokasi berlebihan. Merekam heap dump pada saat nge-lag memungkinkan melihat objek mana yang memenuhi memori.

Xcode Instruments dengan Allocation Tracking

Di iOS gunakan template Allocations di Instruments untuk melacak pembuatan dan pembebasan objek. Aktifkan generasi (Generations) — mereka memungkinkan mengambil snapshot heap di antara tindakan dan melihat objek mana yang tetap di memori. Objek persisten yang tidak dibebaskan — sumber akumulasi memori dan pause berikutnya.

API JankStats di Android

JankStats — pustaka Android yang mengumpulkan metrik frame yang terlewat secara real-time. Ini mengaitkan setiap jank dengan skenario saat ini (misalnya, “scroll daftar”, “membuka layar”), yang memungkinkan untuk memahami pada tindakan mana tepatnya nge-lag terjadi.

Contoh integrasi JankStats untuk melacak bekuan di Android:

class MainActivity : AppCompatActivity() {
    private lateinit var jankStats: JankStats

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        jankStats = JankStats.create(this.window.decorView) { frameData ->
            if (frameData.isJank()) {
                Log.w("Jank", "Duration=${frameData.durationMs}ms")
            }
        }
    }
}

Metode memperbaiki kinerja lambat

Memperbaiki nge-lag membutuhkan kerja yang terarah dengan setiap penyebab. Tidak ada solusi universal — diperlukan analisis profil kinerja spesifik.

Implementasi paginasi melalui Paging 3

Jika daftar berisi 1000+ elemen dan semuanya dimuat sekaligus — ini adalah nge-lag terjamin. Paging 3 di Android dan NSFetchedResultsController di iOS memuat data dalam potongan saat scroll. Pengguna hanya melihat 10–20 elemen pertama, sisanya dimuat di latar belakang.

Optimasi query SQL dan indeks

Room memungkinkan profiling query melalui Inspection Tool di Android Studio: waktu eksekusi, jumlah baris yang dikembalikan, dan rencana query terlihat. Menambahkan indeks pada kolom WHERE dan ORDER BY dapat mengurangi waktu query dari 300 ms menjadi 5 ms. Di iOS pemeriksaan serupa dilakukan oleh Core Data Profiler di Instruments.

Memindahkan tugas ke WorkManager

Sinkronisasi latar belakang, unggah file, pemrosesan data — semua ini harus dilakukan melalui WorkManager (Android) atau Background Tasks (iOS). Jika sinkronisasi dimulai di thread UI, aplikasi akan nge-lag selama eksekusi. WorkManager menjamin eksekusi di thread latar belakang dengan mempertimbangkan status baterai dan jaringan.

Contoh sinkronisasi latar belakang melalui WorkManager di Android:

class SyncWorker(context: Context, params: WorkerParameters)
    : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            Log.d("Sync", "Sinkronisasi data di thread latar belakang")
            syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

Pencegahan nge-lag di tahap pengembangan

Nge-lag dapat dicegah di tahap penulisan kode dengan mengikuti prinsip kerja efisien dengan memori dan thread.

Baseline Profiles untuk kompilasi AOT

Baseline Profiles — daftar kelas dan metode yang dikompilasi Android terlebih dahulu (AOT), bukan JIT. Tanpa profil, setiap layar baru dikompilasi saat pertama kali dibuka, menyebabkan keterlambatan 100–500 ms. Siapkan Baseline Profile untuk layar kunci dan aktifkan generasi di Gradle melalui baseline-profile-gradle-plugin.

Minimalisasi alokasi di jalur panas

Hot path — kode yang dieksekusi di setiap frame: onBindViewHolder, draw, layoutSubviews. Hindari membuat objek di metode ini: gunakan pool objek, StringBuilder alih-alih konkatenasi, cache string yang diformat dan formatter. Setiap alokasi tambahan mendekatkan GC berikutnya.

Profiling melalui Baseline Profiles di CI

Tambahkan ke pipeline CI menjalankan Macrobenchmark dengan skenario scroll daftar dan membuka layar. Tetapkan ambang batas: persentil ke-99 waktu frame tidak boleh melebihi 16 ms. Jika ambang batas terlampaui — build ditolak hingga optimasi.

• Android — Baseline Profiles, Macrobenchmark, JankStats, StrictMode dengan penaltyDeath
• iOS — MetricKit, os_signpost, XCTMetric, Main Thread Checker di skema Debug
• Pendekatan umum — profiling rutin, code review dengan fokus pada alokasi di jalur panas