Runtime, Hot Reload și construirea în dezvoltarea mobilă: ce sunt, concepte cheie și cum funcționează

Runtime și Reflection: iOS Runtime, Method Swizzling și expediere dinamică

Runtime (mediu de execuție) este software-ul care gestionează execuția aplicației. În contextul iOS Runtime, este sistemul dinamic al Objective-C care permite trimiterea de mesaje către obiecte, crearea claselor din mers și înlocuirea metodelor în timpul execuției. Acest lucru este posibil deoarece Objective-C este un limbaj tipizat dinamic construit pe C.

Reflection este capacitatea unui program de a-și examina și modifica propria structură în timpul execuției. În iOS Runtime, aceasta este implementată prin funcții precum class_getInstanceMethod, method_exchangeImplementations și objc_getAssociatedObject. În Kotlin/Java, reflecția folosește KClass / java.lang.reflect.

La IT Sectr, folosim Runtime foarte rar — doar pentru sarcini specifice unde nu există alternativă. De exemplu, Method Swizzling pentru înregistrarea centralizată a analiticelor sau corectarea erorilor în biblioteci. Cu toate acestea, Runtime este un instrument puternic care necesită înțelegere profundă și prudență.

Method Swizzling

Method Swizzling este o tehnică de înlocuire a implementării unei metode Objective-C cu alta în timpul execuției. Este un caz particular de Programare Orientată pe Aspecte (AOP) pentru iOS. Swizzling permite adăugarea de înregistrare, analitice sau cache la metodele existente fără a modifica codul lor sursă.

Un exemplu tipic: înlocuirea viewWillAppear: în UIViewController pentru a adăuga înregistrarea automată a ecranelor. Important: swizzling-ul trebuie executat în metoda +load sau +initialize pentru a garanta execuția înainte de utilizarea clasei. Un swizzling incorect poate cauza comportament nedefinit și erori dificil de depanat.

// Method Swizzling pentru înregistrarea 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]; // apelarea metodei originale
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Acest cod înlocuiește viewWillAppear: pe toate UIViewController prin swizzling. După method_exchangeImplementations, apelul viewWillAppear: original duce la apelul xxx_viewWillAppear:, care apelează metoda originală (prin apel recursiv) și adaugă analitice. DispatchOnce garantează execuția unică a swizzling-ului.

Instrumente web (Transpilation, Polyfill, Bundler, Webpack, Metro)

Dezvoltarea web modernă și dezvoltarea mobilă cu React Native sau Flutter sunt imposibile fără instrumente de construire. Transpilation este conversia codului dintr-o limbă în alta. Cel mai popular exemplu: TypeScript → JavaScript. Un transpilator (Babel, tsc) convertește codul modern într-o versiune compatibilă retroactiv.

Polyfill este cod care adaugă funcționalitate lipsă browserelor vechi. De exemplu, Promise.allSettled() nu funcționează în Internet Explorer, dar un polyfill adaugă această capacitate. Spre deosebire de Runtime nativ, care gestionează execuția codului direct pe dispozitiv, polyfill-urile și transpilatoarele operează la nivelul de abstractizare a limbajului — adaptează sintaxa și API-urile, dar nu interferează cu mediul de execuție.

Webpack este cel mai popular bundler (folosit în 72% din proiecte conform State of JS 2024). Metro este bundlerul Facebook, folosit implicit în React Native. Reflection în JavaScript există prin Object.getPrototypeOf, Proxy și Reflect API — aceste mecanisme permit examinarea și modificarea obiectelor în timpul execuției, ceea ce este fundamental diferit de analiza statică a modulelor în bundlere. Webpack folosește un fișier de configurare care descrie punctul de intrare, ieșirea, încărcătoarele (pentru procesarea diferitelor tipuri de fișiere) și plugin-urile (pentru funcționalitate suplimentară).

// webpack.config.js — configurare minimă
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',
};

Această configurare definește punctul de intrare (index.js), fișierul de ieșire (bundle.js) și o regulă pentru procesarea JavaScript prin Babel. Modul production activează optimizări: minificare, tree shaking și detectare automată a mediului. În etapa Runtime, toate aceste optimizări nu mai afectează logica — browserul execută bundle-ul minificat ca JavaScript obișnuit.

Optimizarea codului (Minification, Tree Shaking, Obfuscation)

Minification este procesul de comprimare a codului prin eliminarea spațiilor, comentariilor și redenumirea variabilelor lungi în scurte. Minificatoare populare: Terser (JS/TS), CSSNano (CSS), html-minifier-terser. Minificarea reduce dimensiunea fișierului cu 50–70%. În producție, Runtime execută codul minificat la fel ca cel original — diferența este doar în lizibilitate și dimensiunea fișierului, nu în semantică.

Tree Shaking este eliminarea codului mort care nu este utilizat în aplicație. Funcționează pe baza analizei statice a modulelor ES (import/export). Dacă o funcție este exportată dar niciodată importată, Tree Shaking o elimină din construcția finală. Tree Shaking analizează codul static — spre deosebire de Reflection, care funcționează dinamic și poate accesa metode și proprietăți invizibile la momentul compilării.

Tree Shaking

Tree Shaking în Webpack este activat automat în modul producție. O condiție importantă: codul trebuie să folosească module ES (import/export), nu CommonJS (require). Dacă o bibliotecă este scrisă în CommonJS, tree shaking nu va funcționa. Pentru un tree shaking optim, folosiți importuri precise: import { merge } from 'lodash-es' în loc de import _ from 'lodash'. Aceasta reduce dimensiunea bundle-ului de la 500 KB la 10 KB pentru o singură funcție.

Hot Reload

Hot Reload este o tehnologie care permite actualizarea codului aplicației fără o reîncărcare completă. În React Native și Flutter, Hot Reload actualizează fișierul modificat din mers, păstrând starea curentă a aplicației. Acest lucru accelerează radical dezvoltarea: modificările sunt vizibile în 1–2 secunde în loc de 10–30 secunde pentru o reconstruire completă. Hot Reload funcționează în cadrul Runtime: modulul modificat este injectat în aplicația în execuție fără a reporni mediul de execuție.

Hot Restart este o repornire rapidă a aplicației cu cod actualizat, dar fără păstrarea stării. Este utilizat când Hot Reload nu este posibil (de exemplu, când codul nativ sau variabilele globale s-au schimbat). La IT Sectr, folosim Hot Reload în toate etapele de dezvoltare UI — economisește până la 50% din timpul pentru ajustări vizuale.

Tabelul 3. Compararea instrumentelor de construire. Webpack este standardul universal. Metro este specializat pentru React Native. Vite și esbuild sunt noua generație focusată pe viteză. Rollup este cea mai bună alegere pentru publicarea bibliotecilor.

Reîncărcare la cald (Hot Reload, Hot Restart)

Hot Reload este o tehnologie care a apărut în dezvoltarea web (React Hot Loader, HMR — Hot Module Replacement) și a trecut la dezvoltarea mobilă cu Flutter și React Native. Esența: când un fișier se schimbă, bundlerul trimite modulul actualizat aplicației în execuție, care înlocuiește codul vechi fără a pierde starea. Spre deosebire de o reconstruire completă, Hot Reload nu repornește Runtime — mediul de execuție continuă să funcționeze, iar modulul modificat este conectat dinamic printr-un mecanism precum HMR sau o actualizare de referință asemănătoare Reflection.

Hot Reload funcționează deoarece framework-ul păstrează widget-urile (Flutter) sau componentele (React) în memorie și actualizează doar părțile modificate. Hot Restart este un mecanism mai dur: repornește complet aplicația, dar este mai rapid decât o reconstruire completă deoarece nu recompilă codul nativ. La IT Sectr, folosim Hot Reload la dezvoltarea UI și Hot Restart la modificarea navigației sau gestionării stării.