Debug у мобільній розробці — суть, режими налагодження та як працює

Суть Debug режиму в мобільній розробці

Debug — це не просто прапорець компілятора, а цілий набір налаштувань, які роблять додаток прозорим для розробника. У Debug-режимі компілятор додає до виконуваного файлу таблицю символьних імен (DWARF), яка пов'язує машинний код із вихідними рядками. Без цієї таблиці налагоджувач не може показати, який рядок коду виконується в поточний момент.

Налагоджувач (debugger) — програма, яка запускає ваш додаток у контрольованому середовищі. Ви можете призупинити виконання на будь-якому рядку (breakpoint), переглянути значення всіх змінних у поточній області видимості, змінити їх на льоту та продовжити виконання. Для мобільних платформ стандартним налагоджувачем є LLDB — компонент LLVM, що використовується як у Xcode, так і в Android Studio.

Debug-режим також включає додаткові перевірки, які вимкнені в Release: assertions (твердження), перевірки меж масивів, детектори витоків пам'яті та розширене логування. Ці перевірки сповільнюють роботу додатка, але виявляють помилки на ранніх етапах розробки — до того, як код потрапить до користувача.

Debug та Release: ключові відмінності збірок

Різниця між Debug та Release збірками принципова: це два різних набори прапорців компілятора, конфігурацій підпису та налаштувань пакування. Розуміння цих відмінностей допомагає уникнути ситуацій, коли «в симуляторі працює, а на реальному пристрої — ні».

Коли що використовувати

Debug-збірка використовується на всіх етапах розробки та тестування на локальних пристроях. Release-збірка збирається перед відправкою до App Store Connect або Google Play Console. Виконання налагодження на Release-збірці технічно можливе, але вкрай незручне через перейменовані методи (R8) та відсутність symbolication для краш-логів.

Проблеми перемикання режимів

Одна з частих проблем — код, який працює в Debug, але падає в Release. Причина — UB (undefined behavior) у коді, який компілятор по-різному обробляє з різними рівнями оптимізації. Типовий приклад: читання неініціалізованої змінної або порушення strict aliasing. Для виявлення таких помилок використовуйте статичний аналізатор (Clang Static Analyzer, ktlint) перед кожною Release-збіркою.

Інструменти налагодження: LLDB, точки зупину та інспектори

LLDB — це високопродуктивний налагоджувач на базі LLVM, що підтримує C, C++, Objective-C, Swift та Kotlin/Native. LLDB надає REPL-інтерфейс, у якому можна виконувати довільні вирази, змінювати значення змінних та викликати функції в контексті зупиненого додатка.

Точки зупину та їх типи

Breakpoint — ключовий інструмент налагоджувача. Ви ставите точку на рядку коду, і додаток зупиняється, коли виконання доходить до цього рядка. LLDB підтримує кілька типів точок: умовні (спрацьовують лише при виконанні умови), символьні (на виклик функції) та одноразові (спрацьовують один раз і автоматично видаляються).

Watchpoints та інспектори пам'яті

Watchpoint — точка спостереження за зміною змінної. Ви вказуєте адресу пам'яті, і налагоджувач зупиняє виконання при будь-якому записі в цю адресу. Цей інструмент незамінний при пошуку гонок даних та некоректних мутацій shared-об'єктів. Для перегляду ієрархії UIKit використовуйте UIView Inspector, доступний у Xcode.

// Встановлення умовного breakpoint
(lldb) breakpoint set --name "viewDidLoad" --condition "self.isViewLoaded == false"

// Watchpoint на властивість
(lldb) watchpoint set variable self->_loadingState

// Виконання коду в контексті зупинки
(lldb) expr self.view.backgroundColor = UIColor.redColor

Інспектори Xcode та Android Studio

Обидві IDE надають графічні інспектори поверх LLDB. Android Studio включає Layout Inspector (перегляд ієрархії View), Network Inspector (трасування HTTP-запитів) та Database Inspector (SQLite у реальному часі). Xcode надає Debug Memory Graph (аналіз витоків пам'яті) та View Debugger (3D-перегляд шарів UIKit).

Remote debugging та налагодження через Wi-Fi

Починаючи з Android 11, налагодження через Wi-Fi працює без USB-підключення: достатньо відсканувати QR-код з Android Studio. iOS підтримує Wi-Fi налагодження з Xcode 9+ — пристрій підключається один раз по USB, після чого дебаг-сесії можуть проходити по мережі. Для CI-серверів Wi-Fi налагодження не підходить через непередбачувані затримки та втрату пакетів, тому в автоматизованих пайплайнах завжди використовують USB. Втім, для локальної розробки Wi-Fi-налагодження помітно зручніше — розробник не прив'язаний до кабелю і може тестувати додаток на пристрої, що знаходиться в іншому кінці кімнати.

Debug на Android: Android Studio та налагодження через ADB

Android Debug Bridge (ADB) — універсальний інструмент для взаємодії з Android-пристроєм з командного рядка. Через ADB можна встановити додаток, запустити налагодження, скопіювати файли, виконати shell-команди та переглянути логи. Android Studio використовує ADB під капотом для всіх налагоджувальних операцій.

Підключення налагоджувача в Android Studio

Android Studio підтримує два режими налагодження: Run (звичайний запуск) та Debug (запуск з підключеним налагоджувачем). У режимі Debug ви можете встановлювати breakpoints прямо в редакторі, переглядати змінні у Debug Tool Window та оцінювати вирази в Evaluate Expression. Для налагодження фонових процесів (Service, BroadcastReceiver) використовуйте Attach Debugger to Android Process.

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

        // Breakpoint тут призупинить виконання
        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 та інспекція баз даних

Команди ADB shell дають доступ до файлової системи пристрою без root-прав. Ви можете переглянути вміст databases директорії, скопіювати .db-файл на комп'ютер і відкрити його будь-яким SQLite-клієнтом. Android Studio Database Inspector автоматизує цей процес: ви бачите живі дані бази в реальному часі та можете виконувати SQL-запити прямо з IDE.

Debug на iOS: Xcode, налагоджувач та діагностика

Xcode надає інтегроване середовище налагодження на базі LLDB. Розробник може запустити додаток на симуляторі або фізичному пристрої, встановити breakpoints та використовувати Debug Navigator для контролю потоків виконання. На відміну від Android, iOS не дозволяє запускати дві Debug-збірки одночасно на одному пристрої без спеціальної конфігурації.

Debug у симуляторі та на пристрої

Симулятор запускає додаток як native macOS-процес, що дає найшвидший цикл налагодження. На фізичному пристрої налагодження відбувається через USB або Wi-Fi (починаючи з iOS 16) і LLDB спілкується з debugserver на пристрої. Продуктивність налагодження на пристрої нижча через обмежену пропускну здатність USB 2.0, але лише фізичний пристрій дозволяє тестувати реальні сценарії: push-сповіщення, камеру, датчики.

import UIKit

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

    private func setupUI() {
        let label = UILabel()
        label.text = "Режим Debug"
        label.textColor = .systemBlue
        view.addSubview(label)
    }
}

Diagnostics та звіти про падіння

Xcode Organizer збирає краш-логи з пристроїв тестувальників через Crash Logs. Для symbolication (перетворення адрес в імена функцій) потрібен .dSYM-файл, який генерується при кожній Debug-збірці. У Release-збірці dSYM також створюється, але краш-логи з App Store потрібно завантажувати в Organizer вручну або через bitcode-сервіс.