Multithreading und Nebenläufigkeit in der mobilen Entwicklung: Was es ist, Prinzipien und wie es funktioniert

Was ist Multithreading?

Multithreading ist die Fähigkeit einer Anwendung, mehrere Codefragmente gleichzeitig auszuführen. Jedes Fragment läuft in einem separaten Thread — einem leichten Prozess mit eigenem Aufrufstapel. In der mobilen Entwicklung werden Threads in zwei Kategorien unterteilt: Main Thread (UI-Thread) und Background Threads (Hintergrundthreads).

Das Betriebssystem selbst verwaltet die Verteilung der Threads auf die Prozessorkerne. Moderne Geräte haben 6–8 Kerne, daher kann die parallele Ausführung die Arbeit tatsächlich beschleunigen. Das Erstellen von Threads ist jedoch eine teure Operation, daher wird die direkte Arbeit mit Thread nicht empfohlen. Stattdessen werden Abstraktionen höherer Ebene verwendet: DispatchQueue, OperationQueue, CoroutineDispatcher.

Nebenläufigkeit (Concurrency) ist ein breiteres Konzept als Multithreading. Nebenläufigkeit bedeutet, dass Aufgaben selbst auf einem einzelnen Kern durch Kontextwechsel "gleichzeitig" ausgeführt werden können. Asynchronität (Async/Await) ist ein Programmiermodell, bei dem eine Aufgabe keinen Thread blockiert, sondern die Kontrolle zurückgibt, während auf ein Ergebnis gewartet wird. Moderne Sprachen (Kotlin, Swift, Dart) haben integrierte Async/Await-Unterstützung.

Bei IT Sectr legen wir besonderen Wert auf eine korrekte Multithreading-Architektur zu Projektbeginn. Fehler, die in der frühen Phase gemacht werden, führen zu schwer auffindbaren Bugs: Datenrennen, Deadlocks und Anwendungsinstabilität unter Last. Jedes unserer Projekte durchläuft in der Planungsphase eine Überprüfung der Nebenläufigkeitsarchitektur.

Hauptthreads (Main/Background)

Der Main Thread (Hauptthread) — der einzige Thread in einer mobilen Anwendung, der Zugriff auf die UI hat. Auf Android heißt er UI Thread, auf iOS — Main Thread. Alle Interface-Operationen — Text ändern, Animationen, Berührungsverarbeitung — werden nur auf dem Main Thread ausgeführt. Wenn eine schwere Operation (Dateiladen, JSON-Parsing) auf dem Hauptthread ausgeführt wird, reagiert die Oberfläche nicht mehr. Auf Android führt dies zu ANR (Application Not Responding), auf iOS — zu einem "eingefrorenen" Bildschirm.

Background Threads (Hintergrundthreads) sind für alles gedacht, was nicht mit der UI zu tun hat: Netzwerkanfragen, Datenbankoperationen, Bildverarbeitung, Kryptographie. Nach Abschluss wird das Ergebnis zur Anzeige an den Main Thread übergeben. Jede Plattform bietet eigene Werkzeuge zum Wechseln zwischen Threads: DispatchQueue.main.async in iOS, runOnUiThread oder withContext(Dispatchers.Main) in Android.

RunLoop — die Ereignisverarbeitungsschleife auf dem Hauptthread von iOS. RunLoop wartet auf Ereignisse (Berührungen, Timer, Benachrichtigungen) und verteilt sie an die entsprechenden Handler. Auf Android ist das Äquivalent Looper, das mit jedem Main Thread verbunden ist. Main Looper extrahiert unendlich Nachrichten aus der Warteschlange und übergibt sie zur Verarbeitung an Handler. Das Verständnis von RunLoop und Looper hilft, Speicherlecks und "Stottern" der Oberfläche zu vermeiden.

GCD und OperationQueue (iOS)

Grand Central Dispatch (GCD) — eine Apple-Bibliothek zur Verwaltung von Multithreading auf C-Ebene. GCD arbeitet mit DispatchQueue — Aufgabenwarteschlangen. Der Entwickler erstellt keine Threads manuell; GCD verwaltet einen Thread-Pool und verteilt Aufgaben auf verfügbare Prozessorkerne. DispatchQueue gibt es in zwei Typen: Serial Queue (serielle Warteschlange — Aufgaben werden nacheinander ausgeführt) und Concurrent Queue (parallele Warteschlange — Aufgaben können gleichzeitig ausgeführt werden).

Main DispatchQueue — eine serielle Warteschlange, die an den Hauptthread gebunden ist. Global Queues sind parallele Warteschlangen mit unterschiedlichen Prioritäten (QoS — Quality of Service): userInteractive, userInitiated, utility, background. Die Wahl der richtigen QoS ist entscheidend für die Leistung: .userInteractive — für Aufgaben, die die UI beeinflussen (Animationen, Rendering); .background — für zeitunkritische Aufgaben (Synchronisation, Cache-Bereinigung).

OperationQueue — eine Abstraktion über GCD mit zusätzlichen Funktionen: Aufgaben abbrechen, Abhängigkeiten zwischen Operationen festlegen, maximale Anzahl paralleler Operationen kontrollieren. Operationen sind Objekte der Klasse Operation (oder BlockOperation). Beispiel: Wenn Sie ein Bild laden, dann einen Filter anwenden und es erst dann anzeigen müssen — OperationQueue mit Abhängigkeiten erledigt das perfekt. In GCD müssten Sie diese Schritte manuell mit DispatchGroup oder Semaphor synchronisieren.

Async/Await in Swift 5.5+ — eine moderne Alternative zu GCD. Die Schlüsselwörter async und await machen asynchronen Code linear und lesbar. Funktionen werden als async markiert, und Aufrufe werden mit await erwartet. Das System selbst verwaltet den Kontextwechsel: Standardmäßig wird eine async-Funktion in einem Hintergrundthread ausgeführt, während UI-Updates auf dem MainActor ausgeführt werden. @MainActor — ein Attribut, das die Codeausführung auf dem Hauptthread garantiert.

Coroutines und Flow (Kotlin)

Coroutines (Koroutinen) — sind leichtgewichtige Threads für Kotlin, entwickelt von JetBrains. Im Gegensatz zu normalen Threads sind Koroutinen nicht an einen bestimmten Thread gebunden. Tausende von Koroutinen können ohne nennenswerten Overhead auf mehreren Threads ausgeführt werden. CoroutineScope verwaltet den Lebenszyklus von Koroutinen: viewModelScope ist an ViewModel gebunden, lifecycleScope — an Activity/Fragment. Wenn der Bereich zerstört wird, werden alle untergeordneten Koroutinen automatisch abgebrochen.

Dispatchers bestimmen, in welchem Thread-Pool die Koroutine ausgeführt wird: Dispatchers.Main — UI-Thread; Dispatchers.IO — für Netzwerkanfragen und Plattenoperationen; Dispatchers.Default — für CPU-intensive Berechnungen. Zum Wechseln des Dispatchers wird withContext verwendet. Koroutinen unterstützen strukturierte Nebenläufigkeit: Jede Koroutine hat einen Elternknoten, und wenn der Elternknoten abgebrochen wird, werden alle untergeordneten Koroutinen abgebrochen. Dies verhindert Speicherlecks und hängende Aufgaben.

Flow — ein kalter asynchroner Datenstrom aus der Koroutinen-Bibliothek. Flow gibt Werte sequenziell aus: (1) der Produzent generiert Daten, (2) Operatoren transformieren den Strom, (3) der Kollektor konsumiert das Ergebnis. Im Gegensatz zu LiveData unterstützt Flow komplexe Operator-Ketten (map, filter, flatMapConcat, catch) und ist vollständig threadsicher. StateFlow und SharedFlow — heiße Varianten von Flow, ideal für UI-Zustand und einmalige Ereignisse (Snackbar, Navigation).

Channel — eine weitere Koroutinen-Abstraktion zum Übergeben von Daten zwischen Koroutinen. Channel funktioniert wie eine Warteschlange: ein Sender (send) und ein oder mehrere Empfänger (receive). Gepufferte Kanäle (Channel(UNLIMITED), Channel(BUFFERED)) ermöglichen die Konfiguration des Verhaltens bei Überlauf. Channel wird oft zusammen mit Flow verwendet, um callback-basierte APIs in Koroutinen zu überbrücken: callbackFlow { … }.

Bei IT Sectr verwenden wir aktiv Koroutinen und Flow in allen Android-Projekten. Dies ermöglicht das Schreiben von asynchronem Code, der synchron aussieht, leicht zu testen ist (runTest, TestDispatcher) und keine manuelle Thread-Verwaltung erfordert. Beispiel einer einfachen Koroutine mit Datenladung:

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 und Combine

Reaktive Programmierung — ein Paradigma, bei dem Daten als asynchrone Ströme (Observable, Publisher) propagiert werden. RxJava/RxKotlin — die beliebteste Implementierung für Android, portiert von .NET Rx. RxSwift — eine ähnliche Bibliothek für iOS. Hauptkomponenten: Observable (Ereignisquelle), Observer (Abonnent), Scheduler (Thread-Verwaltung), Operators (Stromtransformation).

Combine — ein Apple-Framework für reaktive Programmierung, eingeführt in iOS 13. Combine verwendet die Protokolle Publisher (Herausgeber) und Subscriber (Abonnent). Im Gegensatz zu RxSwift ist Combine in das SDK integriert und eng mit SwiftUI verbunden. Operatoren in Combine: map, filter, combineLatest, zip, debounce, throttle — decken die meisten Szenarien ab: von der Datenbindung an die UI bis zum Debounce von Suchanfragen.

Future und Promise — Muster für die Arbeit mit einem einzelnen asynchronen Ergebnis. Future stellt einen Wert dar, der später verfügbar sein wird. Promise ist ein Versprechen, einen Wert zu liefern. In Rx ist dies Single (eine erfolgreiche Antwort oder ein Fehler), in Combine — Future Publisher. In der Praxis sind Future/Promise für einzelne API-Aufrufe praktisch, während Observable/Publisher für kontinuierliche Ströme (Geolokalisierung, Texteingabe) geeignet sind.

Callback und Delegate — klassische Muster für asynchrone Operationen. Callback — eine Funktion, die als Argument übergeben und bei Abschluss der Operation aufgerufen wird. Delegate — ein Objekt, das ein Protokoll mit Ereignishandlermethoden implementiert. Nachteil: "Callback-Hölle" (verschachtelte Callbacks) und Komplexität der Fehlerbehandlung. NotificationCenter (iOS) und EventBus (Android) — Broadcast-Ereignismechanismen, nützlich für lose gekoppelte Kommunikation, führen jedoch zu impliziten Abhängigkeiten.

Multithreading-Probleme (Race Condition, Deadlock)

Multithreading öffnet die Tür zu hoher Leistung, schafft aber gleichzeitig das Risiko schwer auffindbarer Fehler. Die häufigsten: Race Condition (Wettlaufsituation), Deadlock (Verklemmung), Livelock (aktive Verklemmung) und Starvation (Aushungern). Das Verständnis dieser Probleme ist eine wesentliche Fähigkeit für jeden mobilen Entwickler.

Race Condition

Race Condition tritt auf, wenn zwei oder mehr Threads gleichzeitig dieselben Daten ohne Synchronisation lesen und schreiben. Das Ergebnis hängt davon ab, welcher Thread zuerst ausgeführt wird. Klassisches Beispiel: Zwei Threads erhöhen einen Zähler. Die Operation "lesen → erhöhen → schreiben" ist nicht atomar, daher geht bei gleichzeitiger Ausführung eine Erhöhung "verloren". Die Lösung — Verwenden Sie atomare Operationen (AtomicInteger, AtomicReference) oder Sperren (Mutex, Semaphore, synchronized).

Deadlock

Deadlock — eine Situation, in der jeder Thread eine Ressource hält und auf eine von einem anderen Thread gehaltene Ressource wartet. Kein Thread kann fortfahren. Bedingungen für das Auftreten: gegenseitiger Ausschluss, Halten und Warten, keine Vorkaufsrechte, zirkuläres Warten. Vorbeugung: eine einheitliche Reihenfolge der Sperrenerfassung festlegen, tryLock mit Timeout verwenden, Lock-Free-Algorithmen anwenden (ConcurrentHashMap, CopyOnWriteArrayList).

Livelock und Starvation

Livelock — Threads sind nicht blockiert, geben aber ständig Ressourcen aneinander weiter, ohne nützliche Arbeit zu leisten. Beispiel: Zwei Personen treffen sich in einem Korridor und beide gehen zur Seite, wobei sie sich in dieselbe Richtung bewegen. Starvation — ein Thread erhält keinen Zugriff auf eine Ressource, weil andere Threads sie ständig abfangen. Lösung: faire Sperren (Fair Locks), Thread-Prioritäten mit Vorsicht.

Synchronisationswerkzeuge

Zur Vermeidung von Multithreading-Problemen werden Synchronisationsprimitive verwendet: Mutex (gegenseitiger Ausschluss), Semaphore (Begrenzung der Anzahl gleichzeitiger Zugriffe), Lock (Schnittstelle mit tryLock), Synchronized (Sperre auf JVM-Ebene), @MainActor (Swift — Garantie der Ausführung auf dem Hauptthread). Auf Android ist auch ThreadPool über Executors.newFixedThreadPool, newCachedThreadPool verfügbar. Die manuelle Pool-Verwaltung ist jedoch Vorrecht von Legacy-Projekten; in neuen Projekten ist es besser, Koroutinen zu verwenden.