ایپ ڈویلپمنٹ میں Log Level: تعریف، لیول کی اقسام اور کنفیگریشن

Log Level کیا ہے؟

Log Level ہر لاگ پیغام کی ایک خصوصیت ہے جو اس کی اہمیت اور پروسیسنگ کی فوری ضرورت کا تعین کرتی ہے۔ جدید iOS اور Android پلیٹ فارم 6–7 لیول کا ایک متحد پیمانہ سپورٹ کرتے ہیں: سب سے تفصیلی (Verbose/Trace) سے سنگین (Error/Assert) تک۔ لیول کا انتخاب یہ طے کرتا ہے کہ آیا پیغام موجودہ ایپلیکیشن کنفیگریشن کے تحت لاگ میں لکھا جائے گا۔

Log Level کا تصور شدت کے اہرام کے اصول پر مبنی ہے: لیول جتنا اونچا ہوگا، اس پر اتنے ہی کم پیغامات آؤٹ پٹ ہوتے ہیں۔ Semaphore CI، 2024 کے مطابق، پروڈکشن ایپلیکیشن میں تقسیم یوں ہے: Info — 60% پیغامات، Warn — 25%، Error — 10%، Debug — 5%۔ Verbose پیغامات کو پروڈکشن میں مکمل طور پر غیر فعال کر دینا چاہیے۔

ہر پلیٹ فارم Log Level کو اپنے API کے ذریعے نافذ کرتا ہے۔ Android v(), d(), i(), w(), e() طریقوں کے ساتھ android.util.Log استعمال کرتا ہے۔ Apple default, info, debug, error, fault لیول کے ساتھ OSLog استعمال کرتا ہے۔ Timber اور CocoaLumberjack جیسی لائبریریاں ان معیاری API کے اوپر اضافی فعالیت فراہم کرتی ہیں۔

Google I/O 2023 کے مطابق، غلط Log Level کا انتخاب پروڈکشن میں 40% کارکردگی کے مسائل کی وجہ ہے۔ ڈویلپر ریلیز بلڈ میں Debug لاگ چھوڑ دیتے ہیں، جس سے ڈسک پر ضرورت سے زیادہ تحریر اور بیٹری کی تیزی سے کمی ہوتی ہے۔

لاگنگ لیول کی اقسام: Verbose سے Assert تک

Verbose (TRACE) — سب سے تفصیلی لیول، صرف ڈویلپمنٹ کے لیے۔ اس لیول پر تمام درمیانی حسابات، لوپ کی تکرار اور الگورتھم کے ہر مرحلے کے نتائج آؤٹ پٹ ہوتے ہیں۔ Android پر، یہ لیول Log.v() سے مطابقت رکھتا ہے، iOS پر — OSLog قسم debug (iOS 14 سے پہلے os_trace استعمال ہوتا تھا)۔

Debug — ڈویلپمنٹ اور جانچ کے دوران مفید ڈیبگنگ پیغامات۔ ان میں اہم اشیاء کی حالت، SQL سوالات کے نتائج اور API کال کے پیرامیٹرز کے بارے میں معلومات ہوتی ہیں۔ Verbose کے برعکس، Debug پیغامات ساختہ اور معنوی طور پر اہم ہوتے ہیں۔ iOS پر، یہ لیول OSLogType.debug سے مطابقت رکھتا ہے۔

Info — ایپلیکیشن کے عام واقعات کے بارے میں معلوماتی پیغامات: SDK ابتدا، کامیاب تصدیق، اسکرین کھولنا، سرور سے ڈیٹا حاصل کرنا۔ Info پیغامات میں صارفین کا ذاتی ڈیٹا نہیں ہونا چاہیے اور پروڈکشن تجزیہ کے لیے محفوظ ہونا چاہیے۔ iOS پر OSLogType.info استعمال ہوتا ہے، Android پر — Log.i()۔

Warn — ممکنہ مسائل کے بارے میں انتباہ۔ ایپلیکیشن کام جاری رکھتی ہے، لیکن صورت حال توجہ طلب ہے: کیشے کا سائز حد کے قریب، API کا پرانا ورژن، سست نیٹ ورک رسپانس، کنکشن کی دوبارہ کوشش۔ Android پر — Log.w()، iOS پر — OSLogType.default (انتباہ کے لیے)۔

Error — سنگین خرابیاں جہاں ایپلیکیشن درخواست کردہ آپریشن نہیں کر سکتی لیکن کام جاری رکھتی ہے: ناکام API درخواست، کنکشن کا ختم ہونا، ڈیٹا بیس تحریر کی خرابی، اجازتوں کی کمی۔ iOS پر خرابیوں کے لیے OSLogType.error استعمال ہوتا ہے، Android پر — Log.e()۔

Assert (WTF) — سب سے اونچا لیول، «ایسا نہیں ہو سکتا» کی صورت حال کی نشاندہی کرتا ہے۔ ان بگز کو لاگ کرنے کے لیے استعمال ہوتا ہے جو نظام کے بنیادی ناقابل تغیر اصولوں کی خلاف ورزی کرتے ہیں۔ Android پر، Assert پیغامات ڈیفالٹ طور پر ریلیز بلڈ میں ظاہر نہیں ہوتے۔ iOS پر، WTF (What a Terrible Failure) کو OSLogType.fault کے ذریعے ہینڈل کیا جاتا ہے۔

Android پر Log Level کا استعمال

Android Log API — android.util.Log پیکیج سے بلٹ ان لاگنگ میکانزم۔ یہ 6 جامد طریقے فراہم کرتا ہے: Log.v(), Log.d(), Log.i(), Log.w(), Log.e() اور Log.wtf()۔ ہر طریقہ tag (ماخذ شناخت کنندہ سٹرنگ) اور msg (پیغام کا متن) لیتا ہے۔

class UserRepository {
    companion object {
        private val TAG = "UserRepo"
    }

    suspend fun loadUser(id: String): User {
        Log.d(TAG, "$id کے ساتھ صارف لوڈ ہو رہا ہے")

        return try {
            val response = api.fetchUser(id)
            Log.i(TAG, "صارف کامیابی سے لوڈ ہو گیا")
            response.toUser()
        } catch (e: Exception) {
            Log.e(TAG, "صارف لوڈ کرنے میں ناکام: ${e.message}")
            throw e
        }
    }
}

لیول کے مطابق فلٹرنگ Android Logcat میں ADB کے ذریعے کی جاتی ہے: adb logcat *:E صرف Error پیغامات دکھائے گا۔ پروڈکشن بلڈ میں، جب منیفکیشن فعال ہوتا ہے تو ProGuard/R8 کے ذریعے تمام Log.v() اور Log.d() کالز ہٹا دی جاتی ہیں۔ Log.i(), Log.w() اور Log.e() رہ جاتے ہیں، لہذا ان طریقوں کے ذریعے حساس ڈیٹا آؤٹ پٹ نہ کرنا ضروری ہے۔

رن ٹائم پر کسٹم فلٹرنگ کے لیے، Android Log.isLoggable(tag, level) فراہم کرتا ہے — ایک طریقہ جو چیک کرتا ہے کہ دیئے گئے tag کے لیے مخصوص لیول فعال ہے یا نہیں۔ یہ ایپلیکیشن کو دوبارہ بنائے بغیر کسی خاص ماڈیول کے لیے تفصیلی لاگنگ کو متحرک طور پر فعال کرنے کی اجازت دیتا ہے۔

iOS اور macOS پر Log Level کا استعمال

OSLog — Apple کا متحد لاگنگ سسٹم، جس نے متروک NSLog کی جگہ لے لی۔ OSLog 5 لیول فراہم کرتا ہے: debug, info, default (notice), error اور fault۔ اہم فائدہ فارمیٹ شدہ سٹرنگز اور کنسول کے ذریعے متحرک فلٹرنگ کے ساتھ ساختہ لاگنگ ہے۔

import OSLog

let logger = Logger(
    subsystem: "com.example.app",
    category: "network"
)

func fetchData(from url: URL) {
    logger.debug("Starting request to \(url.absoluteString)")

    do {
        let data = try Data(contentsOf: url)
        logger.info("Received \(data.count) bytes")
    } catch {
        logger.error("Request failed: \(error.localizedDescription)")
    }
}

OSLog فلٹرنگ سسٹم آپریٹنگ سسٹم کی سطح پر کام کرتا ہے۔ Debug پیغامات صرف اس وقت لکھے جاتے ہیں جب ڈیبگر منسلک ہو یا -com.apple.CoreData.Logging.debug 1 آرگیومینٹ فعال ہو۔ Info پیغامات ڈیوائس میموری (512 KB تک) میں جمع ہوتے ہیں اور Console.app کے ذریعے قابل رسائی ہوتے ہیں۔ Error اور fault پیغامات مسلسل لکھے جاتے ہیں اور کریش رپورٹنگ سسٹمز کے ذریعے جمع کرنے کے لیے دستیاب ہوتے ہیں۔

OSLog کی ایک اہم خصوصیت: پلیس ہولڈرز کے ساتھ فارمیٹ شدہ سٹرنگز۔ Swift سٹرنگ انٹرپولیشن (جو لیول سے قطع نظر ہمیشہ جانچی جاتی ہے) کے بجائے، OSLog حساس ڈیٹا کو الگ کرنے کے لیے %{public}@ اور %{private}@ کے ساتھ os_log فارمیٹ استعمال کرتا ہے۔ پروڈکشن لاگ میں نجی پیرامیٹرز ماسک کیے جاتے ہیں۔

پروڈکشن بمقابلہ ڈیبگ: لیول فلٹرنگ کیسے کنفیگر کریں

بنیادی اصول — پروڈکشن میں لیول کا کم از کم سیٹ: Info, Warn, Error, Assert۔ Debug اور Verbose کو غیر فعال کر دینا چاہیے۔ وجہ سیکیورٹی سے زیادہ کارکردگی ہے: ہر لاگ کال سٹرنگ کو فارمیٹ کرنے میں CPU وقت خرچ کرتی ہے، چاہے پیغام آؤٹ پٹ نہ ہو۔

سست سٹرنگ فارمیٹنگ

اہم اصلاح — لاگ کالز میں کبھی بھی سٹرنگ انٹرپولیشن استعمال نہ کریں۔ اگر log() کال سے پہلے سٹرنگ بنائی جاتی ہے، تو لیول غیر فعال ہونے پر بھی CPU وقت ضائع ہوتا ہے۔ لیمبڈا یا گارڈ شرائط کے ذریعے سست فارمیٹنگ استعمال کریں۔

Android پر، Log.isLoggable() طریقہ اس مقصد کو پورا کرتا ہے؛ OSLog پر، پلیس ہولڈرز کے ساتھ مقامی فارمیٹ شدہ سٹرنگز معاون ہیں۔ Android کے لیے Timber درخت کے اندر لیول چیک کے ساتھ timber.log.Tree کے ذریعے مسئلہ حل کرتا ہے۔

چلتے چلتے متحرک لیول تبدیلی

Remote Log Level — ایک عمل جہاں لاگنگ لیول Firebase Remote Config یا اسی طرح کی سروس کے ذریعے سرور سے کنٹرول کیا جاتا ہے۔ اگر پروڈکشن میں کوئی پیچیدہ خرابی ہوتی ہے، تو ڈویلپر منتخب صارف گروپ کے آلات پر کسی خاص ماڈیول کے لیے دور سے Debug لاگنگ فعال کر سکتا ہے۔

Firebase، 2024 کے مطابق، یہ عمل نایاب بگز کی تشخیص کے وقت کو 60% تک کم کرتا ہے اور ڈیبگ بلڈ انسٹال کیے بغیر مسئلے کی مکمل تصویر حاصل کرنے کی اجازت دیتا ہے۔ اہم حد — کنفیگریشن حاصل کرنے کے بعد لاگنگ صرف ایپلیکیشن کے اگلے لانچ پر فعال ہوتی ہے۔

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

Android پر BuildConfig.DEBUG اور Swift پر #if DEBUG معیاری مشروط تالیف میکانزم ہیں جو ریلیز بلڈ میں ڈیبگ لیول کو غیر فعال کرتے ہیں۔ صاف ستھرے آرکیٹیکچر کے لیے، مشروط ہدایات کے ساتھ کاروباری منطق کو پیچیدہ نہ کرنے کے لیے Log Level کے انتخاب کو DI-کنٹینر یا لوگر فیکٹری میں منتقل کرنے کی سفارش کی جاتی ہے۔

لاگنگ لیول کے انتخاب کے بہترین طریقے

پہلا اصول — ہر لاگ کال کو «کون، کیا، کب» کے سوال کا جواب دینا چاہیے۔ کون — جزو یا ماڈیول (Android پر tag، iOS پر category)۔ کیا — مخصوص واقعہ یا حالت کی تبدیلی۔ کب — ٹائم سٹیمپ، جو لاگنگ سسٹم کے ذریعے خودکار طور پر شامل کیا جاتا ہے۔

دوسرا اصول — Info اور اس سے اوپر کے ذریعے حساس ڈیٹا لاگ نہ کریں۔ پاس ورڈ، ٹوکن، ای میل، فون نمبر، درست جغرافیائی کوآرڈینیٹ — کسی بھی لاگ میں سختی سے ممنوع ہیں جو پروڈکشن میں جاتا ہے۔ ضرورت پڑنے پر ماسکنگ استعمال کریں: «email: us***@example.com.»

تیسرا اصول — Warn لیول ڈویلپر کی ذمہ داری ہے، Error — ٹیم کی۔ Warn کا مطلب ہے «یہاں ممکنہ مسئلہ ہے، نظر رکھیں»۔ Error کا مطلب ہے «یہاں مسئلہ ہے، اسے ٹھیک کریں»۔ متوقع اور سنبھالے گئے حالات (مثلاً 404 API خرابی) کے لیے Error استعمال نہ کریں۔

چوتھا اصول — مستقل مزاجی۔ پورے پروجیکٹ کو tag اور زمرہ جات کے نام رکھنے کے متحد قوانین استعمال کرنے چاہئیں۔ Android tag کے لیے ClassName.methodName اور iOS category کے لیے module.subsystem تجویز کیا جاتا ہے۔ یہ جزو کے لحاظ سے لاگ کو فوری فلٹر کرنے کی اجازت دیتا ہے۔

پانچواں اصول — اپنے لاگ کو آزمائیں۔ یونٹ ٹیسٹ میں تصدیق کریں کہ مخصوص منظرناموں میں صحیح Log Level کال کیا گیا ہے۔ اس مقصد کے لیے مک لاگنگ لائبریریاں موجود ہیں: Android کے لیے Mockito، iOS کے لیے Cuckoo۔ ٹیسٹ میں لیول کی جانچ پروڈکشن میں ڈیبگ پیغامات کے رساو کو روکتی ہے۔