Runtime, Hot Reload a sestavování v mobilním vývoji: co to je, klíčové koncepty a jak to funguje

Runtime a Reflection: iOS Runtime, Method Swizzling a dynamické odesílání

Runtime (běhové prostředí) je software, který řídí provádění aplikace. V kontextu iOS Runtime je to dynamický systém Objective-C, který umožňuje posílat zprávy objektům, vytvářet třídy za běhu a nahrazovat metody během provádění. To je možné, protože Objective-C je dynamicky typovaný jazyk postavený na C.

Reflection je schopnost programu zkoumat a měnit svou vlastní strukturu za běhu. V iOS Runtime je to implementováno prostřednictvím funkcí jako class_getInstanceMethod, method_exchangeImplementations a objc_getAssociatedObject. V Kotlin/Java používá reflexe KClass / java.lang.reflect.

V IT Sectr používáme Runtime velmi zřídka — pouze pro specifické úkoly, kde není alternativa. Například Method Swizzling pro centralizované protokolování analýz nebo opravu chyb v knihovnách. Runtime je však mocný nástroj, který vyžaduje hluboké porozumění a opatrnost.

Method Swizzling

Method Swizzling je technika nahrazení implementace metody Objective-C jinou za běhu. Jedná se o speciální případ aspektově orientovaného programování (AOP) pro iOS. Swizzling umožňuje přidat protokolování, analýzy nebo ukládání do mezipaměti do existujících metod bez změny jejich zdrojového kódu.

Typický příklad: nahrazení viewWillAppear: v UIViewController pro přidání automatického protokolování obrazovek. Důležité: swizzling musí být proveden v metodě +load nebo +initialize, aby bylo zajištěno provedení před použitím třídy. Nesprávný swizzling může vést k nedefinovanému chování a chybám, které se obtížně ladí.

// Method Swizzling pro protokolování viewWillAppear:
@implementation UIViewController (Tracking)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];
        SEL originalSelector = @selector(viewWillAppear:);
        SEL swizzledSelector = @selector(xxx_viewWillAppear:);
        
        Method originalMethod = class_getInstanceMethod(class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
        method_exchangeImplementations(originalMethod, swizzledMethod);
    });
}

- (void)xxx_viewWillAppear:(BOOL)animated {
    [self xxx_viewWillAppear:animated]; // volání původní metody
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Tento kód nahrazuje viewWillAppear: na všech UIViewController prostřednictvím swizzlingu. Po method_exchangeImplementations vede volání původního viewWillAppear: k volání xxx_viewWillAppear:, které volá původní metodu (prostřednictvím rekurzivního volání) a přidává analýzy. DispatchOnce zaručuje jednorázové provedení swizzlingu.

Webové nástroje (Transpilation, Polyfill, Bundler, Webpack, Metro)

Moderní vývoj webu a mobilní vývoj s React Native nebo Flutter jsou bez nástrojů pro sestavování nemožné. Transpilation je převod kódu z jednoho jazyka do druhého. Nejoblíbenější příklad: TypeScript → JavaScript. Transpilátor (Babel, tsc) převádí moderní kód do zpětně kompatibilní verze.

Polyfill je kód, který přidává chybějící funkčnost starým prohlížečům. Například Promise.allSettled() nefunguje v Internet Exploreru, ale polyfill přidává tuto schopnost. Na rozdíl od nativního Runtime, který řídí provádění kódu přímo na zařízení, polyfilly a transpilátory pracují na úrovni abstrakce jazyka — přizpůsobují syntaxi a API, ale nezasahují do běhového prostředí.

Webpack je nejoblíbenější bundler (používaný v 72% projektů podle State of JS 2024). Metro je bundler od Facebooku, používaný ve výchozím nastavení v React Native. Reflection v JavaScriptu existuje prostřednictvím Object.getPrototypeOf, Proxy a Reflect API — tyto mechanismy umožňují zkoumat a měnit objekty za běhu, což se zásadně liší od statické analýzy modulů v bundlerech. Webpack používá konfigurační soubor, který popisuje vstupní bod, výstup, loadery (pro zpracování různých typů souborů) a pluginy (pro další funkčnost).

// webpack.config.js — minimální konfigurace
const path = require('path');

module.exports = {
    entry: './src/index.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist'),
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: 'babel-loader',
            },
        ],
    },
    mode: 'production',
};

Tato konfigurace definuje vstupní bod (index.js), výstupní soubor (bundle.js) a pravidlo pro zpracování JavaScriptu přes Babel. Režim production zapíná optimalizace: minifikaci, tree shaking a automatickou detekci prostředí. Ve fázi Runtime všechny tyto optimalizace již neovlivňují logiku — prohlížeč spouští minifikovaný bundle jako běžný JavaScript.

Optimalizace kódu (Minification, Tree Shaking, Obfuscation)

Minification je proces komprese kódu odstraněním mezer, komentářů a přejmenováním dlouhých proměnných na krátké. Populární minifikátory: Terser (JS/TS), CSSNano (CSS), html-minifier-terser. Minifikace snižuje velikost souboru o 50–70%. V produkci spouští Runtime minifikovaný kód stejně jako původní — rozdíl je pouze v čitelnosti a velikosti souboru, ne v sémantice.

Tree Shaking je odstranění mrtvého kódu, který se v aplikaci nepoužívá. Funguje na základě statické analýzy ES modulů (import/export). Pokud je funkce exportována, ale nikdy importována, Tree Shaking ji odstraní z konečného sestavení. Tree Shaking analyzuje kód staticky — na rozdíl od Reflection, který pracuje dynamicky a může přistupovat k metodám a vlastnostem neviditelným v době kompilace.

Tree Shaking

Tree Shaking ve Webpacku se automaticky zapíná v produkčním režimu. Důležitá podmínka: kód musí používat ES moduly (import/export), ne CommonJS (require). Pokud je knihovna napsaná v CommonJS, tree shaking nebude fungovat. Pro optimální tree shaking používejte přesné importy: import { merge } from 'lodash-es' místo import _ from 'lodash'. To snižuje velikost bundle z 500 KB na 10 KB pro jednu funkci.

Hot Reload

Hot Reload je technologie, která umožňuje aktualizovat kód aplikace bez úplného znovunačtení. V React Native a Flutter aktualizuje Hot Reload změněný soubor za běhu a zachovává aktuální stav aplikace. To radikálně zrychluje vývoj: změny jsou viditelné za 1–2 sekundy místo 10–30 sekund pro úplné přestavění. Hot Reload pracuje uvnitř Runtime: změněný modul je vložen do běžící aplikace bez restartování běhového prostředí.

Hot Restart je rychlý restart aplikace s aktualizovaným kódem, ale bez zachování stavu. Používá se, když Hot Reload není možný (například když se změnil nativní kód nebo globální proměnné). V IT Sectr používáme Hot Reload ve všech fázích vývoje UI — šetří až 50% času na vizuální úpravy.

Tabulka 3. Srovnání nástrojů pro sestavování. Webpack je univerzální standard. Metro je specializovaný pro React Native. Vite a esbuild jsou nová generace zaměřená na rychlost. Rollup je nejlepší volba pro publikování knihoven.

Hot Reload (Hot Reload, Hot Restart)

Hot Reload je technologie, která vznikla ve vývoji webu (React Hot Loader, HMR — Hot Module Replacement) a přešla do mobilního vývoje s Flutter a React Native. Podstata: když se soubor změní, bundler pošle aktualizovaný modul běžící aplikaci, která nahradí starý kód bez ztráty stavu. Na rozdíl od úplného přestavění Hot Reload nerestartuje Runtime — běhové prostředí pokračuje v činnosti a změněný modul je dynamicky připojen prostřednictvím mechanismu jako HMR nebo aktualizace reference podobné Reflection.

Hot Reload funguje, protože framework udržuje widgety (Flutter) nebo komponenty (React) v paměti a aktualizuje pouze změněné části. Hot Restart je hrubší mechanismus: zcela restartuje aplikaci, ale je rychlejší než úplné přestavění, protože nepřekládá nativní kód. V IT Sectr používáme Hot Reload při vývoji UI a Hot Restart při změnách navigace nebo správy stavu.