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 имплементације унутар swizzled верзије. У супротном, оригинално понашање метода се неповратно губи. Исправан образац — сачувати оригинални 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 догађаја без дуплирања кода у сваком контролеру.
• Логирање мрежних захтева — 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 и bytecode manipulation

На 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 доводи до пада. Невидљивост у коду: 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 методи могу бити swizzle-овани само преко 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 пресретања.