Runtime, Hot Reload und Build in der mobilen Entwicklung: was sie sind, Schlüsselkonzepte und wie sie funktionieren

Runtime und Reflection: iOS Runtime, Method Swizzling und dynamischer Dispatch

Runtime (Ausführungsumgebung) ist die Software, die die Anwendungsausführung verwaltet. Im Kontext von iOS Runtime ist es das dynamische System von Objective-C, das das Senden von Nachrichten an Objekte, das Erstellen von Klassen im laufenden Betrieb und das Ersetzen von Methoden zur Laufzeit ermöglicht. Dies ist möglich, weil Objective-C eine dynamisch typisierte Sprache auf Basis von C ist.

Reflection ist die Fähigkeit eines Programms, seine eigene Struktur zur Laufzeit zu untersuchen und zu ändern. Im iOS Runtime wird dies durch Funktionen wie class_getInstanceMethod, method_exchangeImplementations und objc_getAssociatedObject implementiert. In Kotlin/Java verwendet Reflection KClass / java.lang.reflect.

Bei IT Sectr verwenden wir Runtime sehr selten — nur für spezifische Aufgaben, bei denen es keine Alternative gibt. Zum Beispiel Method Swizzling für zentralisiertes Analytics-Logging oder das Beheben von Bugs in Bibliotheken. Runtime ist jedoch ein mächtiges Werkzeug, das tiefes Verständnis und Vorsicht erfordert.

Method Swizzling

Method Swizzling ist eine Technik zum Ersetzen einer Objective-C-Methodenimplementierung durch eine andere zur Laufzeit. Dies ist ein Spezialfall der aspektorientierten Programmierung (AOP) für iOS. Swizzling ermöglicht das Hinzufügen von Logging, Analytics oder Caching zu vorhandenen Methoden, ohne deren Quellcode zu ändern.

Ein typisches Beispiel: Ersetzen von viewWillAppear: in UIViewController, um automatisches Screen-Logging hinzuzufügen. Wichtig: Swizzling muss in der Methode +load oder +initialize ausgeführt werden, um die Ausführung vor der Verwendung der Klasse sicherzustellen. Falsches Swizzling kann zu undefiniertem Verhalten und schwer zu debuggenden Fehlern führen.

// Method Swizzling für Logging von 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]; // Aufruf der Originalmethode
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Dieser Code ersetzt viewWillAppear: bei allen UIViewController-Instanzen via Swizzling. Nach method_exchangeImplementations führt der Aufruf des ursprünglichen viewWillAppear: zum Aufruf von xxx_viewWillAppear:, das die Originalmethode aufruft (über rekursiven Aufruf) und Analytics hinzufügt. DispatchOnce garantiert die einmalige Ausführung des Swizzling.

Web-Tools (Transpilation, Polyfill, Bundler, Webpack, Metro)

Moderne Webentwicklung und mobile Entwicklung mit React Native oder Flutter sind ohne Build-Tools unmöglich. Transpilation ist die Konvertierung von Code von einer Sprache in eine andere. Das bekannteste Beispiel: TypeScript → JavaScript. Ein Transpiler (Babel, tsc) konvertiert modernen Code in eine abwärtskompatible Version.

Polyfill ist Code, der fehlende Funktionalität zu älteren Browsern hinzufügt. Zum Beispiel funktioniert Promise.allSettled() im Internet Explorer nicht, aber ein Polyfill fügt diese Fähigkeit hinzu. Im Gegensatz zur nativen Runtime, die die Codeausführung direkt auf dem Gerät verwaltet, arbeiten Polyfills und Transpiler auf der Sprachebene — sie passen Syntax und APIs an, greifen aber nicht in die Ausführungsumgebung ein.

Webpack ist der beliebteste Bundler (laut State of JS 2024 in 72% der Projekte verwendet). Metro ist Facebooks Bundler, standardmäßig in React Native verwendet. Reflection in JavaScript existiert über Object.getPrototypeOf, Proxy und Reflect API — diese Mechanismen ermöglichen die Untersuchung und Änderung von Objekten zur Laufzeit, was sich grundlegend von der statischen Modulanalyse in Bundlern unterscheidet. Webpack verwendet eine Konfigurationsdatei, die Eintrittspunkt, Ausgabe, Loader (zur Verarbeitung verschiedener Dateitypen) und Plugins (für zusätzliche Funktionalität) beschreibt.

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

Diese Konfiguration definiert den Einstiegspunkt (index.js), die Ausgabedatei (bundle.js) und eine Regel zur Verarbeitung von JavaScript über Babel. Der production-Modus aktiviert Optimierungen: Minifikation, Tree Shaking und automatische Umgebungserkennung. In der Runtime-Phase beeinflussen all diese Optimierungen die Logik nicht mehr — der Browser führt das minifizierte Bundle wie normales JavaScript aus.

Code-Optimierung (Minification, Tree Shaking, Obfuscation)

Minification ist der Prozess der Codekomprimierung durch Entfernen von Leerzeichen, Kommentaren und Umbenennen langer Variablen in kurze. Beliebte Minifier: Terser (JS/TS), CSSNano (CSS), html-minifier-terser. Minification reduziert die Dateigröße um 50–70%. In der Produktion führt Runtime den minifizierten Code genauso aus wie den Originalcode — der Unterschied liegt nur in Lesbarkeit und Dateigröße, nicht in der Semantik.

Tree Shaking ist die Entfernung von totem Code, der in der Anwendung nicht verwendet wird. Es basiert auf der statischen Analyse von ES-Modulen (import/export). Wenn eine Funktion exportiert, aber nie importiert wird, entfernt Tree Shaking sie aus dem endgültigen Build. Tree Shaking analysiert Code statisch — im Gegensatz zu Reflection, das dynamisch arbeitet und auf Methoden und Eigenschaften zugreifen kann, die zur Kompilierzeit unsichtbar sind.

Tree Shaking

Tree Shaking in Webpack wird automatisch im Produktionsmodus aktiviert. Eine wichtige Bedingung: Der Code muss ES-Module (import/export) verwenden, nicht CommonJS (require). Wenn eine Bibliothek in CommonJS geschrieben ist, funktioniert Tree Shaking nicht. Für optimales Tree Shaking verwenden Sie präzise Importe: import { merge } from 'lodash-es' statt import _ from 'lodash'. Dies reduziert die Bundle-Größe für eine einzelne Funktion von 500 KB auf 10 KB.

Hot Reload

Hot Reload ist eine Technologie, die das Aktualisieren von Anwendungscode ohne vollständigen Neuladen ermöglicht. In React Native und Flutter aktualisiert Hot Reload die geänderte Datei im laufenden Betrieb unter Beibehaltung des aktuellen Anwendungszustands. Dies beschleunigt die Entwicklung radikal: Änderungen sind in 1–2 Sekunden sichtbar statt 10–30 Sekunden für einen vollständigen Neubau. Hot Reload arbeitet innerhalb der Runtime: Das geänderte Modul wird in die laufende Anwendung injiziert, ohne die Ausführungsumgebung neu zu starten.

Hot Restart ist ein schneller Neustart der Anwendung mit aktualisiertem Code, jedoch ohne Zustandserhaltung. Es wird verwendet, wenn Hot Reload nicht möglich ist (z. B. wenn nativer Code oder globale Variablen geändert wurden). Bei IT Sectr verwenden wir Hot Reload in allen UI-Entwicklungsphasen — es spart bis zu 50% Zeit bei visuellen Anpassungen.

Tabelle 3. Vergleich der Build-Tools. Webpack ist der universelle Standard. Metro ist für React Native spezialisiert. Vite und esbuild sind die neue Generation mit Fokus auf Geschwindigkeit. Rollup ist die beste Wahl für die Veröffentlichung von Bibliotheken.

Hot Reload (Hot Reload, Hot Restart)

Hot Reload ist eine Technologie, die in der Webentwicklung entstanden ist (React Hot Loader, HMR — Hot Module Replacement) und mit Flutter und React Native in die mobile Entwicklung übergegangen ist. Das Wesentliche: Wenn sich eine Datei ändert, sendet der Bundler das aktualisierte Modul an die laufende Anwendung, die den alten Code ohne Zustandsverlust ersetzt. Im Gegensatz zu einem vollständigen Neubau startet Hot Reload die Runtime nicht neu — die Ausführungsumgebung läuft weiter, und das geänderte Modul wird dynamisch über einen Mechanismus wie HMR oder eine Reflection-ähnliche Referenzaktualisierung verbunden.

Hot Reload funktioniert, weil das Framework Widgets (Flutter) oder Komponenten (React) im Speicher behält und nur die geänderten Teile aktualisiert. Hot Restart ist ein gröberer Mechanismus: Er startet die Anwendung vollständig neu, ist aber schneller als ein vollständiger Neubau, da er nativen Code nicht neu kompiliert. Bei IT Sectr verwenden wir Hot Reload bei der UI-Entwicklung und Hot Restart bei Änderungen an Navigation oder Zustandsverwaltung.