Flertrådning och Concurrency inom mobilutveckling: vad det är, principer och hur det fungerar

Vad är flertrådning?

Flertrådning är en applikations förmåga att utföra flera kodfragment samtidigt. Varje fragment körs i en separat tråd (Thread) — en lättviktsprocess med egen anropsstack. Inom mobilutveckling delas trådar in i två kategorier: Main Thread (UI-tråd) och Background Threads (bakgrundstrådar).

Operativsystemet hanterar själv fördelningen av trådar över processorkärnorna. Moderna enheter har 6–8 kärnor, så parallell exekvering kan verkligen påskynda arbetet. Att skapa trådar är dock en dyr operation, så direkt arbete med Thread rekommenderas inte. Istället används abstraktioner på högre nivå: DispatchQueue, OperationQueue, CoroutineDispatcher.

Concurrency är ett bredare begrepp än flertrådning. Concurrency innebär att uppgifter kan utföras "samtidigt" även på en enda kärna genom kontextväxling. Asynkronicitet (Async/Await) är en programmeringsmodell där en uppgift inte blockerar en tråd utan återlämnar kontrollen medan den väntar på ett resultat. Moderna språk (Kotlin, Swift, Dart) har inbyggt stöd för Async/Await.

Hos IT Sectr lägger vi särskild vikt vid korrekt flertrådningsarkitektur i början av ett projekt. Misstag som görs i ett tidigt skede leder till svårupptäckta buggar: datakapplöpningar, deadlocks och applikationsinstabilitet under belastning. Varje projekt genomgår en granskning av concurrency-arkitekturen i planeringsstadiet.

Huvudtrådar (Main/Background)

Main Thread (huvudtråden) — den enda tråden i en mobilapplikation som har åtkomst till UI. På Android kallas den UI Thread, på iOS — Main Thread. Alla gränssnittsoperationer — ändra text, animering, bearbetning av beröringar — utförs endast på Main Thread. Om en tung operation (filladdning, JSON-tolkning) utförs på huvudtråden slutar gränssnittet att svara. På Android leder detta till ANR (Application Not Responding), på iOS — till en "frusen" skärm.

Background Threads (bakgrundstrådar) är avsedda för allt som inte rör UI: nätverksförfrågningar, databasoperationer, bildbehandling, kryptografi. Efter slutförandet överförs resultatet till Main Thread för visning. Varje plattform tillhandahåller sina egna verktyg för att växla mellan trådar: DispatchQueue.main.async på iOS, runOnUiThread eller withContext(Dispatchers.Main) på Android.

RunLoop — händelsebearbetningsloopen på iOS huvudtråd. RunLoop väntar på händelser (beröringar, timer, notifieringar) och distribuerar dem till lämpliga hanterare. På Android är motsvarigheten Looper, kopplad till varje Main Thread. Main Looper extraherar oändligt meddelanden från kön och skickar dem till Handler för bearbetning. Att förstå RunLoop och Looper hjälper till att undvika minnesläckor och "stamning" i gränssnittet.

GCD och OperationQueue (iOS)

Grand Central Dispatch (GCD) — ett Apple-bibliotek för att hantera flertrådning på C-språknivå. GCD arbetar med DispatchQueue — uppgiftsköer. Utvecklaren skapar inte trådar manuellt; GCD hanterar en trådpool och distribuerar uppgifter över tillgängliga processorkärnor. DispatchQueue är av två typer: Serial Queue (seriell kö — uppgifter utförs en efter en) och Concurrent Queue (samtidig kö — uppgifter kan utföras samtidigt).

Main DispatchQueue — en seriell kö bunden till huvudtråden. Global Queues — samtidiga köer med olika prioriteter (QoS — Quality of Service): userInteractive, userInitiated, utility, background. Att välja rätt QoS är avgörande för prestanda: .userInteractive — för uppgifter som påverkar UI (animering, rendering); .background — för tidsokritiska uppgifter (synkronisering, cache rensning).

OperationQueue — en abstraktion över GCD med ytterligare funktioner: avbryta uppgifter, ställa in beroenden mellan operationer, kontrollera maximalt antal samtidiga operationer. Operationer är objekt av klassen Operation (eller BlockOperation). Exempel: om du behöver ladda en bild, sedan applicera ett filter och först därefter visa den — OperationQueue med beroenden hanterar det perfekt. I GCD skulle du behöva synkronisera dessa steg manuellt med DispatchGroup eller semafor.

Async/Await i Swift 5.5+ — ett modernt alternativ till GCD. Nyckelorden async och await gör asynkron kod linjär och läsbar. Funktioner markeras som async och anrop väntas via await. Systemet hanterar själv kontextväxling: som standard körs en async-funktion på en bakgrundstråd medan UI-uppdateringar körs på MainActor. @MainActor — ett attribut som garanterar kodkörning på huvudtråden.

Coroutines och Flow (Kotlin)

Coroutines (korutiner) — lätta trådar för Kotlin utvecklade av JetBrains. Till skillnad från vanliga trådar är korutiner inte bundna till en specifik Thread. Tusentals korutiner kan köras på flera trådar utan betydande overhead. CoroutineScope hanterar korutinernas livscykel: viewModelScope är bundet till ViewModel, lifecycleScope — till Activity/Fragment. När scopet förstörs avbryts alla underordnade korutiner automatiskt.

Dispatchers bestämmer vilken trådpool korutinen körs på: Dispatchers.Main — UI-tråd; Dispatchers.IO — för nätverksförfrågningar och diskoperationer; Dispatchers.Default — för CPU-intensiva beräkningar. För att växla dispatcher används withContext. Korutiner stöder strukturerad concurrency: varje korutin har en förälder och när föräldern avbryts avbryts alla underordnade korutiner. Detta förhindrar minnesläckor och hängande uppgifter.

Flow — en kall asynkron dataström från korutinbiblioteket. Flow avger värden sekventiellt: (1) producenten genererar data, (2) operatorer transformerar strömmen, (3) insamlaren konsumerar resultatet. Till skillnad från LiveData stöder Flow komplexa operatorkedjor (map, filter, flatMapConcat, catch) och är helt trådsäker. StateFlow och SharedFlow — heta varianter av Flow, idealiska för UI-tillstånd och engångshändelser (Snackbar, navigering).

Channel — ytterligare en korutinabstraktion för att överföra data mellan korutiner. Channel fungerar som en kö: en avsändare (send) och en eller flera mottagare (receive). Buffrade kanaler (Channel(UNLIMITED), Channel(BUFFERED)) gör det möjligt att konfigurera beteende vid överflöde. Channel används ofta tillsammans med Flow för att brygga callback-baserade API:er till korutiner: callbackFlow { … }.

Hos IT Sectr använder vi aktivt korutiner och Flow i alla Android-projekt. Detta gör det möjligt att skriva asynkron kod som ser synkron ut, är lätt att testa (runTest, TestDispatcher) och inte kräver manuell trådhantering. Exempel på en enkel korutin med dataladdning:

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUsers(): List<User> = withContext(Dispatchers.IO) {
        return@withContext try {
            val users = api.fetchUsers()
            dao.insertAll(users)
            users
        } catch (e: Exception) {
            dao.getAll()
        }
    }
}

Rx och Combine

Reaktiv programmering — ett paradigm där data sprids som asynkrona strömmar (Observable, Publisher). RxJava/RxKotlin — den mest populära implementeringen för Android, porterad från .NET Rx. RxSwift — ett liknande bibliotek för iOS. Huvudkomponenter: Observable (händelsekälla), Observer (prenumerant), Scheduler (trådhantering), Operators (strömtransformering).

Combine — ett Apple-ramverk för reaktiv programmering introducerat i iOS 13. Combine använder protokollen Publisher (utgivare) och Subscriber (prenumerant). Till skillnad från RxSwift är Combine inbyggt i SDK och nära integrerat med SwiftUI. Operatorer i Combine: map, filter, combineLatest, zip, debounce, throttle — täcker de flesta scenarier: från databindning till UI till debounce av sökfråga.

Future och Promise — mönster för att arbeta med ett enda asynkront resultat. Future representerar ett värde som kommer att vara tillgängligt senare. Promise är ett löfte om att tillhandahålla ett värde. I Rx är detta Single (ett framgångsrikt svar eller fel), i Combine — Future Publisher. I praktiken är Future/Promise bekväma för enskilda API-förfrågningar, medan Observable/Publisher — för kontinuerliga strömmar (geolokalisering, textinmatning).

Callback och Delegate — klassiska mönster för asynkrona operationer. Callback — en funktion som skickas som argument och anropas vid slutförande av operationen. Delegate — ett objekt som implementerar ett protokoll med händelsehanteringsmetoder. Nackdel: "callback hell" (nästlade callbacks) och komplexiteten i felhantering. NotificationCenter (iOS) och EventBus (Android) — sändningsmekanismer för händelser, användbara för löst kopplad kommunikation men leder till implicita beroenden.

Flertrådningsproblem (Race Condition, Deadlock)

Flertrådning öppnar dörren till hög prestanda, men skapar samtidigt risk för svårupptäckta fel. De vanligaste: Race Condition (kapplöpningsvillkor), Deadlock (låsning), Livelock (aktiv låsning) och Starvation (trådsvält). Att förstå dessa problem är en obligatorisk färdighet för varje mobilutvecklare.

Race Condition

Race Condition uppstår när två eller flera trådar samtidigt läser och skriver samma data utan synkronisering. Resultatet beror på vilken tråd som körs först. Klassiskt exempel: två trådar ökar en räknare. Operationen "läs → öka → skriv" är inte atomär, så när den utförs samtidigt "försvinner" en ökning. Lösningen — använd atomära operationer (AtomicInteger, AtomicReference) eller lås (Mutex, Semaphore, synchronized).

Deadlock

Deadlock — en situation där varje tråd håller en resurs och väntar på en resurs som hålls av en annan tråd. Ingen tråd kan fortsätta. Förutsättningar: ömsesidig uteslutning, håll och vänta, ingen förebyggande, cirkulär väntan. Förebyggande: fastställa en enhetlig ordning för låsförvärv, använda tryLock med timeout, tillämpa Lock-Free-algoritmer (ConcurrentHashMap, CopyOnWriteArrayList).

Livelock och Starvation

Livelock — trådar är inte blockerade men "passar" ständigt resurser till varandra utan att utföra nyttigt arbete. Exempel: två personer möts i en korridor och båda kliver åt sidan och rör sig i samma riktning. Starvation — en tråd får inte tillgång till en resurs eftersom andra trådar ständigt fångar upp den. Lösning: rättvisa lås (fair locks), trådprioriteringar med försiktighet.

Synkroniseringsverktyg

För att förhindra flertrådningsproblem används synkroniseringsprimitiver: Mutex (ömsesidig uteslutning), Semaphore (begränsning av antalet samtidiga åtkomster), Lock (gränssnitt med tryLock), Synchronized (lås på JVM-nivå), @MainActor (Swift — garanti för körning på huvudtråden). På Android finns även ThreadPool tillgängligt via Executors.newFixedThreadPool, newCachedThreadPool. Manuell poolhantering är dock gamla projektens prerogativ; i nya projekt är det bättre att använda korutiner.