Runtime în dezvoltarea mobilă: ce este, sistemul de execuție și cum funcționează

Ce este Runtime în dezvoltarea mobilă?

Runtime (mediu de execuție) este infrastructura care asigură execuția programului după lansarea acestuia. În contextul dezvoltării mobile, runtime include încărcătorul de clase, alocatorul de memorie, garbage collector-ul, distribuitorul de metode și procesorul de excepții. Fără acest strat intermediar, sistemul de operare nu poate executa bytecode-ul Dalvik sau mesajele Objective-C.

Platformele mobile folosesc implementări diferite ale runtime. Android folosește ART (Android Runtime) cu compilare hibridă AOT/JIT. iOS folosește Objective-C Runtime — un sistem dinamic bazat pe message passing și identificatori SEL. Ambele abordări rezolvă aceeași problemă: să execute codul dezvoltatorului pe un dispozitiv concret cu performanță maximă.

Potrivit Google I/O 2024, Android Runtime procesează peste 10 miliarde de metode pe zi pe dispozitivele din întreaga lume. Performanța runtime influențează direct viteza de lansare a aplicației, fluiditatea animațiilor și consumul bateriei. Fiecare apel de metodă, fiecare alocare de memorie și fiecare ciclu de garbage collection trec prin stratul runtime.

Runtime system: din ce componente este format

Runtime system include cinci componente cheie: încărcătorul de clase, managerul de memorie, interpretorul sau compilatorul, distribuitorul de metode și sistemul de securitate. Fiecare componentă îndeplinește o funcție strict definită în procesul de execuție a codului.

Încărcătorul de clase și verificarea

Când utilizatorul lansează aplicația, ClassLoader încarcă fișierele DEX (Android) sau binarele Mach-O (iOS) în memoria RAM. Pe Android, această etapă include verificarea bytecode-ului: runtime verifică dacă codul nu conține instrucțiuni nesigure, nu depășește limitele tablourilor și respectă tipurile. Verificarea este un pas critic de securitate care previne execuția codului malitios.

Managerul de memorie și Garbage Collector

Memory Manager alocă și eliberează memoria pentru obiecte. În Android, ART folosește un garbage collector concurent cu colectare generatională: obiectele tinere sunt verificate mai des, iar cele vechi — mai rar. Objective-C Runtime folosește Automatic Reference Counting (ARC), unde compilatorul inserează automat apelurile retain/release.

Distribuitorul de metode și tabela virtuală

Method dispatcher determină ce implementare de metodă va fi apelată. În limbajele statice (Kotlin, Swift), distribuirea se face prin vtable — tabela metodelor virtuale. În limbajele dinamice (Objective-C), mesajul trece prin objc_msgSend, care caută implementarea în clasă și în superclasele sale. Rezultatul este stocat în method cache pentru a accelera apelurile repetate.

Cum funcționează ART pe Android

Android Runtime (ART) este o mașină virtuală care execută bytecode-ul DEX al aplicațiilor Android. ART a înlocuit Dalvik în Android 5.0 Lollipop, oferind compilare AOT: aplicația este compilată în cod mașină o singură dată, în timpul instalării. Aceasta a eliminat costurile suplimentare ale compilării JIT la fiecare lansare.

Începând cu Android 7.0 Nougat, ART folosește o abordare hibridă. La instalare se realizează compilarea JIT doar pentru metodele utilizate frecvent (hot methods), iar restul codului este interpretat. Un proces de fundal (profile-guided optimization) analizează ce metode sunt apelate cel mai des și le compilează AOT în perioadele de inactivitate ale dispozitivului. Aceasta reduce timpul de instalare și oferă simultan o performanță ridicată.

ART include, de asemenea, AOT compiler (dex2oat), care transformă fișierele DEX în binare ELF cu cod mașină ARM64. Compilarea se realizează cu trei niveluri de optimizare: quicken (rapidă), optimize (medie) și everything (completă). Implicit, Android aplică optimize, care face echilibru între viteza de compilare și performanța codului.

class RuntimeExample {
    fun measureExecutionTime() {
        val start = System.nanoTime()
        // Apelul unei metode compilate de ART
        processData()
        val end = System.nanoTime()
        println("Timp de execuție: ${end - start} ns")
    }
}

În exemplul de mai sus, System.nanoTime() este o metodă nativă al cărei apel este distribuit prin runtime ART către nucleul Linux. ART transformă bytecode-ul Kotlin în instrucțiuni ARM64, care sunt executate de procesorul dispozitivului. Acest proces are loc imperceptibil pentru dezvoltator, dar optimizarea lui este o sarcină cheie a echipei Android Platform.

Profile-Guided Optimization (PGO)

Optimizarea bazată pe profile este un mecanism ART care colectează profile de utilizare a metodelor. Fișierul profiles/.primary.prof conține lista metodelor hot care sunt compilate AOT. Potrivit Android Performance Team, PGO accelerează lansarea aplicației cu 15–30% după câteva zile de utilizare, când profilul este acumulat.

Dezvoltatorul poate activa baseline profiles în proiectul său Gradle. Acestea sunt adnotări manuale care indică ART ce metode să compileze AOT imediat după instalare. Baseline profiles scurtează prima lansare cu 40% fără a aștepta profilarea de fundal.

Cum funcționează Objective-C Runtime pe iOS

Objective-C Runtime este o bibliotecă dinamică care asigură execuția codului Objective-C pe iOS și macOS. Nucleul său este funcția objc_msgSend, care implementează message passing: în loc de un apel direct de metodă, obiectul trimite un mesaj cu un selector, iar runtime determină ce implementare trebuie executată.

Fiecare obiect Objective-C conține un pointer isa către clasă, iar clasa are o dispatch table (tabel de distribuire) care face corespondența între selectori (SEL) și implementări (IMP). Când este apelată o metodă, objc_msgSend parcurge lanțul: clasă → superclasă → NSObject, până când găsește IMP. Dacă implementarea nu este găsită, runtime apelează forwarding mechanism, care poate intercepta mesajul sau poate genera o excepție.

Objective-C Runtime suportă, de asemenea, method swizzling — înlocuirea IMP pentru un selector existent în timpul rulării. Este un mecanism puternic folosit în bibliotecile AOP și instrumentele de monitorizare, dar care necesită prudență din cauza impactului asupra întregii aplicații.

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

@implementation RuntimeDemo
- (void)printClassInfo {
    // objc_getClass — funcție runtime
    Class cls = objc_getClass("RuntimeDemo");
    unsigned int count;
    Method *methods = class_copyMethodList(cls, &count);
    NSLog("Numărul de metode: %d", count);
}
@end

Codul demonstrează accesul direct la Objective-C Runtime API: objc_getClass obține obiectul clasei după nume, iar class_copyMethodList extrage lista tuturor metodelor. Aceasta este reflection în acțiune — acces la metadatele clasei în timpul rulării. O astfel de abordare este folosită în XCTest pentru înregistrarea dinamică a testelor.

Pointerul isa și tagged pointers

isa pointer este un pointer către clasa obiectului, stocat în primii 8 octeți ai fiecărui obiect. Începând cu iOS 12, Apple a introdus isa-swizzling pentru optimizare: biții inferiori ai isa codifică informații suplimentare despre starea obiectului. Tagged pointers sunt o altă optimizare în care valorile de până la 60 de biți (NSNumber, NSDate) sunt stocate direct în pointer, fără alocarea unui obiect în heap. Aceasta reduce sarcina managerului de memorie cu 30%.

Compilarea JIT și AOT: compararea abordărilor

JIT (Just-In-Time) și AOT (Ahead-Of-Time) sunt două abordări de compilare a bytecode-ului în cod mașină. JIT compilează codul în timpul rulării aplicației, analizând secțiunile fierbinți și optimizându-le pe loc. AOT compilează întregul cod în avans — la instalarea aplicației sau în partea dezvoltatorului.

Abordarea hibridă ART (Android 7+) este considerată optimă: aplicația folosește interpretorul pentru metodele apelate rar, JIT pentru metodele hot și AOT pentru metodele din profile-guided optimization. iOS, dimpotrivă, folosește un AOT strict prin LLVM: Swift și Objective-C sunt compilate în cod mașină în etapa de compilare în Xcode.

Potrivit Apple Developer Documentation, 2024, Swift runtime adaugă aproximativ 15 MB la dimensiunea aplicației. Flutter folosește propria Dart VM, unde compilarea JIT funcționează în modul debug pentru hot reload, iar AOT — în modul release pentru performanță maximă. React Native folosește Hermes — un motor JavaScript cu compilare AOT care reduce timpul de lansare cu 50%.

ARM64 Runtime și codul mașină

ARM64 Runtime este nivelul pe care codul mașină interacționează cu procesorul dispozitivului. Majoritatea dispozitivelor mobile moderne funcționează pe procesoare ARM64 (aarch64). Runtime traduce bytecode-ul sau apelurile native în instrucțiuni ARM64, pe care CPU le execută.

Registrele cheie ARM64 folosite de runtime: x0–x7 (parametrii funcțiilor), x8 (rezultat indirect), x30 (adresa de returnare), sp (stack pointer), fp (frame pointer). ART generează cod care respectă ARM64 Procedure Call Standard: toate apelurile de metode trec prin protocolul definit de arhitectura procesorului.

Înțelegerea ARM64 ABI este importantă la optimizarea performanței: inline-caching, predicția salturilor și alinierea codului în memorie influențează direct viteza de lucru a runtime. Instrumentele de profilare (Android Studio Profiler, Instruments) arată ce secțiuni de cod petrec cel mai mult timp în runtime — tocmai optimizarea lor oferă cea mai mare creștere.

// Exemplu de assembly ARM64 generat de ART
// Apelul unei metode cu doi parametri

mov    x0, x23            // self (this)
mov    x1, x24            // param1
mov    x2, x25            // param2
bl     methodEntryPoint   // apel prin runtime
str    x0, [sp, #8]      // salvarea rezultatului

În acest exemplu, instrucțiunile ARM64 mov transferă argumentele în registrele x0–x2, bl apelează punctul de intrare al metodei, iar str salvează valoarea returnată. Runtime generează astfel de instrucțiuni pentru fiecare apel de metodă, optimizând secvența prin devirtualization și inlining.

Influența runtime asupra performanței

Runtime overhead este costul inevitabil al distribuirii dinamice. Fiecare apel de metodă prin runtime necesită: căutarea implementării în dispatch table, verificarea tipurilor, apelarea IMP și returnarea rezultatului. Măsurătorile arată că runtime adaugă 10–50 ns per apel în Objective-C și 5–20 ns în ART.

Pentru a reduce overhead-ul, dezvoltatorii folosesc monomorphic inlining (ART) și method caching (Objective-C). Kotlin/Native și Swift sunt compilate direct în ARM64, eliminând complet stratul runtime, dar pierzând capacitățile dinamice — reflection, swizzling, încărcarea dinamică a claselor.