Runtime, Hot Reload és építés a mobilfejlesztésben: mik ezek, kulcsfontosságú fogalmak és hogyan működnek

Runtime és Reflection: iOS Runtime, Method Swizzling és dinamikus üzenetküldés

Runtime (végrehajtási környezet) az a szoftver, amely az alkalmazás végrehajtását kezeli. Az iOS Runtime kontextusában ez az Objective-C dinamikus rendszere, amely lehetővé teszi üzenetek küldését objektumoknak, osztályok létrehozását menet közben és metódusok cseréjét futás közben. Ez azért lehetséges, mert az Objective-C egy dinamikusan típusos nyelv, amely C-re épül.

Reflection egy program azon képessége, hogy futás közben megvizsgálja és módosítsa saját szerkezetét. Az iOS Runtime-ban ez olyan függvényeken keresztül valósul meg, mint a class_getInstanceMethod, method_exchangeImplementations és objc_getAssociatedObject. Kotlin/Java-ban a reflection a KClass / java.lang.reflect használja.

Az IT Sectr-nél nagyon ritkán használjuk a Runtime-ot — csak olyan speciális feladatokhoz, ahol nincs alternatíva. Például Method Swizzling a központosított analitikai naplózáshoz vagy a könyvtárak hibáinak javításához. A Runtime azonban egy hatékony eszköz, amely mély megértést és óvatosságot igényel.

Method Swizzling

Method Swizzling egy olyan technika, amely futás közben egy Objective-C metódus implementációját egy másikra cseréli. Ez az aspektusorientált programozás (AOP) egy speciális esete iOS-re. A Swizzling lehetővé teszi naplózás, analitika vagy gyorsítótárazás hozzáadását meglévő metódusokhoz anélkül, hogy megváltoztatná a forráskódjukat.

Egy tipikus példa: a viewWillAppear: cseréje a UIViewController-ben automatikus képernyő-naplózás hozzáadásához. Fontos: a swizzling-et a +load vagy +initialize metódusban kell végrehajtani, hogy garantáljuk a végrehajtást az osztály használata előtt. A helytelen swizzling nem definiált viselkedéshez és nehezen debugolható hibákhoz vezethet.

// Method Swizzling a viewWillAppear: naplózásához
@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]; // az eredeti metódus meghívása
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Ez a kód a viewWillAppear: metódust cseréli ki az összes UIViewController-en swizzling segítségével. A method_exchangeImplementations után az eredeti viewWillAppear: meghívása a xxx_viewWillAppear: meghívásához vezet, amely meghívja az eredeti metódust (rekurzív hívással) és hozzáadja az analitikát. A DispatchOnce garantálja a swizzling egyszeri végrehajtását.

Webeszközök (Transpilation, Polyfill, Bundler, Webpack, Metro)

A modern webfejlesztés és a React Native vagy Flutter használatával történő mobilfejlesztés lehetetlen építőeszközök nélkül. Transpilation a kód átalakítása egyik nyelvről a másikra. A legnépszerűbb példa: TypeScript → JavaScript. Egy transzpiláló (Babel, tsc) a modern kódot visszafelé kompatibilis verzióvá alakítja.

Polyfill olyan kód, amely hiányzó funkcionalitást ad hozzá a régi böngészőkhöz. Például a Promise.allSettled() nem működik az Internet Explorer-ben, de egy polyfill hozzáadja ezt a képességet. A natív Runtime-tól eltérően, amely közvetlenül az eszközön kezeli a kód végrehajtását, a polyfill-ek és transzpilálók a nyelvi absztrakció szintjén működnek — hozzáigazítják a szintaxist és API-kat, de nem avatkoznak be a végrehajtási környezetbe.

Webpack a legnépszerűbb bundler (a State of JS 2024 szerint a projektek 72%-ában használják). A Metro a Facebook bundlere, amely alapértelmezés szerint használatos a React Native-ben. Reflection a JavaScript-ben az Object.getPrototypeOf, Proxy és Reflect API-n keresztül létezik — ezek a mechanizmusok lehetővé teszik az objektumok futás közbeni vizsgálatát és módosítását, ami alapvetően különbözik a bundlerek statikus modulanalízisétől. A Webpack egy konfigurációs fájlt használ, amely leírja a belépési pontot, a kimenetet, a betöltőket (különböző fájltípusok feldolgozásához) és a bővítményeket (további funkcionalitáshoz).

// webpack.config.js — minimális konfiguráció
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',
};

Ez a konfiguráció meghatározza a belépési pontot (index.js), a kimeneti fájlt (bundle.js) és egy szabályt a JavaScript Babel-en keresztüli feldolgozásához. A production mód optimalizációkat kapcsol be: minifikációt, tree shaking-et és automatikus környezetfelismerést. A Runtime szakaszban ezek az optimalizációk már nem befolyásolják a logikát — a böngésző a minifikált bundle-t normál JavaScriptként hajtja végre.

Kódoptimalizálás (Minification, Tree Shaking, Obfuscation)

Minification a kód tömörítésének folyamata szóközök, megjegyzések eltávolításával és hosszú változók rövidre átnevezésével. Népszerű minifikátorok: Terser (JS/TS), CSSNano (CSS), html-minifier-terser. A minifikáció 50–70%-kal csökkenti a fájlméretet. Élesben a Runtime a minifikált kódot ugyanúgy hajtja végre, mint az eredetit — a különbség csak az olvashatóságban és a fájlméretben van, nem a szemantikában.

Tree Shaking a fel nem használt, halott kód eltávolítása az alkalmazásból. Az ES-modulok (import/export) statikus elemzésén alapul. Ha egy függvény exportálva van, de soha nem importálják, a Tree Shaking eltávolítja a végső buildből. A Tree Shaking statikusan elemzi a kódot — ellentétben a Reflection-nel, amely dinamikusan működik és hozzáférhet a fordítási időben láthatatlan metódusokhoz és tulajdonságokhoz.

Tree Shaking

Tree Shaking a Webpack-ben automatikusan bekapcsol éles módban. Fontos feltétel: a kódnak ES-modulokat (import/export) kell használnia, nem CommonJS-t (require). Ha egy könyvtár CommonJS-ben íródott, a tree shaking nem fog működni. Az optimális tree shaking-hez használjon pontos importokat: import { merge } from 'lodash-es' az import _ from 'lodash' helyett. Ez egyetlen függvény esetében 500 KB-ról 10 KB-ra csökkenti a bundle méretét.

Hot Reload

Hot Reload egy olyan technológia, amely lehetővé teszi az alkalmazáskód frissítését teljes újratöltés nélkül. A React Native-ben és Flutter-ben a Hot Reload menet közben frissíti a megváltoztatott fájlt, megőrizve az alkalmazás aktuális állapotát. Ez radikálisan felgyorsítja a fejlesztést: a változtatások 1–2 másodperc alatt láthatóvá válnak, szemben a teljes újraépítés 10–30 másodpercével. A Hot Reload a Runtime-on belül működik: a módosított modul a futó alkalmazásba injektálódik a végrehajtási környezet újraindítása nélkül.

A Hot Restart az alkalmazás gyors újraindítása frissített kóddal, de az állapot megőrzése nélkül. Akkor használatos, amikor a Hot Reload nem lehetséges (például amikor a natív kód vagy a globális változók megváltoztak). Az IT Sectr-nél a Hot Reload-ot a UI-fejlesztés minden szakaszában használjuk — akár 50%-ot spórolva a vizuális módosítások idejéből.

3. táblázat. Építőeszközök összehasonlítása. A Webpack univerzális szabvány. A Metro a React Native-re specializált. A Vite és az esbuild a sebességre összpontosító új generáció. A Rollup a legjobb választás könyvtárak kiadásához.

Forró újratöltés (Hot Reload, Hot Restart)

Hot Reload egy olyan technológia, amely a webfejlesztésből származik (React Hot Loader, HMR — Hot Module Replacement) és átkerült a mobilfejlesztésbe a Flutter és React Native alkalmazásával. A lényeg: amikor egy fájl megváltozik, a bundler elküldi a frissített modult a futó alkalmazásnak, amely állapotvesztés nélkül lecseréli a régi kódot. A teljes újraépítéssel ellentétben a Hot Reload nem indítja újra a Runtime-ot — a végrehajtási környezet tovább működik, és a módosított modul dinamikusan csatlakozik egy olyan mechanizmuson keresztül, mint a HMR vagy egy Reflection-szerű referenciamódosítás.

A Hot Reload azért működik, mert a keretrendszer a widget-eket (Flutter) vagy komponenseket (React) memóriában tartja és csak a megváltozott részeket frissíti. Hot Restart egy durvább mechanizmus: teljesen újraindítja az alkalmazást, de gyorsabb, mint a teljes újraépítés, mert nem fordítja újra a natív kódot. Az IT Sectr-nél a Hot Reload-ot a UI fejlesztésekor, a Hot Restart-ot pedig a navigáció vagy állapotkezelés módosításakor használjuk.