Runtime, Hot Reload och bygge i mobil utveckling: vad det är, viktiga koncept och hur det fungerar

Runtime och Reflection: iOS Runtime, Method Swizzling och dynamisk sändning

Runtime (exekveringsmiljö) är programvaran som hanterar applikationens exekvering. I sammanhanget av iOS Runtime är det Objective-Cs dynamiska system som tillåter sändning av meddelanden till objekt, skapande av klasser i farten och ersättning av metoder under körning. Detta är möjligt eftersom Objective-C är ett dynamiskt typat språk byggt på C.

Reflection är ett programs förmåga att undersöka och ändra sin egen struktur under körning. I iOS Runtime implementeras detta genom funktioner som class_getInstanceMethod, method_exchangeImplementations och objc_getAssociatedObject. I Kotlin/Java använder reflektion KClass / java.lang.reflect.

Hos IT Sectr använder vi Runtime mycket sällan — bara för specifika uppgifter där det inte finns något alternativ. Till exempel Method Swizzling för centraliserad analysloggning eller korrigering av buggar i bibliotek. Runtime är dock ett kraftfullt verktyg som kräver djup förståelse och försiktighet.

Method Swizzling

Method Swizzling är en teknik för att ersätta en Objective-C-metodimplementering med en annan under körning. Detta är ett specialfall av aspektorienterad programmering (AOP) för iOS. Swizzling tillåter tillägg av loggning, analys eller cachning till befintliga metoder utan att ändra deras källkod.

Ett typiskt exempel: ersätta viewWillAppear: i UIViewController för att lägga till automatisk skärmloggning. Viktigt: swizzling måste utföras i metoden +load eller +initialize för att garantera exekvering före användning av klassen. Felaktig swizzling kan orsaka odefinierat beteende och buggar som är svåra att felsöka.

// Method Swizzling för loggning av 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]; // anrop av den ursprungliga metoden
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Denna kod ersätter viewWillAppear: på alla UIViewController via swizzling. Efter method_exchangeImplementations leder anrop av den ursprungliga viewWillAppear: till anrop av xxx_viewWillAppear:, som anropar den ursprungliga metoden (via rekursivt anrop) och lägger till analys. DispatchOnce garanterar engångsexekvering av swizzling.

Webbverktyg (Transpilation, Polyfill, Bundler, Webpack, Metro)

Modern webbutveckling och mobil utveckling med React Native eller Flutter är omöjliga utan byggverktyg. Transpilation är konvertering av kod från ett språk till ett annat. Det mest populära exemplet: TypeScript → JavaScript. En transpilator (Babel, tsc) konverterar modern kod till en bakåtkompatibel version.

Polyfill är kod som lägger till saknad funktionalitet till gamla webbläsare. Till exempel fungerar Promise.allSettled() inte i Internet Explorer, men en polyfill lägger till denna förmåga. Till skillnad från inbyggt Runtime, som hanterar kodexekvering direkt på enheten, arbetar polyfills och transpilatorer på språknivå — de anpassar syntax och API:er men stör inte exekveringsmiljön.

Webpack är den mest populära bundlern (används i 72% av projekten enligt State of JS 2024). Metro är Facebooks bundler, som används som standard i React Native. Reflection i JavaScript finns via Object.getPrototypeOf, Proxy och Reflect API — dessa mekanismer tillåter undersökning och ändring av objekt under körning, vilket är fundamentalt annorlunda från statisk modulanalys i bundlers. Webpack använder en konfigurationsfil som beskriver ingångspunkt, utdata, lastare (för bearbetning av olika filtyper) och plugins (för ytterligare funktionalitet).

// webpack.config.js — minimal konfiguration
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',
};

Denna konfiguration definierar ingångspunkten (index.js), utdatafilen (bundle.js) och en regel för bearbetning av JavaScript via Babel. production-läge aktiverar optimeringar: minifiering, tree shaking och automatisk miljödetektering. I Runtime-steget påverkar alla dessa optimeringar inte längre logiken — webbläsaren exekverar den minifierade bunten som vanlig JavaScript.

Kodoptimering (Minification, Tree Shaking, Obfuscation)

Minification är processen att komprimera kod genom att ta bort mellanslag, kommentarer och byta namn på långa variabler till korta. Populära minifierare: Terser (JS/TS), CSSNano (CSS), html-minifier-terser. Minifiering minskar filstorleken med 50–70%. I produktion exekverar Runtime minifierad kod på samma sätt som originalkoden — skillnaden är bara i läsbarhet och filstorlek, inte i semantik.

Tree Shaking är borttagning av död kod som inte används i applikationen. Det fungerar baserat på statisk analys av ES-moduler (import/export). Om en funktion exporteras men aldrig importeras, tar Tree Shaking bort den från den slutliga bygget. Tree Shaking analyserar kod statiskt — till skillnad från Reflection, som arbetar dynamiskt och kan komma åt metoder och egenskaper som är osynliga vid kompilering.

Tree Shaking

Tree Shaking i Webpack aktiveras automatiskt i produktionsläge. Ett viktigt villkor: koden måste använda ES-moduler (import/export), inte CommonJS (require). Om ett bibliotek är skrivet i CommonJS kommer tree shaking inte att fungera. För optimal tree shaking, använd exakta importer: import { merge } from 'lodash-es' istället för import _ from 'lodash'. Detta minskar buntstorleken från 500 KB till 10 KB för en enskild funktion.

Hot Reload

Hot Reload är en teknik som möjliggör uppdatering av applikationskod utan fullständig omladdning. I React Native och Flutter uppdaterar Hot Reload den ändrade filen i farten, med bevarande av applikationens aktuella tillstånd. Detta påskyndar utvecklingen radikalt: ändringar syns inom 1–2 sekunder istället för 10–30 sekunder för en fullständig ombyggnad. Hot Reload fungerar inom Runtime: den ändrade modulen injiceras i den körande applikationen utan omstart av exekveringsmiljön.

Hot Restart är en snabb omstart av applikationen med uppdaterad kod, men utan bevarande av tillstånd. Det används när Hot Reload inte är möjligt (till exempel när inbyggd kod eller globala variabler har ändrats). Hos IT Sectr använder vi Hot Reload i alla stadier av UI-utveckling — det sparar upp till 50% av tiden på visuella justeringar.

Tabell 3. Jämförelse av byggverktyg. Webpack är den universella standarden. Metro är specialiserad för React Native. Vite och esbuild är den nya generationen fokuserad på hastighet. Rollup är det bästa valet för att publicera bibliotek.

Hot Reload (Hot Reload, Hot Restart)

Hot Reload är en teknik som uppstod inom webbutveckling (React Hot Loader, HMR — Hot Module Replacement) och övergick till mobil utveckling med Flutter och React Native. Kärnan: när en fil ändras skickar bundlern den uppdaterade modulen till den körande applikationen, som ersätter den gamla koden utan att förlora tillstånd. Till skillnad från en fullständig ombyggnad startar Hot Reload inte om Runtime — exekveringsmiljön fortsätter att fungera och den ändrade modulen ansluts dynamiskt via en mekanism som HMR eller en Reflection-liknande referensuppdatering.

Hot Reload fungerar eftersom ramverket håller widgets (Flutter) eller komponenter (React) i minnet och uppdaterar bara de ändrade delarna. Hot Restart är en grövre mekanism: den startar om applikationen helt, men är snabbare än en fullständig ombyggnad eftersom den inte omkompilerar inbyggd kod. Hos IT Sectr använder vi Hot Reload vid UI-utveckling och Hot Restart vid ändring av navigering eller tillståndshantering.