Debug in der mobilen Entwicklung — Bedeutung, Debug-Modi und Funktionsweise

Was der Debug-Modus in der mobilen Entwicklung ist

Debug ist nicht nur ein Compiler-Flag, sondern eine ganze Reihe von Einstellungen, die die Anwendung für den Entwickler transparent machen. Im Debug-Modus fügt der Compiler der ausführbaren Datei eine Symboltabelle (DWARF) hinzu, die Maschinencode mit Quellzeilen verknüpft. Ohne diese Tabelle kann der Debugger nicht anzeigen, welche Codezeile gerade ausgeführt wird.

Debugger ist ein Programm, das Ihre Anwendung in einer kontrollierten Umgebung ausführt. Sie können die Ausführung an jeder Zeile anhalten (Breakpoint), die Werte aller Variablen im aktuellen Gültigkeitsbereich anzeigen, sie im laufenden Betrieb ändern und die Ausführung fortsetzen. Für mobile Plattformen ist der Standard-Debugger LLDB — eine LLVM-Komponente, die sowohl in Xcode als auch in Android Studio verwendet wird.

Der Debug-Modus beinhaltet auch zusätzliche Prüfungen, die im Release deaktiviert sind: Assertions, Array-Grenzen-Prüfungen, Speicherleck-Erkennung und erweiterte Protokollierung. Diese Prüfungen verlangsamen die Anwendung, decken aber Fehler in frühen Entwicklungsphasen auf — bevor der Code zum Benutzer gelangt.

Debug vs. Release: Hauptunterschiede der Builds

Der Unterschied zwischen Debug- und Release-Builds ist grundlegend: Es handelt sich um zwei verschiedene Sätze von Compiler-Flags, Signierungskonfigurationen und Paketierungseinstellungen. Das Verständnis dieser Unterschiede hilft, Situationen zu vermeiden, in denen es „im Simulator funktioniert, auf dem echten Gerät aber nicht“.

Wann was verwenden

Debug-Build wird in allen Phasen der Entwicklung und des Testens auf lokalen Geräten verwendet. Der Release-Build wird vor dem Einreichen an App Store Connect oder Google Play Console erstellt. Das Debuggen eines Release-Builds ist technisch möglich, aber aufgrund umbenannter Methoden (R8) und fehlender Symbolication für Absturzprotokolle äußerst umständlich.

Probleme beim Moduswechsel

Ein häufiges Problem ist Code, der im Debug-Modus funktioniert, aber im Release-Modus abstürzt. Die Ursache ist UB (undefiniertes Verhalten) in Code, den der Compiler mit verschiedenen Optimierungsstufen unterschiedlich behandelt. Ein typisches Beispiel: Lesen einer nicht initialisierten Variablen oder Verletzung von Strict Aliasing. Verwenden Sie zur Erkennung solcher Fehler vor jedem Release-Build einen statischen Analysator (Clang Static Analyzer, ktlint).

Debugging-Werkzeuge: LLDB, Haltepunkte und Inspektoren

LLDB ist ein leistungsstarker Debugger auf Basis von LLVM, der C, C++, Objective-C, Swift und Kotlin/Native unterstützt. LLDB bietet eine REPL-Schnittstelle, in der Sie beliebige Ausdrücke ausführen, Variablenwerte ändern und Funktionen im Kontext der angehaltenen Anwendung aufrufen können.

Haltepunkte und ihre Typen

Breakpoint ist ein Schlüsselwerkzeug des Debuggers. Sie setzen einen Punkt auf einer Codezeile, und die Anwendung hält an, wenn die Ausführung diese Zeile erreicht. LLDB unterstützt mehrere Breakpoint-Typen: bedingte (lösen nur bei erfüllter Bedingung aus), symbolische (bei Funktionsaufruf) und Einmal-Breakpoints (lösen einmal aus und werden automatisch entfernt).

Watchpoints und Speicherinspektoren

Watchpoint ist ein Beobachtungspunkt für Variablenänderungen. Sie geben eine Speicheradresse an, und der Debugger hält die Ausführung bei jedem Schreibzugriff auf diese Adresse an. Dieses Werkzeug ist unverzichtbar für die Suche nach Datenrennen und falschen Mutationen gemeinsamer Objekte. Verwenden Sie zum Anzeigen der UIKit-Hierarchie den UIView Inspector in Xcode.

// Bedingten Breakpoint setzen
(lldb) breakpoint set --name "viewDidLoad" --condition "self.isViewLoaded == false"

// Watchpoint auf Eigenschaft
(lldb) watchpoint set variable self->_loadingState

// Code im angehaltenen Kontext ausführen
(lldb) expr self.view.backgroundColor = UIColor.redColor

Xcode- und Android Studio-Inspektoren

Beide IDEs bieten grafische Inspektoren auf Basis von LLDB. Android Studio umfasst Layout Inspector (View-Hierarchie), Network Inspector (HTTP-Anfrageverfolgung) und Database Inspector (SQLite in Echtzeit). Xcode bietet Debug Memory Graph (Speicherleck-Analyse) und View Debugger (3D-Ansicht der UIKit-Ebenen).

Remote-Debugging und Wi-Fi-Debugging

Seit Android 11 funktioniert Debugging über Wi-Fi ohne USB-Verbindung: Einfach den QR-Code aus Android Studio scannen. iOS unterstützt Wi-Fi-Debugging seit Xcode 9+ — das Gerät wird einmal per USB verbunden, danach können Debug-Sitzungen über das Netzwerk laufen. Wi-Fi-Debugging ist aufgrund unvorhersehbarer Latenzen und Paketverluste nicht für CI-Server geeignet, daher verwenden automatisierte Pipelines immer USB. Für die lokale Entwicklung ist Wi-Fi-Debugging jedoch deutlich bequemer — der Entwickler ist nicht an ein Kabel gebunden und kann die Anwendung auf einem Gerät am anderen Ende des Raums testen.

Debug unter Android: Android Studio und ADB-Debugging

Android Debug Bridge (ADB) ist ein universelles Werkzeug zur Interaktion mit einem Android-Gerät über die Befehlszeile. Über ADB können Sie eine Anwendung installieren, das Debugging starten, Dateien kopieren, Shell-Befehle ausführen und Protokolle anzeigen. Android Studio verwendet ADB intern für alle Debugging-Operationen.

Debugger-Verbindung in Android Studio

Android Studio unterstützt zwei Debugging-Modi: Run (normaler Start) und Debug (Start mit angeschlossenem Debugger). Im Debug-Modus können Sie Breakpoints direkt im Editor setzen, Variablen im Debug Tool Window anzeigen und Ausdrücke in Evaluate Expression auswerten. Verwenden Sie Attach Debugger to Android Process zum Debuggen von Hintergrundprozessen (Service, BroadcastReceiver).

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // Breakpoint hier hält die Ausführung an
        val button = findViewById<Button>(R.id.btn_debug)
        button.setOnClickListener {
            startDebugProcess()
        }
    }

    private fun startDebugProcess() {
        val data = fetchDataFromApi()
        Log.d("Debug", "Data loaded: $data")
    }
}

ADB-Shell und Datenbankinspektion

ADB-Shell-Befehle ermöglichen Zugriff auf das Dateisystem des Geräts ohne Root-Rechte. Sie können den Inhalt des databases-Verzeichnisses anzeigen, die .db-Datei auf Ihren Computer kopieren und mit jedem SQLite-Client öffnen. Android Studio Database Inspector automatisiert diesen Prozess: Sie sehen Live-Datenbankdaten in Echtzeit und können SQL-Abfragen direkt aus der IDE ausführen.

Debug unter iOS: Xcode, Debugger und Diagnose

Xcode bietet eine integrierte Debugging-Umgebung auf Basis von LLDB. Der Entwickler kann die Anwendung auf einem Simulator oder physischen Gerät ausführen, Breakpoints setzen und den Debug Navigator zur Steuerung der Ausführungsthreads verwenden. Im Gegensatz zu Android erlaubt iOS nicht, zwei Debug-Builds gleichzeitig auf demselben Gerät ohne spezielle Konfiguration auszuführen.

Debugging im Simulator und auf dem Gerät

Der Simulator führt die Anwendung als nativen macOS-Prozess aus und bietet so den schnellsten Debugging-Zyklus. Auf einem physischen Gerät erfolgt das Debugging über USB oder Wi-Fi (ab iOS 16), und LLDB kommuniziert mit debugserver auf dem Gerät. Die Debugging-Leistung auf dem Gerät ist aufgrund der begrenzten USB-2.0-Bandbreite geringer, aber nur ein physisches Gerät ermöglicht das Testen realer Szenarien: Push-Benachrichtigungen, Kamera, Sensoren.

import UIKit

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        setupUI()
    }

    private func setupUI() {
        let label = UILabel()
        label.text = "Debug-Modus"
        label.textColor = .systemBlue
        view.addSubview(label)
    }
}

Diagnose und Absturzberichte

Xcode Organizer sammelt Absturzprotokolle von den Geräten der Tester über Crash Logs. Für die Symbolication (Umwandlung von Adressen in Funktionsnamen) wird die .dSYM-Datei benötigt, die bei jedem Debug-Build erzeugt wird. Im Release-Build wird ebenfalls dSYM erstellt, aber Absturzprotokolle aus dem App Store müssen manuell oder über den Bitcode-Dienst in den Organizer hochgeladen werden.