iOS Runtime: co to jest, środowisko wykonawcze aplikacji na iPhone

Co to jest iOS Runtime?

iOS Runtime — to zbiór komponentów systemowych zapewniających wykonanie aplikacji na urządzeniach Apple pod kontrolą iOS. Obejmuje Objective-C Runtime (biblioteka libobjc.A.dylib), Swift Runtime (libswiftCore.dylib), Core Foundation, frameworki Cocoa Touch (UIKit, Foundation), dynamiczny ładowacz dyld i środowisko uruchomieniowe do zarządzania pamięcią, wątkami i komunikacją międzyprocesową.

Architektonicznie iOS Runtime działa na trzech poziomach. Na dolnym poziomie — binarny format Mach-O i dyld, ładujący plik wykonywalny i biblioteki. Średni poziom — Objective-C Runtime i Swift Runtime, odpowiadające za dyspozycję metod i zarządzanie obiektami. Górny poziom — frameworki Cocoa Touch (UIKit, Foundation, Core Data, Metal), udostępniające API dla programisty.

Zrozumienie iOS Runtime pozwala programiście rozwiązywać złożone zadania: swizzling metod (Method Swizzling) do testów A/B i analityki, dynamiczne ładowanie klas, optymalizację pamięci poprzez zrozumienie ARC, debugowanie retain cycles i wycieków pamięci, optymalizację czasu uruchamiania aplikacji przez dyld. Bez znajomości runtime niemożliwe jest profilowanie i optymalizacja na poziomie systemu.

Komponenty iOS Runtime

Format Mach-O

Aplikacje dla iOS są kompilowane do formatu Mach-O (Mach Object). Plik Mach-O zawiera nagłówek (header), polecenia ładowania (load commands) i segmenty (segments): __TEXT (kod, stałe), __DATA (zmienne globalne, metadane Objective-C), __LINKEDIT (symbole, tabele relokacji). dyld analizuje Mach-O i ładuje zależności przed wykonaniem pierwszej instrukcji.

Objective-C Runtime: message passing i dynamiczna dyspozycja

Objective-C Runtime — najpotężniejsza część iOS Runtime. W przeciwieństwie do C++ z wczesnym wiązaniem (early binding), Objective-C używa późnego wiązania (late binding) poprzez message passing. Wywołanie metody [receiver message] jest kompilowane nie jako bezpośrednie wywołanie funkcji, ale jako objc_msgSend(receiver, @selector(message)), który dynamicznie znajduje implementację metody w klasie obiektu.

Każdy obiekt Objective-C przechowuje wskaźnik isa na swoją klasę. Klasa zawiera listę metod (method list), pamięć podręczną metod (method cache) i wskaźnik na superklasę. objc_msgSend przeszukuje łańcuch dziedziczenia: sprawdza cache klasy, następnie method list, potem przechodzi do superklasy. Jeśli metoda nie zostanie znaleziona, uruchamiany jest forward: resolveInstanceMethod, forwardingTargetForSelector i forwardInvocation.

Method Swizzling — technika zamiany implementacji metody w locie poprzez wymianę IMP (implementation pointer) w runtime. Używana do testów A/B, analityki (automatyczne śledzenie ekranów) i monitorowania. Niezalecana w produkcji bez ostatecznej konieczności, ponieważ może kolidować z aktualizacjami systemu operacyjnego.

Przykład: Method Swizzling w Objective-C

// Metoda Swizzling do śledzenia 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 {
    // Śledzenie zdarzenia
    NSLog(@"View Did Load: %@", self.class);
    // Wywołanie oryginalnej implementacji
    [self swizzled_viewDidLoad];
}

@end

Kategoria UIViewController (Tracking) zastępuje viewDidLoad na swizzled_viewDidLoad we wszystkich UIViewController w aplikacji. dispatch_once gwarantuje jednokrotne swizzling. class_addMethod zapobiega podwójnemu swizzling i konfliktom z superklasami. Używane do automatycznego śledzenia wyświetlania ekranów w analityce bez zmiany kodu źródłowego kontrolerów.

isa pointer i tagged pointers

We współczesnych iOS (arm64) firma Apple zoptymalizowała wskaźnik isa: nie jest to już prosty adres klasy, ale pole bitowe (non-pointer isa), zawierające flagi zarządzania pamięcią i informację o klasie. Tagged pointers — kolejna optymalizacja: wartości NSNumber, NSDate i NSString małego rozmiaru są przechowywane nie jako obiekty na stercie, ale bezpośrednio we wskaźniku, eliminując narzuty malloc i retain/release. tagged pointer jest rozpoznawany po najmłodszym bicie isa.

Swift Runtime: statyczna dyspozycja i optymalizacja

Swift Runtime różni się od Objective-C Runtime zasadniczo: Swift domyślnie używa statycznej dyspozycji (static dispatch) poprzez vtable dla metod klasy i direct call dla value types i extension methods. Dynamiczna dyspozycja (dynamic dispatch) jest używana tylko dla metod oznaczonych @objc lub dynamic. Daje to wzrost wydajności do 40% w porównaniu z Objective-C.

Value types (struct, enum) w Swift — kluczowa różnica w porównaniu z Objective-C. Są przechowywane na stosie (stack) lub wewnątrz innego obiektu, nie używają retain/release i nie uczestniczą w ARC dla licznika odwołań. Struct nie ma wskaźnika isa i nie może być wysłana przez objc_msgSend. Protocol witnesses — odpowiednik vtable dla protokołów, umożliwiający dynamiczną dyspozycję dla existential container.

Swift Runtime obejmuje również generics z reifikacją (reified generics poprzez mangled symbols) i COW (Copy-on-Write) do optymalizacji string, array, dictionary, set. Przy kopiowaniu kolekcji rzeczywiste kopiowanie następuje tylko przy modyfikacji jednej z kopii. Minimalizuje to narzuty przy przekazywaniu kolekcji między funkcjami.

Swift vs Objective-C dyspozycja

import Foundation

// Swift: statyczna dyspozycja (vtable dla 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") }
}

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

// Testowanie wydajności
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")
}

Przykład demonstruje trzy typy dyspozycji w Swift: vtable dla class (Dog), objc_msgSend dla @objc dynamic (Cat) i direct call dla struct (Cow). Protocol witnesses w existential container ([SoundMaker]) dodają narzut. W praktyce Swift wybiera statyczną dyspozycję wszędzie, gdzie to możliwe, zapewniając wydajność bliską C.

Swift Runtime i most Objective-C

Swift Runtime jest zaprojektowany dla pełnej zgodności z Objective-C Runtime. Każda klasa Swift dziedzicząca po NSObject automatycznie rejestruje się w Objective-C Runtime i może być wywołana przez objc_msgSend. Atrybut @objc udostępnia metodę Swift z poziomu Objective-C. String bridge: Swift String jest automatycznie mostkowany do NSString przy przekazywaniu do API Objective-C (toll-free bridging).

ARC: Automatic Reference Counting i zarządzanie pamięcią

ARC (Automatic Reference Counting) — system zarządzania pamięcią w iOS, działający na etapie kompilacji. Kompilator (Clang) analizuje czas życia obiektów i automatycznie wstawia wywołania retain/release/autorelease. Programista nie musi wywoływać ich ręcznie — w przeciwieństwie do Manual Retain-Release (MRR) sprzed iOS 5. ARC działa na poziomie obiektów Objective-C i Swift class, ale nie dla value types (struct, enum).

Każdy obiekt Objective-C i Swift class ma licznik odwołań (retain count), przechowywany w polu extra_rc wewnątrz non-pointer isa. Przy tworzeniu obiektu retain count = 1. Przy retain licznik rośnie, przy release — maleje. Gdy licznik osiąga 0, obiekt jest dealokowany przez dealloc (Objective-C) lub deinit (Swift). ARC jest bezpieczny wątkowo: retain/release używają operacji atomowych (OSAtomicIncrement32/OSAtomicDecrement32).

Retain cycles — główny problem ARC. Jeśli obiekt A przechowuje strong referencję do B, a B — strong referencję do A, oba obiekty nigdy nie zostaną dealokowane, ponieważ ich liczniki odwołań nie wyzerują się. Rozwiązanie — słabe referencje (__weak w Objective-C, weak w Swift) lub unowned. Słabe referencje nie zwiększają retain count i automatycznie się zerują (nil) przy dealokacji obiektu.

Debugowanie retain cycles przez Instruments

import Foundation

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

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

var parent: Parent? = Parent()
var child: Child? = Child()
parent?.child = child
child?.parent = parent  // cykl: Parent -> Child -> Parent
parent = nil
child = nil
// deinit NIE jest wywoływany — wyciek pamięci!

// Naprawa: weak
class WeakChild {
    weak var parent: Parent?  // weak — nie zwiększa retain count
    deinit { print("WeakChild deallocated") }
}

// Naprawa: unowned (dla gwarantowanego czasu życia)
class UnownedChild {
    unowned let parent: Parent
    init(parent: Parent) { self.parent = parent }
    deinit { print("UnownedChild deallocated") }
}

// Sprawdzenie przez Instruments
func profileMemory() {
    // 1. Uruchom Instruments > Leaks
    // 2. Wykonaj działanie tworzące obiekty
    // 3. Sprawdź Leaks pod kątem wycieków
    // 4. W Allocations znajdź obiekty bez dealloc
    for _ in 0..<1000 {
        let p = Parent()
        let c = WeakChild()
        p.child = c as? Child
        // c.parent = p — NIE dodajemy, weak
    }
}

Przykład retain cycle między Parent i Child: oba przechowują strong referencje wzajemnie, ARC nie może wyzerować liczników. Naprawa — weak parent w Child. weak automatycznie się zeruje przy dealokacji parent. unowned — dla przypadków, gdy czas życia parent jest gwarantowanie dłuższy niż child (np. viewController i view). Używaj Instruments > Leaks do wykrywania retain cycles na wczesnym etapie.

Autorelease pool

Autorelease pool — mechanizm opóźnionego release dla obiektów utworzonych bez jawnej własności. @autoreleasepool { } w Swift i Objective-C tworzy pulę, która jest drenowana na końcu bloku, wysyłając release do każdego obiektu w puli. Krytyczne znaczenie w pętlach (tworzenie tysięcy tymczasowych obiektów) i na wątkach tła bez RunLoop. UIKit RunLoop automatycznie drenuje główną pulę autorelease na każdej iteracji.

dyld: dynamiczny ładowacz i uruchamianie aplikacji

dyld (dynamic link editor) — systemowy ładowacz odpowiedzialny za ładowanie plików wykonywalnych Mach-O i związanych bibliotek dynamicznych (dylib) przy uruchamianiu aplikacji iOS. dyld znajduje się pod ścieżką /usr/lib/dyld i jest częścią libSystem. Proces ładowania obejmuje kilka etapów: parsowanie Mach-O, ładowanie zależności (Library Loader, LC_LOAD_DYLIB), relokację adresów (ASLR), inicjalizację Objective-C Runtime i wywołanie main().

Czas uruchamiania aplikacji (launch time) krytycznie zależy od dyld: im więcej bibliotek dynamicznych i klas Objective-C, tym dłuższy pre-main time. Apple zaleca minimalizowanie liczby metod +load (wykonują się przed main), zastępując je +initialize (leniwa inicjalizacja). Od 2020 roku Apple używa prebuilt dyld cache na iOS: biblioteki systemowe są wstępnie połączone w jedną pamięć podręczną, co przyspiesza ładowanie.

Pomiar pre-main time

import Foundation

// Pomiar czasu uruchamiania przez DYLD_PRINT_STATISTICS
// W Xcode: Edit Scheme > Run > Arguments > Environment Variables
// DYLD_PRINT_STATISTICS = 1
// DYLD_PRINT_STATISTICS_DETAILS = 1

// Programowy pomiar pre-main time
@main
struct AppMain {
    static func main() {
        let launchStart = CFAbsoluteTimeGetCurrent()

        // UIApplicationMain następuje tutaj
        AppDelegate.main()

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

// Optymalizacja: zamiana +load na +initialize
class OptimizedClass {
    // ❌ +load wykonuje się przed main
    // override class func load() { }

    // ✅ +initialize wykonuje się przy pierwszym użyciu
    static let shared = OptimizedClass()
    private init() {
        // Inicjalizacja tutaj
    }
}

// Optymalizacja liczby dylib
// Łączenie bibliotek statycznych zmniejsza liczbę LC_LOAD_DYLIB
// Użyj flagi -ObjC do linkowania tylko używanych klas Objective-C
// Xcode: Build Settings > Mach-O Type > Static Library

Do pomiaru pre-main time użyj DYLD_PRINT_STATISTICS w schemacie Xcode. Wynik pokaże total time, dylib loading time, rebase/bind time, Objective-C setup time i initializer time. Wartości docelowe: total < 400ms dla zimnego startu, < 200ms dla ciepłego. Optymalizacje: łączenie bibliotek, zamiana +load na +initialize, zmniejszanie liczby klas Objective-C (używaj Swift), minimalna liczba dynamicznych frameworków.

dsc (dyld shared cache)

dyld shared cache — pamięć podręczna wstępnie połączonych bibliotek systemowych na iOS. Wszystkie systemowe dylib (UIKit, Foundation, CoreGraphics) są połączone w jeden plik: /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64. Eliminuje to konieczność ładowania każdej biblioteki systemowej osobno — dyld odwołuje się do pamięci podręcznej, co znacznie przyspiesza uruchamianie. Aplikacje z 10+ dynamicznymi frameworkami doświadczają największego opóźnienia, ponieważ niestandardowe dylib nie są częścią dsc.