Jank para sa mga mobile app — ano ito, mga sanhi at pag-aayos

Ano ang Jank

Jank — ay isang terminong mula sa computer graphics na tumutukoy sa isang visual defect kung saan ang animation ay gumagalaw nang may mga haltak sa halip na makinis na pag-slide. Sa mobile development, sinusukat ang Jank bilang bilang ng mga nalaktawang frame (skipped frames) bawat yunit ng oras. Kung hindi makapaghanda ang system ng isang frame sa oras ng VSync, inuulit ng display ang nakaraang frame — may pause na 16.6 ms sa 60 Hz. Ang isang nalaktawang frame ay maaaring hindi mahalata, ngunit ang serye ng 3–5 sunod-sunod na nalaktawang frame ay lumilikha ng pakiramdam ng “pagbagal” na 50–80 ms, na malinaw na nararamdaman ng gumagamit.

Ang Jank ay lalong kritikal para sa mga animation na dapat gumana sa pare-parehong bilis: pag-scroll ng listahan, animation ng pagbubukas ng menu, mga parallax effect, mga transition sa pagitan ng mga screen. Ayon sa UX research ng Google (2024), ang isang app na may Jank indicator na higit sa 3% ng scroll session ay tumatanggap ng 22% higit pang isang-star na review kaysa sa isang app na may indicator na mas mababa sa 0.5%. Ang tool na Android Vitals ay awtomatikong sinusubaybayan ang Jank at inuuri ito ayon sa severity: moderate, severe at critical.

Mga pangunahing sanhi ng Jank

Ang mga sanhi ng Jank ay nahahati sa ilang kategorya. Una — Layout Jank: sanhi ng madalas na requestLayout() dahil sa pagbabago ng laki ng View, mga animation ng LayoutTransition o dynamic na pag-load ng nilalaman. Bawat tawag sa requestLayout ay nagti-trigger ng Measure + Layout para sa buong sub-tree ng View, na maaaring tumagal ng 5–30 ms. Pangalawa — Draw Jank: nauugnay sa overdraw at paggamit ng mabibigat na drawable. Pangatlo — Thread Jank: pag-block ng main thread dahil sa mga synchronous na operasyon — pag-load ng file, pagtatrabaho sa database sa pangunahing thread, pag-decode ng Bitmap.

Pang-apat na kategorya — GC Jank: garbage collection sa ART/Dalvik o Swift ARC. Kapag maraming bagay ang naipon sa heap, nagti-trigger ang GC ng Stop-The-World pause na 5–15 ms. Sa Android, ang mga GC pause ay kadalasang nangyayari sa madalas na alokasyon sa mga loop: paggawa ng mga bagay sa onDraw(), alokasyon sa mga adapter, hindi nagamit na lambda expression. Panglima — IPC Jank: interprocess communication (ContentProvider, Binder) sa pangunahing thread. Pang-anim — Rendering Jank: mabagal na GPU rendering dahil sa hindi optimal na shader o malalaking texture.

Diagnosis ng Jank sa Android

Sa Android, nagsisimula ang diagnosis ng Jank sa system trace na Perfetto. Itinatala ng Perfetto ang aktibidad ng lahat ng thread, CPU, GPU at scheduler. Isang malinaw na indicator ng Jank ang mga linyang Choreographer.doFrame at Choreographer.doCallbacks: kung ang interval sa pagitan ng dalawang sunod-sunod na tawag sa doFrame ay lumampas sa 16.6 ms, nalaktawan ang frame. Ipinapakita ng Perfetto ang eksaktong dahilan — kung aling system call, lock o GC ang nagdulot ng pagkaantala. Sa Android Studio Profiler, ang katulad na functionality ay available sa pamamagitan ng CPU Profiler.

Para sa awtomatikong pag-detect ng Jank sa produksyon, ginagamit ang FrameMetricsAggregator — API na nangongolekta ng statistics bawat frame at nag-a-aggregate bawat session. Sa Android 12+, lumitaw ang PerformanceHintManager — API para sa mga pahiwatig sa system tungkol sa target na frame rate. Kung ipinapahiwatig ng app na ito ay gumagana sa isang 120 FPS scenario, maaaring taasan ng system ang CPU/GPU frequency para maiwasan ang Jank. Para sa simpleng logging ng lahat ng nalaktawang frame, sapat na ang mag-subscribe sa Choreographer.FrameCallback.

Pag-log ng Jank sa pamamagitan ng Choreographer

Ang Kotlin code ay nag-subscribe sa Choreographer.FrameCallback at nagla-log ng bawat nalaktawang frame na may indikasyon ng tagal ng pagkaantala. Ang callback ay tinatawag sa bawat VSync.

class JankDetector {

    private val frameBudget = 16_666_666L
    private var previousFrameTime = 0L

    private val callback =
        Choreographer.FrameCallback { currentTime ->
            if (previousFrameTime != 0L) {
                val frameDuration =
                    currentTime - previousFrameTime
                val skippedFrames =
                    (frameDuration / frameBudget) - 1
                if (skippedFrames > 0) {
                    Log.w("Jank",
                        "$skippedFrames frame ang nalaktawan")
                }
            }
            previousFrameTime = currentTime
            Choreographer.getInstance()
                .postFrameCallback(this)
        }

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

Diagnosis ng Jank sa iOS

Sa iOS, ang diagnosis ng Jank ay isinasagawa sa pamamagitan ng Instruments na may Core Animation template. Ipinapakita ng Instruments ang real-time FPS, bilang ng offscreen-render at hit-test. Mga pangunahing indicator ng Jank sa iOS: mga pulang column sa time scale ng Core Animation (paglampas sa badyet ng frame), mataas na Renderer indicator (nangangahulugang offscreen rendering) at mababang FPS. Para sa pag-monitor ng produksyon, nangongolekta ang MetricKit ng mga report na may MXAnimatoryMetric, na may kasamang average FPS, P50 at P95 na oras ng frame.

Ang native diagnosis ng Jank sa iOS ay may kasamang CADisplayLink na may pagsusuri ng timestamp at targetTimestamp. Kung ang kasalukuyang timestamp ay malaki ang agwat sa targetTimestamp, nangangahulugang isa o higit pang frame ang nalaktawan. Inirerekomenda din ng Apple ang paggamit ng os_signpost para sa custom na profiling: maglagay ng signpost-interval sa simula at dulo ng frame rendering at suriin sa Instruments kung aling mga interval ang lumalampas sa 16.6 ms. Sa SwiftUI, para sa diagnosis ng Jank ginagamit ang UIView.invalidateIntrinsicContentSize — ang madalas na pagtawag sa paraang ito ay nagpapahiwatig ng hindi matatag na Layout.

CADisplayLink para sa pag-detect ng Jank

Ang Swift code ay tumutukoy ng mga nalaktawang frame sa pamamagitan ng CADisplayLink. Kung ang pagkakaiba sa pagitan ng timestamp at targetTimestamp ay lumampas sa 16.6 ms — ang Jank ay naitala.

class JankMonitor {

    private var displayLink: CADisplayLink?
    private var totalJank = 0

    func start() {
        displayLink = CADisplayLink(
            target: self,
            selector: #selector(detectJank)
        )
        displayLink?.add(to: .current,
            forMode: .common)
    }

    @objc
    private func detectJank() {
        guard let link = displayLink else { return }
        let delay = link.targetTimestamp
            - link.timestamp
        if delay > 0.0167 {
            totalJank += 1
        }
    }
}

Mga tool sa pag-profile ng Jank

Para sa pag-profile ng Jank, ginagamit ang parehong built-in na tool ng OS at third-party na SDK. Sa Android, ang pangunahing tool ay Perfetto (pumalit sa Systrace). Pinapayagan ng Perfetto ang pag-record ng mga trace hanggang 30 segundo at pagsusuri sa pamamagitan ng web interface ui.perfetto.dev. Ipinapakita nito ang eksaktong timeline na may aktibidad ng Choreographer, rendering threads (RenderThread) at GPU. Para sa detalyadong pagsusuri ng mga problema sa GPU, ginagamit ang AGI (Android GPU Inspector), na nagpapakita hindi lamang ng oras ng frame kundi pati na rin ang pagkarga ng mga partikular na GPU block — shader, rasterizer, texture block.

Sa iOS, ang katumbas ay Instruments na may mga template na Core Animation, Metal System Trace at GPU Driver. Ipinapakita ng Core Animation ang FPS at oras ng frame, Metal System Trace — trabaho ng GPU na may detalye hanggang sa bawat draw call. Para sa pag-profile sa mga tunay na device sa ilalim ng load, ginagamit ang Firebase Performance (nangongolekta ng Screen Rendering metric) at Sentry (kumukuha ng stack trace sa Jank). Ang bagong Android 15 Performance Hint API ay nagpapahintulot sa developer na ipahiwatig sa system kung aling mga frame ang mahalaga at makatanggap ng mga babala mula sa system kapag papalapit sa Jank.

FrameMetricsAggregator sa produksyon

Ang Kotlin code ay gumagamit ng FrameMetricsAggregator para sa pagkolekta ng frame statistics bawat session. Pagkatapos ihinto ang aggregator, ipinapakita ang bilang ng mga nalaktawang frame.

class JankAggregator(private val activity: Activity) {

    private val aggregator = FrameMetricsAggregator()

    fun startCollection() {
        aggregator.add(activity.window)
    }

    fun stopAndReport() {
        aggregator.remove()
        val result = aggregator.getMetrics()
        val totalFrames = result
            ?.get(FrameMetrics.TOTAL_DURATION)
            ?.size ?: 0
        val jankFrames = result
            ?.get(FrameMetrics.TOTAL_DURATION)
            ?.count { it > 16_666_666L} ?: 0
        Log.d("JankReport",
            "Jank ratio: ${jankFrames * 100 / totalFrames}%")
    }
}

Mga paraan ng pag-aayos ng pagkautal ng frame

Ang pag-aayos ng Jank ay nangangailangan ng kombinasyon ng mga pamamaraan depende sa uri nito. Para sa Layout Jank: palitan ang malalalim na hierarchy ng ConstraintLayout/Compose/SwiftUI, gumamit ng merge-tag, iwasan ang requestLayout sa mga animation. Para sa Draw Jank: gumamit ng Debug GPU Overdraw para mahanap ang 4x+ overdraw, palitan ang mabibigat na drawable ng vector (VectorDrawable/PDF), gamitin nang may pag-iingat ang hardware layers — pinapabilis nila ang rendering ngunit kumokonsumo ng mas maraming GPU memory. Para sa Thread Jank: ilipat ang lahat ng I/O operations, trabaho sa database at Bitmap decoding sa background threads, gumamit ng Kotlin Coroutines na may tamang Dispatcher o RxJava na may Schedulers.io().

Para sa GC Jank: bawasan ang alokasyon sa onDraw() at getView(), gumamit ng object pool (ObjectPool), palitan ang for-each ng indexed for, gamitin nang maingat ang immutable data class sa Kotlin na may copy() — ang copy ay lumilikha ng bagong bagay. Para sa IPC Jank: lazy initialization ng ContentProvider sa pamamagitan ng App Startup, ilipat ang Binder calls sa background thread. Para sa Rendering Jank: bawasan ang laki ng texture hanggang sa maximum na resolution ng screen, gumamit ng ASTC o ETC2 compression, iwasan ang hindi kinakailangang shader compilation (i-compile ang shader nang maaga). Komprehensibong solusyon — regular na pagpapatakbo ng Perfetto/Instruments profiling sa CI at pagsubaybay sa Jank regression.

Anti-Jank pattern: Async Layout

Ang Kotlin code ay nagpapakita ng asynchronous na pag-load ng data sa screen pagkatapos ng reportFullyDrawn, upang ang mabigat na trabaho ay hindi harangan ang unang frame. Ang callback ay tinatawag pagkatapos makita ng gumagamit ang interface.

class JankSafeLoader {

    suspend fun loadAfterFirstFrame(
        activity: Activity
    ) {
        // ginagarantiya na ang unang frame ay nai-render na
        if (Build.VERSION.SDK_INT >= 29) {
            activity.reportFullyDrawn()
        }

        // mabigat na pagkarga — pagkatapos ng unang frame
        withContext(Dispatchers.IO) {
            val data = fetchHeavyData()
            withContext(Dispatchers.Main) {
                updateUI(data)
            }
        }
    }
}