موبائل ڈیولپمنٹ میں Debug — یہ کیا ہے، ڈیبگ موڈز اور یہ کیسے کام کرتا ہے

موبائل ڈیولپمنٹ میں Debug موڈ کیا ہے

Debug صرف ایک کمپائلر فلیگ نہیں ہے بلکہ سیٹنگز کا ایک مکمل سیٹ ہے جو ایپلیکیشن کو ڈیولپر کے لیے شفاف بناتا ہے۔ Debug موڈ میں، کمپائلر ایگزیکیوٹیبل فائل میں علامتی ناموں کی ایک جدول (DWARF) شامل کرتا ہے، جو مشین کوڈ کو سورس لائنوں سے جوڑتی ہے۔ اس جدول کے بغیر، ڈیبگر یہ نہیں دکھا سکتا کہ اس وقت کوڈ کی کون سی لائن چل رہی ہے۔

ڈیبگر (debugger) ایک پروگرام ہے جو آپ کی ایپلیکیشن کو کنٹرول شدہ ماحول میں چلاتا ہے۔ آپ کسی بھی لائن پر عمل روک سکتے ہیں (بریک پوائنٹ)، موجودہ دائرہ کار میں تمام متغیرات کی قدریں دیکھ سکتے ہیں، انہیں چلتے چلتے تبدیل کر سکتے ہیں اور عمل جاری رکھ سکتے ہیں۔ موبائل پلیٹ فارمز کے لیے معیاری ڈیبگر LLDB ہے — Xcode اور Android Studio دونوں میں استعمال ہونے والا LLVM جز۔

Debug موڈ میں اضافی جانچیں بھی شامل ہیں جو Release میں غیر فعال ہوتی ہیں: دعوے (assertions)، صفوں کی حدوں کی جانچ، میموری لیک ڈیٹیکٹر اور وسیع لاگنگ۔ یہ جانچیں ایپلیکیشن کو سست کرتی ہیں لیکن ڈیولپمنٹ کے ابتدائی مراحل میں غلطیاں پکڑتی ہیں — کوڈ صارف تک پہنچنے سے پہلے۔

Debug اور Release: بلڈز کے اہم فرق

Debug اور Release بلڈز کے درمیان فرق بنیادی ہے: یہ کمپائلر فلیگز، دستخط کنفیگریشنز اور پیکیجنگ سیٹنگز کے دو مختلف سیٹ ہیں۔ ان فرقوں کو سمجھنا “سیمیولیٹر میں کام کرتا ہے لیکن اصلی ڈیوائس پر نہیں” جیسی صورتوں سے بچنے میں مدد کرتا ہے۔

کب کیا استعمال کریں

Debug بلڈ ڈیولپمنٹ اور مقامی ڈیوائسز پر جانچ کے تمام مراحل میں استعمال ہوتا ہے۔ Release بلڈ App Store Connect یا Google Play Console پر بھیجنے سے پہلے بنایا جاتا ہے۔ Release بلڈ پر ڈیبگنگ تکنیکی طور پر ممکن ہے لیکن نام تبدیل شدہ طریقوں (R8) اور کریش لاگز کے لیے symbolication کی کمی کی وجہ سے انتہائی غیر آرام دہ ہے۔

موڈ تبدیل کرنے کے مسائل

ایک عام مسئلہ وہ کوڈ ہے جو Debug میں کام کرتا ہے لیکن Release میں کریش ہوتا ہے۔ وجہ کوڈ میں UB (غیر متعین رویہ) ہے جسے کمپائلر مختلف آپٹیمائزیشن لیولز پر مختلف طریقے سے سنبھالتا ہے۔ ایک عام مثال: غیر ابتدائی شدہ متغیر پڑھنا یا strict aliasing کی خلاف ورزی۔ ایسی غلطیوں کا پتہ لگانے کے لیے، ہر Release بلڈ سے پہلے ایک جامد تجزیہ کار (Clang Static Analyzer، ktlint) استعمال کریں۔

ڈیبگنگ ٹولز: LLDB، بریک پوائنٹس اور انسپکٹرز

LLDB LLVM پر مبنی ایک اعلیٰ کارکردگی والا ڈیبگر ہے، جو C، C++، Objective-C، Swift اور Kotlin/Native کو سپورٹ کرتا ہے۔ LLDB ایک REPL انٹرفیس فراہم کرتا ہے جس میں آپ صوابدیدی ایکسپریشنز چلا سکتے ہیں، متغیرات کی قدریں تبدیل کر سکتے ہیں اور روکی گئی ایپلیکیشن کے سیاق و سباق میں فنکشنز کال کر سکتے ہیں۔

بریک پوائنٹس اور ان کی اقسام

بریک پوائنٹ ڈیبگر کا ایک اہم ٹول ہے۔ آپ کوڈ کی ایک لائن پر ایک نقطہ سیٹ کرتے ہیں، اور جب عمل اس لائن تک پہنچتا ہے تو ایپلیکیشن رک جاتی ہے۔ LLDB کئی اقسام کے بریک پوائنٹس کو سپورٹ کرتا ہے: مشروط (صرف شرط پوری ہونے پر فعال)، علامتی (فنکشن کال پر) اور ایک بار استعمال (ایک بار فعال ہو کر خود بخود ہٹا دیے جاتے ہیں)۔

واچ پوائنٹس اور میموری انسپکٹرز

واچ پوائنٹ متغیر کی تبدیلی کا مشاہدہ کرنے کا نقطہ ہے۔ آپ ایک میموری ایڈریس بتاتے ہیں، اور ڈیبگر اس ایڈریس پر کسی بھی تحریر پر عمل روک دیتا ہے۔ یہ ٹول ڈیٹا ریس اور مشترکہ اشیاء کی غلط تبدیلیاں تلاش کرنے میں ناگزیر ہے۔ UIKit درجہ بندی دیکھنے کے لیے، Xcode میں دستیاب UIView Inspector استعمال کریں۔

// مشروط بریک پوائنٹ سیٹ کرنا
(lldb) breakpoint set --name "viewDidLoad" --condition "self.isViewLoaded == false"

// پراپرٹی پر واچ پوائنٹ
(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 (UIKit پرتوں کا 3D منظر) فراہم کرتا ہے۔

ریموٹ ڈیبگنگ اور Wi-Fi ڈیبگنگ

Android 11 سے شروع کرتے ہوئے، Wi-Fi پر ڈیبگنگ USB کنکشن کے بغیر کام کرتی ہے: بس Android Studio سے QR کوڈ اسکین کریں۔ iOS Xcode 9+ سے Wi-Fi ڈیبگنگ کو سپورٹ کرتا ہے — ڈیوائس ایک بار USB کے ذریعے منسلک ہوتی ہے، جس کے بعد ڈیبگ سیشن نیٹ ورک پر چل سکتے ہیں۔ Wi-Fi ڈیبگنگ غیر متوقع تاخیر اور پیکٹ کے نقصان کی وجہ سے CI سرورز کے لیے موزوں نہیں ہے، اس لیے خودکار پائپ لائنیں ہمیشہ USB استعمال کرتی ہیں۔ تاہم، مقامی ڈیولپمنٹ کے لیے، Wi-Fi ڈیبگنگ نمایاں طور پر زیادہ آسان ہے — ڈیولپر کیبل سے بندھا نہیں ہوتا اور کمرے کے دوسرے سرے پر موجود ڈیوائس پر ایپلیکیشن ٹیسٹ کر سکتا ہے۔

Android پر Debug: Android Studio اور ADB ڈیبگنگ

Android Debug Bridge (ADB) کمانڈ لائن سے Android ڈیوائس کے ساتھ تعامل کے لیے ایک عالمگیر ٹول ہے۔ ADB کے ذریعے آپ ایپلیکیشن انسٹال کر سکتے ہیں، ڈیبگنگ شروع کر سکتے ہیں، فائلیں کاپی کر سکتے ہیں، shell کمانڈز چلا سکتے ہیں اور لاگز دیکھ سکتے ہیں۔ Android Studio تمام ڈیبگنگ کارروائیوں کے لیے ADB استعمال کرتا ہے۔

Android Studio میں ڈیبگر منسلک کرنا

Android Studio دو ڈیبگنگ موڈز کو سپورٹ کرتا ہے: Run (عام لانچ) اور Debug (ڈیبگر منسلک کر کے لانچ)۔ Debug موڈ میں آپ براہ راست ایڈیٹر میں بریک پوائنٹس سیٹ کر سکتے ہیں، 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)

        // یہاں بریک پوائنٹ عمل روک دے گا
        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 کمانڈز روٹ مراعات کے بغیر ڈیوائس فائل سسٹم تک رسائی فراہم کرتی ہیں۔ آپ databases ڈائریکٹری کا مواد دیکھ سکتے ہیں، .db فائل کو اپنے کمپیوٹر پر کاپی کر سکتے ہیں اور کسی بھی SQLite کلائنٹ سے کھول سکتے ہیں۔ Android Studio Database Inspector اس عمل کو خودکار کرتا ہے: آپ ریئل ٹائم میں لائیو ڈیٹابیس ڈیٹا دیکھتے ہیں اور براہ راست IDE سے SQL سوالات چلا سکتے ہیں۔

iOS پر Debug: Xcode، ڈیبگر اور تشخیص

Xcode LLDB پر مبنی ایک مربوط ڈیبگنگ ماحول فراہم کرتا ہے۔ ڈیولپر سیمیولیٹر یا فزیکل ڈیوائس پر ایپلیکیشن چلا سکتا ہے، بریک پوائنٹس سیٹ کر سکتا ہے اور عمل کے دھاگوں کو کنٹرول کرنے کے لیے Debug Navigator استعمال کر سکتا ہے۔ Android کے برعکس، iOS خصوصی کنفیگریشن کے بغیر ایک ہی ڈیوائس پر ایک ساتھ دو Debug بلڈ چلانے کی اجازت نہیں دیتا۔

سیمیولیٹر اور ڈیوائس پر ڈیبگنگ

سیمیولیٹر ایپلیکیشن کو ایک مقامی macOS عمل کے طور پر چلاتا ہے، جو تیز ترین ڈیبگنگ سائیکل فراہم کرتا ہے۔ فزیکل ڈیوائس پر، ڈیبگنگ USB یا Wi-Fi (iOS 16 سے) کے ذریعے ہوتی ہے اور LLDB ڈیوائس پر debugserver کے ساتھ بات چیت کرتا ہے۔ محدود USB 2.0 بینڈوتھ کی وجہ سے ڈیوائس پر ڈیبگنگ کارکردگی کم ہے، لیکن صرف فزیکل ڈیوائس حقیقی منظرناموں کی جانچ کی اجازت دیتی ہے: پش نوٹیفیکیشن، کیمرہ، سینسرز۔

import UIKit

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

    private func setupUI() {
        let label = UILabel()
        label.text = "ڈیبگ موڈ"
        label.textColor = .systemBlue
        view.addSubview(label)
    }
}

تشخیص اور کریش رپورٹس

Xcode Organizer Crash Logs کے ذریعے ٹیسٹرز کے ڈیوائسز سے کریش لاگز جمع کرتا ہے۔ symbolication (پتوں کو فنکشن ناموں میں تبدیل کرنا) کے لیے .dSYM فائل درکار ہے، جو ہر Debug بلڈ کے ساتھ بنتی ہے۔ Release بلڈ میں بھی dSYM بنتا ہے، لیکن App Store سے کریش لاگز کو دستی طور پر یا bitcode سروس کے ذریعے Organizer میں اپ لوڈ کرنا ہوتا ہے۔