Zasekávání ve vývoji — co to je, příčiny a metody optimalizace

Co znamená „zasekává se“ v mobilním vývoji

Zasekává se — neformální termín, kterým uživatelé popisují subjektivně pomalý chod aplikace. Na rozdíl od lagu, který se projevuje jako konstantní zpoždění, je zasekávání nepravidelné zamrzání: aplikace může několik sekund perfektně fungovat a poté se na 1–3 sekundy „zamyslet“.

Technická charakteristika jevu

Z hlediska profilování se zasekávání projevuje jako série vynechaných snímků (jank) se špičkovým zpožděním nad 100 ms. Na grafu FPS to vypadá jako prudké poklesy: 60 → 20 → 55 → 10 snímků za sekundu. Na rozdíl od lagu s rovnoměrně nízkým FPS má zasekávání výraznou variabilitu.

Uživatelské vnímání

Když se aplikace zasekává, uživatel nerozumí logice zpomalení: obrazovka se může plynule posouvat a poté náhle zastavit na sekundu. To způsobuje frustraci a snižuje důvěru v aplikaci. Podle Google 53% uživatelů opouští web nebo aplikaci, pokud načítání trvá déle než 3 sekundy.

Příčiny náhlých zpomalení v aplikacích

Nepravidelný charakter zasekávání naznačuje, že problém je způsoben událostními faktory, nikoli stálým přetížením. Podívejme se na typické scénáře.

GC pauzy při alokaci objektů

Na Android v prostředí ART zastavuje sběr odpadu všechna vlákna aplikace. Pokud se v kódu vytváří mnoho dočasných objektů — například při každém volání onBindViewHolder se vytváří nový String konkatenací — GC se spouští častěji. Pauza může trvat 5–50 ms v závislosti na velikosti haldy a generaci objektů. Uživatel to cítí jako náhlé „zamyšlení“.

Synchronní SQL dotazy ve vlákně UI

Room na Android a Core Data na iOS podporují asynchronní dotazy, ale vývojáři často volají getValue() nebo provádějí dotaz přes runBlocking pro jednoduchost. Těžký SELECT s joiny na tabulce s 10 000 řádky může trvat 200–500 ms a během té doby zcela blokovat UI.

Dekódování obrazu bez downscale

Načtení obrázku z kamery (12 Mp, 4000x3000 px) bez škálování trvá až 200 ms na dekódování do Bitmap. Pokud se obrázky načítají asynchronně, ale bez omezeného fondu vláken, současné spuštění 5–6 dekódování může přetížit CPU a způsobit migrující zpomalení.

• Android — konkatenace řetězců ve smyčkách, vytváření objektů v horkých cestách, Bitmap bez inSampleSize
• iOS — autorelease fondy s velkým počtem objektů, imageWithContentsOfFile bez škálování, synchronní URLSession
• Cross-platform — parsování JSON ve vlákně UI, načítání dat v hlavním vlákně s čekáním na odpověď serveru

Jak diagnostikovat zamrzání na Android a iOS

Diagnostika nepravidelných zpomalení je obtížnější než diagnostika konstantních lagů, protože problém se nemusí při každém spuštění opakovat. Je třeba sbírat statistiku po delší dobu.

Memory Profiler se záznamem GC událostí

Android Studio Memory Profiler ukazuje nejen využití paměti, ale také GC události: četnost, typ (Concurrent, Full), trvání. Pokud se GC vyskytuje častěji než 1krát za 5 sekund v klidovém stavu — to je známka nadměrné alokace. Záznam heap dump v okamžiku zasekávání umožňuje vidět, které objekty zabírají paměť.

Xcode Instruments s Allocation Tracking

Na iOS použijte šablonu Allocations v Instruments pro sledování vytváření a uvolňování objektů. Zapněte generace (Generations) — umožňují pořizovat snímky haldy mezi akcemi a vidět, které objekty zůstávají v paměti. Perzistentní objekty, které se neuvolňují — zdroj hromadění paměti a následných pauz.

JankStats API na Android

JankStats — knihovna Android, která sbá metrik vynechaných snímků v reálném čase. Každý jank připojuje k aktuálnímu scénáři (např. „posouvání seznamu“, „otevření obrazovky“), což umožňuje pochopit, při které konkrétní akci dochází k zasekávání.

Příklad integrace JankStats pro sledování zamrzání na 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")
            }
        }
    }
}

Metody odstranění pomalého chodu

Odstranění zasekávání vyžaduje cílenou práci s každou příčinou. Neexistuje univerzální řešení — je třeba analýza konkrétních profilů výkonu.

Zavedení stránkování pomocí Paging 3

Pokud seznam obsahuje 1000+ prvků a všechny se načítají najednou — je to zaručené zasekávání. Paging 3 na Android a NSFetchedResultsController na iOS načítají data po dávkách během posouvání. Uživatel vidí pouze prvních 10–20 prvků, zbytek se načítá na pozadí.

Optimalizace SQL dotazů a indexů

Room umožňuje profilovat dotazy pomocí Inspection Tool v Android Studio: je vidět doba provedení, počet vrácených řádků a plán dotazu. Přidání indexů na sloupce WHERE a ORDER BY může zkrátit dobu dotazu z 300 ms na 5 ms. Na iOS provádí podobnou kontrolu Core Data Profiler v Instruments.

Přesun úloh do WorkManager

Synchronizace na pozadí, nahrávání souborů, zpracování dat — všechno by mělo být provedeno pomocí WorkManager (Android) nebo Background Tasks (iOS). Pokud je synchronizace spuštěna ve vlákně UI, aplikace se během provádění zasekne. WorkManager zaručuje provedení v pozadí s ohledem na stav baterie a sítě.

Příklad synchronizace na pozadí pomocí WorkManager na Android:

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

    override suspend fun doWork(): Result {
        return try {
            Log.d("Sync", "Synchronizace dat v pozadí vlákna")
            syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

Prevence zasekávání ve fázi vývoje

Zasekávání lze předejít ve fázi psaní kódu dodržováním zásad efektivní práce s pamětí a vlákny.

Baseline Profiles pro AOT kompilaci

Baseline Profiles — seznam tříd a metod, které Android kompiluje předem (AOT), nikoli JIT. Bez profilu se každá nová obrazovka kompiluje při prvním otevření, což způsobuje zpoždění 100–500 ms. Připravte Baseline Profile pro klíčové obrazovky a zapněte generování v Gradle pomocí baseline-profile-gradle-plugin.

Minimalizace alokací v horkých cestách

Hot path — kód, který se provádí při každém snímku: onBindViewHolder, draw, layoutSubviews. Vyhněte se vytváření objektů v těchto metodách: použijte fond objektů, StringBuilder místo konkatenace, kešujte formátované řetězce a formátovače. Každá další alokace přibližuje další GC.

Profilování pomocí Baseline Profiles v CI

Přidejte do CI pipeline spuštění Macrobenchmark se scénářem posouvání seznamu a otevření obrazovky. Nastavte práh: 99. percentil času snímku by neměl přesáhnout 16 ms. Pokud je práh překročen — build je odmítnut do optimalizace.

• Android — Baseline Profiles, Macrobenchmark, JankStats, StrictMode s penaltyDeath
• iOS — MetricKit, os_signpost, XCTMetric, Main Thread Checker v Debug schématu
• Obecný přístup — pravidelné profilování, code review se zaměřením na alokace v horkých cestách