Runtime, Hot Reload i budowanie w rozwoju mobilnym: co to jest, kluczowe koncepcje i jak działa

Runtime i Reflection: iOS Runtime, Method Swizzling i dynamiczne wysyłanie

Runtime (środowisko wykonawcze) to oprogramowanie zarządzające wykonywaniem aplikacji. W kontekście iOS Runtime jest to dynamiczny system Objective-C, który pozwala wysyłać wiadomości do obiektów, tworzyć klasy w locie i zastępować metody w czasie wykonywania. Jest to możliwe, ponieważ Objective-C jest dynamicznie typowanym językiem opartym na C.

Reflection to zdolność programu do badania i modyfikowania własnej struktury w czasie wykonywania. W iOS Runtime jest to implementowane przez funkcje takie jak class_getInstanceMethod, method_exchangeImplementations i objc_getAssociatedObject. W Kotlin/Java refleksja używa KClass / java.lang.reflect.

W IT Sectr używamy Runtime bardzo rzadko — tylko do konkretnych zadań, gdzie nie ma alternatywy. Na przykład Method Swizzling do scentralizowanego logowania analityki lub naprawiania błędów w bibliotekach. Jednak Runtime to potężne narzędzie, które wymaga głębokiego zrozumienia i ostrożności.

Method Swizzling

Method Swizzling to technika zastępowania implementacji metody Objective-C inną w czasie wykonywania. Jest to szczególny przypadek programowania aspektowego (AOP) dla iOS. Swizzling pozwala dodać logowanie, analitykę lub buforowanie do istniejących metod bez zmiany ich kodu źródłowego.

Typowy przykład: zastąpienie viewWillAppear: w UIViewController w celu dodania automatycznego logowania ekranów. Ważne: swizzling należy wykonać w metodzie +load lub +initialize, aby zagwarantować wykonanie przed użyciem klasy. Nieprawidłowy swizzling może prowadzić do niezdefiniowanego zachowania i błędów trudnych do debugowania.

// Method Swizzling do logowania 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]; // wywołanie oryginalnej metody
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Ten kod zastępuje viewWillAppear: we wszystkich UIViewController poprzez swizzling. Po method_exchangeImplementations wywołanie oryginalnego viewWillAppear: prowadzi do wywołania xxx_viewWillAppear:, które wywołuje oryginalną metodę (poprzez wywołanie rekurencyjne) i dodaje analitykę. DispatchOnce gwarantuje jednokrotne wykonanie swizzlingu.

Narzędzia sieciowe (Transpilation, Polyfill, Bundler, Webpack, Metro)

Nowoczesne tworzenie stron internetowych i tworzenie aplikacji mobilnych z React Native lub Flutter są niemożliwe bez narzędzi do budowania. Transpilation to konwersja kodu z jednego języka na inny. Najpopularniejszy przykład: TypeScript → JavaScript. Transpilator (Babel, tsc) konwertuje nowoczesny kod na wstecznie kompatybilną wersję.

Polyfill to kod, który dodaje brakującą funkcjonalność starym przeglądarkom. Na przykład Promise.allSettled() nie działa w Internet Explorerze, ale polyfill dodaje tę możliwość. W przeciwieństwie do natywnego Runtime, który zarządza wykonywaniem kodu bezpośrednio na urządzeniu, polyfill i transpilatory działają na poziomie abstrakcji języka — dostosowują składnię i API, ale nie ingerują w środowisko wykonawcze.

Webpack to najpopularniejszy bundler (używany w 72% projektów według State of JS 2024). Metro to bundler Facebooka, używany domyślnie w React Native. Reflection w JavaScript istnieje poprzez Object.getPrototypeOf, Proxy i Reflect API — te mechanizmy pozwalają badać i modyfikować obiekty w czasie wykonywania, co zasadniczo różni się od statycznej analizy modułów w bundlerach. Webpack używa pliku konfiguracyjnego, który opisuje punkt wejścia, wyjście, loadery (do przetwarzania różnych typów plików) i wtyczki (do dodatkowej funkcjonalności).

// webpack.config.js — minimalna konfiguracja
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',
};

Ta konfiguracja określa punkt wejścia (index.js), plik wyjściowy (bundle.js) i regułę przetwarzania JavaScript przez Babel. Tryb production włącza optymalizacje: minifikację, tree shaking i automatyczne wykrywanie środowiska. Na etapie Runtime wszystkie te optymalizacje nie wpływają już na logikę — przeglądarka wykonuje zminifikowany bundle jako zwykły JavaScript.

Optymalizacja kodu (Minification, Tree Shaking, Obfuscation)

Minification to proces kompresji kodu poprzez usuwanie spacji, komentarzy i zmienianie długich nazw zmiennych na krótkie. Popularne minifikatory: Terser (JS/TS), CSSNano (CSS), html-minifier-terser. Minifikacja zmniejsza rozmiar pliku o 50–70%. W produkcji Runtime wykonuje zminifikowany kod tak samo jak oryginalny — różnica jest tylko w czytelności i rozmiarze pliku, nie w semantyce.

Tree Shaking to usuwanie martwego kodu, który nie jest używany w aplikacji. Działa na podstawie statycznej analizy modułów ES (import/export). Jeśli funkcja jest eksportowana, ale nigdy nie importowana, Tree Shaking usuwa ją z końcowej kompilacji. Tree Shaking analizuje kod statycznie — w przeciwieństwie do Reflection, który działa dynamicznie i może uzyskiwać dostęp do metod i właściwości niewidocznych w czasie kompilacji.

Tree Shaking

Tree Shaking w Webpack jest włączany automatycznie w trybie produkcyjnym. Ważny warunek: kod musi używać modułów ES (import/export), a nie CommonJS (require). Jeśli biblioteka jest napisana w CommonJS, tree shaking nie zadziała. Dla optymalnego tree shaking używaj precyzyjnych importów: import { merge } from 'lodash-es' zamiast import _ from 'lodash'. Zmniejsza to rozmiar bundle z 500 KB do 10 KB dla jednej funkcji.

Hot Reload

Hot Reload to technologia, która pozwala aktualizować kod aplikacji bez pełnego przeładowania. W React Native i Flutter Hot Reload aktualizuje zmieniony plik w locie, zachowując bieżący stan aplikacji. To radykalnie przyspiesza rozwój: zmiany są widoczne w 1–2 sekundy zamiast 10–30 sekund przy pełnej przebudowie. Hot Reload działa wewnątrz Runtime: zmodyfikowany moduł jest wstrzykiwany do działającej aplikacji bez restartowania środowiska wykonawczego.

Hot Restart to szybki restart aplikacji ze zaktualizowanym kodem, ale bez zachowania stanu. Jest używany, gdy Hot Reload nie jest możliwy (na przykład, gdy zmienił się kod natywny lub zmienne globalne). W IT Sectr używamy Hot Reload na wszystkich etapach rozwoju UI — oszczędza to do 50% czasu na poprawki wizualne.

Tabela 3. Porównanie narzędzi do budowania. Webpack to uniwersalny standard. Metro jest wyspecjalizowany dla React Native. Vite i esbuild to nowa generacja skupiona na szybkości. Rollup to najlepszy wybór do publikowania bibliotek.

Gorące przeładowanie (Hot Reload, Hot Restart)

Hot Reload to technologia, która powstała w tworzeniu stron internetowych (React Hot Loader, HMR — Hot Module Replacement) i przeszła do tworzenia aplikacji mobilnych z Flutter i React Native. Istota: gdy plik się zmienia, bundler wysyła zaktualizowany moduł do działającej aplikacji, która zastępuje stary kod bez utraty stanu. W przeciwieństwie do pełnej przebudowy, Hot Reload nie restartuje Runtime — środowisko wykonawcze nadal działa, a zmodyfikowany moduł jest dynamicznie podłączany przez mechanizm taki jak HMR lub aktualizacja referencji podobna do Reflection.

Hot Reload działa, ponieważ framework przechowuje widżety (Flutter) lub komponenty (React) w pamięci i aktualizuje tylko zmienione części. Hot Restart to bardziej prymitywny mechanizm: całkowicie restartuje aplikację, ale jest szybszy niż pełna przebudowa, ponieważ nie rekompiluje kodu natywnego. W IT Sectr używamy Hot Reload podczas tworzenia UI i Hot Restart przy zmianach nawigacji lub zarządzania stanem.