Debug a mobilfejlesztésben — a hibakeresési módok lényege és működése

A Debug mód lényege a mobilfejlesztésben

Debug (hibakeresés) — nem csupán egy fordítói kapcsoló, hanem a beállítások egész sorozata, amely átláthatóvá teszi az alkalmazást a fejlesztő számára. Debug módban a fordító hozzáad egy szimbolikus névtáblát (DWARF) a futtatható fájlhoz, amely összekapcsolja a gépi kódot az eredeti forrássorokkal. E tábla nélkül a debugger nem tudja megmutatni, melyik kódsor hajtódik éppen végre.

Debugger — program, amely az alkalmazást ellenőrzött környezetben futtatja. Megállíthatja a végrehajtást bármelyik sorban (breakpoint), megtekintheti az összes változó értékét az aktuális láthatósági tartományban, menet közben módosíthatja őket és folytathatja a végrehajtást. A mobil platformok számára a szabványos debugger az LLDB — egy LLVM összetevő, amelyet mind az Xcode-ban, mind az Android Studio-ban használnak.

A Debug mód továbbá bekapcsol további ellenőrzéseket, amelyek a Release-ben ki vannak kapcsolva: ellenőrzések (assertions), tömbhatár-ellenőrzések, memóriaszivárgás-érzékelők és kiterjesztett naplózás. Ezek az ellenőrzések lassítják az alkalmazást, de a fejlesztés korai szakaszaiban feltárják a hibákat — mielőtt a kód a felhasználóhoz érkezne.

Debug és Release: a buildek fő különbségei

A különbség a Debug és Release buildek között alapvető: ez két különböző fordítói kapcsolókészlet, aláírási konfiguráció és csomagolási beállítás. E különbségek megértése segít elkerülni az olyan helyzeteket, amikor „működik a szimulátorban, de valódi eszközön — nem”.

Mikor mit használjunk

Debug build használatos a fejlesztés és tesztelés minden szakaszaiban helyi eszközökön. Release build az App Store Connect vagy Google Play Console küldése előtt készül. A hibakeresés Release builden technikailag lehetséges, de rendkívül kényelmetlen az átnevezett metódusok (R8) és a szimbolizáció (symbolication) hiánya miatt a crash naplókhoz.

A módok váltásának problémái

Az egyik gyakori probléma a kód, ami Debug-ban működik, de Release-ben összeomlik. Az ok UB (undefined behavior) a kódban, amit a fordító eltérően kezel különböző optimalizálási szinteken. Tipikus példa: inicializálatlan változó olvasása vagy strict aliasing megsértése. Az ilyen hibák feltárásához használjon statikus elemzőt (Clang Static Analyzer, ktlint) minden Release build előtt.

Hibakeresési eszközök: LLDB, töréspontok és ellenőrzők

LLDB — egy nagy teljesítményű debugger LLVM alapokon, amely támogatja a C, C++, Objective-C, Swift és Kotlin/Native nyelveket. Az LLDB REPL interfészt biztosít, amelyben tetszőleges kifejezéseket hajthat végre, változóértékeket módosíthat és függvényeket hívhat a megállított alkalmazás kontextusában.

Töréspontok és típusaik

Breakpoint — a debugger kulcsfontosságú eszköze. Pontot helyez el egy kódsoron, és az alkalmazás megáll, amikor a végrehajtás eléri ezt a sort. Az LLDB több típusú pontot támogat: feltételes (csak a feltétel teljesülésekor aktiválódik), szimbolikus (függvényhíváskor) és egyszer használatos (egyszer aktiválódik és automatikusan törlődik).

Watchpoint-ok és memóriaellenőrzők

Watchpoint — egy változó változásának megfigyelési pontja. Megad egy memóriacímet, és a debugger megállítja a végrehajtást minden íráskor arra a címre. Ez az eszköz nélkülözhetetlen az adatversenyek és a megosztott objektumok helytelen módosításainak keresésében. A UIKit hierarchia megtekintéséhez használja az Xcode-ban elérhető UIView Inspector-t.

// Feltételes breakpoint beállítása
(lldb) breakpoint set --name "viewDidLoad" --condition "self.isViewLoaded == false"

// Watchpoint tulajdonságra
(lldb) watchpoint set variable self->_loadingState

// Kód végrehajtása a megállás kontextusában
(lldb) expr self.view.backgroundColor = UIColor.redColor

Xcode és Android Studio ellenőrzők

Mindkét IDE grafikus ellenőrzőket biztosít az LLDB tetején. Az Android Studio tartalmaz Layout Inspector-t (View hierarchia megtekintése), Network Inspector-t (HTTP kérések nyomon követése) és Database Inspector-t (valós idejű SQLite). Az Xcode Debug Memory Graph-ot (memóriaszivárgás elemzése) és View Debugger-t (UIKit rétegek 3D nézete) biztosít.

Távoli hibakeresés és hibakeresés Wi-Fi-n keresztül

Android 11-től kezdve a Wi-Fi-n keresztül történő hibakeresés USB csatlakozás nélkül működik: elég beolvasni a QR kódot az Android Studio-ból. Az iOS támogatja a Wi-Fi hibakeresést Xcode 9+-tól — az eszköz egyszer csatlakozik USB-n keresztül, majd a debug munkamenetek a hálózaton keresztül zajlhatnak. CI szerverekhez a Wi-Fi hibakeresés nem alkalmas a kiszámíthatatlan késleltetések és csomagvesztés miatt, ezért az automatizált pipeline-okban mindig USB-t használnak. Helyi fejlesztéshez azonban a Wi-Fi hibakeresés lényegesen kényelmesebb — a fejlesztő nincs kábelhez kötve, és tesztelheti az alkalmazást a szoba másik végén lévő eszközön.

Debug Androidon: Android Studio és hibakeresés ADB-n keresztül

Android Debug Bridge (ADB) — univerzális eszköz az Android eszközzel való interakcióhoz parancssorból. Az ADB-n keresztül telepítheti az alkalmazást, elindíthatja a hibakeresést, másolhat fájlokat, hajthat végre shell parancsokat és tekinthet meg naplókat. Az Android Studio az ADB-t használja a háttérben minden hibakeresési művelethez.

Debugger csatlakoztatása az Android Studio-ban

Android Studio két hibakeresési módot támogat: Run (normál indítás) és Debug (indítás csatlakoztatott debuggerrel). Debug módban közvetlenül a szerkesztőben állíthat be breakpointokat, tekintheti meg a változókat a Debug Tool Window-ban és értékelhet kifejezéseket az Evaluate Expression-ben. Háttérfolyamatok (Service, BroadcastReceiver) hibakereséséhez használja az Attach Debugger to Android Process funkciót.

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

        // Breakpoint itt felfüggeszti a végrehajtást
        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 és adatbázis vizsgálat

ADB shell parancsok hozzáférést biztosítanak az eszköz fájlrendszeréhez root jogosultságok nélkül. Megtekintheti a databases könyvtár tartalmát, másolhatja a .db fájlt a számítógépre és megnyithatja bármely SQLite klienssel. Az Android Studio Database Inspector automatizálja ezt a folyamatot: valós időben látja az adatbázis élő adatait és közvetlenül az IDE-ből hajthat végre SQL lekérdezéseket.

Debug iOS-en: Xcode, debugger és diagnosztika

Xcode integrált hibakeresési környezetet biztosít LLDB alapokon. A fejlesztő elindíthatja az alkalmazást szimulátoron vagy fizikai eszközön, beállíthat breakpointokat és használhatja a Debug Navigator-t a végrehajtási szálak vezérléséhez. Az Androidtól eltérően az iOS nem engedélyezi két Debug build egyidejű futtatását egy eszközön különleges konfiguráció nélkül.

Hibakeresés szimulátorban és eszközön

A szimulátor az alkalmazást natív macOS folyamatként futtatja, ami a leggyorsabb hibakeresési ciklust biztosítja. Fizikai eszközön a hibakeresés USB-n vagy Wi-Fi-n keresztül történik (iOS 16-tól), és az LLDB a debugserver-rel kommunikál az eszközön. A hibakeresés teljesítménye eszközön alacsonyabb az USB 2.0 korlátozott sávszélessége miatt, de csak a fizikai eszköz teszi lehetővé a valós forgatókönyvek tesztelését: push értesítések, kamera, érzékelők.

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)
    }
}

Diagnosztika és crash jelentések

Xcode Organizer összegyűjti a crash naplókat a tesztelők eszközeiről a Crash Logs segítségével. A szimbolizációhoz (címek konvertálása függvénynevekké) .dSYM fájl szükséges, amely minden Debug buildnél létrejön. Release buildben is létrejőn a dSYM, de az App Store-ból származó crash naplókat kézzel kell betölteni az Organizer-be vagy a bitcode szolgáltatáson keresztül.