Runtime, Hot Reload та збірка в мобільній розробці: що це, ключові концепції та як працює

Runtime та Reflection: iOS Runtime, Method Swizzling та динамічна диспетчеризація

Runtime (середовище виконання) — це програмне забезпечення, яке керує виконанням додатка. У контексті iOS Runtime — це динамічна система Objective-C, яка дозволяє надсилати повідомлення об'єктам, створювати класи на льоту та замінювати методи під час виконання. Це можливо завдяки тому, що Objective-C — динамічно типізована мова поверх C.

Reflection — здатність програми досліджувати та змінювати свою структуру під час виконання. В iOS Runtime це реалізовано через функції на кшталт class_getInstanceMethod, method_exchangeImplementations та objc_getAssociatedObject. У Kotlin/Java для рефлексії використовується KClass / java.lang.reflect.

В IT Sectr ми використовуємо Runtime вкрай рідко — тільки для специфічних завдань, де немає альтернативи. Наприклад, Method Swizzling для централізованого логування аналітики або виправлення багів у бібліотеках. Однак Runtime — потужний інструмент, який вимагає глибокого розуміння та обережності.

Method Swizzling

Method Swizzling — це техніка заміни реалізації методу Objective-C на іншу під час виконання. Це окремий випадок Aspect-Oriented Programming (AOP) для iOS. Swizzling дозволяє додати логування, аналітику або кешування в існуючі методи без зміни їх вихідного коду.

Типовий приклад: замінити viewWillAppear: у UIViewController, щоб додати автоматичне логування екранів. Важливо: swizzling потрібно виконувати в методі +load або +initialize, щоб гарантувати виконання до використання класу. Неправильний swizzling може призвести до невизначеної поведінки та багів, які складно налагоджувати.

// Method Swizzling для логування 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]; // виклик оригінального методу
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Код замінює viewWillAppear: у всіх UIViewController через swizzling. Після method_exchangeImplementations виклик оригінального viewWillAppear: призводить до виклику xxx_viewWillAppear:, який викликає оригінальний метод (через рекурсивний виклик) та додає аналітику. DispatchOnce гарантує одноразове виконання swizzling.

Веб-інструменти (Transpilation, Polyfill, Bundler, Webpack, Metro)

Сучасна веб-розробка та мобільна розробка на React Native або Flutter неможливі без інструментів збірки. Transpilation — перетворення коду з однієї мови на іншу. Найпопулярніший приклад: TypeScript → JavaScript. Транспілятор (Babel, tsc) перетворює сучасний код у зворотно сумісну версію.

Polyfill — це код, який додає відсутню функціональність старим браузерам. Наприклад, Promise.allSettled() не працює в Internet Explorer, але поліфіл додає цю можливість. На відміну від нативного Runtime, який керує виконанням коду безпосередньо на пристрої, поліфіли та транспілятори працюють на рівні абстракції мови — вони адаптують синтаксис та API, але не втручаються в середовище виконання.

Webpack — найпопулярніший бандлер (використовується в 72% проектів за даними State of JS 2024). Metro — бандлер від Facebook, що використовується за замовчуванням у React Native. Reflection у JavaScript існує через Object.getPrototypeOf, Proxy та Reflect API — ці механізми дозволяють досліджувати та змінювати об'єкти під час виконання, що принципово відрізняється від статичного аналізу модулів у бандлерах. Webpack використовує конфігураційний файл, де описуються entry point, output, loaders (для обробки різних типів файлів) та plugins (для додаткової функціональності).

// webpack.config.js — мінімальна конфігурація
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',
};

Ця конфігурація визначає точку входу (index.js), вихідний файл (bundle.js) та правило для обробки JavaScript через Babel. Режим production включає оптимізації: мініфікацію, tree shaking та автоматичне визначення середовища. На етапі Runtime всі ці оптимізації вже не впливають на логіку — браузер виконує стиснений bundle як звичайний JavaScript.

Оптимізація коду (Minification, Tree Shaking, Obfuscation)

Minification (мініфікація) — процес стиснення коду за рахунок видалення пробілів, коментарів, перейменування довгих змінних у короткі. Популярні мініфікатори: Terser (JS/TS), CSSNano (CSS), html-minifier-terser. Мініфікація зменшує розмір файлу на 50–70%. У Production Runtime мініфікований код виконується так само, як і вихідний — різниця лише в читабельності та розмірі файлу, а не в семантиці.

Tree Shaking — видалення мертвого коду, який не використовується в додатку. Працює на основі статичного аналізу ES-модулів (import/export). Якщо функція експортується, але ніде не імпортується, Tree Shaking видаляє її з підсумкової збірки. Tree Shaking аналізує код статично — на відміну від Reflection, який працює динамічно та може звертатися до методів і властивостей, невидимих на етапі компіляції.

Tree Shaking

Tree Shaking у Webpack вмикається автоматично в режимі production. Важлива умова: код повинен використовувати ES-модулі (import/export), а не CommonJS (require). Якщо бібліотека написана на CommonJS, tree shaking не спрацює. Для оптимального tree shaking використовуйте точні імпорти: import { merge } from 'lodash-es' замість import _ from 'lodash'. Це зменшує розмір збірки з 500 КБ до 10 КБ для однієї функції.

Hot Reload

Hot Reload — технологія, що дозволяє оновлювати код додатка без повного перезавантаження. У React Native та Flutter Hot Reload оновлює змінений файль на льоту, зберігаючи поточний стан додатка. Це радикально прискорює розробку: зміни видно за 1–2 секунди замість 10–30 секунд при повній перезбірці. Hot Reload працює в Runtime: змінений модуль підставляється в працюючий додаток без перезапуску середовища виконання.

Hot Restart — це швидкий перезапуск додатка з оновленим кодом, але без збереження стану. Використовується, коли Hot Reload неможливий (наприклад, змінився нативний код або глобальні змінні). В IT Sectr ми використовуємо Hot Reload на всіх етапах розробки UI — це економить до 50% часу на візуальні правки.

Таблиця 3. Порівняння інструментів збірки. Webpack — універсальний стандарт. Metro — спеціалізований для React Native. Vite та esbuild — нове покоління з фокусом на швидкість. Rollup — найкращий вибір для публікації бібліотек.

Гаряче перезавантаження (Hot Reload, Hot Restart)

Hot Reload — це технологія, яка з'явилася у веб-розробці (React Hot Loader, HMR — Hot Module Replacement) та перейшла в мобільну розробку з Flutter та React Native. Суть: при зміні файлу бандлер відправляє оновлений модуль у працюючий додаток, який замінює старий код без втрати стану. На відміну від повної перезбірки, Hot Reload не перезапускає Runtime — середовище виконання продовжує працювати, а змінений модуль підключається динамічно через механізм на кшталт HMR або Reflection-подібного оновлення посилань.

Hot Reload працює за рахунок того, що фреймворк зберігає віджети (Flutter) або компоненти (React) у пам'яті та оновлює лише змінені частини. Hot Restart — грубіший механізм: він повністю перезапускає додаток, але швидше повної перезбірки, оскільки не перекомпілює нативний код. В IT Sectr ми використовуємо Hot Reload при розробці UI та Hot Restart при зміні навігації або стейт-менеджменту.