Debug sa mobile development — esensya ng mga debug mode at paano ito gumagana

Esensya ng Debug mode sa mobile development

Debug (pagde-debug) — ay hindi lamang isang compiler flag, kundi isang buong hanay ng mga setting na ginagawang transparent ang app para sa developer. Sa Debug mode, ang compiler ay nagdaragdag ng table ng symbolic names (DWARF) sa executable file na nag-uugnay ng machine code sa orihinal na source lines. Kung wala ang table na ito, hindi maipakita ng debugger kung aling linya ng code ang kasalukuyang na-e-execute.

Debugger — isang program na nagpapatakbo ng iyong app sa isang kontroladong kapaligiran. Maaari mong ihinto ang execution sa anumang linya (breakpoint), tingnan ang mga halaga ng lahat ng variable sa kasalukuyang scope, baguhin ang mga ito on the fly at ipagpatuloy ang execution. Para sa mga mobile platform, ang standard debugger ay LLDB — isang LLVM component na ginagamit kapwa sa Xcode at Android Studio.

Ang Debug mode ay nag-a-activate din ng mga karagdagang pagsusuri na naka-off sa Release: assertions, pagsusuri sa mga hangganan ng array, detector ng memory leak at pinahabang logging. Ang mga pagsusuring ito ay nagpapabagal sa app ngunit nakakatuklas ng mga error sa maagang yugto ng development — bago makarating ang code sa user.

Debug at Release: pangunahing pagkakaiba ng build

Ang pagkakaiba sa pagitan ng Debug at Release build ay pangunahing: ito ay dalawang magkaibang set ng compiler flags, signing configurations at packaging settings. Ang pag-unawa sa mga pagkakaibang ito ay nakakatulong upang maiwasan ang mga sitwasyon tulad ng “gumagana sa simulator, ngunit sa totoong device — hindi”.

Kailan gagamitin ang ano

Debug build ay ginagamit sa lahat ng yugto ng development at testing sa mga lokal na device. Release build ay ginagawa bago ipadala sa App Store Connect o Google Play Console. Ang pagde-debug sa Release build ay technically posible, ngunit lubhang hindi maginhawa dahil sa mga pinalitang pangalan ng method (R8) at kawalan ng symbolication para sa crash logs.

Mga problema sa pagpapalit ng mode

Isa sa mga karaniwang problema ay code na gumagana sa Debug ngunit nabigo sa Release. Ang dahilan ay UB (undefined behavior) sa code na iba-ibang pinoproseso ng compiler sa iba't ibang antas ng optimization. Karaniwang halimbawa: pagbabasa ng hindi na-initialize na variable o paglabag sa strict aliasing. Para matukoy ang mga ganitong error, gumamit ng static analyzer (Clang Static Analyzer, ktlint) bago ang bawat Release build.

Mga tool sa pagde-debug: LLDB, breakpoint at inspector

LLDB — ay isang high-performance debugger batay sa LLVM na sumusuporta sa C, C++, Objective-C, Swift at Kotlin/Native. Ang LLDB ay nagbibigay ng REPL interface kung saan maaari kang mag-execute ng mga arbitrary expression, magbago ng mga variable value at tumawag ng mga function sa konteksto ng naka-pause na app.

Mga breakpoint at ang kanilang mga uri

Breakpoint — pangunahing tool ng debugger. Naglalagay ka ng punto sa isang linya ng code, at humihinto ang app kapag naabot ng execution ang linyang iyon. Sinusuportahan ng LLDB ang ilang uri ng punto: conditional (na-activate lang kapag natugunan ang condition), symbolic (sa function call) at one-shot (na-activate nang isang beses at awtomatikong tinatanggal).

Watchpoint at memory inspector

Watchpoint — punto ng pagmamasid sa pagbabago ng variable. Tinutukoy mo ang isang memory address, at pinipigilan ng debugger ang execution sa bawat pagsulat sa address na iyon. Ang tool na ito ay kailangang-kailangan sa paghahanap ng data races at hindi tamang mutations ng shared objects. Para tingnan ang UIKit hierarchy, gamitin ang UIView Inspector na available sa Xcode.

// Pag-set ng conditional breakpoint
(lldb) breakpoint set --name "viewDidLoad" --condition "self.isViewLoaded == false"

// Watchpoint sa property
(lldb) watchpoint set variable self->_loadingState

// Pag-execute ng code sa konteksto ng paghinto
(lldb) expr self.view.backgroundColor = UIColor.redColor

Xcode at Android Studio inspector

Parehong IDE ay nagbibigay ng graphic inspector batay sa LLDB. Ang Android Studio ay may kasamang Layout Inspector (pagtingin sa View hierarchy), Network Inspector (pagsubaybay sa HTTP requests) at Database Inspector (real-time na SQLite). Ang Xcode ay nagbibigay ng Debug Memory Graph (memory leak analysis) at View Debugger (3D view ng UIKit layers).

Remote debugging at debugging sa pamamagitan ng Wi-Fi

Mula sa Android 11, ang debugging sa pamamagitan ng Wi-Fi ay gumagana nang walang USB connection: i-scan lang ang QR code mula sa Android Studio. Sinusuportahan ng iOS ang Wi-Fi debugging mula sa Xcode 9+ — ang device ay kumokonekta nang isang beses sa pamamagitan ng USB, pagkatapos ang mga debug session ay maaaring maganap sa network. Para sa CI servers, hindi angkop ang Wi-Fi debugging dahil sa hindi mahuhulaang latency at packet loss, kaya sa automated pipelines ay palaging ginagamit ang USB. Gayunpaman, para sa local development, ang Wi-Fi debugging ay mas maginhawa — ang developer ay hindi nakatali sa cable at maaaring subukan ang app sa isang device sa kabilang dulo ng kuwarto.

Debug sa Android: Android Studio at pagde-debug sa pamamagitan ng ADB

Android Debug Bridge (ADB) — universal tool para sa pakikipag-ugnayan sa Android device mula sa command line. Sa pamamagitan ng ADB maaari kang mag-install ng app, magsimula ng debugging, kumopya ng mga file, mag-execute ng shell commands at tumingin ng logs. Ginagamit ng Android Studio ang ADB sa likod para sa lahat ng debugging operations.

Pagkonekta ng debugger sa Android Studio

Android Studio ay sumusuporta sa dalawang debug mode: Run (normal na pagpapatakbo) at Debug (pagpapatakbo na may naka-konektang debugger). Sa Debug mode, maaari kang mag-set ng breakpoints nang direkta sa editor, tumingin ng mga variable sa Debug Tool Window at mag-evaluate ng mga expression sa Evaluate Expression. Para sa debugging ng background processes (Service, BroadcastReceiver), gamitin ang Attach Debugger to Android Process.

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

        // Breakpoint dito ay magpi-pause ng execution
        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 at inspeksyon ng database

ADB shell commands ay nagbibigay ng access sa file system ng device nang walang root rights. Maaari mong tingnan ang nilalaman ng databases directory, kopyahin ang .db file sa computer at buksan ito gamit ang anumang SQLite client. Ang Android Studio Database Inspector ay nag-a-automate ng prosesong ito: nakikita mo ang live na data ng database sa real-time at maaari kang mag-execute ng SQL queries nang direkta mula sa IDE.

Debug sa iOS: Xcode, debugger at diagnostic

Xcode ay nagbibigay ng integrated debugging environment batay sa LLDB. Ang developer ay maaaring magpatakbo ng app sa simulator o pisikal na device, mag-set ng breakpoints at gumamit ng Debug Navigator para kontrolin ang execution threads. Hindi tulad ng Android, ang iOS ay hindi pinapayagan ang pagpapatakbo ng dalawang Debug build nang sabay sa isang device nang walang espesyal na configuration.

Pagde-debug sa simulator at sa device

Simulator ay nagpapatakbo ng app bilang isang native na macOS process, na nagbibigay ng pinakamabilis na debug cycle. Sa pisikal na device, ang debugging ay sa pamamagitan ng USB o Wi-Fi (mula sa iOS 16), at ang LLDB ay nakikipag-ugnayan sa debugserver sa device. Ang performance ng debugging sa device ay mas mababa dahil sa limitadong bandwidth ng USB 2.0, ngunit ang pisikal na device lamang ang nagpapahintulot sa pagsubok ng mga totoong scenario: push notification, camera, sensor.

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

Diagnostic at crash reports

Xcode Organizer ay nangongolekta ng crash logs mula sa mga device ng tester sa pamamagitan ng Crash Logs. Para sa symbolication (conversion ng mga address sa function names), kinakailangan ang .dSYM file na nabubuo sa bawat Debug build. Sa Release build, ang dSYM ay ginagawa rin, ngunit ang crash logs mula sa App Store ay kailangang i-load sa Organizer nang manu-mano o sa pamamagitan ng bitcode service.