Frame Rate sa mga mobile app — ano ito, fps at kung paano pagbutihin

Ano ang Frame Rate

Frame Rate (rate ng frame) — ay isang metrik na sinusukat sa mga frame bawat segundo (fps) na nagpapakita kung gaano kadalas bawat segundo ina-update ng app ang imahe sa screen. Ang mata ng tao ay nakakakita ng paggalaw bilang makinis mula sa 24 fps (pelikula), ngunit para sa interaktibong UI kinakailangan ang minimum na 60 fps upang ang mga pagpindot at animation ay maramdaman agad. Ang bawat frame ay isang kumpletong siklo: pagproseso ng input ng gumagamit, pagkalkula ng Layout, rendering ng View hierarchy at output sa screen. Kung ang alinman sa mga yugto ay lumampas sa inilaang badyet ng oras (16.6 ms sa 60 fps), ang frame ay lalaktawan at makikita ng gumagamit ang pagkautal.

Mahalagang makilala ang Frame Rate ng app mula sa refresh rate ng display (Refresh Rate). Ang refresh rate ay isang katangian ng screen: gaano kadalas bawat segundo pisikal na nire-refresh ng display ang imahe (60, 90, 120 o 144 Hz). Frame Rate — ay kung gaano karaming frame bawat segundo ang kayang i-render ng app. Kung ang app ay gumagawa ng 60 fps sa isang 120 Hz display, bawat pangalawang frame ay didoblehin — ang imahe ay mananatiling makinis, ngunit hindi gaanong responsibo kaysa sa maaari. Ayon sa Google I/O 2023, ang mga modernong flagship ay kayang mapanatili ang 120 fps sa mga simpleng UI scenario, ngunit sa mabibigat na pagkarga (mga laro, kumplikadong listahan) ang rate ay bumababa sa 40–60 fps.

Paano gumagana ang rendering ng frame

Ang rendering ng frame sa isang mobile app ay dumadaan sa pipeline ng ilang yugto. Sa Android, ang pipeline ay kinabibilangan ng: pagproseso ng input (Input), animation (Animation), pagsukat at pag-aayos (Layout), pagguhit (Draw), pag-sync sa GPU at output sa screen (Swap). Bawat yugto ay isinasagawa sa CPU o GPU, at ang kabuuang oras ng lahat ng yugto ay hindi dapat lumampas sa badyet ng frame. Para sa 60 fps ang badyet ay 16.6 ms, para sa 120 fps — 8.3 ms. Choreographer (Android) at CADisplayLink (iOS) ay nag-sync ng rendering sa vertical refresh ng display (VSync), na ginagarantiya na ang frame ay ipinapakita lamang sa sandali ng pag-refresh ng screen, iniiwasan ang pagkapunit ng imahe (tearing).

Sa iOS, ang pipeline ay katulad: Run Loop ay nagpoproseso ng mga kaganapan, Core Animation ay nagkalkula ng mga layer, Render Server (isang hiwalay na proseso) ay nagre-render at nagpapadala ng frame sa GPU. Ang pagkakaiba ng iOS — ang hiwalay na proseso ng Render Server na naghihiwalay ng rendering mula sa pangunahing app. Kung i-block ng app ang main thread, maaari pa ring ipakita ng Render Server ang huling kilalang frame, ngunit titigil ang mga animation. Kung ang Render Server mismo ay hindi maka-keep up — ang GPU ay idle at bumababa ang Frame Rate. Ayon sa Apple WWDC 2022, ang pinakakaraniwang dahilan ng mababang Frame Rate sa iOS ay labis na nesting ng CALayer, mabibigat na shadowPath at offscreen rendering.

Pagsubaybay ng mga frame sa pamamagitan ng Choreographer

Ang code sa Kotlin ay nag-subscribe sa Choreographer.FrameCallback at nagla-log ng aktwal na oras sa pagitan ng mga frame. Kung ang interval ay lumampas sa 16.6 ms — isang nalaktawang frame ang naitatala.

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)
    }
}

Refresh rate ng display at Frame Rate

Refresh Rate (rate ng pag-refresh) — ay isang hardware na katangian ng display na tumutukoy kung gaano kadalas bawat segundo pisikal na iginuhit muli ng screen ang imahe. Ang mga karaniwang display ay may 60 Hz, ang mga modernong flagship — 90, 120 o 144 Hz. Ang Frame Rate ng app ay maaaring mas mababa, katumbas o mas mataas sa refresh rate (sa huling kaso, ang mga sobrang frame ay itinatapon). Ang ideal na scenario — ang Frame Rate ay tumutugma sa Refresh Rate: bawat hardware cycle ay tumatanggap ng bagong frame mula sa app at ang paggalaw ay pinakamakinis. Kung mas mababa ang Frame Rate, inuulit ng display ang huling frame, na nararamdaman bilang micro-kautal (stutter).

Sinusuportahan ng Android at iOS ang dynamic na paglipat ng refresh rate. Ang Android 12+ ay gumagamit ng Smart Refresh Rate: sa pag-scroll, itinataas ng system ang rate sa 120 Hz, sa static na nilalaman ibinababa sa 60 Hz upang makatipid ng baterya. Ang iOS ProMotion (iPhone 13 Pro at mas bago) ay gumagana nang katulad — ang rate ay nag-iiba mula 10 hanggang 120 Hz depende sa nilalaman. Dapat suriin ng developer kung sinusuportahan ng device ang mataas na rate at iakma ang badyet ng oras bawat frame. Kung hindi kayang i-render ng app ang frame sa loob ng 8.3 ms (para sa 120 Hz), mas mainam na pilitin na gumana sa 60 Hz — ito ay magbibigay ng matatag na Frame Rate na walang mga nalaktawang frame.

Mga tool sa pagsukat ng Frame Rate

Para sa pagsukat ng Frame Rate sa mga mobile app, available ang parehong built-in na tool ng mga platform at third-party na profiler. Sa Android, ang pangunahing tool ay GPU Profiling (Developer Options → Profile GPU Rendering) na nagpapakita ng time scale ng bawat frame na may paghihiwalay ayon sa yugto (Draw, Prepare, Process, Execute). Ang mas detalyadong pagsusuri ay ibinibigay ng Android Studio Profiler — nagre-record ito ng kumpletong profile ng rendering na may pagtukoy ng mga partikular na View na nagdudulot ng pag-redraw. Sa iOS, ginagamit ang Instruments na may template na Core Animation — nagpapakita ito ng FPS, oras ng rendering ng mga layer at bilang ng offscreen rendering.

Para sa pag-monitor ng Frame Rate sa produksyon, ginagamit ang Firebase Performance (Android) — kinokolekta nito ang Frame Rate sa background at ini-aggregate ayon sa device, bersyon ng OS at session. Sa iOS, ang MetricKit ay nagbibigay ng katulad na data sa pamamagitan ng MXAnimatoryMetric. Para sa mga laro at Flutter app, ginagamit ang FrameTimingCallback (Flutter) at Unity Profiler. Mahalagang sukatin hindi ang average na Frame Rate, kundi ang mga percentile: P50, P90 at P99. Ang app ay maaaring magpakita ng average na 55 fps, ngunit may P99 = 30 fps — ibig sabihin nito na 1% ng oras nakikita ng mga gumagamit ang matinding pagkautal at ito ay sapat para sa mga negatibong review.

Pagsukat ng Frame Rate sa Flutter

Ang halimbawa sa Dart ay nagpapakita kung paano mag-subscribe sa FrameTimingCallback sa Flutter at mag-log ng bilang ng mga nalaktawang frame. Ang callback ay na-trigger pagkatapos ng bawat natapos na frame.

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}");
    }
}

Pag-optimize ng rate ng frame

Ang pag-optimize ng Frame Rate ay nagsisimula sa pagtukoy ng mga bottleneck sa pipeline ng rendering. Sa yugto ng Layout, ang mga pangunahing problema ay labis na nesting ng View hierarchy, paggamit ng mga relative Layout (RelativeLayout na may maraming patakaran) at madalas na pagtawag sa requestLayout. Solusyon — gumamit ng ConstraintLayout o flat hierarchy, iwasan ang nesting ng higit sa 5–6 na antas. Sa yugto ng Draw — pag-redraw (overdraw): kapag ang isang pixel ay iginuhit nang maraming beses bawat frame. Halimbawa, puting background ng Activity sa ilalim ng semi-transparent na fragment, sa ilalim nito ay isa pang layer — bawat pixel ay iginuhit nang tatlong beses. Ang tool na Debug GPU Overdraw ay nagpapakita ng mga problemang zone na may indikasyon ng kulay. Inirerekomenda na panatilihin ang overdraw sa antas na 2x o mas mababa.

Sa iOS, ang mga pangunahing problema ay mabibigat na cornerRadius at masksToBounds — nagdudulot ito ng offscreen rendering, kung saan ang Core Animation ay gumagawa ng pansamantalang buffer, gumuguhit dito, pagkatapos ay kinokopya ang resulta sa screen. Ang offscreen rendering ay madaling makita sa Instruments Core Animation: kung ang Renderer na linya ay pula — may mga problema. Solusyon — gumamit ng UIImageView na may mga pre-crop na imahe sa halip na cornerRadius, iwasan ang groupOpacity at shouldRasterize nang walang matinding pangangailangan. Para sa parehong platform, ang pag-minimize ng bilang ng mga tawag sa invalidate() at setNeedsDisplay() ay kritikal — bawat ganoong tawag ay nagsisimula ng kumpletong siklo ng pag-redraw ng view.

Pag-optimize ng hierarchy sa Android

Ang code ay nagpapakita ng pagpapalit ng malalim na nesting ng RelativeLayout ng flat na istraktura ng ConstraintLayout. Ang pagbawas ng antas ng nesting mula 4 hanggang 1 ay nagpapaikli ng oras ng Layout ng 30–50%.

// Halimbawa: flat na istraktura sa pamamagitan ng 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
        // pag-binding ng data nang hindi iginuguhit muli ang buong container
    }
}

Mga adaptibong rate at Dynamic Frame Rate

Ang mga modernong mobile app ay lalong gumagamit ng adaptibong Frame Rate — isang sistema na dynamic na nag-aayos ng target na rate sa kasalukuyang scenario. Sa mabilis na pag-scroll, ang listahan ay nangangailangan ng 120 fps para sa kinis, sa static na screen sapat na ang 60 fps o kahit 30 fps para sa video. Sa Android, ang adaptasyon ay ipinapatupad sa pamamagitan ng Choreographer.setFrameInterval (API 33+) at Window.setFrameRate. Maaaring ipahiwatig ng developer ang gustong rate sa system: setPreferredRefreshRate sa SurfaceView o setFrameRate sa Window. Ang iOS ay awtomatikong namamahala ng rate sa pamamagitan ng ProMotion, ngunit maaaring tahasang itakda ng developer ang preferredFramesPerSecond para sa CADisplayLink.

Ang Dynamic Frame Rate ay lalong mahalaga para sa mga laro at app na may mga animation. Ayon sa datos ng Google, ang pagbaba ng Frame Rate mula 120 hanggang 60 Hz sa static na screen ay nakakatipid ng hanggang 30–40% na enerhiya ng GPU. Upang makamit ang pinakamahusay na balanse sa pagitan ng kinis at konsumo ng kuryente, inirerekomenda: sukatin ang aktwal na Frame Rate sa iba't ibang scenario, itakda ang target na fps depende sa scene (laro — 60, menu — 30, video — 24) at lumipat ng mga mode sa pamamagitan ng Lifecycle-aware na mga component, upang ang app kapag na-minimize ay hindi mag-aksaya ng resources sa pag-render ng 120 fps sa background.

Pagtatakda ng gustong Frame Rate

Ang code sa Swift ay nagtatakda ng preferredFramesPerSecond para sa CADisplayLink sa iOS. Sa pag-scroll, ang rate ay tumataas sa 120 Hz, sa pagtigil — bumababa sa 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() {
        // pag-update ng animation
    }
}