Logcat — یہ کیا ہے، لاگنگ کی سطحیں اور لاگز کے ساتھ کام

Android میں Logcat کیا ہے

Logcat ایک Android سسٹم بفر ہے جس میں تمام عمل (Linux کرنل، system_server اور ایپلیکیشنز سمیت) ایک مخصوص فارمیٹ میں پیغامات لکھتے ہیں۔ logcat ٹول، جو Android SDK میں شامل ہے، اس بفر کو پڑھتا ہے اور ریئل ٹائم میں پیغامات دکھاتا ہے۔ Android 4.1 (API 16) سے شروع ہو کر، Logcat تک رسائی محدود ہے: ایپلیکیشنز صرف اپنے لاگز پڑھ سکتی ہیں، اور سسٹم لاگز ڈیبگ رسائی کے ساتھ ADB کے ذریعے قابل رسائی ہیں۔

ہر Logcat پیغام میں پانچ فیلڈز ہوتے ہیں: تاریخ اور وقت، PID (عمل کا شناخت کنندہ)، TID (تھریڈ کا شناخت کنندہ)، لاگ کی سطح اور ٹیگ۔ فارمیٹ مقررہ ہے اور Android کے تمام ورژنز میں ایک جیسا ہے۔ یہ IDE پر انحصار کیے بغیر CI/CD پائپ لائنوں میں لاگ فلٹرنگ کے لیے grep، awk اور sed یوٹیلیٹیز کے استعمال کی اجازت دیتا ہے۔

لاگز ایک مقررہ سائز کے رنگ بفر میں محفوظ ہوتے ہیں: main کے لیے 256 KB، system کے لیے 256 KB اور events کے لیے 256 KB (Android 5+)۔ بفر کے بھر جانے پر پرانے پیغامات حذف ہو جاتے ہیں۔ ڈویلپر PROP logcat.size پراپرٹی یا ڈیوائس کے ڈویلپر آپشنز میں بفر کا سائز تبدیل کر سکتا ہے۔

لاگ کی سطحیں اور ٹیگز: Logcat پیغام کی ساخت

چھ سطحیں لاگنگ پیغام کی اہمیت کا تعین کرتی ہیں۔ Android دوسرے پلیٹ فارمز کی طرح معیاری سطحیں استعمال کرتا ہے لیکن Log کلاس میں اپنے مستقل ناموں کے ساتھ۔ صحیح سطح کا انتخاب لاگز کو مؤثر طریقے سے فلٹر کرنے اور اہم پیغامات کو ثانوی پیغامات میں دب جانے سے بچانے میں مدد کرتا ہے۔

ٹیگز: ماڈیولز کے مطابق پیغامات کی تنظیم

ٹیگ (tag) — 23 حروف تک کی ایک سٹرنگ جو پیغام کے ماخذ کی شناخت کرتی ہے۔ ٹیگ کے طور پر کلاس یا ماڈیول کا نام استعمال کرنے کی سفارش کی جاتی ہے: MainActivity، AuthManager، NetworkModule۔ یہ ایپلیکیشن کے کسی مخصوص جزو کے مطابق لاگز کو فلٹر کرنے کی اجازت دیتا ہے۔ ٹیم میں یکسانیت کے لیے، آپ علیحدہ فائل میں ٹیگ مستقل بنا سکتے ہیں یا Timber لائبریری استعمال کر سکتے ہیں، جو کلاس کے نام کی بنیاد پر خود بخود ٹیگ داخل کرتی ہے۔

کریش لاگز اور استثنیٰ اسٹیک ٹریس

جب ایک غیر ہینڈل شدہ استثنیٰ ہوتا ہے، Android خود بخود Logcat میں مکمل اسٹیک ٹریس لکھتا ہے، جس میں کلاس، طریقہ، کوڈ لائن اور کال چین کی نشاندہی ہوتی ہے۔ کریش لاگ میں استثنیٰ کی قسم (NullPointerException، RuntimeException)، پیغام اور کریش پوائنٹ سے ایپلیکیشن کے انٹری پوائنٹ تک کال کی ترتیب ہوتی ہے۔ صارفین کے آلات سے کریش لاگز کے تجزیہ کے لیے Firebase Crashlytics استعمال کیا جاتا ہے، جو اسٹیک ٹریس کو مبہم نقشے (Android کے لیے mapping.txt) کے ساتھ ہم آہنگ کرتا ہے۔

Android Studio میں Logcat: انٹرفیس، فلٹرز اور تلاش

Android Studio View → Tool Windows → Logcat (Alt + 6) کے ذریعے قابل رسائی ایک گرافیکل Logcat انٹرفیس فراہم کرتا ہے۔ Logcat ونڈو ریئل ٹائم میں اپ ڈیٹ ہوتی ہے، منسلک ڈیوائس کے تمام پیغامات دکھاتی ہے اور عام سلسلے سے مطلوبہ معلومات کو الگ کرنے کے لیے لچکدار فلٹرز ترتیب دینے کی اجازت دیتی ہے۔

سطح اور ٹیگ کے مطابق فلٹرنگ

Log Level ڈراپ ڈاؤن کم از کم سطح کے مطابق پیغامات کو فلٹر کرتا ہے: صرف انتباہات اور خرابیاں دیکھنے کے لیے WARN منتخب کریں، VERBOSE، DEBUG اور INFO کو چھپاتے ہوئے۔ تلاش کا فیلڈ پیغام کے متن یا ٹیگ کے ذریعے تلاش کرنے کی اجازت دیتا ہے — regex تعاون یافتہ ہے، جو پیٹرن کے مطابق پیغامات تلاش کرنے کے لیے آسان ہے۔

محفوظ کردہ فلٹرز

Saved Filters — Android Studio میں Logcat کی ایک طاقتور خصوصیت۔ آپ ایک فلٹر بنا سکتے ہیں جو صرف آپ کی ایپلیکیشن کے ٹیگ (tag:MyApp) اور WARN+ سطح والے پیغامات دکھاتا ہے۔ فلٹرز سیشنز کے درمیان محفوظ رہتے ہیں اور ڈراپ ڈاؤن فہرست سے دستیاب ہوتے ہیں۔ ایک سے زیادہ ماڈیولز والے پروجیکٹس کے لیے، ہر ماڈیول کے لیے علیحدہ فلٹر بنائیں۔

# ایپلیکیشن لاگز کو فلٹر کرنے کے لیے مثال کا اظہار
tag:"MyApp" level:WARN # صرف MyApp کے لیے WARN+
package:"com.mycompany" # پیکج کے تمام لاگز
-tag:"okhttp" # OkHttp کے لاگز خارج کریں

برآمد اور تجزیہ

Logcat لاگز Save to File آئیکن کے ذریعے ٹیکسٹ فائل میں برآمد کیے جا سکتے ہیں۔ یہ Jira میں ٹکٹس سے منسلک کرنے یا طویل سیشنز کا تجزیہ کرنے کے لیے مفید ہے۔ برآمد شدہ لاگ کو کسی بھی ٹیکسٹ ایڈیٹر میں کھولا جا سکتا ہے اور پیٹرن تلاش کرنے کے لیے grep لگایا جا سکتا ہے۔ فارمیٹ شدہ دیکھنے کے لیے، logcat-color یوٹیلیٹی استعمال کریں۔

ADB logcat: جدید کام کے لیے ٹرمینل کمانڈز

ADB logcat Logcat کا کنسول ورژن ہے، جو Android Debug Bridge کے ذریعے قابل رسائی ہے۔ اس کا بنیادی فائدہ CI سرورز، آٹومیشن اسکرپٹس اور Android Studio کے بغیر آلات پر چلانے کی صلاحیت ہے۔ ADB logcat GUI کی طرح تمام فلٹرز کو سپورٹ کرتا ہے، لیکن کمانڈ لائن کی لچک کے ساتھ۔

بنیادی کمانڈز

adb logcat کمانڈ بغیر آرگیومنٹس کے پورے بفر کو ریئل ٹائم میں آؤٹ پٹ کرتی ہے۔ روکنے کے لیے Ctrl+C استعمال کریں۔ -c فلیگ ریکارڈنگ شروع کرنے سے پہلے بفر کو صاف کرتا ہے — یہ اس وقت آسان ہوتا ہے جب آپ کو موجودہ ٹیسٹ کے لاگز کو پچھلے پیغامات سے الگ کرنے کی ضرورت ہو۔ -b فلیگ بفر کی قسم منتخب کرتا ہے: main، system، events، crash (Android 12+)۔

# بفر صاف کریں اور MyApp ٹیگ کے ساتھ لاگ ریکارڈنگ شروع کریں
adb logcat -c
adb logcat MyApp:D *:S

# لاگز کو فائل میں محفوظ کریں
adb logcat -d > logcat_dump.txt

# عمل PID کے مطابق فلٹرنگ
adb logcat --pid=12345

grep اور awk کے ساتھ فلٹرنگ

ADB کو Unix یوٹیلیٹیز کے ساتھ ملانا زیادہ سے زیادہ لچک دیتا ہے۔ مثال کے طور پر، فلٹر "*:S TAG:D" صرف TAG ٹیگ والے DEBUG سطح اور اس سے اوپر کے پیغامات دکھاتا ہے، باقی سب چھپاتا ہے۔ صرف استثنیات دیکھنے کے لیے grep -i exception استعمال کریں۔ خرابی کی تعدد کا تجزیہ کرنے کے لیے، ٹیگ کالم پر sort | uniq -c لگائیں۔

CI/CD میں Logcat

CI سرورز پر، Logcat UI ٹیسٹ چلانے کے دوران تشخیص جمع کرنے کے لیے استعمال ہوتا ہے۔ عام پائپ لائن: ٹیسٹ چلانے سے پہلے بفر صاف کریں، ٹیسٹ پر عملدرآمد کے بعد لاگ ڈمپ کو بلڈ آرٹیفیکٹ کے طور پر محفوظ کریں۔ اگر ٹیسٹ ناکام ہوتا ہے، تو لاگز اس بات کا تعین کر سکتے ہیں کہ ناکامی ANR، غیر ہینڈل شدہ استثنیٰ یا نیٹ ورک ٹائم آؤٹ کی وجہ سے ہوئی تھی۔

کوڈ میں لاگنگ: Log.d، Log.e اور Timber

android.util.Log کلاس — Logcat میں پیغامات لکھنے کے لیے بلٹ ان API ہے۔ Log.v، Log.d، Log.i، Log.w، Log.e اور Log.wtf ایک ٹیگ (سٹرنگ) اور ایک پیغام (سٹرنگ) یا پیغام + Throwable قبول کرتے ہیں۔ پیغامات کی فارمیٹنگ کے لیے String.format یا Kotlin سٹرنگ ٹیمپلیٹس استعمال کریں — سٹرنگ کنکٹینیشن سے بچیں، جو ہیپ میں غیر ضروری آبجیکٹ بناتا ہے۔

Timber لائبریری

Timber — Jake Wharton کی ایک مقبول لائبریری ہے جو بلٹ ان Log API کی خامیوں کو دور کرتی ہے۔ Timber خود بخود اس کلاس کے نام کی بنیاد پر ٹیگ داخل کرتی ہے جس نے لاگنگ کو کال کیا اور ہر کال میں ٹیگ پاس کرنے کی ضرورت نہیں ہوتی۔ Timber مشروط لاگنگ کو بھی سپورٹ کرتی ہے: Release بلڈ میں، Timber.v اور Timber.d کالز کو Application.onCreate میں ایک لائن سے غیر فعال کیا جا سکتا ہے۔

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // بلٹ ان Log API
        Log.d("MainActivity", "onCreate called")

        // Timber — کلاس کے نام سے خودکار ٹیگ
        Timber.d("onCreate called")
    }

    private fun loadData() {
        try {
            val result = fetchFromNetwork()
            Timber.i("Data loaded: $result")
        } catch (e: IOException) {
            Timber.e(e, "Failed to load data")
        }
    }
}

Release کے لیے مشروط لاگنگ

Release بلڈ میں Logcat بفر پر بوجھ کم کرنے اور حساس معلومات کے رساو کو روکنے کے لیے VERBOSE اور DEBUG لاگز کو غیر فعال کرنے کی سفارش کی جاتی ہے۔ Timber PlantingTree کے ذریعے اس مسئلے کو حل کرتی ہے: Debug فلیور میں DebugTree لگایا جاتا ہے (سب کچھ لاگ کرتا ہے)، Release میں — CrashReportingTree (صرف Crashlytics کے ذریعے ERROR لاگ کرتا ہے)۔ بلٹ ان Log API مشروط لاگنگ کو سپورٹ نہیں کرتی — ڈویلپر کو ہر کال کو if (BuildConfig.DEBUG) سے لپیٹنا ہوتا ہے۔