Runtime, Hot Reload et compilation dans le développement mobile : ce que c'est, concepts clés et fonctionnement

Runtime et Reflection : iOS Runtime, Method Swizzling et dispatch dynamique

Runtime (environnement d'exécution) est le logiciel qui gère l'exécution de l'application. Dans le contexte d'iOS Runtime, c'est le système dynamique d'Objective-C qui permet d'envoyer des messages aux objets, de créer des classes à la volée et de remplacer des méthodes pendant l'exécution. Cela est possible car Objective-C est un langage dynamiquement typé construit sur C.

Reflection est la capacité d'un programme à examiner et modifier sa propre structure pendant l'exécution. Dans iOS Runtime, cela est implémenté via des fonctions comme class_getInstanceMethod, method_exchangeImplementations et objc_getAssociatedObject. En Kotlin/Java, la réflexion utilise KClass / java.lang.reflect.

Chez IT Sectr, nous utilisons Runtime très rarement — uniquement pour des tâches spécifiques où il n'y a pas d'alternative. Par exemple, Method Swizzling pour la journalisation centralisée d'analytiques ou la correction de bugs dans des bibliothèques. Cependant, Runtime est un outil puissant qui nécessite une compréhension approfondie et de la prudence.

Method Swizzling

Method Swizzling est une technique permettant de remplacer l'implémentation d'une méthode Objective-C par une autre pendant l'exécution. C'est un cas particulier de programmation orientée aspect (AOP) pour iOS. Swizzling permet d'ajouter de la journalisation, des analytiques ou du caching à des méthodes existantes sans modifier leur code source.

Un exemple typique : remplacer viewWillAppear: dans UIViewController pour ajouter une journalisation automatique des écrans. Important : le swizzling doit être exécuté dans la méthode +load ou +initialize pour garantir l'exécution avant l'utilisation de la classe. Un swizzling incorrect peut provoquer un comportement indéfini et des bugs difficiles à déboguer.

// Method Swizzling pour journaliser viewWillAppear:
@implementation UIViewController (Tracking)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];
        SEL originalSelector = @selector(viewWillAppear:);
        SEL swizzledSelector = @selector(xxx_viewWillAppear:);
        
        Method originalMethod = class_getInstanceMethod(class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
        method_exchangeImplementations(originalMethod, swizzledMethod);
    });
}

- (void)xxx_viewWillAppear:(BOOL)animated {
    [self xxx_viewWillAppear:animated]; // appel de la méthode originale
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Ce code remplace viewWillAppear: sur tous les UIViewController via le swizzling. Après method_exchangeImplementations, l'appel au viewWillAppear: original entraîne l'appel de xxx_viewWillAppear:, qui appelle la méthode originale (via un appel récursif) et ajoute des analytiques. DispatchOnce garantit l'exécution unique du swizzling.

Outils web (Transpilation, Polyfill, Bundler, Webpack, Metro)

Le développement web moderne et le développement mobile avec React Native ou Flutter sont impossibles sans outils de compilation. Transpilation est la conversion de code d'un langage à un autre. L'exemple le plus populaire : TypeScript → JavaScript. Un transpileur (Babel, tsc) convertit le code moderne en une version rétrocompatible.

Polyfill est un code qui ajoute des fonctionnalités manquantes aux navigateurs anciens. Par exemple, Promise.allSettled() ne fonctionne pas dans Internet Explorer, mais un polyfill ajoute cette capacité. Contrairement au Runtime natif, qui gère l'exécution du code directement sur l'appareil, les polyfills et transpileurs opèrent au niveau d'abstraction du langage — ils adaptent la syntaxe et les API, mais n'interfèrent pas avec l'environnement d'exécution.

Webpack est le bundler le plus populaire (utilisé dans 72% des projets selon State of JS 2024). Metro est le bundler de Facebook, utilisé par défaut dans React Native. Reflection en JavaScript existe via Object.getPrototypeOf, Proxy et Reflect API — ces mécanismes permettent d'examiner et de modifier des objets pendant l'exécution, ce qui est fondamentalement différent de l'analyse statique des modules dans les bundlers. Webpack utilise un fichier de configuration qui décrit le point d'entrée, la sortie, les loaders (pour traiter différents types de fichiers) et les plugins (pour des fonctionnalités supplémentaires).

// webpack.config.js — configuration minimale
const path = require('path');

module.exports = {
    entry: './src/index.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist'),
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: 'babel-loader',
            },
        ],
    },
    mode: 'production',
};

Cette configuration définit le point d'entrée (index.js), le fichier de sortie (bundle.js) et une règle pour traiter JavaScript via Babel. Le mode production active les optimisations : minification, tree shaking et détection automatique de l'environnement. Au stade Runtime, toutes ces optimisations n'affectent plus la logique — le navigateur exécute le bundle minifié comme du JavaScript normal.

Optimisation du code (Minification, Tree Shaking, Obfuscation)

Minification est le processus de compression du code en supprimant les espaces, les commentaires et en renommant les variables longues en courtes. Minificateurs populaires : Terser (JS/TS), CSSNano (CSS), html-minifier-terser. La minification réduit la taille du fichier de 50 à 70%. En production, Runtime exécute le code minifié de la même manière que l'original — la différence réside uniquement dans la lisibilité et la taille du fichier, pas dans la sémantique.

Tree Shaking est la suppression du code mort qui n'est pas utilisé dans l'application. Il fonctionne sur la base de l'analyse statique des modules ES (import/export). Si une fonction est exportée mais jamais importée, Tree Shaking la supprime de la compilation finale. Tree Shaking analyse le code statiquement — contrairement à Reflection, qui fonctionne dynamiquement et peut accéder à des méthodes et propriétés invisibles au moment de la compilation.

Tree Shaking

Tree Shaking dans Webpack est activé automatiquement en mode production. Une condition importante : le code doit utiliser des modules ES (import/export), pas CommonJS (require). Si une bibliothèque est écrite en CommonJS, le tree shaking ne fonctionnera pas. Pour un tree shaking optimal, utilisez des importations précises : import { merge } from 'lodash-es' au lieu de import _ from 'lodash'. Cela réduit la taille du bundle de 500 Ko à 10 Ko pour une seule fonction.

Hot Reload

Hot Reload est une technologie qui permet de mettre à jour le code de l'application sans rechargement complet. Dans React Native et Flutter, Hot Reload met à jour le fichier modifié à la volée, en préservant l'état actuel de l'application. Cela accélère radicalement le développement : les changements sont visibles en 1 à 2 secondes au lieu de 10 à 30 secondes pour une reconstruction complète. Hot Reload fonctionne dans le Runtime : le module modifié est injecté dans l'application en cours d'exécution sans redémarrer l'environnement d'exécution.

Hot Restart est un redémarrage rapide de l'application avec du code mis à jour, mais sans conservation de l'état. Il est utilisé lorsque Hot Reload n'est pas possible (par exemple, lorsque le code natif ou les variables globales ont changé). Chez IT Sectr, nous utilisons Hot Reload à toutes les étapes du développement UI — cela permet d'économiser jusqu'à 50% du temps sur les ajustements visuels.

Tableau 3. Comparaison des outils de compilation. Webpack est le standard universel. Metro est spécialisé pour React Native. Vite et esbuild sont la nouvelle génération axée sur la vitesse. Rollup est le meilleur choix pour publier des bibliothèques.

Rechargement à chaud (Hot Reload, Hot Restart)

Hot Reload est une technologie née dans le développement web (React Hot Loader, HMR — Hot Module Replacement) et transférée au développement mobile avec Flutter et React Native. L'essence : lorsqu'un fichier change, le bundler envoie le module mis à jour à l'application en cours d'exécution, qui remplace l'ancien code sans perte d'état. Contrairement à une reconstruction complète, Hot Reload ne redémarre pas le Runtime — l'environnement d'exécution continue de fonctionner et le module modifié est connecté dynamiquement via un mécanisme comme HMR ou une mise à jour de référence similaire à Reflection.

Hot Reload fonctionne car le framework conserve les widgets (Flutter) ou composants (React) en mémoire et ne met à jour que les parties modifiées. Hot Restart est un mécanisme plus grossier : il redémarre complètement l'application, mais est plus rapide qu'une reconstruction complète car il ne recompile pas le code natif. Chez IT Sectr, nous utilisons Hot Reload lors du développement UI et Hot Restart lors des modifications de navigation ou de gestion d'état.