iOS Runtime : qu'est-ce que c'est, environnement d'exécution des applications sur iPhone

Qu'est-ce que iOS Runtime ?

iOS Runtime est un ensemble de composants système qui assurent l'exécution des applications sur les appareils Apple sous iOS. Il inclut Objective-C Runtime (bibliothèque libobjc.A.dylib), Swift Runtime (libswiftCore.dylib), Core Foundation, les frameworks Cocoa Touch (UIKit, Foundation), le chargeur dynamique dyld et l'environnement d'exécution pour la gestion de la mémoire, des threads et de la communication interprocessus.

Architecturalement, iOS Runtime opère à trois niveaux. Au niveau le plus bas — le format binaire Mach-O et dyld, qui charge le fichier exécutable et les bibliothèques. Le niveau intermédiaire — Objective-C Runtime et Swift Runtime, responsables du dispatch des méthodes et de la gestion des objets. Le niveau supérieur — les frameworks Cocoa Touch (UIKit, Foundation, Core Data, Metal), qui fournissent des API au développeur.

Comprendre iOS Runtime permet au développeur de résoudre des problèmes complexes : le swizzling de méthodes (Method Swizzling) pour les tests A/B et l'analytique, le chargement dynamique de classes, l'optimisation de la mémoire via la compréhension d'ARC, le débogage des retain cycles et des fuites mémoire, l'optimisation du temps de lancement de l'application via dyld. Sans connaissance du runtime, le profilage et l'optimisation au niveau système sont impossibles.

Composants de iOS Runtime

Format Mach-O

Les applications pour iOS sont compilées au format Mach-O (Mach Object). Un fichier Mach-O contient un en-tête, des commandes de chargement et des segments : __TEXT (code, constantes), __DATA (variables globales, métadonnées Objective-C), __LINKEDIT (symboles, tables de relocalisation). dyld analyse le Mach-O et charge les dépendances avant d'exécuter la première instruction.

Objective-C Runtime : Message Passing et Dispatch Dynamique

Objective-C Runtime est la partie la plus puissante de iOS Runtime. Contrairement au C++ avec liaison précoce (early binding), Objective-C utilise une liaison tardive (late binding) via message passing. Un appel de méthode [receiver message] n'est pas compilé en un appel de fonction direct, mais en objc_msgSend(receiver, @selector(message)), qui trouve dynamiquement l'implémentation de la méthode dans la classe de l'objet.

Chaque objet Objective-C stocke un pointeur isa vers sa classe. La classe contient une liste de méthodes, un cache de méthodes et un pointeur vers la superclasse. objc_msgSend parcourt la chaîne d'héritage : vérifie le cache de la classe, puis la liste de méthodes, puis passe à la superclasse. Si la méthode n'est pas trouvée, le forwarding est déclenché : resolveInstanceMethod, forwardingTargetForSelector et forwardInvocation.

Method Swizzling est une technique d'échange d'implémentations de méthodes à la volée via l'échange d'IMP (pointeur d'implémentation) à l'exécution. Il est utilisé pour les tests A/B, l'analytique (suivi automatique d'écrans) et la surveillance. Il n'est pas recommandé en production sans nécessité critique, car il peut entrer en conflit avec les mises à jour de l'OS.

Exemple : Method Swizzling en Objective-C

// Method Swizzling pour le suivi de 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 {
    // Suivi d'événement
    NSLog(@"View Did Load : %@", self.class);
    // Appel de l'implémentation originale
    [self swizzled_viewDidLoad];
}

@end

La catégorie UIViewController (Tracking) remplace viewDidLoad par swizzled_viewDidLoad dans tous les UIViewControllers de l'application. dispatch_once garantit un swizzling unique. class_addMethod évite le double swizzling et les conflits avec les superclasses. Il est utilisé pour le suivi automatique des vues d'écran dans l'analytique sans modifier le code source du contrôleur.

Pointeur isa et Tagged Pointers

Dans iOS moderne (arm64), Apple a optimisé le pointeur isa : ce n'est pas simplement une adresse de classe, mais un champ de bits (non-pointer isa) contenant des indicateurs de gestion de la mémoire et des informations de classe. Les tagged pointers sont une autre optimisation : les petites valeurs NSNumber, NSDate et NSString ne sont pas stockées comme des objets sur le tas, mais directement dans le pointeur, éliminant les frais généraux de malloc et retain/release. Un tagged pointer est reconnu par le bit de poids faible de isa.

Swift Runtime : Dispatch Statique et Optimisation

Swift Runtime diffère fondamentalement de Objective-C Runtime : Swift par défaut utilise le dispatch statique (static dispatch) via vtable pour les méthodes de classe et direct call pour les value types et les méthodes d'extension. Le dispatch dynamique (dynamic dispatch) est utilisé uniquement pour les méthodes marquées @objc ou dynamic. Cela offre jusqu'à 40% d'amélioration des performances par rapport à Objective-C.

Value types (struct, enum) en Swift sont une différence clé avec Objective-C. Ils sont stockés sur la pile ou à l'intérieur d'un autre objet, n'utilisent pas retain/release et ne participent pas à l'ARC pour le comptage de références. Struct n'a pas de pointeur isa et ne peut pas être envoyé via objc_msgSend. Les protocol witnesses sont un analogue de vtable pour les protocoles, permettant le dispatch dynamique pour les existential containers.

Swift Runtime inclut également generics avec réification (reified generics via mangled symbols) et COW (Copy-on-Write) pour optimiser string, array, dictionary, set. Lors de la copie d'une collection, la copie réelle n'a lieu que lorsque l'une des copies est modifiée. Cela minimise les frais généraux lors du passage de collections entre fonctions.

Dispatch Swift vs Objective-C

import Foundation

// Swift : dispatch statique (vtable pour class)
class Animal {
    func makeSound() { print("...") }  // vtable
}

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

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

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

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

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

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

// Test de performance
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")
}

L'exemple montre trois types de dispatch en Swift : vtable pour class (Dog), objc_msgSend pour @objc dynamic (Cat) et direct call pour struct (Cow). Les protocol witnesses dans les existential containers ([SoundMaker]) ajoutent des frais généraux. En pratique, Swift choisit le dispatch statique partout où possible, offrant des performances proches de C.

Swift Runtime et Pont Objective-C

Swift Runtime est conçu pour une compatibilité totale avec Objective-C Runtime. Toute classe Swift héritant de NSObject est automatiquement enregistrée dans Objective-C Runtime et peut être appelée via objc_msgSend. L'attribut @objc rend une méthode Swift accessible depuis Objective-C. Pont String : Swift String est automatiquement pontée vers NSString lors du passage à une API Objective-C (toll-free bridging).

ARC : Comptage Automatique de Références et Gestion de la Mémoire

ARC (Automatic Reference Counting) est un système de gestion de la mémoire dans iOS qui opère à la compilation. Le compilateur (Clang) analyse les durées de vie des objets et insère automatiquement des appels retain/release/autorelease. Le développeur n'a pas besoin de les appeler manuellement — contrairement au Manual Retain-Release (MRR) avant iOS 5. ARC fonctionne au niveau des objets Objective-C et Swift, mais pas pour les value types (struct, enum).

Chaque objet Objective-C et classe Swift a un compteur de références (retain count), stocké dans le champ extra_rc à l'intérieur du non-pointer isa. Lors de la création d'un objet, retain count = 1. Lors de retain, le compteur augmente ; lors de release, il diminue. Lorsque le compteur atteint 0, l'objet est désalloué via dealloc (Objective-C) ou deinit (Swift). ARC est thread-safe : retain/release utilisent des opérations atomiques (OSAtomicIncrement32/OSAtomicDecrement32).

Retain cycles sont le principal problème d'ARC. Si l'objet A a une référence strong vers B, et B a une référence strong vers A, les deux objets ne seront jamais désalloués car leurs compteurs de références n'atteindront jamais zéro. La solution est les références weak (__weak en Objective-C, weak en Swift) ou les références unowned. Les références weak n'augmentent pas le retain count et sont automatiquement mises à zéro (nil) lors de la désallocation de l'objet.

Débogage des Retain Cycles avec Instruments

import Foundation

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

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

var parent: Parent? = Parent()
var child: Child? = Child()
parent?.child = child
child?.parent = parent  // cycle : Parent -> Child -> Parent
parent = nil
child = nil
// deinit NON appelé — fuite mémoire !

// Correction : weak
class WeakChild {
    weak var parent: Parent?  // weak — n'augmente pas le retain count
    deinit { print("WeakChild deallocated") }
}

// Correction : unowned (pour durée de vie garantie)
class UnownedChild {
    unowned let parent: Parent
    init(parent: Parent) { self.parent = parent }
    deinit { print("UnownedChild deallocated") }
}

// Vérification via Instruments
func profileMemory() {
    // 1. Lancer Instruments > Leaks
    // 2. Effectuer une action créant des objets
    // 3. Vérifier Leaks pour les fuites
    // 4. Dans Allocations trouver les objets sans dealloc
    for _ in 0..<1000 {
        let p = Parent()
        let c = WeakChild()
        p.child = c as? Child
        // c.parent = p — N'ajoutons pas, weak
    }
}

L'exemple de retain cycle entre Parent et Child : les deux maintiennent des références strong l'un vers l'autre, ARC ne peut pas mettre les compteurs à zéro. La correction est weak parent dans Child. weak est automatiquement mis à zéro lors de la désallocation de parent. unowned est pour les cas où la durée de vie de parent est garantie plus longue que celle de child (par exemple, viewController et view). Utilisez Instruments > Leaks pour détecter les retain cycles précocement.

Autorelease Pool

Autorelease pool est un mécanisme de libération différée pour les objets créés sans propriété explicite. @autoreleasepool { } en Swift et Objective-C crée un pool qui est drainé à la fin du bloc, envoyant release à chaque objet du pool. Il est crucial dans les boucles (création de milliers d'objets temporaires) et sur les threads d'arrière-plan sans RunLoop. L'UIKit RunLoop draine automatiquement le pool d'autorelease principal à chaque itération.

dyld : Chargeur Dynamique et Lancement d'Application

dyld (dynamic link editor) est le chargeur système responsable du chargement des fichiers exécutables Mach-O et des bibliothèques dynamiques associées (dylib) au lancement d'une application iOS. dyld se trouve à /usr/lib/dyld et fait partie de libSystem. Le processus de chargement comprend plusieurs étapes : analyse Mach-O, chargement des dépendances (Library Loader, LC_LOAD_DYLIB), relocalisation d'adresses (ASLR), initialisation d'Objective-C Runtime et appel à main().

Le temps de lancement de l'application dépend crucialement de dyld : plus il y a de bibliothèques dynamiques et de classes Objective-C, plus le pre-main time est long. Apple recommande de minimiser le nombre de méthodes +load (elles s'exécutent avant main), en les remplaçant par +initialize (initialisation paresseuse). Depuis 2020, Apple utilise un cache dyld préconstruit sur iOS : les bibliothèques système sont préliées dans un seul cache, accélérant le chargement.

Mesure du Pre-main Time

import Foundation

// Mesure du temps de lancement via DYLD_PRINT_STATISTICS
// Dans Xcode : Edit Scheme > Run > Arguments > Environment Variables
// DYLD_PRINT_STATISTICS = 1
// DYLD_PRINT_STATISTICS_DETAILS = 1

// Mesure programmatique du pre-main time
@main
struct AppMain {
    static func main() {
        let launchStart = CFAbsoluteTimeGetCurrent()

        // UIApplicationMain se produit ici
        AppDelegate.main()

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

// Optimisation : remplacer +load par +initialize
class OptimizedClass {
    // ❌ +load s'exécute avant main
    // override class func load() { }

    // ✅ +initialize s'exécute au premier accès
    static let shared = OptimizedClass()
    private init() {
        // Initialisation ici
    }
}

// Optimisation du nombre de dylib
// La fusion de bibliothèques statiques réduit le nombre de LC_LOAD_DYLIB
// Utilisez le flag -ObjC pour lier uniquement les classes Objective-C utilisées
// Xcode : Build Settings > Mach-O Type > Static Library

Pour mesurer le pre-main time, utilisez DYLD_PRINT_STATISTICS dans le schéma Xcode. La sortie montre le temps total, le temps de chargement dylib, le temps rebase/bind, le temps de configuration Objective-C et le temps d'initialisation. Valeurs cibles : total < 400ms pour un démarrage à froid, < 200ms pour un démarrage à chaud. Optimisations : fusionner les bibliothèques, remplacer +load par +initialize, réduire le nombre de classes Objective-C (utilisez Swift), nombre minimal de frameworks dynamiques.

dsc (dyld Shared Cache)

dyld shared cache est un cache de bibliothèques système préliées sur iOS. Toutes les dylib système (UIKit, Foundation, CoreGraphics) sont combinées en un seul fichier : /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64. Cela élimine le besoin de charger chaque bibliothèque système séparément — dyld accède au cache, ce qui accélère considérablement le démarrage. Les applications avec 10+ frameworks dynamiques subissent le plus grand retard, car les dylib personnalisées ne sont pas incluses dans le dsc.