Frame Rate di aplikasi seluler — apa itu, fps dan cara meningkatkannya

Apa itu Frame Rate

Frame Rate (frekuensi bingkai) — adalah metrik yang diukur dalam bingkai per detik (fps) yang menunjukkan seberapa sering per detik aplikasi memperbarui gambar di layar. Mata manusia merasakan gerakan sebagai mulus mulai dari 24 fps (film), tetapi untuk UI interaktif diperlukan minimal 60 fps agar sentuhan dan animasi terasa instan. Setiap bingkai adalah siklus lengkap: pemrosesan masukan pengguna, perhitungan Layout, rendering hierarki View dan keluaran ke layar. Jika salah satu tahap melebihi anggaran waktu yang dialokasikan (16.6 ms pada 60 fps), bingkai terlewat dan pengguna melihat kegagapan.

Penting untuk membedakan Frame Rate aplikasi dari kecepatan penyegaran layar (Refresh Rate). Kecepatan penyegaran adalah karakteristik layar: seberapa sering per detik layar secara fisik menyegarkan gambar (60, 90, 120 atau 144 Hz). Frame Rate — adalah berapa banyak bingkai per detik yang berhasil di-render aplikasi. Jika aplikasi menghasilkan 60 fps pada layar 120 Hz, setiap bingkai kedua akan digandakan — gambar tetap mulus, tetapi tidak seresponsif yang seharusnya. Menurut Google I/O 2023, flagship modern dapat mempertahankan 120 fps dalam skenario UI sederhana, tetapi dalam beban berat (game, daftar kompleks) frekuensi turun menjadi 40–60 fps.

Bagaimana cara kerja rendering bingkai

Rendering bingkai di aplikasi seluler melewati jalur pipa beberapa tahap. Di Android, jalur pipa meliputi: pemrosesan masukan (Input), animasi (Animation), pengukuran dan tata letak (Layout), penggambaran (Draw), sinkronisasi dengan GPU dan keluaran ke layar (Swap). Setiap tahap dijalankan pada CPU atau GPU, dan total waktu semua tahap tidak boleh melebihi anggaran bingkai. Untuk 60 fps anggaran 16.6 ms, untuk 120 fps — 8.3 ms. Choreographer (Android) dan CADisplayLink (iOS) menyinkronkan rendering dengan penyegaran vertikal layar (VSync), memastikan bahwa bingkai hanya ditampilkan saat penyegaran layar, menghindari robekan gambar (tearing).

Di iOS, jalur pipa serupa: Run Loop memproses peristiwa, Core Animation menghitung lapisan, Render Server (proses terpisah) melakukan rendering dan mengirim bingkai ke GPU. Perbedaan iOS — proses Render Server terpisah yang mengisolasi rendering dari aplikasi utama. Jika aplikasi memblokir thread utama, Render Server masih dapat menampilkan bingkai terakhir yang diketahui, tetapi animasi akan berhenti. Jika Render Server sendiri tidak dapat mengimbangi — GPU menganggur dan Frame Rate turun. Menurut Apple WWDC 2022, penyebab paling umum Frame Rate rendah di iOS adalah nesting CALayer yang berlebihan, shadowPath berat, dan rendering di luar layar (offscreen rendering).

Melacak bingkai melalui Choreographer

Kode di Kotlin berlangganan Choreographer.FrameCallback dan mencatat waktu aktual antar bingkai. Jika interval melebihi 16.6 ms — bingkai terlewat dicatat.

class FrameRateMonitor {

    private var lastFrameTime = 0L
    private val frameCallback =
        Choreographer.FrameCallback { frameTimeNanos ->
            if (lastFrameTime != 0L) {
                val deltaMs = (frameTimeNanos - lastFrameTime) / 1_000_000f
                if (deltaMs > 16.6f) {
                    Log.w("FrameRate",
                        "Skipped frame: $deltaMs ms")
                }
            }
            lastFrameTime = frameTimeNanos
            Choreographer.getInstance()
                .postFrameCallback(this)
        }

    fun start() {
        Choreographer.getInstance()
            .postFrameCallback(frameCallback)
    }
}

Kecepatan penyegaran layar dan Frame Rate

Refresh Rate (kecepatan penyegaran) — adalah karakteristik perangkat keras layar yang menentukan seberapa sering per detik layar secara fisik menggambar ulang gambar. Layar standar memiliki 60 Hz, flagship modern — 90, 120 atau 144 Hz. Frame Rate aplikasi bisa lebih rendah, sama atau lebih tinggi dari kecepatan penyegaran (dalam kasus terakhir, bingkai berlebih dibuang). Skenario ideal — Frame Rate cocok dengan Refresh Rate: setiap siklus perangkat keras menerima bingkai baru dari aplikasi dan gerakan sangat mulus. Jika Frame Rate lebih rendah, layar mengulangi bingkai terakhir, yang dirasakan sebagai kegagapan mikro (stutter).

Android dan iOS mendukung peralihan kecepatan penyegaran secara dinamis. Android 12+ menggunakan Smart Refresh Rate: saat menggulir, sistem menaikkan kecepatan menjadi 120 Hz, saat konten statis menurunkannya menjadi 60 Hz untuk menghemat baterai. iOS ProMotion (iPhone 13 Pro dan lebih baru) bekerja serupa — kecepatan bervariasi dari 10 hingga 120 Hz tergantung konten. Pengembang harus memeriksa apakah perangkat mendukung kecepatan tinggi dan menyesuaikan anggaran waktu per bingkai. Jika aplikasi tidak dapat merender bingkai dalam 8.3 ms (untuk 120 Hz), lebih baik memaksa bekerja pada 60 Hz — ini akan memastikan Frame Rate stabil tanpa bingkai terlewat.

Alat ukur Frame Rate

Untuk mengukur Frame Rate di aplikasi seluler, tersedia baik alat bawaan platform maupun profiler pihak ketiga. Di Android, alat utamanya adalah GPU Profiling (Developer Options → Profile GPU Rendering) yang menunjukkan skala waktu setiap bingkai dengan perincian per tahap (Draw, Prepare, Process, Execute). Analisis lebih detail disediakan oleh Android Studio Profiler — ia merekam profil rendering lengkap dengan menunjukkan View spesifik yang menyebabkan penggambaran ulang. Di iOS, Instruments dengan template Core Animation digunakan — menampilkan FPS, waktu rendering lapisan dan jumlah rendering di luar layar.

Untuk pemantauan Frame Rate di produksi, Firebase Performance (Android) digunakan — ia mengumpulkan Frame Rate di latar belakang dan mengagregasikannya berdasarkan perangkat, versi OS dan sesi. Di iOS, MetricKit menyediakan data serupa melalui MXAnimatoryMetric. Untuk game dan aplikasi Flutter, FrameTimingCallback (Flutter) dan Unity Profiler digunakan. Penting untuk mengukur bukan Frame Rate rata-rata, tetapi persentil: P50, P90 dan P99. Aplikasi mungkin menunjukkan rata-rata 55 fps, tetapi memiliki P99 = 30 fps — ini berarti 1% waktu pengguna melihat kegagapan parah dan ini cukup untuk ulasan negatif.

Mengukur Frame Rate di Flutter

Contoh di Dart menunjukkan cara berlangganan FrameTimingCallback di Flutter dan mencatat jumlah bingkai yang terlewat. Callback dipicu setelah setiap bingkai selesai.

import 'package:flutter/scheduler.dart';

class FrameRateLogger {
    int totalFrames = 0;
    int missedFrames = 0;

    void start() {
        SchedulerBinding.instance
            .addTimingsCallback(_onReportTimings);
    }

    void _onReportTimings(List<FrameTiming> timings) {
        for (final timing in timings) {
            totalFrames++;
            if (timing.totalSpan()
                > Duration(milliseconds: 16)) {
                missedFrames++;
            }
        }
        debugPrint("FPS: \${totalFrames - missedFrames}");
    }
}

Optimalisasi frekuensi bingkai

Optimalisasi Frame Rate dimulai dengan mengidentifikasi hambatan di jalur pipa rendering. Pada tahap Layout, masalah utamanya adalah nesting hierarki View yang berlebihan, penggunaan Layout relatif (RelativeLayout dengan banyak aturan) dan panggilan requestLayout yang sering. Solusi — menggunakan ConstraintLayout atau hierarki datar, hindari nesting lebih dari 5–6 tingkat. Pada tahap Draw — penggambaran ulang (overdraw): ketika piksel digambar beberapa kali per bingkai. Misalnya, latar belakang putih Activity di bawah fragmen semi-transparan, di bawahnya ada lapisan lain — setiap piksel digambar tiga kali. Alat Debug GPU Overdraw menunjukkan zona bermasalah dengan indikasi warna. Disarankan menjaga overdraw pada level 2x atau lebih rendah.

Di iOS, masalah utamanya adalah cornerRadius berat dan masksToBounds — menyebabkan rendering di luar layar (offscreen rendering), di mana Core Animation membuat buffer sementara, menggambar di dalamnya, lalu menyalin hasilnya ke layar. Offscreen rendering mudah terlihat di Instruments Core Animation: jika baris Renderer berwarna merah — ada masalah. Solusi — gunakan UIImageView dengan gambar yang sudah dipotong sebelumnya daripada cornerRadius, hindari groupOpacity dan shouldRasterize tanpa kebutuhan mendesak. Untuk kedua platform, meminimalkan jumlah panggilan invalidate() dan setNeedsDisplay() sangat penting — setiap panggilan tersebut memulai siklus penggambaran ulang tampilan secara lengkap.

Optimalisasi hierarki di Android

Kode mendemonstrasikan penggantian nesting dalam RelativeLayout dengan struktur datar ConstraintLayout. Pengurangan tingkat nesting dari 4 menjadi 1 memperpendek waktu Layout sebesar 30–50%.

// Contoh: struktur datar melalui ConstraintLayout
class OptimizedView(context: Context) :
    ConstraintLayout(context) {

    private val binding =
        ItemProfileBinding.inflate(
            LayoutInflater.from(context)
        )

    fun bind(user: User) {
        binding.avatar.setImageURI(user.avatarUrl)
        binding.nameText.text = user.name
        // mengikat data tanpa menggambar ulang seluruh wadah
    }
}

Kecepatan adaptif dan Dynamic Frame Rate

Aplikasi seluler modern semakin sering menggunakan Frame Rate adaptif — sistem yang secara dinamis menyesuaikan kecepatan target dengan skenario saat ini. Saat menggulir cepat, daftar memerlukan 120 fps untuk kehalusan, di layar statis 60 fps atau bahkan 30 fps untuk video sudah cukup. Di Android, adaptasi diimplementasikan melalui Choreographer.setFrameInterval (API 33+) dan Window.setFrameRate. Pengembang dapat menunjukkan kecepatan pilihan ke sistem: setPreferredRefreshRate di SurfaceView atau setFrameRate di Window. iOS secara otomatis mengelola kecepatan melalui ProMotion, tetapi pengembang dapat secara eksplisit mengatur preferredFramesPerSecond untuk CADisplayLink.

Dynamic Frame Rate sangat penting untuk game dan aplikasi dengan animasi. Menurut data Google, menurunkan Frame Rate dari 120 menjadi 60 Hz pada layar statis menghemat hingga 30–40% energi GPU. Untuk mencapai keseimbangan terbaik antara kehalusan dan konsumsi daya, disarankan: ukur Frame Rate aktual di berbagai skenario, tetapkan fps target tergantung pada scene (game — 60, menu — 30, video — 24) dan alihkan mode melalui komponen yang sadar siklus hidup, sehingga aplikasi saat diminimalkan tidak membuang sumber daya untuk rendering 120 fps di latar belakang.

Mengatur Frame Rate pilihan

Kode di Swift mengatur preferredFramesPerSecond untuk CADisplayLink di iOS. Saat menggulir, kecepatan naik menjadi 120 Hz, saat berhenti — turun menjadi 60 Hz.

class AdaptiveFrameRateManager {

    private var displayLink: CADisplayLink?

    func startWithHighRate() {
        displayLink = CADisplayLink(
            target: self,
            selector: #selector(step)
        )
        if #available(iOS 15.0, *) {
            displayLink?.preferredFrameRateRange =
                CAFrameRateRange(
                    minimum: 60,
                    maximum: 120,
                    preferred: 120
                )
        }
        displayLink?.add(to: .current,
            forMode: .common)
    }

    @objc
    private func step() {
        // pembaruan animasi
    }
}