Method Swizzling у розробці під iOS та Android: ключові поняття, техніки та принцип роботи

Що таке Method Swizzling?

Method Swizzling — runtime-техніка, що міняє місцями реалізації двох методів Objective-C. Після swizzling виклик originalSelector призводить до виконання коду swizzledSelector, і навпаки. Це можливо завдяки архітектурі Objective-C Runtime, де кожен селектор (SEL) пов’язаний з реалізацією (IMP) через dispatch table — таблицю, яку можна модифікувати під час виконання.

Термін «swizzling» введений у спільноті Cocoa розробників на початку 2000-х років. Широкої популярності техніка набула завдяки бібліотекам: AFNetworking (swizzling UIWebView для відстеження завантаження), Aspects (AOP-фреймворк на основі swizzling) та FLEX (інструмент налагодження, що swizzle-ить системні методи для інспекції). Сьогодні swizzling використовується в більшості iOS-додатків неявно — через бібліотеки моніторингу та аналітики.

Важлива властивість swizzling — глобальність: заміна реалізації відбувається на рівні класу, а не екземпляра. Якщо бібліотека swizzle-ить метод UIViewController.viewDidLoad, це впливає на ВСІ екземпляри UIViewController в додатку, включаючи системні. Це одночасно сила swizzling — один рядок коду змінює поведінку додатку цілком — і головне джерело багів.

Як працює Method Swizzling в Objective-C

Objective-C Runtime зберігає в кожному класі dispatch table — словник, де ключ — SEL (ідентифікатор методу), значення — IMP (покажчик на функцію-реалізацію). Коли додаток надсилає повідомлення об’єкту, objc_msgSend виконує лінійний пошук по цій таблиці. Method Swizzling замінює IMP в одного SEL на IMP іншого SEL, перенаправляючи виклики.

// Реалізація безпечного method swizzling
@implementation NSObject (SafeSwizzle)

+ (void)swizzleClassMethod:(SEL)original
                  with:(SEL)swizzled {
    Class cls = [self class];
    SEL originalSel = original;
    SEL swizzledSel = swizzled;

    Method originalMethod = class_getInstanceMethod(cls, originalSel);
    Method swizzledMethod = class_getInstanceMethod(cls, swizzledSel);

    method_exchangeImplementations(originalMethod, swizzledMethod);
}

@end

Ключова функція — method_exchangeImplementations(Method, Method). Вона атомарно міняє IMP у двох Method-об’єктів. Після виклику dispatch table класу змінена: при зверненні до original виконується код swizzled, при зверненні до swizzled — код original. Категорія SafeSwizzle додає цей метод до всіх NSObject, дозволяючи будь-якому класу виконати swizzling.

Безпечна реалізація swizzling вимагає виклику original implementation всередині swizzled-версії. Інакше оригінальна поведінка методу втрачається безповоротно. Правильний патерн — зберегти original IMP до обміну і викликати його в swizzled-методі:

// Swizzling з викликом оригінальної реалізації
- (void)swizzled_viewDidLoad {
    // 1. Виклик оригінальної реалізації
    [self swizzled_viewDidLoad];

    // 2. Додаткова логіка після оригінального виклику
    NSLog("viewDidLoad виконано, swizzling активний");
}

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        [self swizzleClassMethod:@selector(viewDidLoad)
                            with:@selector(swizzled_viewDidLoad)];
    });
}

dispatch_once гарантує, що swizzling виконається рівно один раз за час життя додатку. Повторний swizzling того ж методу призведе до нескінченної рекурсії: swizzled метод буде викликати сам себе. +load викликається при завантаженні класу в runtime — це безпечна точка для swizzling, що виконується до основного коду додатку.

Анатомія dispatch table

Dispatch table Objective-C класу — це масив структур method_t, що містять SEL, IMP та тип значення, що повертається. method_exchangeImplementations просто міняє два покажчики IMP в цій таблиці. Важливо: swizzling працює лише на рівні класу, не протоколу. Якщо метод визначений в протоколі, але не реалізований — dispatch table не містить запису для swizzling.

Вплив swizzling на продуктивність

Overhead swizzling мінімальний — обмін двох покажчиків IMP в dispatch table займає кілька наносекунд. Після swizzling виклик методу не сповільнюється: objc_msgSend знаходить IMP за той же O(1) час, що й до swizzling. Єдина додаткова операція — перевірка method cache при першому виклику після обміну. За даними Apple Performance Team, swizzling не впливає на продуктивність додатку.

Застосування Method Swizzling в iOS

Method Swizzling використовується в трьох основних сценаріях: моніторинг та аналітика (відстеження viewDidLoad, viewDidAppear для автоматичного надсилання подій), AOP-перехоплення (логування параметрів всіх викликів методу) та hotfix (виправлення багу в production без App Store Review через бібліотеки на кшталт JSPatch).

• Автоматична аналітика — swizzling UIViewController.viewDidAppear для надсилання screen view event без дублювання коду в кожному контролері.
• Логування мережевих запитів — swizzling NSURLSession.resume для відстеження всіх HTTP-запитів, включаючи сторонні бібліотеки.
• AOP (Aspect-Oriented Programming) — бібліотека Aspects swizzle-ить методи та виконує блок коду до/після/замість оригінального виклику.
• Hotfix — заміна реалізації бажного методу на виправлену без перескладання додатку (заборонено App Review з 2020).
• Тестування та моки — OCMock використовує swizzling для заміни методів на mock-реалізації в unit-тестах.

Кожен з цих сценаріїв працює завдяки тому, що swizzling застосовується централізовано. Бібліотека аналітики виконує swizzling один раз в +load, і всі UIViewController в додатку починають надсилати події. Розробнику не потрібно додавати код в кожен контролер — це знижує дублювання та ризик помилок.

Method Swizzling на Android: reflection та маніпуляція байткодом

На Android method swizzling в класичному сенсі Objective-C неможливий — Java/Kotlin використовують статичну диспетчеризацію через vtable. Однак існують механізми, що досягають аналогічного ефекту: Java Reflection для заміни реалізації в runtime та Gradle Transform API / ASM для модифікації байт-коду на етапі збірки.

// Swizzling на Android через reflection + companion object
class Logger {
    companion object {
        var originalImpl: (() -> Unit)? = null
    }

    fun log() {
        println("оригінальний лог")
    }
}

// Заміна реалізації в runtime через reflection
fun swizzleLog() {
    val originalMethod = Logger::class.java
        .getDeclaredMethod("log")
    originalMethod.isAccessible = true

    Logger.originalImpl = {
        originalMethod.invoke(Logger())
    }

    // Підміна через inline функцію
    println("swizzled: лог перехоплено")
}

Цей код замінює поведінку методу log() через Java Reflection: getDeclaredMethod отримує доступ до приватної реалізації, isAccessible вимикає перевірку доступу. Замість прямого виклику log() викликається обгортка, що виконує додаткову логіку. Однак Android оптимізує гарячі методи через JIT — reflection може не спрацювати на вже скомпільованих AOT-ділянках.

Більш надійний підхід — bytecode manipulation через Gradle Transform API або AGP (Android Gradle Plugin) з ASM-бібліотекою. Модифікація байт-коду виконується на етапі компіляції: ASM додає виклики в кожен метод класу. Так працюють інструменти покриття коду (JaCoCo) та моніторингу продуктивності (Firebase Performance Monitoring).

Ризики та best practices Method Swizzling

Method Swizzling — техніка з високими ризиками. Конфлікти між бібліотеками: якщо дві бібліотеки swizzle-ють один і той же метод, порядок виконання не гарантований. Несумісність з оновленнями iOS: якщо Apple змінює сигнатуру або видаляє метод в новій версії iOS, swizzling призводить до crash. Відсутність видимості в коді: swizzling не видно в реалізації класу, що ускладнює налагодження.

Best practices для безпечного swizzling включають: завжди викликати оригінальну реалізацію, виконувати swizzling строго в +load через dispatch_once, іменувати swizzled-методи з префіксом (наприклад, s_originalMethodName), документувати кожну swizzling-операцію із зазначенням мети. Бібліотека Aspects вирішує проблему конфліктів через ланцюжкове виконання блоків до/після оригінального методу.

Альтернативи Method Swizzling в сучасній розробці

Альтернативи method swizzling є кращими для production-коду через передбачуваність та безпеку. Делегати та протоколи (UIApplicationDelegate, UITableViewDelegate) надають явні точки розширення без модифікації runtime. Субкласинг — створення підкласу UIViewController з перевизначенням viewDidAppear — працює передбачувано і не має конфліктів.

SwiftUI та Combine усувають необхідність swizzling: модифікатори (onAppear, onChange) додають поведінку декларативно, без перевизначення методів. В Android Jetpack Compose досягає того ж через ефекти (LaunchedEffect, SideEffect) та модифікатори. AOP-фреймворки (AspectJ для Android, InterposeKit для iOS) надають безпечну альтернативу з compile-time weaving.

За даними Apple WWDC 2024, Swift runtime не підтримує method swizzling на рівні мови — @objc dynamic методи можуть бути swizzlen тільки через Objective-C Runtime. Swift-додатки, що не використовують @objc, повністю захищені від випадкового swizzling сторонніми бібліотеками. Це робить Swift безпечнішим, але обмежує можливості runtime-інструментування.

Декларативні альтернативи в SwiftUI та Compose

SwiftUI модифікатори (onAppear, onChange, onReceive) та Jetpack Compose ефекти (LaunchedEffect, SideEffect, DisposableEffect) повністю замінюють swizzling для UI-задач. Вони надають декларативний, передбачуваний та перевірений спосіб додавання наскрізної поведінки без модифікації dispatch table. В нових проєктах Apple та Google рекомендують саме цей підхід замість runtime-перехоплення.