Runtime in der mobilen Entwicklung: Was es ist, Runtime-System und wie es funktioniert

Was ist Runtime in der mobilen Entwicklung?

Runtime ist die Infrastruktur, die die Programmausführung nach dem Start sicherstellt. Im Kontext der mobilen Entwicklung umfasst Runtime den Klassenlader, Speicherallokator, Garbage Collector, Methodendispatcher und Ausnahmebehandler. Ohne diese Zwischenschicht kann das Betriebssystem keinen Dalvik-Bytecode oder Objective-C-Nachrichten ausführen.

Mobile Plattformen verwenden unterschiedliche Runtime-Implementierungen. Android verwendet ART (Android Runtime) mit hybrider AOT/JIT-Kompilierung. iOS verwendet Objective-C Runtime — ein dynamisches System basierend auf Message Passing und SEL-Identifikatoren. Beide Ansätze lösen dasselbe Problem: den Code des Entwicklers auf einem bestimmten Gerät mit maximaler Leistung auszuführen.

Laut Google I/O 2024 verarbeitet Android Runtime täglich über 10 Milliarden Methoden auf Geräten weltweit. Die Runtime-Leistung beeinflusst direkt die Startgeschwindigkeit der Anwendung, die Flüssigkeit von Animationen und den Batterieverbrauch. Jeder Methodenaufruf, jede Speicherzuweisung und jeder Garbage-Collection-Zyklus durchläuft die Runtime-Schicht.

Runtime-System: Aus welchen Komponenten besteht es

Runtime-System umfasst fünf Schlüsselkomponenten: Klassenlader, Speicherverwalter, Interpreter oder Compiler, Methodendispatcher und Sicherheitssystem. Jede Komponente erfüllt eine streng definierte Funktion im Codeausführungsprozess.

Klassenlader und Verifizierung

Wenn ein Benutzer eine Anwendung startet, lädt der ClassLoader DEX-Dateien (Android) oder Mach-O-Binärdateien (iOS) in den RAM. In Android umfasst diese Phase die Bytecode-Verifizierung: Die Runtime prüft, ob der Code keine unsicheren Anweisungen enthält, nicht über Array-Grenzen hinausgeht und Typen einhält. Die Verifizierung ist ein kritischer Sicherheitsschritt, der die Ausführung von schädlichem Code verhindert.

Speicherverwalter und Garbage Collector

Speicherverwalter weist Speicher für Objekte zu und gibt ihn frei. In Android ART wird ein nebenläufiger Garbage Collector mit generationaler Sammlung verwendet: Junge Objekte werden häufiger überprüft, alte seltener. Objective-C Runtime verwendet Automatic Reference Counting (ARC), bei dem der Compiler automatisch retain/release-Aufrufe einfügt.

Methodendispatcher und virtuelle Tabelle

Methodendispatcher bestimmt, welche Methodenimplementierung aufgerufen wird. In statischen Sprachen (Kotlin, Swift) erfolgt der Dispatch über vtable — eine Tabelle virtueller Methoden. In dynamischen Sprachen (Objective-C) durchläuft die Nachricht objc_msgSend, das die Implementierung in der Klasse und ihren Oberklassen sucht. Das Ergebnis wird im Method Cache zwischengespeichert, um wiederholte Aufrufe zu beschleunigen.

Wie ART auf Android funktioniert

Android Runtime (ART) ist eine virtuelle Maschine, die DEX-Bytecode von Android-Anwendungen ausführt. ART ersetzte Dalvik in Android 5.0 Lollipop und führte AOT-Kompilierung ein: Die Anwendung wird während der Installation einmal in Maschinencode kompiliert. Dies beseitigte den Overhead der JIT-Kompilierung bei jedem Start.

Ab Android 7.0 Nougat verwendet ART einen hybriden Ansatz. Während der Installation wird die JIT-Kompilierung nur für häufig verwendete Methoden (Hot Methods) durchgeführt, der restliche Code wird interpretiert. Ein Hintergrundprozess (Profile-Guided Optimization) analysiert, welche Methoden am häufigsten aufgerufen werden, und kompiliert sie AOT während der Leerlaufzeit des Geräts. Dies reduziert die Installationszeit bei gleichzeitiger Gewährleistung hoher Leistung.

ART enthält auch einen AOT-Compiler (dex2oat), der DEX-Dateien in ELF-Binärdateien mit ARM64-Maschinencode umwandelt. Die Kompilierung erfolgt mit drei Optimierungsstufen: quicken (schnell), optimize (mittel) und everything (vollständig). Standardmäßig verwendet Android optimize, das zwischen Kompilierungsgeschwindigkeit und Codeleistung abwägt.

class RuntimeExample {
    fun measureExecutionTime() {
        val start = System.nanoTime()
        // Methodenaufruf, der von ART kompiliert wird
        processData()
        val end = System.nanoTime()
        println("Ausführungszeit: ${end - start} ns")
    }
}

Im obigen Beispiel ist System.nanoTime() eine native Methode, deren Aufruf über die ART-Runtime an den Linux-Kernel weitergeleitet wird. ART wandelt Kotlin-Bytecode in ARM64-Anweisungen um, die vom Prozessor des Geräts ausgeführt werden. Dieser Prozess erfolgt für den Entwickler transparent, aber seine Optimierung ist eine Schlüsselaufgabe des Android Platform-Teams.

Profile-Guided Optimization (PGO)

Profile-Guided Optimization ist ein ART-Mechanismus, der Methodennutzungsprofile sammelt. Die Datei profiles/.primary.prof enthält eine Liste von Hot Methods, die AOT kompiliert werden. Laut Android Performance Team beschleunigt PGO den Anwendungsstart nach mehrtägiger Nutzung um 15–30%, sobald das Profil aufgebaut ist.

Der Entwickler kann Baseline Profiles in seinem Gradle-Projekt aktivieren. Dies sind manuelle Annotationen, die ART mitteilen, welche Methoden sofort nach der Installation AOT kompiliert werden sollen. Baseline Profiles reduzieren den ersten Start um 40%, ohne auf die Hintergrundprofilierung warten zu müssen.

Wie Objective-C Runtime auf iOS funktioniert

Objective-C Runtime ist eine dynamische Bibliothek, die die Ausführung von Objective-C-Code auf iOS und macOS ermöglicht. Ihr Kern ist die Funktion objc_msgSend, die Message Passing implementiert: Anstelle eines direkten Methodenaufrufs sendet das Objekt eine Nachricht mit einem Selektor, und die Runtime bestimmt, welche Implementierung ausgeführt werden soll.

Jedes Objective-C-Objekt enthält einen isa-Zeiger auf seine Klasse, und die Klasse besitzt eine Dispatch Table, die Selektoren (SEL) Implementierungen (IMP) zuordnet. Wenn eine Methode aufgerufen wird, durchläuft objc_msgSend die Kette: Klasse → Oberklasse → NSObject, bis es die IMP findet. Wird keine Implementierung gefunden, ruft die Runtime den Forwarding Mechanism auf, der die Nachricht abfangen oder eine Ausnahme auslösen kann.

Objective-C Runtime unterstützt auch Method Swizzling — das Ersetzen der IMP eines vorhandenen Selektors zur Laufzeit. Dies ist ein leistungsstarker Mechanismus, der in AOP-Bibliotheken und Überwachungstools verwendet wird, aber aufgrund seiner Auswirkungen auf die gesamte Anwendung Vorsicht erfordert.

@interface RuntimeDemo : NSObject
- (void)printClassInfo;
@end

@implementation RuntimeDemo
- (void)printClassInfo {
    // objc_getClass — Runtime-Funktion
    Class cls = objc_getClass("RuntimeDemo");
    unsigned int count;
    Method *methods = class_copyMethodList(cls, &count);
    NSLog("Anzahl der Methoden: %d", count);
}
@end

Der Code demonstriert direkten Zugriff auf die Objective-C Runtime API: objc_getClass erhält das Klassenobjekt anhand des Namens, class_copyMethodList ruft die Liste aller Methoden ab. Dies ist Reflektion in Aktion — Zugriff auf Klassenmetadaten zur Laufzeit. Dieser Ansatz wird in XCTest für die dynamische Testregistrierung verwendet.

isa-Zeiger und Tagged Pointers

isa-Zeiger ist ein Zeiger auf die Klasse des Objekts, der in den ersten 8 Bytes jedes Objekts gespeichert ist. Ab iOS 12 führte Apple isa-Swizzling zur Optimierung ein: Die niedrigen Bits von isa kodieren zusätzliche Informationen über den Zustand des Objekts. Tagged Pointers sind eine weitere Optimierung, bei der Werte bis zu 60 Bit (NSNumber, NSDate) direkt im Zeiger gespeichert werden, ohne ein Objekt auf dem Heap zu allozieren. Dies reduziert die Speicherverwalterlast um 30%.

JIT vs AOT-Kompilierung: Vergleich der Ansätze

JIT (Just-In-Time) und AOT (Ahead-Of-Time) sind zwei Ansätze zur Kompilierung von Bytecode in Maschinencode. JIT kompiliert Code während der Anwendungsausführung, analysiert heiße Stellen und optimiert sie spontan. AOT kompiliert den gesamten Code im Voraus — während der Installation der Anwendung oder auf Entwicklerseite.

Der hybride ART-Ansatz (Android 7+) gilt als optimal: Die Anwendung verwendet einen Interpreter für selten aufgerufene Methoden, JIT für Hot Methods und AOT für Methoden aus der Profile-Guided Optimization. iOS verwendet dagegen striktes AOT über LLVM: Swift und Objective-C werden während der Build-Phase in Xcode in Maschinencode kompiliert.

Laut Apple Developer Documentation, 2024 fügt die Swift-Runtime etwa 15 MB zur Anwendungsgröße hinzu. Flutter verwendet seine eigene Dart VM, bei der die JIT-Kompilierung im Debug-Modus für Hot Reload und AOT im Release-Modus für maximale Leistung arbeitet. React Native verwendet Hermes — eine JavaScript-Engine mit AOT-Kompilierung, die die Startzeit um 50% reduziert.

ARM64 Runtime und Maschinencode

ARM64 Runtime ist die Ebene, auf der Maschinencode mit dem Prozessor des Geräts interagiert. Die meisten modernen Mobilgeräte arbeiten auf ARM64 (aarch64)-Prozessoren. Die Runtime übersetzt Bytecode oder native Aufrufe in ARM64-Anweisungen, die die CPU ausführt.

Wichtige ARM64-Register, die von der Runtime verwendet werden: x0–x7 (Funktionsparameter), x8 (indirektes Ergebnis), x30 (Rücksprungadresse), sp (Stack Pointer), fp (Frame Pointer). ART erzeugt Code, der dem ARM64 Procedure Call Standard folgt: Alle Methodenaufrufe durchlaufen das von der Prozessorarchitektur definierte Protokoll.

Das Verständnis der ARM64 ABI ist für die Leistungsoptimierung wichtig: Inline-Caching, Branch Prediction und Code-Ausrichtung im Speicher beeinflussen direkt die Geschwindigkeit der Runtime. Profiling-Tools (Android Studio Profiler, Instruments) zeigen, welche Codeabschnitte die meiste Zeit in der Runtime verbringen — deren Optimierung bringt die größte Verbesserung.

// Beispiel einer von ART erzeugten ARM64-Assembly
// Methodenaufruf mit zwei Parametern

mov    x0, x23            // self (this)
mov    x1, x24            // param1
mov    x2, x25            // param2
bl     methodEntryPoint   // Aufruf über Runtime
str    x0, [sp, #8]      // Ergebnis speichern

In diesem Beispiel übergeben ARM64-Anweisungen mov Argumente an die Register x0–x2, bl ruft den Methodeneinstiegspunkt auf, und str speichert den Rückgabewert. Die Runtime erzeugt solche Anweisungen für jeden Methodenaufruf und optimiert die Sequenz durch Devirtualisierung und Inlining.

Auswirkungen der Runtime auf die Leistung

Runtime-Overhead ist der unvermeidliche Preis des dynamischen Dispatches. Jeder Methodenaufruf über die Runtime erfordert: Suche der Implementierung in der Dispatch Table, Typüberprüfung, Aufruf der IMP und Rückgabe des Ergebnisses. Messungen zeigen, dass die Runtime in Objective-C 10–50 ns pro Aufruf und in ART 5–20 ns hinzufügt.

Zur Reduzierung des Overheads verwenden Entwickler monomorphes Inlining (ART) und Method Caching (Objective-C). Kotlin/Native und Swift kompilieren direkt nach ARM64 und eliminieren die Runtime-Schicht vollständig, verlieren dabei aber dynamische Fähigkeiten — Reflektion, Swizzling, dynamisches Klassenladen.