Background Thread in der mobilen Entwicklung: Was es ist, Aufgaben und Einsatzmöglichkeiten

Was ist ein Background Thread

Background Thread — jeder Thread in einer Anwendung, der nicht der Main Thread ist und keinen Zugriff auf die UI hat. Seine Aufgabe ist es, den Hauptthread von schweren Operationen zu entlasten, damit die Oberfläche reaktionsfähig bleibt. Das Betriebssystem verteilt die Hintergrundthreads auf die CPU-Kerne und ermöglicht so die parallele Ausführung mehrerer Aufgaben. iOS verwaltet den Thread-Pool automatisch über GCD, Android über Java Executors-Pools.

Im Gegensatz zum Main Thread, der Ereignisse sequenziell (eines nach dem anderen) verarbeitet, können Hintergrundthreads parallel ausgeführt werden, begrenzt nur durch die Anzahl der CPU-Kerne. Auf einem 8-Kern-Gerät können beispielsweise bis zu 8 parallele Hintergrundaufgaben ohne signifikante Verlangsamung ausgeführt werden. Eine übermäßige Anzahl von Threads (Hunderte) führt jedoch zu Thread Starvation — Konkurrenz um die Kerne und steigendem Overhead durch Kontextwechsel (Context Switch).

Quality of Service (QoS) — ein iOS-Mechanismus, mit dem die Priorität einer Hintergrundaufgabe angegeben werden kann. Werte: .userInteractive (höchste, fast Main Thread), .userInitiated (Benutzer erwartet ein Ergebnis), .default (Standard), .utility (Benutzer wartet nicht direkt), .background (niedrigste, für Synchronisation und Indizierung). Unter Android ist das Äquivalent Thread.setPriority() von 1 bis 10, aber Android verwendet auch cgroups zur Gruppenverwaltung von Thread-Prioritäten.

Background Thread unter iOS: GCD und DispatchQueue.global

DispatchQueue.global(qos:) — die primäre Methode, um eine Hintergrundwarteschlange unter iOS zu erhalten. GCD (Grand Central Dispatch) erstellt automatisch einen Thread-Pool und verteilt Aufgaben auf die Kerne. Der Aufruf DispatchQueue.global(qos: .background).async {} sendet einen Block an die Hintergrundwarteschlange mit der niedrigsten Priorität. Für Aufgaben, deren Ergebnis sofort benötigt wird, verwenden Sie .userInitiated oder .utility.

OperationQueue — eine höherwertige Abstraktion über GCD, mit der Abhängigkeiten zwischen Operationen, die maximale Anzahl gleichzeitiger Operationen (maxConcurrentOperationCount) und Prioritäten festgelegt werden können. OperationQueue ist praktisch für komplexe Multitasking-Ketten: Datei herunterladen → entpacken → im Cache speichern. Standardmäßig verwendet OperationQueue Hintergrundthreads, sofern nicht anders angegeben.

import UIKit

class ImageDownloader {

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

        // OperationQueue mit 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 Hintergrundwarteschlange mit verschiedenen QoS
    func backgroundTaskWithQoS() {
        DispatchQueue.global(qos: .userInitiated).async {
            // Hohe Priorität — Benutzer wartet auf Ergebnis
            let result = self.heavyComputation()
            DispatchQueue.main.async {
                self.showResult(result)
            }
        }
    }

    private func heavyComputation() -> String {
        Thread.sleep(forTimeInterval: 2) // Arbeit simulieren
        return "Berechnungsergebnis"
    }

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

Im Beispiel lädt die OperationQueue zwei Bilder parallel (maxConcurrentOperationCount = 2) mit Hintergrund-QoS über qualityOfService = .utility. Die GCD-Methode backgroundTaskWithQoS verwendet eine globale Warteschlange mit .userInitiated für eine Aufgabe, deren Ergebnis der Benutzer erwartet. Beide Ansätze enden mit der Rückkehr zu DispatchQueue.main, um die UI zu aktualisieren — dies ist eine zwingende Anforderung unter iOS.

Serielle vs. gleichzeitige Hintergrundwarteschlangen

GCD unterstützt zwei Arten von Warteschlangen: serielle und gleichzeitige. Serielle Warteschlangen führen Aufgaben eine nach der anderen aus — dies ist praktisch für den Zugriff auf eine gemeinsam genutzte Ressource (Datei, DB) ohne Sperren. Gleichzeitige Warteschlangen führen Aufgaben parallel aus und verteilen sie auf die verfügbaren Kerne. DispatchQueue.global ist immer gleichzeitig. Um eine serielle Warteschlange zu erstellen, verwenden Sie DispatchQueue(label: "com.app.queue").

Background Thread unter Android: Executors und Dispatchers

Android bietet mehrere Abstraktionsebenen für Hintergrundthreads. Der klassische Ansatz ist java.util.concurrent.Executors.newFixedThreadPool(n) oder Executors.newCachedThreadPool(). Der moderne Ansatz sind Kotlin Coroutines mit Dispatchers.IO (für E/A: Netzwerk, Dateien, DB) und Dispatchers.Default (für CPU-intensive Aufgaben: Sortieren, Bildverarbeitung). WorkManager ist für verzögerte und garantierte Hintergrundaufgaben.

HandlerThread — eine spezialisierte Android-Klasse zum Erstellen eines Hintergrundthreads mit eigenem Looper (Nachrichtenwarteschlange). Im Gegensatz zu Executors ermöglicht HandlerThread das Senden von Nachrichten und Runnables über einen Handler. Es wird für Operationen verwendet, die eine Warteschlange erfordern (z. B. sequenzielles DB-Schreiben). Nach der Verwendung muss quit() oder quitSafely() aufgerufen werden, um Ressourcen freizugeben.

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

class DataRepository {

    private val ioExecutor = Executors.newFixedThreadPool(4)

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

    // Moderner Ansatz über Coroutines
    suspend fun loadDataCoroutines(): String {
        return withContext(Dispatchers.IO) {
            // Dateioperation — wird im Hintergrundpool ausgeführt
            readFromFile()
        }
        // Ergebnis wird automatisch an Dispatchers.Main zurückgegeben
    }

    // CPU-intensive Aufgabe auf Dispatchers.Default
    suspend fun processImage(pixels: IntArray): IntArray {
        return withContext(Dispatchers.Default) {
            // Sortieren, Filtern — wird auf Default-Pool ausgeführt
            pixels.sortedArray()
        }
    }

    private fun readFromFile(): String {
        Thread.sleep(1000) // Lesen aus Datei simulieren
        return "file_content"
    }

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

Das DataRepository-Beispiel zeigt die Entwicklung von Hintergrundthreads unter Android. Die Legacy-Methode loadDataLegacy verwendet Executors.newFixedThreadPool(4) mit einem Handler zur Rückkehr zum Main Thread. Die moderne loadDataCoroutines verwendet withContext(Dispatchers.IO) — die Koroutine wird während der Ausführung angehalten, ohne den Thread zu blockieren, und wird automatisch auf dem Main Thread fortgesetzt. Dispatchers.Default wird für CPU-gebundene Operationen (Sortieren, Filtern, Datentransformation) empfohlen.

Koroutinen als moderner Standard für Hintergrundaufgaben

Kotlin Coroutines — nicht nur eine Möglichkeit, mit Threads zu arbeiten, sondern ein grundlegend anderes Modell: Asynchrone Aufgaben sind nicht an einen bestimmten Thread gebunden und können ohne Blockierung angehalten werden. Das bedeutet, dass eine Koroutine im Hintergrund keinen Thread belegt, sondern ihn für andere Aufgaben freigibt. Der Suspension-Mechanismus ermöglicht die Ausführung von Hunderttausenden gleichzeitiger Aufgaben in einem Pool von 4–8 Threads ohne Thread Starvation.

Drei Hauptdispatcher: Dispatchers.Main (UI, ein Thread), Dispatchers.IO (standardmäßig 64 Threads für blockierende Operationen: Netzwerk, Dateien, DB), Dispatchers.Default (entspricht der Anzahl der CPU-Kerne, für intensive Berechnungen). Durch Kombinieren mit withContext wechselt der Entwickler zwischen Threads, ohne Callbacks zu erstellen. withContext ist eine Suspend-Funktion, die die Kontrolle erst zurückgibt, wenn die Aufgabe abgeschlossen ist.

// Koroutinen: Komposition von Hintergrundaufgaben
import kotlinx.coroutines.async
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.delay

suspend fun loadUserProfile(userId: String): UserProfile =
    coroutineScope {
        // Paralleles Laden von Daten aus verschiedenen Quellen
        val user = async(Dispatchers.IO) { fetchUser(userId) }
        val posts = async(Dispatchers.IO) { fetchPosts(userId) }
        val avatar = async(Dispatchers.Default) {
            processAvatar(fetchAvatar(userId))
        }

        // await() — wird bis zum Abschluss aller Aufgaben angehalten
        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 }

Die Funktion loadUserProfile startet drei parallele Hintergrundaufgaben über async. fetchUser und fetchPosts sind E/A-gebunden (Netzwerk) und werden auf Dispatchers.IO ausgeführt. processAvatar ist CPU-gebunden (Bildverarbeitung) und wird auf Dispatchers.Default ausgeführt. await() hält die Koroutine an, bis alle Aufgaben abgeschlossen sind. Die Gesamtausführungszeit entspricht der maximalen Zeit der drei Aufgaben (500 ms für fetchPosts), nicht deren Summe. Dies ist ein entscheidender Vorteil von Koroutinen gegenüber sequenzieller Ausführung.

Strukturierte Nebenläufigkeit: Vermeidung von Lecks

Structured Concurrency — ein Prinzip, bei dem jede Koroutine einen Elternbereich hat und das Abbrechen des Elternteils automatisch die Kind-Koroutinen abbricht. Unter Android bricht lifecycleScope alle Koroutinen ab, wenn die Activity zerstört wird. viewModelScope tut dies beim Bereinigen des ViewModel. Dies verhindert Lecks von Hintergrundaufgaben: Wenn der Benutzer den Bildschirm schließt, wird die Koroutine im Hintergrund keine Daten mehr laden, die nicht mehr benötigt werden.

// WorkManager mit Koroutinen
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 {
        // Wird auf Dispatchers.Default ausgeführt (standardmäßig)
        return withContext(Dispatchers.IO) {
            try {
                syncDataToServer()
                Result.success()
            } catch (e: Exception) {
                if (runAttemptCount < 3) Result.retry() else Result.failure()
            }
        }
    }

    private suspend fun syncDataToServer() {
        // Synchronisationssimulation
        delay(1000)
    }
}

// Starten einer WorkManager-Aufgabe mit Einschränkungen
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)
}