Background Thread in mobiele ontwikkeling: wat is het, taken en gebruiksmethoden

Wat is Background Thread

Background Thread — elke thread in een app die niet de Main Thread is en geen toegang heeft tot de UI. De taak is om de hoofdthread te ontlasten van zware bewerkingen, zodat de interface responsief blijft. Het besturingssysteem verdeelt achtergrondthreads over de processorkernen, waardoor meerdere taken parallel kunnen worden uitgevoerd. iOS beheert automatisch de threadpool via GCD, Android via Java Executors-pools.

In tegenstelling tot de Main Thread, die gebeurtenissen sequentieel verwerkt (een voor een), kunnen achtergrondthreads parallel worden uitgevoerd, alleen beperkt door het aantal CPU-kernen. Op een apparaat met 8 kernen kunnen bijvoorbeeld tot 8 parallelle achtergrondtaken worden gestart zonder significante vertraging. Een overmatig aantal threads (honderden) leidt echter tot thread starvation — concurrentie om kernen en toename van overhead voor contextwisseling (context switch).

Quality of Service (QoS) — een iOS-mechanisme waarmee de prioriteit van een achtergrondtaak kan worden ingesteld. Waarden: .userInteractive (hoogste, bijna Main Thread), .userInitiated (gebruiker wacht op resultaat), .default (standaard), .utility (gebruiker wacht niet direct), .background (laagste, voor synchronisatie en indexering). In Android is het equivalent Thread.setPriority() van 1 tot 10, maar Android gebruikt ook cgroups voor groepsbeheer van threadprioriteiten.

Background Thread in iOS: GCD en DispatchQueue.global

DispatchQueue.global(qos:) — de primaire manier om een achtergrondwachtrij in iOS te verkrijgen. GCD (Grand Central Dispatch) maakt automatisch een threadpool aan en verdeelt taken over de kernen. De aanroep DispatchQueue.global(qos: .background).async {} stuurt een uitvoeringsblok naar de achtergrondwachtrij met de laagste prioriteit. Voor taken waarvan het resultaat onmiddellijk nodig is, gebruik .userInitiated of .utility.

OperationQueue — een abstractie op hoger niveau boven GCD, waarmee afhankelijkheden tussen bewerkingen, het maximum aantal gelijktijdige bewerkingen (maxConcurrentOperationCount) en prioriteiten kunnen worden ingesteld. OperationQueue is handig voor complexe multitasking-ketens: bestand downloaden -> uitpakken -> in cache opslaan. Standaard gebruikt OperationQueue achtergrondthreads, tenzij anders aangegeven.

import UIKit

class ImageDownloader {

    func downloadImagesSequentially() {
        let urls = ["https://example.com/1.png", "https://example.com/2.png"]

        // OperationQueue met maxConcurrentOperationCount = 2
        let queue = OperationQueue()
        queue.maxConcurrentOperationCount = 2
        queue.qualityOfService = .utility

        for urlString in urls {
            queue.addOperation {
                guard let url = URL(string: urlString),
                      let data = try? Data(contentsOf: url)
                else { return }

                DispatchQueue.main.async {
                    print("Geladen: \(url.lastPathComponent)")
                }
            }
        }
    }

    // GCD: globale achtergrondwachtrij met verschillende QoS
    func backgroundTaskWithQoS() {
        DispatchQueue.global(qos: .userInitiated).async {
            // Hoge prioriteit — gebruiker wacht op resultaat
            let result = self.heavyComputation()
            DispatchQueue.main.async {
                self.showResult(result)
            }
        }
    }

    private func heavyComputation() -> String {
        Thread.sleep(forTimeInterval: 2) // simulatie van werk
        return "Resultaat van berekeningen"
    }

    private func showResult(_ result: String) {
        print("Result on Main: \(result)")
    }
}

In het voorbeeld laadt OperationQueue twee afbeeldingen parallel (maxConcurrentOperationCount = 2) met achtergrond via qualityOfService = .utility. De GCD-methode backgroundTaskWithQoS gebruikt de globale wachtrij met .userInitiated voor een taak waarvan de gebruiker het resultaat verwacht. Beide benaderingen eindigen met terugkeer naar DispatchQueue.main voor UI-update — dit is een verplichte iOS-vereiste.

Serial vs Concurrent achtergrondwachtrijen

GCD ondersteunt twee typen wachtrijen: serial (sequentiëel) en concurrent (parallel). Serial wachtrijen voeren taken een voor een uit — dit is handig voor toegang tot een gedeelde bron (bestand, database) zonder vergrendelingen. Concurrent wachtrijen voeren taken parallel uit en verdelen ze over vrije kernen. DispatchQueue.global is altijd concurrent. Gebruik DispatchQueue(label: "com.app.queue") om een serial wachtrij te maken.

Background Thread in Android: Executors en Dispatchers

Android biedt verschillende abstractieniveaus voor achtergrondthreads. De klassieke benadering — java.util.concurrent.Executors.newFixedThreadPool(n) of Executors.newCachedThreadPool(). De moderne benadering — Kotlin Coroutines met Dispatchers.IO (voor invoer-uitvoer: netwerk, bestanden, database) en Dispatchers.Default (voor CPU-intensieve taken: sorteren, beeldverwerking). WorkManager — voor uitgestelde en gegarandeerde achtergrondtaken.

HandlerThread — een speciale Android-klasse voor het maken van een achtergrondthread met een eigen Looper (berichtenwachtrij). In tegenstelling tot Executors, maakt HandlerThread het mogelijk berichten en Runnable te verzenden via Handler. Het wordt gebruikt voor bewerkingen die in de wachtrij moeten worden geplaatst (bijv. sequentieel schrijven naar de database). Na gebruik moet quit() of quitSafely() worden aangeroepen om bronnen vrij te geven.

// Android: Executors en Coroutines Dispatchers
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.util.concurrent.Executors

class DataRepository {

    private val ioExecutor = Executors.newFixedThreadPool(4)

    // Klassieke benadering via Executors
    fun loadDataLegacy(callback: (String) -> Unit) {
        ioExecutor.execute {
            val result = readFromFile()
            val handler = android.os.Handler(android.os.Looper.getMainLooper())
            handler.post { callback(result) }
        }
    }

    // Moderne benadering via Coroutines
    suspend fun loadDataCoroutines(): String {
        return withContext(Dispatchers.IO) {
            // Bestandsbewerking — uitgevoerd in achtergrondpool
            readFromFile()
        }
        // Resultaat wordt automatisch teruggebracht naar Dispatchers.Main
    }

    // CPU-intensieve taak op Dispatchers.Default
    suspend fun processImage(pixels: IntArray): IntArray {
        return withContext(Dispatchers.Default) {
            // Sorteren, filteren — uitgevoerd op Default-pool
            pixels.sortedArray()
        }
    }

    private fun readFromFile(): String {
        Thread.sleep(1000) // simulatie van lezen uit bestand
        return "file_content"
    }

    fun cleanup() {
        ioExecutor.shutdown()
    }
}

Het voorbeeld DataRepository toont de evolutie van achtergrondthreads in Android. De legacy-methode loadDataLegacy gebruikt Executors.newFixedThreadPool(4) met Handler om terug te keren naar de Main Thread. De moderne loadDataCoroutines gebruikt withContext(Dispatchers.IO) — de coroutine pauzeert tijdens het werk, blokkeert de thread niet en hervat automatisch op de Main Thread. Dispatchers.Default wordt aanbevolen voor CPU-gebonden bewerkingen (sorteren, filteren, gegevenstransformatie).

Coroutines als moderne standaard voor achtergrondtaken

Kotlin Coroutines — niet zomaar een manier om met threads te werken, maar een fundamenteel ander model: asynchrone taken zijn niet gebonden aan een specifieke thread en kunnen worden onderbroken (suspend) zonder te blokkeren. Dit betekent dat tijdens achtergrondwerk de coroutine geen thread bezet, maar deze vrijmaakt voor andere taken. Het suspension-mechanisme maakt het mogelijk honderdduizenden concurrent taken uit te voeren op een pool van 4-8 threads zonder thread starvation.

Drie belangrijkste dispatchers: Dispatchers.Main (UI, één thread), Dispatchers.IO (standaard 64 threads voor blokkerende bewerkingen: netwerk, bestanden, database), Dispatchers.Default (gelijk aan het aantal CPU-kernen, voor intensieve berekeningen). Door ze te combineren via withContext, schakelt de ontwikkelaar tussen threads zonder callbacks te maken. withContext is een suspend-functie die de controle pas teruggeeft wanneer de taak is voltooid.

// Coroutines: compositie van achtergrondtaken
import kotlinx.coroutines.async
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.delay

suspend fun loadUserProfile(userId: String): UserProfile =
    coroutineScope {
        // Parallel laden van gegevens uit verschillende bronnen
        val user = async(Dispatchers.IO) { fetchUser(userId) }
        val posts = async(Dispatchers.IO) { fetchPosts(userId) }
        val avatar = async(Dispatchers.Default) {
            processAvatar(fetchAvatar(userId))
        }

        // await() — pauzeert tot voltooiing van alle taken
        UserProfile(
            user = user.await(),
            posts = posts.await(),
            avatar = avatar.await()
        )
    }

data class UserProfile(
    val user: String,
    val posts: List<String>,
    val avatar: ByteArray
)

suspend fun fetchUser(id: String): String { delay(300); return "User:$id" }
suspend fun fetchPosts(id: String): List<String> { delay(500); return listOf("Post1") }
suspend fun fetchAvatar(id: String): ByteArray { delay(200); return ByteArray(1024) }
suspend fun processAvatar(data: ByteArray): ByteArray { delay(100); return data }

De functie loadUserProfile start drie parallelle achtergrondtaken via async. fetchUser en fetchPosts zijn IO-gebonden (netwerk), uitgevoerd op Dispatchers.IO. processAvatar is CPU-gebonden (beeldverwerking), uitgevoerd op Dispatchers.Default. await() pauzeert de coroutine tot alle taken zijn voltooid. De totale uitvoeringstijd is gelijk aan de maximale tijd van de drie taken (500 ms voor fetchPosts), niet de som. Dit is het belangrijkste voordeel van coroutines ten opzichte van sequentiële uitvoering.

Structured concurrency: voorkomen van lekken

Structured concurrency — het principe waarbij elke coroutine een parent-scope heeft en het annuleren van de ouder automatisch de kind-coroutines annuleert. In Android annuleert lifecycleScope alle coroutines bij vernietiging van de Activity. viewModelScope — bij het opschonen van de ViewModel. Dit voorkomt lekken van achtergrondtaken: als de gebruiker het scherm heeft gesloten, blijft de achtergrondcoroutine geen gegevens laden die niemand meer nodig heeft.

// WorkManager met coroutines
import android.content.Context
import androidx.work.*
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext

class SyncWorker(
    appContext: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(appContext, workerParams) {

    override suspend fun doWork(): Result {
        // Uitgevoerd op Dispatchers.Default (standaard)
        return withContext(Dispatchers.IO) {
            try {
                syncDataToServer()
                Result.success()
            } catch (e: Exception) {
                if (runAttemptCount < 3) Result.retry() else Result.failure()
            }
        }
    }

    private suspend fun syncDataToServer() {
        // Simulatie van synchronisatie
        delay(1000)
    }
}

// WorkManager-taak starten met beperkingen
fun scheduleSync(context: Context) {
    val constraints = Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED)
        .setRequiresBatteryNotLow(true)
        .build()

    val syncWork = OneTimeWorkRequestBuilder<SyncWorker>()
        .setConstraints(constraints)
        .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 10, java.util.concurrent.TimeUnit.SECONDS)
        .build()

    WorkManager.getInstance(context).enqueue(syncWork)
}