iOS Runtime: какво е, среда за изпълнение на приложения на iPhone

Какво е iOS Runtime?

iOS Runtime — колекция от системни компоненти, които осигуряват изпълнението на приложения на Apple устройства под iOS. Включва Objective-C Runtime (библиотека libobjc.A.dylib), Swift Runtime (libswiftCore.dylib), Core Foundation, Cocoa Touch рамки (UIKit, Foundation), динамичния зареждач dyld и среда за изпълнение за управление на паметта, нишки и междупроцесна комуникация.

Архитектурно iOS Runtime работи на три нива. На долното ниво — двоичен формат Mach-O и dyld, който зарежда изпълнимия файл и библиотеките. Средното ниво — Objective-C Runtime и Swift Runtime, отговорни за изпращането на методи и управлението на обекти. Горното ниво — Cocoa Touch рамки (UIKit, Foundation, Core Data, Metal), които предоставят API за разработчика.

Разбирането на iOS Runtime позволява на разработчика да решава сложни задачи: swizzling на методи (Method Swizzling) за A/B тестване и аналитика, динамично зареждане на класове, оптимизиране на паметта чрез разбиране на ARC, отстраняване на retain cycles и изтичания на памет, оптимизиране на времето за стартиране на приложението чрез dyld. Без познаване на runtime профилирането и оптимизирането на системно ниво са невъзможни.

Компоненти на iOS Runtime

Формат Mach-O

Приложенията за iOS се компилират във формат Mach-O (Mach Object). Файлът Mach-O съдържа заглавка (header), команди за зареждане (load commands) и сегменти (segments): __TEXT (код, константи), __DATA (глобални променливи, Objective-C метаданни), __LINKEDIT (символи, таблици за преместване). dyld анализира Mach-O и зарежда зависимостите преди изпълнението на първата инструкция.

Objective-C Runtime: message passing и динамично изпращане

Objective-C Runtime — най-мощната част на iOS Runtime. За разлика от C++ с ранно свързване (early binding), Objective-C използва късно свързване (late binding) чрез message passing. Извикването на метод [receiver message] се компилира не като директно извикване на функция, а като objc_msgSend(receiver, @selector(message)), който динамично намира имплементацията на метода в класа на обекта.

Всеки обект Objective-C съхранява указател isa към своя клас. Класът съдържа списък с методи (method list), кеш на методи (method cache) и указател към суперкласа. objc_msgSend преминава през веригата на наследяване: проверява кеша на класа, след това method list, после преминава към суперкласа. Ако методът не бъде намерен, се активира forward: resolveInstanceMethod, forwardingTargetForSelector и forwardInvocation.

Method Swizzling — техника за замяна на имплементацията на метод в движение чрез обмен на IMP (implementation pointer) в runtime. Използва се за A/B тестване, аналитика (автоматично проследяване на екрани) и мониторинг. Не се препоръчва в продукция без крайна необходимост, тъй като може да влезе в конфликт с актуализации на операционната система.

Пример: Method Swizzling в Objective-C

// Method Swizzling за проследяване на 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 {
    // Проследяване на събитие
    NSLog(@"View Did Load: %@", self.class);
    // Извикване на оригиналната имплементация
    [self swizzled_viewDidLoad];
}

@end

Категорията UIViewController (Tracking) заменя viewDidLoad с swizzled_viewDidLoad във всички UIViewController в приложението. dispatch_once гарантира еднократно swizzling. class_addMethod предотвратява двойно swizzling и конфликти със суперкласове. Използва се за автоматично проследяване на показване на екрани в аналитика без промяна на изходния код на контролерите.

Указател isa и tagged pointers

В модерен iOS (arm64) Apple оптимизира указателя isa: той не е просто адрес на клас, а битово поле (non-pointer isa), съдържащо флагове за управление на паметта и информация за класа. Tagged pointers — друга оптимизация: стойностите NSNumber, NSDate и NSString с малък размер се съхраняват не като обекти в heap-а, а директно в указателя, елиминирайки режийните разходи на malloc и retain/release. tagged pointer се разпознава по най-малко значимия бит на isa.

Swift Runtime: статично изпращане и оптимизация

Swift Runtime се различава фундаментално от Objective-C Runtime: Swift по подразбиране използва статично изпращане (static dispatch) чрез vtable за методи на клас и direct call за value types и extension methods. Динамично изпращане (dynamic dispatch) се използва само за методи, маркирани с @objc или dynamic. Това дава увеличение на производителността до 40% в сравнение с Objective-C.

Value types (struct, enum) в Swift — ключовата разлика от Objective-C. Те се съхраняват в стека (stack) или вътре в друг обект, не използват retain/release и не участват в ARC за брояча на референции. Struct няма указател isa и не може да бъде изпратен чрез objc_msgSend. Protocol witnesses — аналог на vtable за протоколи, позволяващ динамично изпращане за existential container.

Swift Runtime също включва generics с реификация (reified generics чрез mangled symbols) и COW (Copy-on-Write) за оптимизация на string, array, dictionary, set. При копиране на колекция, действителното копиране се случва само при промяна на едно от копията. Това минимизира режийните разходи при предаване на колекции между функции.

Swift срещу Objective-C изпращане

import Foundation

// Swift: статично изпращане (vtable за 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") }
}

// Използване на existential container
let soundMakers: [SoundMaker] = [Dog(), Cow(), Duck()]
for maker in soundMakers {
    maker.makeSound()  // protocol witness dispatch
}

// Тестване на производителност
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")
}

Примерът демонстрира три типа изпращане в Swift: vtable за class (Dog), objc_msgSend за @objc dynamic (Cat) и direct call за struct (Cow). Protocol witnesses в existential container ([SoundMaker]) добавят режийни разходи. На практика Swift избира статично изпращане навсякъде, където е възможно, осигурявайки производителност, близка до C.

Swift Runtime и мост към Objective-C

Swift Runtime е проектиран за пълна съвместимост с Objective-C Runtime. Всеки Swift клас, наследяващ NSObject, автоматично се регистрира в Objective-C Runtime и може да бъде извикан чрез objc_msgSend. Атрибутът @objc прави Swift метода достъпен от Objective-C. Мост за String: Swift String автоматично се моства към NSString при предаване към Objective-C API (toll-free bridging).

ARC: Automatic Reference Counting и управление на паметта

ARC (Automatic Reference Counting) — система за управление на паметта в iOS, която работи на етапа на компилация. Компилаторът (Clang) анализира жизнения цикъл на обектите и автоматично вмъква извиквания на retain/release/autorelease. Разработчикът не трябва да ги извиква ръчно — за разлика от Manual Retain-Release (MRR) преди iOS 5. ARC работи на ниво Objective-C обекти и Swift class, но не за value types (struct, enum).

Всеки обект Objective-C и Swift class има брояч на референции (retain count), съхраняван в полето extra_rc вътре в non-pointer isa. При създаване на обект, retain count = 1. При retain броячът нараства, при release намалява. Когато броячът достигне 0, обектът се деалокира чрез dealloc (Objective-C) или deinit (Swift). ARC е thread-safe: retain/release използват атомарни операции (OSAtomicIncrement32/OSAtomicDecrement32).

Retain cycles — основният проблем на ARC. Ако обект A съхранява strong референция към B, а B — strong референция към A, и двата обекта никога няма да бъдат деалокирани, тъй като техните броячи на референции няма да се нулират. Решение — слаби референции (__weak в Objective-C, weak в Swift) или unowned. Слабите референции не увеличават retain count и автоматично се нулират (nil) при деалокация на обекта.

Отстраняване на retain cycles чрез Instruments

import Foundation

// Пример за retain cycle
class Parent {
    var child: Child?
    deinit { print("Parent deallocated") }
}

class Child {
    var parent: Parent?  // strong — създава retain cycle!
    deinit { print("Child deallocated") }
}

var parent: Parent? = Parent()
var child: Child? = Child()
parent?.child = child
child?.parent = parent  // цикъл: Parent -> Child -> Parent
parent = nil
child = nil
// deinit НЕ се извиква — изтичане на памет!

// Поправка: weak
class WeakChild {
    weak var parent: Parent?  // weak — не увеличава retain count
    deinit { print("WeakChild deallocated") }
}

// Поправка: unowned (за гарантиран жизнен цикъл)
class UnownedChild {
    unowned let parent: Parent
    init(parent: Parent) { self.parent = parent }
    deinit { print("UnownedChild deallocated") }
}

// Проверка чрез Instruments
func profileMemory() {
    // 1. Стартирайте Instruments > Leaks
    // 2. Изпълнете действие, създаващо обекти
    // 3. Проверете Leaks за изтичания
    // 4. В Allocations намерете обекти без dealloc
    for _ in 0..<1000 {
        let p = Parent()
        let c = WeakChild()
        p.child = c as? Child
        // c.parent = p — НЕ добавяме, weak
    }
}

Пример за retain cycle между Parent и Child: и двамата държат strong референции един към друг, ARC не може да нулира броячите. Поправка — weak parent в Child. weak автоматично се нулира при деалокация на parent. unowned — за случаи, когато жизненият цикъл на parent е гарантирано по-дълъг от този на child (напр. viewController и view). Използвайте Instruments > Leaks за откриване на retain cycles в ранен етап.

Autorelease pool

Autorelease pool — механизъм за отложен release за обекти, създадени без изрична собственост. @autoreleasepool { } в Swift и Objective-C създава пул, който се изпразва в края на блока, изпращайки release на всеки обект в пула. Критично важен в цикли (създаване на хиляди временни обекти) и на фонови нишки без RunLoop. UIKit RunLoop автоматично изпразва главния autorelease pool при всяка итерация.

dyld: динамичен зареждач и стартиране на приложение

dyld (dynamic link editor) — системен зареждач, отговорен за зареждане на изпълними файлове Mach-O и свързани динамични библиотеки (dylib) при стартиране на iOS приложение. dyld се намира на път /usr/lib/dyld и е част от libSystem. Процесът на зареждане включва няколко етапа: парсване на Mach-O, зареждане на зависимости (Library Loader, LC_LOAD_DYLIB), преместване на адреси (ASLR), инициализация на Objective-C Runtime и извикване на main().

Времето за стартиране на приложението (launch time) критично зависи от dyld: колкото повече динамични библиотеки и Objective-C класове, толкова по-дълъг е pre-main time. Apple препоръчва минимизиране на броя на +load методите (изпълняват се преди main), като ги замени с +initialize (мързелива инициализация). От 2020 г. Apple използва предварително изградена dyld cache на iOS: системните библиотеки са предварително свързани в единен кеш, което ускорява зареждането.

Измерване на pre-main time

import Foundation

// Измерване на времето за стартиране чрез DYLD_PRINT_STATISTICS
// В Xcode: Edit Scheme > Run > Arguments > Environment Variables
// DYLD_PRINT_STATISTICS = 1
// DYLD_PRINT_STATISTICS_DETAILS = 1

// Програмно измерване на pre-main time
@main
struct AppMain {
    static func main() {
        let launchStart = CFAbsoluteTimeGetCurrent()

        // UIApplicationMain се случва тук
        AppDelegate.main()

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

// Оптимизация: замяна на +load с +initialize
class OptimizedClass {
    // ❌ +load се изпълнява преди main
    // override class func load() { }

    // ✅ +initialize се изпълнява при първо използване
    static let shared = OptimizedClass()
    private init() {
        // Инициализация тук
    }
}

// Оптимизация на броя dylib
// Обединяването на статични библиотеки намалява броя LC_LOAD_DYLIB
// Използвайте флага -ObjC за свързване само на използваните Objective-C класове
// Xcode: Build Settings > Mach-O Type > Static Library

За измерване на pre-main time използвайте DYLD_PRINT_STATISTICS в схемата на Xcode. Резултатът ще покаже total time, dylib loading time, rebase/bind time, Objective-C setup time и initializer time. Целеви стойности: total < 400ms за студен старт, < 200ms за топъл старт. Оптимизации: обединяване на библиотеки, замяна на +load с +initialize, намаляване на броя на Objective-C класове (използвайте Swift), минимален брой динамични рамки.

dsc (dyld shared cache)

dyld shared cache — кеш на предварително свързани системни библиотеки на iOS. Всички системни dylib (UIKit, Foundation, CoreGraphics) са обединени в един файл: /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64. Това елиминира необходимостта от отделно зареждане на всяка системна библиотека — dyld получава достъп до кеша, което значително ускорява стартирането. Приложенията с 10+ динамични рамки изпитват най-голямо забавяне, тъй като персонализираните dylib не са част от dsc.