iOS Runtime: mi ez, alkalmazások végrehajtási környezete iPhone-on

Mi az iOS Runtime?

iOS Runtime — az Apple iOS alatt futó eszközökön az alkalmazások végrehajtását biztosító rendszerkomponensek gyűjteménye. Magában foglalja az Objective-C Runtime-ot (libobjc.A.dylib könyvtár), a Swift Runtime-ot (libswiftCore.dylib), a Core Foundation-t, a Cocoa Touch keretrendszereket (UIKit, Foundation), a dinamikus betöltő dyld-t és a memória, szálak és folyamatközi kommunikáció kezelésére szolgáló runtime környezetet.

Architekturálisan az iOS Runtime három szinten működik. Az alsó szinten — a Mach-O bináris formátum és a dyld, amely betölti a végrehajtható fájlt és a könyvtárakat. A középső szinten — az Objective-C Runtime és a Swift Runtime, amelyek a metódusok dispatch-jéért és az objektumok kezeléséért felelősek. A felső szinten — a Cocoa Touch keretrendszerek (UIKit, Foundation, Core Data, Metal), amelyek API-t biztosítanak a fejlesztő számára.

Az iOS Runtime ismerete lehetővé teszi a fejlesztő számára összetett feladatok megoldását: metódus-swizzling (Method Swizzling) A/B teszteléshez és analitikához, osztályok dinamikus betöltése, memória optimalizálása az ARC megértésén keresztül, retain cycle-ek és memóriaszivárgások hibakeresése, az alkalmazás indítási idejének optimalizálása a dyld segítségével. Runtime ismeretek nélkül a profilozás és optimalizálás rendszerszinten lehetetlen.

Az iOS Runtime komponensei

Mach-O formátum

Az iOS alkalmazások Mach-O (Mach Object) formátumba fordulnak. A Mach-O fájl fejlécet (header), betöltési parancsokat (load commands) és szegmenseket (segments) tartalmaz: __TEXT (kód, konstansok), __DATA (globális változók, Objective-C metaadatok), __LINKEDIT (szimbólumok, relokációs táblák). A dyld elemzi a Mach-O-t és betölti a függőségeket az első utasítás végrehajtása előtt.

Objective-C Runtime: message passing és dinamikus dispatch

Objective-C Runtime — az iOS Runtime legerősebb része. Ellentétben a C++-szal, amely korai kötést (early binding) használ, az Objective-C késői kötést (late binding) alkalmaz message passing segítségével. A [receiver message] metódushívás nem közvetlen függvényhívásként fordul, hanem objc_msgSend(receiver, @selector(message))-ként, amely dinamikusan megtalálja a metódus implementációját az objektum osztályában.

Minden Objective-C objektum egy isa mutatót tárol az osztályára. Az osztály metóduslistát (method list), metódus-gyorsítótárat (method cache) és egy mutatót a szuperosztályra tartalmaz. Az objc_msgSend bejárja az öröklődési láncot: ellenőrzi az osztály gyorsítótárát, majd a method list-et, azután a szuperosztályra lép. Ha a metódus nem található, a forward aktiválódik: resolveInstanceMethod, forwardingTargetForSelector és forwardInvocation.

Method Swizzling — technika a metódus implementációjának helyben történő cseréjére az IMP (implementation pointer) runtime-ban történő kicserélésével. A/B teszteléshez, analitikához (képernyők automatikus követése) és monitorozáshoz használják. Éles környezetben nem ajánlott végszükség nélkül, mert ütközhet az operációs rendszer frissítéseivel.

Példa: Method Swizzling Objective-C-ben

// Method Swizzling a viewDidLoad követéséhez
#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 {
    // Esemény követése
    NSLog(@"View Did Load: %@", self.class);
    // Eredeti implementáció meghívása
    [self swizzled_viewDidLoad];
}

@end

Az UIViewController (Tracking) kategória az alkalmazás összes UIViewController-jében lecseréli a viewDidLoad-ot swizzled_viewDidLoad-ra. A dispatch_once garantálja az egyszeri swizzling-et. A class_addMethod megakadályozza a dupla swizzling-et és a szuperosztályokkal való ütközéseket. A vezérlők forráskódjának megváltoztatása nélkül használják a képernyők automatikus követésére az analitikában.

isa mutató és tagged pointers

A modern iOS-ben (arm64) az Apple optimalizálta az isa mutatót: ez nem csupán egy osztálycím, hanem egy bitmező (non-pointer isa), amely memóriakezelési jelzőket és az osztályra vonatkozó információkat tartalmaz. A Tagged pointers — egy másik optimalizáció: a kis méretű NSNumber, NSDate és NSString értékek nem objektumként a heap-en, hanem közvetlenül a mutatóban tárolódnak, kiküszöbölve a malloc és retain/release overhead-jét. A tagged pointer az isa legkevésbé jelentős bitjéről ismerhető fel.

Swift Runtime: statikus dispatch és optimalizálás

Swift Runtime alapvetően különbözik az Objective-C Runtime-tól: a Swift alapértelmezés szerint statikus dispatch-ot (static dispatch) használ vtable-en keresztül az osztálymetódusokhoz és direct call-t a value types és extension methods esetében. Dinamikus dispatch (dynamic dispatch) csak a @objc vagy dynamic jelölésű metódusokra használatos. Ez akár 40%-os teljesítménynövekedést eredményez az Objective-C-hez képest.

Value types (struct, enum) a Swift-ben — a legfontosabb különbség az Objective-C-hez képest. A veremben (stack) vagy egy másik objektumon belül tárolódnak, nem használnak retain/release-t és nem vesznek részt az ARC-ben a referenciaszámláló számára. A Struct-nak nincs isa mutatója és nem küldhető el objc_msgSend-en keresztül. A Protocol witnesses — a vtable megfelelője protokollokhoz, amely lehetővé teszi a dinamikus dispatch-t az existential container számára.

A Swift Runtime tartalmazza továbbá a generics-et reifikációval (reified generics mangled symbols segítségével) és a COW-t (Copy-on-Write) a string, array, dictionary, set optimalizálásához. Gyűjtemény másolásakor a tényleges másolás csak akkor történik meg, ha az egyik másolat módosul. Ez minimalizálja az overhead-et a gyűjtemények függvények közötti átadásakor.

Swift vs Objective-C dispatch

import Foundation

// Swift: statikus dispatch (vtable class számára)
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") }
}

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

// Teljesítménytesztelés
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")
}

A példa három dispatch-típust mutat be a Swift-ben: vtable a class (Dog) számára, objc_msgSend a @objc dynamic (Cat) számára és direct call a struct (Cow) számára. A protocol witnesses az existential container-ben ([SoundMaker]) overhead-et adnak. A gyakorlatban a Swift ahol csak lehetséges, a statikus dispatch-ot választja, C-hez közeli teljesítményt biztosítva.

Swift Runtime és Objective-C híd

Swift Runtime teljes kompatibilitásra lett tervezve az Objective-C Runtime-tal. Minden NSObject-et öröklő Swift osztály automatikusan regisztrálódik az Objective-C Runtime-ban és meghívható objc_msgSend-en keresztül. A @objc attribútum elérhetővé teszi a Swift metódust Objective-C-ből. A String híd: a Swift String automatikusan bridgelődik NSString-re, amikor Objective-C API-nak adják át (toll-free bridging).

ARC: Automatic Reference Counting és memóriakezelés

ARC (Automatic Reference Counting) — memóriakezelő rendszer iOS-ben, amely a fordítási fázisban működik. A fordító (Clang) elemzi az objektumok élettartamát és automatikusan beszúrja a retain/release/autorelease hívásokat. A fejlesztőnek nem kell manuálisan meghívnia azokat — ellentétben az iOS 5 előtti Manual Retain-Release (MRR) rendszerrel. Az ARC az Objective-C objektumok és Swift class szintjén működik, de nem a value types (struct, enum) esetében.

Minden Objective-C objektumnak és Swift class-nak van egy referenciaszámlálója (retain count), amely a non-pointer isa-n belüli extra_rc mezőben tárolódik. Az objektum létrehozásakor retain count = 1. Retain esetén a számláló nő, release esetén csökken. Amikor a számláló 0-t ér el, az objektum dealloc (Objective-C) vagy deinit (Swift) révén felszabadul. Az ARC thread-safe: a retain/release atomi műveleteket használ (OSAtomicIncrement32/OSAtomicDecrement32).

Retain cycles — az ARC fő problémája. Ha az A objektum strong referenciát tárol B-re, B pedig strong referenciát A-ra, egyik objektum sem fog soha felszabadulni, mert referenciaszámlálóik nem nullázódnak. Megoldás — gyenge referenciák (__weak Objective-C-ben, weak Swift-ben) vagy unowned. A gyenge referenciák nem növelik a retain count-ot és automatikusan nullázódnak (nil) az objektum felszabadulásakor.

Retain cycle-ek hibakeresése Instruments segítségével

import Foundation

// Példa retain cycle-re
class Parent {
    var child: Child?
    deinit { print("Parent deallocated") }
}

class Child {
    var parent: Parent?  // strong — retain cycle-t hoz létre!
    deinit { print("Child deallocated") }
}

var parent: Parent? = Parent()
var child: Child? = Child()
parent?.child = child
child?.parent = parent  // ciklus: Parent -> Child -> Parent
parent = nil
child = nil
// A deinit NEM hívódik meg — memóriaszivárgás!

// Javítás: weak
class WeakChild {
    weak var parent: Parent?  // weak — nem növeli a retain count-ot
    deinit { print("WeakChild deallocated") }
}

// Javítás: unowned (garantált élettartamhoz)
class UnownedChild {
    unowned let parent: Parent
    init(parent: Parent) { self.parent = parent }
    deinit { print("UnownedChild deallocated") }
}

// Ellenőrzés Instruments segítségével
func profileMemory() {
    // 1. Indítsa el az Instruments > Leaks eszközt
    // 2. Hajtsa végre a műveletet, amely objektumokat hoz létre
    // 3. Ellenőrizze a Leaks-et szivárgásokra
    // 4. Az Allocations-ben keresse meg a dealloc nélküli objektumokat
    for _ in 0..<1000 {
        let p = Parent()
        let c = WeakChild()
        p.child = c as? Child
        // c.parent = p — NEM adjuk hozzá, weak
    }
}

Példa retain cycle-re Parent és Child között: mindkettő strong referenciát tart a másikra, az ARC nem tudja nullázni a számlálókat. Javítás — weak parent a Child-ben. A weak automatikusan nullázódik a parent felszabadulásakor. unowned — olyan esetekre, amikor a parent élettartama garantáltan hosszabb, mint a child-é (pl. viewController és view). Használja az Instruments > Leaks eszközt a retain cycle-ek korai felismeréséhez.

Autorelease pool

Autorelease pool — késleltetett release mechanizmus a kifejezett tulajdonlás nélkül létrehozott objektumok számára. A @autoreleasepool { } Swift-ben és Objective-C-ben egy pool-t hoz létre, amely a blokk végén kiürül, release-t küldve a pool minden objektumának. Kritikus ciklusokban (több ezer ideiglenes objektum létrehozása) és RunLoop nélküli háttérszálakon. Az UIKit RunLoop automatikusan kiüríti a fő autorelease pool-t minden iterációban.

dyld: dinamikus betöltő és alkalmazásindítás

dyld (dynamic link editor) — rendszerbetöltő, amely felelős a Mach-O végrehajtható fájlok és a kapcsolódó dinamikus könyvtárak (dylib) betöltéséért az iOS alkalmazás indításakor. A dyld a /usr/lib/dyld útvonalon található és a libSystem része. A betöltési folyamat több szakaszból áll: a Mach-O elemzése, függőségek betöltése (Library Loader, LC_LOAD_DYLIB), címek relokációja (ASLR), az Objective-C Runtime inicializálása és a main() meghívása.

Az alkalmazás indítási ideje (launch time) kritikusan függ a dyld-től: minél több dinamikus könyvtár és Objective-C osztály van, annál hosszabb a pre-main time. Az Apple javasolja a +load metódusok számának minimalizálását (ezek a main előtt futnak), helyettesítve őket +initialize-szal (lusta inicializálás). 2020 óta az Apple prebuilt dyld cache-t használ iOS-en: a rendszerkönyvtárak előre össze vannak kapcsolva egyetlen gyorsítótárban, ami felgyorsítja a betöltést.

Pre-main time mérése

import Foundation

// Az indítási idő mérése DYLD_PRINT_STATISTICS segítségével
// Xcode-ban: Edit Scheme > Run > Arguments > Environment Variables
// DYLD_PRINT_STATISTICS = 1
// DYLD_PRINT_STATISTICS_DETAILS = 1

// Pre-main time programozott mérése
@main
struct AppMain {
    static func main() {
        let launchStart = CFAbsoluteTimeGetCurrent()

        // A UIApplicationMain itt történik
        AppDelegate.main()

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

// Optimalizálás: +load cseréje +initialize-ra
class OptimizedClass {
    // ❌ A +load a main előtt fut
    // override class func load() { }

    // ✅ A +initialize az első használatkor fut
    static let shared = OptimizedClass()
    private init() {
        // Inicializálás itt
    }
}

// A dylib-ek számának optimalizálása
// A statikus könyvtárak összevonása csökkenti az LC_LOAD_DYLIB számát
// Használja a -ObjC kapcsolót csak a használt Objective-C osztályok linkeléséhez
// Xcode: Build Settings > Mach-O Type > Static Library

A pre-main time méréséhez használja a DYLD_PRINT_STATISTICS-ot az Xcode sémában. A kimenet megjeleníti a total time, dylib loading time, rebase/bind time, Objective-C setup time és initializer time értékeket. Célértékek: total < 400ms hideg indításhoz, < 200ms meleg indításhoz. Optimalizálások: könyvtárak összevonása, +load cseréje +initialize-ra, az Objective-C osztályok számának csökkentése (használjon Swift-et), minimális számú dinamikus keretrendszer.

dsc (dyld shared cache)

dyld shared cache — az előre összekapcsolt rendszerkönyvtárak gyorsítótára iOS-en. Az összes rendszer-dylib (UIKit, Foundation, CoreGraphics) egy fájlba van egyesítve: /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64. Ez kiküszöböli az egyes rendszerkönyvtárak külön-külön történő betöltésének szükségességét — a dyld a gyorsítótárhoz fér hozzá, ami jelentősen felgyorsítja az indítást. A 10+ dinamikus keretrendszerrel rendelkező alkalmazások tapasztalják a legnagyobb késleltetést, mert az egyedi dylib-ek nem részei a dsc-nek.