Hot Reload pro mobilní aplikace: co to je, princip fungování a mechanismy

Co je Hot Reload?

Hot Reload — vývojový mechanismus, při kterém je zdrojový kód měněn a aplikován na již běžící aplikaci bez jejího zastavení. Vývojář upraví soubor, uloží jej a po 0.3–2 sekundách se aktualizované rozhraní zobrazí na obrazovce. Stav aplikace (čítače, pozice posouvání, zadaná data) je zachován — vývojář neztrácí kontext.

Koncepce hot reload vznikla v raných webových nástrojích (LiveReload, 2010) a byla adaptována pro mobilní vývoj frameworky Flutter (2017) a React Native (2015). Dnes je hot reload povinnou funkcí moderních mobilních frameworků, vedle debug konfigurace a profilování. Bez hot reload je vývoj UI považován za neefektivní: každé zobrazení změny vyžaduje 10–30 sekund na překompilování a spuštění.

Technicky se hot reload skládá ze tří kroků: detekce změny (file watcher), kompilace změněného kódu (incremental compiler) a aplikace (hot patching). Každý framework implementuje tyto kroky jinak, ale výsledek je stejný: minimální zpoždění mezi úpravou a zobrazením.

Jak funguje Hot Reload ve Flutter

Hot Reload ve Flutter je postaven na architektuře Dart VM a JIT kompilaci. Když vývojář stiskne „Hot Reload” v IDE nebo uloží soubor, Flutter provede inkrementální kompilaci změněných Dart knihoven do kernel souborů (.dill). Dart VM tyto soubory načte a nahradí implementace změněných funkcí v běžící aplikaci.

// Flutter widget se stavem zachovávaným při hot reload
class CounterWidget extends StatefulWidget {
    @override
    State createState() => _CounterState();
}

class _CounterState extends State {
    int _counter = 0;

    @override
    Widget build(BuildContext context) {
        return Column(
            children: [
                Text('Počítadlo: $_counter'),
                ElevatedButton(
                    onPressed: () => setState(() => _counter++),
                    child: Text('Zvýšit'),
                ),
            ],
        );
    }
}

V příkladu StatefulWidget CounterWidget zachovává pole _counter během hot reload. Dart VM znovu vytvoří stav (State) voláním reassemble(), ale nevynuluje _counter — hodnota je zachována, pokud není widget zcela znovu vytvořen. Flutter volá reassemble() pro všechny State objekty a build() se znovu spustí s aktuálním kódem a zachovaným stavem.

Kdy hot reload nefunguje: pokud byla změněna statická inicializační proměnná (static const), globální proměnná, main(), deklarace třídy enum/mixin, kód v @override initState(). V těchto případech je vyžadován Hot Restart. Podle údajů Flutter Team (2025) je hot reload úspěšný v 85–90 % případů; 10–15 % změn vyžaduje úplný restart.

Dart VM JIT a kernel soubory

Dart VM v debug režimu pracuje jako JIT kompilátor: interpretuje Dart kód prostřednictvím kernel formátu (obdoba bytekódu). Hot reload načte nový kernel soubor a nahradí staré definice funkcí. VM nerestartuje izoláty (isolates) — všechny asynchronní operace (Future, Stream) nadále fungují. V release režimu je Dart kompilován AOT (dart2native) a hot reload není k dispozici.

Jak funguje Fast Refresh v React Native

Fast Refresh (dříve Hot Reloading) v React Native používá Metro bundler — JavaScript modulární bundler, který sleduje změny souborů. Když vývojář uloží soubor, Metro zkompiluje pouze změněný modul (HMR — Hot Module Replacement) a odešle aktualizaci přes WebSocket do běžící aplikace.

// React Native komponenta se zachováním stavu při hot reload
import React, { useState } from 'react';
import { View, Text, Button } from 'react-native';

const Counter = () => {
    const [count, setCount] = useState(0);

    return (
        <View>
            <Text>Počítadlo: {count}Text>
            <Button title="Zvýšit"
                onPress={() => setCount(c => c + 1)} />
        View>
    );
};

Fast Refresh zachovává React stav (useState, useReducer) při aktualizaci modulu. Metro HMR přenáší pouze diff změněného modulu — ne celý bundle. React Native používá React Fast Refresh, vyvinutý React týmem (Dan Abramov, 2019): generuje nový render pro komponentu, ale zachovává hook stavy a props, pokud se podpis komponenty nezměnil.

Fast Refresh nefunguje při změně: exportu komponenty, hooků (useEffect, useMemo), modulárních závislostí a nativních modulů (Java/Objective-C). Pro takové změny je vyžadován Reload (úplné znovunačtení JS bundle) nebo Rebuild (překompilování nativního kódu). Doba fast refresh — 200–800 ms, plný reload — 2–5 sekund.

Hot Reload vs Hot Restart: srovnání

Hot Reload a Hot Restart — dva režimy aktualizace kódu s různými scénáři použití. Hot Reload je vhodný pro změny UI (styly, rozvržení, barvy, texty), když se struktura tříd a typ stavu nemění. Hot Restart je nezbytný při změně podpisů metod, přidávání nových widgetů/komponent do kořenového stromu, změně initState a nativních modulů.

Doporučená strategie: začít s hot reload. Pokud se změny neaplikovaly (IDE zobrazuje „Reload needed”) — provést hot restart. Ve Flutter se ikona tlačítka mění: blesk (⚡) pro hot reload, přeškrtnutý blesk — pokud je vyžadován restart. Efektivita vývoje s hot reload je o 40–60 % vyšší ve srovnání s úplnými překompilacemi (údaje JetBrains Developer Survey 2024).

Mechanismy implementace: injekce kódu a horká náhrada

Injekce kódu (code injection) — společný mechanismus hot reload používaný všemi frameworky. Zahrnuje tři fáze. První — detekce změny: file watcher (vestavěný v IDE) nebo souborový systém (FSNotify) zaznamená změnu .dart, .js, .tsx souboru. Druhá — kompilace: inkrementální kompilátor převede pouze změněný soubor do mezilehlé reprezentace (kernel .dill pro Dart, HMR-module pro JS). Třetí — aplikace: nový kód je přenesen do zařízení a nahradí staré definice v paměti běžící aplikace.

Horká náhrada funkcí (hot patching) — technika, při které runtime nahrazuje ukazatel na funkci (function pointer) v tabulce virtuálních metod. Dart VM používá ClassTable — interní strukturu obsahující všechny načtené třídy. Při hot reload VM najde třídu v ClassTable a nahradí její definice funkcí novými z kernel souboru. Všechny existující instance třídy automaticky získají nové chování.

// Flutter: reassemble callback pro správu stavu po hot reload
class MyWidget extends StatefulWidget {
    @override
    State createState() => _MyState();
}

mixin ReloadAware on State {
    @override
    void reassemble() {
        super.reassemble();
        // Resetování mezipaměti nebo dat po hot reload
        clearCache();
    }
}

V příkladu mixin ReloadAware přepisuje metodu reassemble(), kterou Dart VM volá na každém State objektu po hot reload. Vývojář může resetovat mezipaměť, znovu inicializovat zdroje nebo provést migraci stavu. Bez této metody mohou stará data zůstat v mezipaměti a způsobit nesoulad po aktualizaci widgetů.

Omezení horké náhrady

Horká náhrada nefunguje pro změny vyžadující přerozdělení paměti pro nová pole, změnu typu proměnné ve třídě, přidání nových polí do StatefulWidget, změnu hodnot enum nebo generic parametrů. Tyto změny jsou nekompatibilní s existujícími objekty v paměti — Dart VM nemůže „přeskupit” pole v již přidělených objektech. Pro takové případy je vyžadován horký restart (hot restart) nebo úplná překompilace.

Hot Reload v nativním vývoji: Android a iOS

Nativní Android a iOS vývoj tradičně nemá plnohodnotný hot reload. Android Studio s Android 11+ a AGP 4.2+ podporuje Apply Changes: aktualizaci kódu bez restartu aplikace. Apply Changes funguje prostřednictvím Android Runtime (ART) — nahrazuje implementace metod v dex souborech za běhu. Apply Changes je však omezený: nefunguje pro změny zdrojů (layout.xml, drawable), manifestu a nativních knihoven.

Apple představil Previews (SwiftUI Preview) v Xcode 15 (2023) — to není hot reload v klasickém smyslu. Previews kompilují sekci náhledu odděleně od hlavní aplikace a zobrazují výsledek v plátně Xcode. Při uložení souboru se Preview aktualizuje za 1–3 sekundy, ale stav aplikace není zachován. Pro UIKit projekty je hot reload k dispozici prostřednictvím nástrojů třetích stran: InjectionIII (John Holdsworth) a SwiftHotReload.

Kotlin Multiplatform (KMP) od roku 2024 získal experimentální podporu hot reload od JetBrains. Mechanismus je založen na Kotlin/Native runtime s náhradou funkcí v objektovém souboru (.klib). JetBrains Compose Multiplayer používá vlastní implementaci hot reload, podobnou Flutter: inkrementální kompilace a náhrada tříd v Kotlin/Native runtime. Rychlost — 1–3 sekundy, k dispozici pouze pro změny UI.

Apply Changes v Android Studio: jak funguje

Apply Changes — mechanismus Android Studio využívající ART runtime API. Při uložení kódu Android Studio určí, které třídy se změnily, a odešle jejich dex soubory do zařízení přes adb. ART nahrazuje implementace metod v běžící aplikaci bez zastavení. Apply Changes funguje ve třech režimech: Instant Run (rychlá náhrada metody), Swap (náhrada třídy s novým vytvořením instancí) a Restart Activity (pokud změny nejsou kompatibilní s aktuálním stavem).