iOS Runtime: ce este, mediul de execuție al aplicațiilor pe iPhone

Ce este iOS Runtime?

iOS Runtime — este ansamblul componentelor de sistem care asigură execuția aplicațiilor pe dispozitivele Apple sub iOS. Include Objective-C Runtime (biblioteca libobjc.A.dylib), Swift Runtime (libswiftCore.dylib), Core Foundation, frameworkuri Cocoa Touch (UIKit, Foundation), încărcătorul dinamic dyld și mediul de execuție pentru gestionarea memoriei, thread-urilor și comunicării interproces.

Arhitectural, iOS Runtime funcționează pe trei niveluri. La nivelul inferior — formatul binar Mach-O și dyld, care încarcă fișierul executabil și bibliotecile. Nivelul mijlociu — Objective-C Runtime și Swift Runtime, responsabile pentru expedierea metodelor și gestionarea obiectelor. Nivelul superior — frameworkurile Cocoa Touch (UIKit, Foundation, Core Data, Metal), care oferă API pentru dezvoltator.

Înțelegerea iOS Runtime permite dezvoltatorului să rezolve sarcini complexe: swizzling de metode (Method Swizzling) pentru testare A/B și analitică, încărcarea dinamică a claselor, optimizarea memoriei prin înțelegerea ARC, depanarea retain cycle-urilor și a scurgerilor de memorie, optimizarea timpului de pornire a aplicației prin dyld. Fără cunoașterea runtime-ului, profilarea și optimizarea la nivel de sistem sunt imposibile.

Componentele iOS Runtime

Formatul Mach-O

Aplicațiile pentru iOS sunt compilate în format Mach-O (Mach Object). Fișierul Mach-O conține antet (header), comenzi de încărcare (load commands) și segmente (segments): __TEXT (cod, constante), __DATA (variabile globale, metadate Objective-C), __LINKEDIT (simboluri, tabele de relocare). dyld analizează Mach-O și încarcă dependențele înainte de executarea primei instrucțiuni.

Objective-C Runtime: message passing și expediere dinamică

Objective-C Runtime — cea mai puternică parte a iOS Runtime. Spre deosebire de C++ cu legare timpurie (early binding), Objective-C folosește legare târzie (late binding) prin message passing. Apelul de metodă [receiver message] este compilat nu ca un apel direct de funcție, ci ca objc_msgSend(receiver, @selector(message)), care găsește dinamic implementarea metodei în clasa obiectului.

Fiecare obiect Objective-C stochează un pointer isa către clasa sa. Clasa conține lista de metode (method list), cache-ul de metode (method cache) și un pointer către superclasă. objc_msgSend parcurge lanțul de moștenire: verifică cache-ul clasei, apoi method list, apoi trece la superclasă. Dacă metoda nu este găsită, se activează forward: resolveInstanceMethod, forwardingTargetForSelector și forwardInvocation.

Method Swizzling — tehnică de înlocuire a implementării metodei pe loc prin schimbul IMP (implementation pointer) în runtime. Folosită pentru testare A/B, analitică (urmărire automată a ecranelor) și monitorizare. Nerecomandată în producție fără necesitate absolută, deoarece poate intra în conflict cu actualizările sistemului de operare.

Exemplu: Method Swizzling în Objective-C

// Method Swizzling pentru urmărirea viewDidLoad
#import 

@implementation UIViewController (Tracking)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];

        SEL originalSelector = @selector(viewDidLoad);
        SEL swizzledSelector = @selector(swizzled_viewDidLoad);

        Method originalMethod = class_getInstanceMethod(
            class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(
            class, swizzledSelector);

        BOOL didAddMethod = class_addMethod(
            class,
            originalSelector,
            method_getImplementation(swizzledMethod),
            method_getTypeEncoding(swizzledMethod)
        );

        if (didAddMethod) {
            class_replaceMethod(
                class,
                swizzledSelector,
                method_getImplementation(originalMethod),
                method_getTypeEncoding(originalMethod)
            );
        } else {
            method_exchangeImplementations(
                originalMethod, swizzledMethod);
        }
    });
}

- (void)swizzled_viewDidLoad {
    // Urmărirea evenimentului
    NSLog(@"View Did Load: %@", self.class);
    // Apelarea implementării originale
    [self swizzled_viewDidLoad];
}

@end

Categoria UIViewController (Tracking) înlocuiește viewDidLoad cu swizzled_viewDidLoad în toate UIViewController-urile din aplicație. dispatch_once garantează o singură swizzling. class_addMethod previne dubla swizzling și conflictele cu superclasele. Folosită pentru urmărirea automată a afișării ecranelor în analitică fără modificarea codului sursă al controlerelor.

Pointerul isa și tagged pointers

În iOS modern (arm64), Apple a optimizat pointerul isa: acesta nu mai este doar o adresă de clasă, ci un câmp de biți (non-pointer isa) care conține flaguri de gestionare a memoriei și informații despre clasă. Tagged pointers — o altă optimizare: valorile NSNumber, NSDate și NSString de dimensiuni mici sunt stocate nu ca obiecte în heap, ci direct în pointer, eliminând overhead-ul de malloc și retain/release. tagged pointer este recunoscut după bitul cel mai puțin semnificativ al isa.

Swift Runtime: expediere statică și optimizare

Swift Runtime diferă fundamental de Objective-C Runtime: Swift folosește implicit expediere statică (static dispatch) prin vtable pentru metodele clasei și direct call pentru value types și extension methods. Expedierea dinamică (dynamic dispatch) este folosită doar pentru metodele marcate cu @objc sau dynamic. Acest lucru oferă o creștere a performanței de până la 40% față de Objective-C.

Value types (struct, enum) în Swift — diferența cheie față de Objective-C. Sunt stocate pe stivă (stack) sau în interiorul unui alt obiect, nu folosesc retain/release și nu participă la ARC pentru contorul de referințe. Struct nu are pointer isa și nu poate fi trimis prin objc_msgSend. Protocol witnesses — analogul vtable pentru protocoale, permițând expediere dinamică pentru existential container.

Swift Runtime include, de asemenea, generics cu reificare (reified generics prin mangled symbols) și COW (Copy-on-Write) pentru optimizarea string, array, dictionary, set. La copierea unei colecții, copierea reală are loc doar la modificarea uneia dintre copii. Acest lucru minimizează overhead-ul la transmiterea colecțiilor între funcții.

Expediere Swift vs Objective-C

import Foundation

// Swift: expediere statică (vtable pentru class)
class Animal {
    func makeSound() { print("...") }  // vtable
}

class Dog: Animal {
    override func makeSound() { print("Woof") }  // vtable override
}

// @objc dynamic: Objective-C Runtime dispatch
class Cat: Animal {
    @objc dynamic override func makeSound() {
        print("Meow")
    }  // objc_msgSend
}

// Struct — no runtime dispatch
struct Cow {
    func makeSound() { print("Moo") }  // direct call
}

// Protocol with protocol witness
protocol SoundMaker {
    func makeSound()
}

struct Duck: SoundMaker {
    func makeSound() { print("Quack") }
}

// Utilizarea existential container
let soundMakers: [SoundMaker] = [Dog(), Cow(), Duck()]
for maker in soundMakers {
    maker.makeSound()  // protocol witness dispatch
}

// Testare performanță
func testDispatch() {
    let dog = Dog()
    let cat = Cat()
    var cow = Cow()

    let start = CFAbsoluteTimeGetCurrent()
    for _ in 0..<1000000 {
        dog.makeSound()  // vtable: ~3ns
        cat.makeSound()  // objc_msgSend: ~15ns
        cow.makeSound()  // direct: ~1ns
    }
    let elapsed = CFAbsoluteTimeGetCurrent() - start
    print("Elapsed: (elapsed) sec")
}

Exemplul demonstrează trei tipuri de expediere în Swift: vtable pentru class (Dog), objc_msgSend pentru @objc dynamic (Cat) și direct call pentru struct (Cow). Protocol witnesses în existential container ([SoundMaker]) adaugă overhead. În practică, Swift alege expediere statică oriunde este posibil, asigurând performanță apropiată de C.

Swift Runtime și puntea Objective-C

Swift Runtime este proiectat pentru compatibilitate completă cu Objective-C Runtime. Orice clasă Swift care moștenește NSObject se înregistrează automat în Objective-C Runtime și poate fi apelată prin objc_msgSend. Atributul @objc face metoda Swift accesibilă din Objective-C. Puntea String: Swift String este automat legat la NSString la transmiterea către API Objective-C (toll-free bridging).

ARC: Automatic Reference Counting și gestionarea memoriei

ARC (Automatic Reference Counting) — sistem de gestionare a memoriei în iOS, care funcționează în faza de compilare. Compilatorul (Clang) analizează durata de viață a obiectelor și inserează automat apelurile retain/release/autorelease. Dezvoltatorul nu trebuie să le apeleze manual — spre deosebire de Manual Retain-Release (MRR) înainte de iOS 5. ARC funcționează la nivelul obiectelor Objective-C și Swift class, dar nu pentru value types (struct, enum).

Fiecare obiect Objective-C și Swift class are un contor de referințe (retain count), stocat în câmpul extra_rc din interiorul non-pointer isa. La crearea obiectului, retain count = 1. La retain, contorul crește; la release, scade. Când contorul ajunge la 0, obiectul este dealocat prin dealloc (Objective-C) sau deinit (Swift). ARC este thread-safe: retain/release folosesc operații atomice (OSAtomicIncrement32/OSAtomicDecrement32).

Retain cycles — principala problemă a ARC. Dacă obiectul A stochează o referință strong către B, iar B — o referință strong către A, ambele obiecte nu vor fi niciodată dealocate, deoarece contoarele lor de referințe nu se vor zero. Soluția — referințe slabe (__weak în Objective-C, weak în Swift) sau unowned. Referințele slabe nu măresc retain count și se anulează automat (nil) la dealocarea obiectului.

Depanarea retain cycle-urilor prin Instruments

import Foundation

// Exemplu retain cycle
class Parent {
    var child: Child?
    deinit { print("Parent deallocated") }
}

class Child {
    var parent: Parent?  // strong — creează retain cycle!
    deinit { print("Child deallocated") }
}

var parent: Parent? = Parent()
var child: Child? = Child()
parent?.child = child
child?.parent = parent  // ciclu: Parent -> Child -> Parent
parent = nil
child = nil
// deinit NU este apelat — scurgere de memorie!

// Remediere: weak
class WeakChild {
    weak var parent: Parent?  // weak — nu mărește retain count
    deinit { print("WeakChild deallocated") }
}

// Remediere: unowned (pentru durată de viață garantată)
class UnownedChild {
    unowned let parent: Parent
    init(parent: Parent) { self.parent = parent }
    deinit { print("UnownedChild deallocated") }
}

// Verificare prin Instruments
func profileMemory() {
    // 1. Rulați Instruments > Leaks
    // 2. Efectuați acțiunea care creează obiecte
    // 3. Verificați Leaks pentru scurgeri
    // 4. În Allocations găsiți obiecte fără dealloc
    for _ in 0..<1000 {
        let p = Parent()
        let c = WeakChild()
        p.child = c as? Child
        // c.parent = p — NU adăugăm, weak
    }
}

Exemplu de retain cycle între Parent și Child: amândouă au referințe strong reciproc, ARC nu poate zero contoarele. Remediere — weak parent în Child. weak se anulează automat la dealocarea lui parent. unowned — pentru cazurile când durata de viață a lui parent este garantat mai mare decât a lui child (de exemplu, viewController și view). Folosiți Instruments > Leaks pentru detectarea retain cycle-urilor în stadii incipiente.

Autorelease pool

Autorelease pool — mecanism de release amânat pentru obiectele create fără proprietate explicită. @autoreleasepool { } în Swift și Objective-C creează un pool care este drenat la sfârșitul blocului, trimițând release fiecărui obiect din pool. Critic în bucle (crearea a mii de obiecte temporare) și pe thread-uri de fundal fără RunLoop. UIKit RunLoop drenează automat pool-ul principal de autorelease la fiecare iterație.

dyld: încărcătorul dinamic și pornirea aplicației

dyld (dynamic link editor) — încărcătorul de sistem responsabil pentru încărcarea fișierelor executabile Mach-O și a bibliotecilor dinamice asociate (dylib) la pornirea aplicației iOS. dyld se află la calea /usr/lib/dyld și face parte din libSystem. Procesul de încărcare include mai multe etape: parsarea Mach-O, încărcarea dependențelor (Library Loader, LC_LOAD_DYLIB), relocarea adreselor (ASLR), inițializarea Objective-C Runtime și apelarea main().

Timpul de pornire a aplicației (launch time) depinde critic de dyld: cu cât mai multe biblioteci dinamice și clase Objective-C, cu atât pre-main time este mai lung. Apple recomandă minimizarea numărului de metode +load (se execută înainte de main), înlocuindu-le cu +initialize (inițializare leneșă). Din 2020, Apple folosește prebuilt dyld cache pe iOS: bibliotecile de sistem sunt prelegatîntr-un singur cache, accelerând încărcarea.

Măsurarea pre-main time

import Foundation

// Măsurarea timpului de pornire prin DYLD_PRINT_STATISTICS
// În Xcode: Edit Scheme > Run > Arguments > Environment Variables
// DYLD_PRINT_STATISTICS = 1
// DYLD_PRINT_STATISTICS_DETAILS = 1

// Măsurarea programatică a pre-main time
@main
struct AppMain {
    static func main() {
        let launchStart = CFAbsoluteTimeGetCurrent()

        // UIApplicationMain are loc aici
        AppDelegate.main()

        let launchEnd = CFAbsoluteTimeGetCurrent()
        let preMainTime = launchEnd - launchStart
        print("Pre-main time: (preMainTime) sec")
    }
}

// Optimizare: înlocuirea +load cu +initialize
class OptimizedClass {
    // ❌ +load se execută înainte de main
    // override class func load() { }

    // ✅ +initialize se execută la prima utilizare
    static let shared = OptimizedClass()
    private init() {
        // Inițializare aici
    }
}

// Optimizarea numărului de dylib
// Îmbinarea bibliotecilor statice reduce numărul LC_LOAD_DYLIB
// Folosiți flag-ul -ObjC pentru linkarea doar a claselor Objective-C utilizate
// Xcode: Build Settings > Mach-O Type > Static Library

Pentru măsurarea pre-main time folosiți DYLD_PRINT_STATISTICS în schema Xcode. Rezultatul va afișa total time, dylib loading time, rebase/bind time, Objective-C setup time și initializer time. Valori țintă: total < 400ms pentru pornire la rece, < 200ms pentru pornire la cald. Optimizări: îmbinarea bibliotecilor, înlocuirea +load cu +initialize, reducerea numărului de clase Objective-C (folosiți Swift), numărul minim de frameworkuri dinamice.

dsc (dyld shared cache)

dyld shared cache — cache-ul bibliotecilor de sistem prelegat pe iOS. Toate dylib-urile de sistem (UIKit, Foundation, CoreGraphics) sunt îmbinate într-un singur fișier: /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64. Aceasta elimină necesitatea încărcării fiecărei biblioteci de sistem separat — dyld accesează cache-ul, ceea ce accelerează semnificativ pornirea. Aplicațiile cu 10+ frameworkuri dinamice experimentează cea mai mare întârziere, deoarece dylib-urile personalizate nu fac parte din dsc.