Debug dans le développement mobile — définition, modes de débogage et fonctionnement

Qu'est-ce que le mode Debug dans le développement mobile

Debug n'est pas seulement un drapeau du compilateur, mais un ensemble complet de paramètres qui rendent l'application transparente pour le développeur. En mode Debug, le compilateur ajoute une table de noms symboliques (DWARF) au fichier exécutable, qui relie le code machine aux lignes source. Sans cette table, le débogueur ne peut pas montrer quelle ligne de code est en cours d'exécution.

Débogueur (debugger) est un programme qui exécute votre application dans un environnement contrôlé. Vous pouvez suspendre l'exécution à n'importe quelle ligne (point d'arrêt), visualiser les valeurs de toutes les variables dans la portée actuelle, les modifier à la volée et continuer l'exécution. Pour les plateformes mobiles, le débogueur standard est LLDB — un composant LLVM utilisé à la fois dans Xcode et Android Studio.

Le mode Debug inclut également des vérifications supplémentaires qui sont désactivées en Release : assertions, vérifications des limites de tableaux, détecteurs de fuites mémoire et journalisation étendue. Ces vérifications ralentissent l'application mais détectent les erreurs dès les premiers stades de développement — avant que le code n'atteigne l'utilisateur.

Debug vs Release : différences clés entre les builds

La différence entre les builds Debug et Release est fondamentale : ce sont deux ensembles différents de drapeaux du compilateur, de configurations de signature et de paramètres d'empaquetage. Comprendre ces différences permet d'éviter les situations où « ça marche sur le simulateur mais pas sur un vrai appareil ».

Quand utiliser quoi

Build Debug est utilisé à toutes les étapes du développement et des tests sur les appareils locaux. Le build Release est assemblé avant l'envoi à App Store Connect ou Google Play Console. Déboguer sur un build Release est techniquement possible mais extrêmement inconfortable en raison des méthodes renommées (R8) et de l'absence de symbolication pour les journaux de crash.

Problèmes de changement de mode

Un problème courant est le code qui fonctionne en Debug mais plante en Release. La cause est un UB (comportement indéfini) dans le code que le compilateur traite différemment selon les niveaux d'optimisation. Un exemple typique : lire une variable non initialisée ou violer le strict aliasing. Pour détecter ces erreurs, utilisez un analyseur statique (Clang Static Analyzer, ktlint) avant chaque build Release.

Outils de débogage : LLDB, points d'arrêt et inspecteurs

LLDB est un débogueur haute performance basé sur LLVM, supportant C, C++, Objective-C, Swift et Kotlin/Native. LLDB fournit une interface REPL dans laquelle vous pouvez exécuter des expressions arbitraires, modifier des valeurs de variables et appeler des fonctions dans le contexte d'une application suspendue.

Points d'arrêt et leurs types

Point d'arrêt est un outil clé du débogueur. Vous placez un point sur une ligne de code, et l'application se suspend lorsque l'exécution atteint cette ligne. LLDB supporte plusieurs types de points d'arrêt : conditionnels (ne se déclenchent que si une condition est remplie), symboliques (sur appel de fonction) et à usage unique (se déclenchent une fois et sont supprimés automatiquement).

Watchpoints et inspecteurs mémoire

Watchpoint est un point d'observation des modifications d'une variable. Vous spécifiez une adresse mémoire, et le débogueur suspend l'exécution lors de toute écriture à cette adresse. Cet outil est indispensable pour trouver les courses de données et les mutations incorrectes d'objets partagés. Pour visualiser la hiérarchie UIKit, utilisez l'UIView Inspector disponible dans Xcode.

// Définir un point d'arrêt conditionnel
(lldb) breakpoint set --name "viewDidLoad" --condition "self.isViewLoaded == false"

// Watchpoint sur propriété
(lldb) watchpoint set variable self->_loadingState

// Exécuter du code dans le contexte suspendu
(lldb) expr self.view.backgroundColor = UIColor.redColor

Inspecteurs Xcode et Android Studio

Les deux IDE fournissent des inspecteurs graphiques au-dessus de LLDB. Android Studio inclut Layout Inspector (hiérarchie des vues), Network Inspector (traçage des requêtes HTTP) et Database Inspector (SQLite en temps réel). Xcode fournit Debug Memory Graph (analyse des fuites mémoire) et View Debugger (vue 3D des couches UIKit).

Débogage à distance et par Wi-Fi

À partir d'Android 11, le débogage par Wi-Fi fonctionne sans connexion USB : il suffit de scanner le code QR depuis Android Studio. iOS supporte le débogage Wi-Fi depuis Xcode 9+ — l'appareil se connecte une fois via USB, après quoi les sessions de débogage peuvent s'exécuter sur le réseau. Le débogage Wi-Fi n'est pas adapté aux serveurs CI en raison de la latence imprévisible et de la perte de paquets, donc les pipelines automatisés utilisent toujours l'USB. Cependant, pour le développement local, le débogage Wi-Fi est nettement plus pratique — le développeur n'est pas attaché à un câble et peut tester l'application sur un appareil à l'autre bout de la pièce.

Debug sur Android : Android Studio et débogage via ADB

Android Debug Bridge (ADB) est un outil universel pour interagir avec un appareil Android depuis la ligne de commande. Via ADB, vous pouvez installer une application, lancer le débogage, copier des fichiers, exécuter des commandes shell et visualiser les journaux. Android Studio utilise ADB en interne pour toutes les opérations de débogage.

Connexion du débogueur dans Android Studio

Android Studio supporte deux modes de débogage : Run (lancement normal) et Debug (lancement avec débogueur connecté). En mode Debug, vous pouvez définir des points d'arrêt directement dans l'éditeur, inspecter les variables dans la fenêtre Debug Tool et évaluer des expressions dans Evaluate Expression. Pour déboguer les processus en arrière-plan (Service, BroadcastReceiver), utilisez Attach Debugger to Android Process.

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

        // Le point d'arrêt ici suspendra l'exécution
        val button = findViewById<Button>(R.id.btn_debug)
        button.setOnClickListener {
            startDebugProcess()
        }
    }

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

Shell ADB et inspection de base de données

Les commandes shell ADB donnent accès au système de fichiers de l'appareil sans privilèges root. Vous pouvez visualiser le contenu du répertoire databases, copier le fichier .db sur votre ordinateur et l'ouvrir avec n'importe quel client SQLite. Android Studio Database Inspector automatise ce processus : vous voyez les données de la base de données en direct en temps réel et pouvez exécuter des requêtes SQL directement depuis l'IDE.

Debug sur iOS : Xcode, débogueur et diagnostic

Xcode fournit un environnement de débogage intégré basé sur LLDB. Le développeur peut exécuter l'application sur un simulateur ou un appareil physique, définir des points d'arrêt et utiliser le Debug Navigator pour contrôler les threads d'exécution. Contrairement à Android, iOS ne permet pas d'exécuter deux builds Debug simultanément sur le même appareil sans configuration spéciale.

Débogage sur simulateur et appareil

Le simulateur exécute l'application comme un processus macOS natif, offrant le cycle de débogage le plus rapide. Sur un appareil physique, le débogage s'effectue via USB ou Wi-Fi (à partir d'iOS 16), et LLDB communique avec debugserver sur l'appareil. Les performances de débogage sur l'appareil sont inférieures en raison de la bande passante limitée de l'USB 2.0, mais seul un appareil physique permet de tester des scénarios réels : notifications push, caméra, capteurs.

import UIKit

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

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

Diagnostic et rapports de crash

Xcode Organizer collecte les journaux de crash des appareils des testeurs via Crash Logs. La symbolication (conversion des adresses en noms de fonctions) nécessite le fichier .dSYM, qui est généré avec chaque build Debug. Dans un build Release, le dSYM est également créé, mais les journaux de crash de l'App Store doivent être téléchargés dans Organizer manuellement ou via le service bitcode.