Debug în dezvoltarea mobilă — esenţa modurilor de depanare şi cum funcţionează

Esenţa modului Debug în dezvoltarea mobilă

Debug (depanare) — nu este doar un flag de compilator, ci un înTreg set de setări care fac aplicaţia transparentă pentru dezvoltator. În modul Debug, compilatorul adaugă în fişierul executabil un tabel de nume simbolice (DWARF) care leagă codul maşină de liniile sursă originale. Fără acest tabel, debuggerul nu poate arăta care linie de cod se execută în momentul curent.

Debuggerul — un program care rulează aplicaţia într-un mediu controlat. Puteţi suspenda execuţia pe orice linie (breakpoint), vizualiza valorile tuturor variabilelor din domeniul curent de vizibilitate, să le modificaţi în zbor şi să continuaţi execuţia. Pentru platformele mobile, debuggerul standard este LLDB — componenta LLVM, folosită atât în Xcode, cât şi în Android Studio.

Modul Debug activează şi verificări suplimentare care sunt dezactivate în Release: aserţiuni (assertions), verificarea limitelor tablourilor, detectoarele de scurgeri de memorie şi logare extinsă. Aceste verificări încetinesc aplicaţia, dar depistează erorile în etapele incipiente de dezvoltare — înainte ca codul să ajungă la utilizator.

Debug şi Release: diferenţele cheie ale build-urilor

Diferenţa între build-urile Debug şi Release este fundamentală: sunt două seturi diferite de flaguri de compilator, configuraţii de semnare şi setări de ambalare. Înţelegerea acestor diferenţe ajută la evitarea situaţiilor de tip „funcţionează în simulator, dar pe dispozitiv real — nu”.

Când să folosiţi ce

Build-ul Debug este folosit în toate etapele de dezvoltare şi testare pe dispozitive locale. Build-ul Release este construit înainte de trimiterea la App Store Connect sau Google Play Console. Executarea depanării pe build-ul Release este tehnic posibilă, dar extrem de incomodă din cauza numelor de metode redenumite (R8) şi lipsei de symbolication pentru jurnalele de crash.

Problemele comutării modurilor

Una dintre problemele frecvente este codul care funcţionează în Debug, dar că cade în Release. Cauza este UB (undefined behavior) în cod, pe care compilatorul îl procesează diferit la diferite niveluri de optimizare. Exemplu tipic: citirea unei variabile neiniţializate sau încălcarea strict aliasing. Pentru depistarea unor astfel de erori, folosiţi un analizator static (Clang Static Analyzer, ktlint) înaintea fiecărui build Release.

Instrumente de depanare: LLDB, puncte de înrerupere şi inspectori

LLDB — este un debugger de înaltă performanţă bazat pe LLVM, care suportă C, C++, Objective-C, Swift şi Kotlin/Native. LLDB oferă o interfaţă REPL în care puteţi executa expresii arbitrare, modifica valorile variabilelor şi apela funcţii în contextul aplicaţiei oprite.

Puncte de înrerupere şi tipurile lor

Breakpoint — instrumentul cheie al debuggerului. Plasaţi un punct pe o linie de cod, iar aplicaţia se opreşte când execuţia ajunge la acea linie. LLDB suportă mai multe tipuri de puncte: condiţionale (se activează doar la îndeplinirea unei condiţii), simbolice (la apelul unei funcţii) şi de unică folosinţă (se activează o dată şi se şterg automat).

Watchpoint-uri şi inspectori de memorie

Watchpoint — punct de observare a modificării unei variabile. Indicaţi o adresă de memorie, iar debuggerul opreşte execuţia la orice scriere în acea adresă. Acest instrument este indispensabil la căutarea condiţiilor de cursă şi a mutaţiilor incorecte ale obiectelor partajate. Pentru vizualizarea ierarhiei UIKit, folosiţi UIView Inspector disponibil în Xcode.

// Setarea breakpoint-ului condiţional
(lldb) breakpoint set --name "viewDidLoad" --condition "self.isViewLoaded == false"

// Watchpoint pe proprietate
(lldb) watchpoint set variable self->_loadingState

// Executarea codului în contextul opririi
(lldb) expr self.view.backgroundColor = UIColor.redColor

Inspectorii Xcode şi Android Studio

Ambele IDE oferă inspectori grafici bazaţi pe LLDB. Android Studio include Layout Inspector (vizualizarea ierarhiei View), Network Inspector (trasarea cererilor HTTP) şi Database Inspector (SQLite în timp real). Xcode oferă Debug Memory Graph (analiza scurgerilor de memorie) şi View Debugger (vizualizarea 3D a straturilor UIKit).

Depanarea la distanţă şi depanarea prin Wi-Fi

Încând cu Android 11, depanarea prin Wi-Fi funcţionează fără conexiune USB: este suficient să scanaţi codul QR din Android Studio. iOS suportă depanarea prin Wi-Fi de la Xcode 9+ — dispozitivul se conectează o dată prin USB, după care sesiunile de depanare pot avea loc prin reţea. Pentru serverele CI, depanarea prin Wi-Fi nu este potrivită din cauza întârzierilor imprevizibile şi a pierderii de pachete, de aceea în pipeline-urile automatizate se foloseşte întotdeauna USB. Cu toate acestea, pentru dezvoltarea locală, depanarea prin Wi-Fi este mult mai comodă — dezvoltatorul nu este legat de cablu şi poate testa aplicaţia pe un dispozitiv aflat în cealaltă parte a camerei.

Debug pe Android: Android Studio şi depanare prin ADB

Android Debug Bridge (ADB) — instrument universal pentru interacţiunea cu dispozitivul Android din linia de comandă. Prin ADB puteţi instala aplicaţia, lansa depanarea, copia fişiere, executa comenzi shell şi vizualiza jurnale. Android Studio foloseşte ADB în culise pentru toate operaţiunile de depanare.

Conectarea debuggerului în Android Studio

Android Studio suportă două moduri de depanare: Run (pornire normală) şi Debug (pornire cu debugger conectat). În modul Debug puteţi seta breakpoint-uri direct în editor, vizualiza variabilele în Debug Tool Window şi evalua expresii în Evaluate Expression. Pentru depanarea proceselor de fundal (Service, BroadcastReceiver) folosiţi Attach Debugger to Android Process.

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

        // Breakpoint-ul aici va suspenda execuţia
        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 şi inspectarea bazelor de date

Comenzile ADB shell oferă acces la sistemul de fişiere al dispozitivului fără drepturi root. Puteţi vizualiza conţinutul directorului databases, copia fişierul .db pe computer şi îl deschideţi cu orice client SQLite. Android Studio Database Inspector automatizează acest proces: vedeţi datele live ale bazei în timp real şi puteţi executa interogări SQL direct din IDE.

Debug pe iOS: Xcode, debugger şi diagnosticare

Xcode oferă un mediu integrat de depanare bazat pe LLDB. Dezvoltatorul poate rula aplicaţia pe simulator sau dispozitiv fizic, seta breakpoint-uri şi folosi Debug Navigator pentru controlul fluxurilor de execuţie. Spre deosebire de Android, iOS nu permite rularea a două build-uri Debug simultan pe acelaşi dispozitiv fără o configuraţie specială.

Depanarea în simulator şi pe dispozitiv

Simulatorul rulează aplicaţia ca proces nativ macOS, ceea ce oferă cel mai rapid ciclu de depanare. Pe dispozitivul fizic, depanarea are loc prin USB sau Wi-Fi (încând cu iOS 16), iar LLDB comunică cu debugserver pe dispozitiv. Performanţa depanării pe dispozitiv este mai scăzută din cauza lăţimii de bandă limitate USB 2.0, dar numai dispozitivul fizic permite testarea scenariilor reale: notificări push, cameră, senzori.

import UIKit

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

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

Diagnosticare şi rapoarte de crash

Xcode Organizer colectează jurnalele de crash de pe dispozitivele testerilor prin Crash Logs. Pentru symbolication (conversia adreselor în nume de funcţii) este necesar fişierul .dSYM, care este generat la fiecare build Debug. În build-ul Release, dSYM este de asemenea creat, dar jurnalele de crash din App Store trebuie încărcate în Organizer manual sau prin serviciul bitcode.