Hot Reload mobilalkalmazásokhoz: mi ez, működési elv és mechanizmusok

Mi az a Hot Reload?

Hot Reload — olyan fejlesztési mechanizmus, amelyben a forráskódot módosítják és egy már futó alkalmazásra alkalmazzák anélkül, hogy azt leállítanák. A fejlesztő szerkeszti a fájlt, elmenti, és 0.3–2 másodperc múlva a frissített felület megjelenik a képernyőn. Az alkalmazás állapota (számlálók, görgetési pozíció, bevitt adatok) megmarad — a fejlesztő nem veszíti el a kontextust.

A hot reload koncepciója a korai webes eszközökben (LiveReload, 2010) jelent meg, és a Flutter (2017) és React Native (2015) keretrendszerek adaptálták a mobilfejlesztéshez. Ma a hot reload a modern mobil keretrendszerek kötelező funkciója, a debug konfiguráció és a profilozás mellett. Hot reload nélkül a UI-fejlesztés hatástalannak számít: minden változtatás megtekintése 10–30 másodpercet igényel az újrafordításra és indításra.

Technikailag a hot reload három lépésből áll: változás észlelése (file watcher), módosított kód fordítása (incremental compiler) és alkalmazása (hot patching). Minden keretrendszer másképp valósítja meg ezeket a lépéseket, de az eredmény ugyanaz: minimális késleltetés a szerkesztés és a megjelenítés között.

Hogyan működik a Hot Reload a Flutterben

Hot Reload a Flutterben a Dart VM architektúrájára és a JIT-fordításra épül. Amikor a fejlesztő megnyomja a „Hot Reload” gombot az IDE-ben vagy elment egy fájlt, a Flutter elvégzi a módosított Dart könyvtárak növekményes fordítását kernel fájlokba (.dill). A Dart VM betölti ezeket a fájlokat, és lecseréli a módosított függvények implementációit a futó alkalmazásban.

// Flutter widget állapottal, amely megmarad hot reload során
class CounterWidget extends StatefulWidget {
    @override
    State createState() => _CounterState();
}

class _CounterState extends State {
    int _counter = 0;

    @override
    Widget build(BuildContext context) {
        return Column(
            children: [
                Text('Számláló: $_counter'),
                ElevatedButton(
                    onPressed: () => setState(() => _counter++),
                    child: Text('Növelés'),
                ),
            ],
        );
    }
}

A példában a StatefulWidget CounterWidget megőrzi a _counter mezőt hot reload közben. A Dart VM újra létrehozza az állapotot (State) a reassemble() meghívásával, de nem nullázza a _counter-t — az érték megmarad, ha a widget nem kerül teljesen újra létrehozásra. A Flutter meghívja a reassemble() metódust az összes State objektumra, és a build() újra lefut a friss kóddal és a megőrzött állapottal.

Mikor nem működik a hot reload: ha statikus inicializációs változó (static const), globális változó, main(), enum/mixin osztálydeklaráció, @override initState()-ban lévő kód változott. Ezekben az esetekben Hot Restart szükséges. A Flutter Team (2025) adatai szerint a hot reload az esetek 85–90%-ában sikeres; a változtatások 10–15%-a teljes újraindítást igényel.

Dart VM JIT és kernel fájlok

Dart VM debug módban JIT-fordítóként működik: a Dart kódot kernel formátumon keresztül értelmezi (a bájtkód analógja). A hot reload betölti az új kernel fájlt, és lecseréli a régi függvénydefiníciókat. A VM nem indítja újra az izolátumokat (isolates) — minden aszinkron művelet (Future, Stream) tovább működik. Release módban a Dart AOT (dart2native) fordítással készül, és a hot reload nem elérhető.

Hogyan működik a Fast Refresh a React Native-ben

Fast Refresh (korábban Hot Reloading) a React Native-ben a Metro bundlert használja — egy JavaScript moduláris bundlert, amely nyomon követi a fájlváltozásokat. Amikor a fejlesztő elment egy fájlt, a Metro csak a módosított modult fordítja le (HMR — Hot Module Replacement), és elküldi a frissítést WebSocketen keresztül a futó alkalmazásba.

// React Native komponens állapotmegőrzéssel hot reload során
import React, { useState } from 'react';
import { View, Text, Button } from 'react-native';

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

    return (
        <View>
            <Text>Számláló: {count}Text>
            <Button title="Növelés"
                onPress={() => setCount(c => c + 1)} />
        View>
    );
};

A Fast Refresh megőrzi a React állapotot (useState, useReducer) a modul frissítésekor. Metro HMR csak a módosított modul diff-jét küldi el — nem a teljes bundlet. A React Native a React Fast Refresh-et használja, amelyet a React csapat fejlesztett ki (Dan Abramov, 2019): új renderelést generál a komponenshez, de megtartja a hook állapotokat és a propsokat, ha a komponens aláírása nem változott.

A Fast Refresh nem működik a következők változtatásakor: komponens export, hookok (useEffect, useMemo), moduláris függőségek és natív modulok (Java/Objective-C). Az ilyen változtatásokhoz Reload (a JS-bundle teljes újratöltése) vagy Rebuild (natív kód újrafordítása) szükséges. Fast refresh idő — 200–800 ms, teljes reload — 2–5 másodperc.

Hot Reload vs Hot Restart: összehasonlítás

Hot Reload és Hot Restart — két kódfrissítési mód eltérő használati forgatókönyvekkel. A Hot Reload UI-változtatásokhoz (stílusok, elrendezés, színek, szövegek) alkalmas, amikor az osztályok szerkezete és az állapot típusa nem változik. Hot Restart szükséges a metódusaláírások megváltoztatásakor, új widgetek/komponensek hozzáadásakor a gyökérelemfához, initState és natív modulok megváltoztatásakor.

Ajánlott stratégia: kezdeni hot reload-dal. Ha a változtatások nem érvényesültek (az IDE „Reload needed” üzenetet mutat) — hajtsa végre a hot restart-ot. A Flutterben a gomb ikonja megváltozik: villám (⚡) hot reload esetén, áthúzott villám — ha restart szükséges. Fejlesztési hatékonyság hot reload-dal 40–60%-kal magasabb a teljes újrafordításokhoz képest (JetBrains Developer Survey 2024 adatai).

Megvalósítási mechanizmusok: kódbefecskendezés és forró csere

Kódbefecskendezés (code injection) — a hot reload közös mechanizmusa, amelyet minden keretrendszer használ. Három fázisból áll. Első — változás észlelése: file watcher (az IDE-be építve) vagy a fájlrendszer (FSNotify) rögzíti a .dart, .js, .tsx fájl változását. Második — fordítás: a növekményes fordító csak a módosított fájlt alakítja át köztes reprezentációvá (kernel .dill Dart esetén, HMR-module JS esetén). Harmadik — alkalmazás: az új kód átkerül az eszközre, és lecseréli a régi definíciókat a futó alkalmazás memóriájában.

Függvények forró cseréje (hot patching) — technika, amelyben a runtime lecseréli a függvénymutatót (function pointer) a virtuális metódustáblában. A Dart VM a ClassTable-t használja — egy belső struktúrát, amely az összes betöltött osztályt tartalmazza. Hot reload esetén a VM megtalálja az osztályt a ClassTable-ben, és lecseréli a függvénydefinícióit a kernel fájlból származó újakra. Az osztály összes meglévő példánya automatikusan megkapja az új viselkedést.

// Flutter: reassemble visszahívás az állapot kezeléséhez hot reload után
class MyWidget extends StatefulWidget {
    @override
    State createState() => _MyState();
}

mixin ReloadAware on State {
    @override
    void reassemble() {
        super.reassemble();
        // Gyorsítótár vagy adatok visszaállítása hot reload után
        clearCache();
    }
}

A példában a ReloadAware mixin felülírja a reassemble() metódust, amelyet a Dart VM minden State objektumon meghív hot reload után. A fejlesztő visszaállíthatja a gyorsítótárat, újrainicializálhatja az erőforrásokat, vagy állapotáttelepítést végezhet. E metódus nélkül a régi adatok a gyorsítótárban maradhatnak, és inkonzisztenciát okozhatnak a widgetek frissítése után.

A forró csere korlátai

A forró csere nem működik olyan változtatásoknál, amelyek a memória újraelosztását igénylik új mezőkhöz, az osztályban lévő változó típusának megváltoztatását, új mezők hozzáadását a StatefulWidget-hez, enum értékek vagy generikus paraméterek megváltoztatását. Ezek a változtatások nem kompatibilisek a memóriában lévő meglévő objektumokkal — a Dart VM nem tudja „átrendezni” a mezőket a már lefoglalt objektumokban. Ilyen esetekben forró újraindítás (hot restart) vagy teljes újrafordítás szükséges.

Hot Reload natív fejlesztésben: Android és iOS

Natív Android és iOS fejlesztés hagyományosan nem rendelkezik teljes hot reload-dal. Az Android Studio Android 11+ és AGP 4.2+ támogatja az Apply Changes-t: kód frissítése az alkalmazás újraindítása nélkül. Az Apply Changes az Android Runtime (ART) segítségével működik — menet közben lecseréli a metódusimplementációkat a dex fájlokban. Az Apply Changes azonban korlátozott: nem működik erőforrások (layout.xml, drawable), manifest és natív könyvtárak változtatására.

Apple bemutatta a Previews (SwiftUI Preview) funkciót az Xcode 15-ben (2023) — ez nem hot reload a klasszikus értelemben. A Previews külön fordítja le az előnézeti szakaszt a fő alkalmazástól, és az eredményt az Xcode canvas-ban jeleníti meg. Fájl mentésekor a Preview 1–3 másodperc alatt frissül, de az alkalmazás állapota nem marad meg. UIKit projektekhez a hot reload harmadik féltől származó eszközökkel érhető el: InjectionIII (John Holdsworth) és SwiftHotReload.

Kotlin Multiplatform (KMP) 2024-től kapott kísérleti hot reload támogatást a JetBrains-től. A mechanizmus a Kotlin/Native runtime-on alapul a függvények objektumfájlban (.klib) történő cseréjével. A JetBrains Compose Multiplayer a saját hot reload megvalósítását használja, hasonlóan a Flutterhez: növekményes fordítás és osztálycsere a Kotlin/Native runtime-ban. Sebesség — 1–3 másodperc, csak UI-változtatásokhoz érhető el.

Apply Changes az Android Studio-ban: hogyan működik

Apply Changes — az Android Studio mechanizmusa, amely az ART runtime API-t használja. Kód mentésekor az Android Studio meghatározza, mely osztályok változtak meg, és elküldi a dex fájljaikat az eszközre adb-n keresztül. Az ART lecseréli a metódusimplementációkat a futó alkalmazásban anélkül, hogy leállítaná. Az Apply Changes három módban működik: Instant Run (gyors metóduscsere), Swap (osztálycsere a példányok újra létrehozásával) és Restart Activity (ha a változtatások nem kompatibilisek az aktuális állapottal).