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, затем переходит к суперклассу. Если метод не найден, запускается forwarded: 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 pointer и tagged pointers

В современных iOS (arm64) компания Apple оптимизировала isa pointer: это не просто адрес класса, а битовое поле (non-pointer isa), содержащее флаги управления памятью и информацию о классе. Tagged pointers — ещё одна оптимизация: значения NSNumber, NSDate и NSString небольшого размера хранятся не как объекты в куче, а прямо в указателе, устраняя накладные расходы на 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 pointer и не может быть отправлен через objc_msgSend. Protocol witnesses — аналог vtable для протоколов, позволяющий динамическую диспетчеризацию для existential container.

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

Swift vs 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
}

// Performance testing
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]) добавляют overhead. На практике Swift выбирает статическую диспетчеризацию везде, где возможно, обеспечивая производительность, близкую к C.

Swift Runtime и Objective-C bridge

Swift Runtime спроектирован для полной совместимости с Objective-C Runtime. Любой Swift класс, наследующий NSObject, автоматически регистрируется в Objective-C Runtime и может быть вызван через objc_msgSend. @objc атрибут делает Swift method доступным из Objective-C. String bridge: Swift String автоматически bridged к 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 объектов, но не для 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 ссылки (__weak в Objective-C, weak в Swift) или unowned ссылки. Weak ссылки не увеличивают 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 (для guaranteed lifetime)
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 автоматически дренирует main 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 (ленивая инициализация). C 2020 года Apple использует prebuilt 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.