کارکردگی کی نگرانی — یہ کیا ہے، میٹرکس اور ڈیٹا اکٹھا کرنا

کارکردگی کی نگرانی کیا ہے

کارکردگی کی نگرانی رن ٹائم میٹرکس، میموری کے استعمال، فریم ریٹ اور توانائی کی کھپت کو جمع کرکے ایپلیکیشن کے رویے کو ماپنے کا عمل ہے۔ کریش رپورٹنگ کے برعکس، جو صرف مہلک ناکامیوں کو پکڑتی ہے، کارکردگی کی نگرانی بتدریج بگاڑ کو ٹریک کرتی ہے: ایپ کام کرتی ہے لیکن جتنی تیز ہونی چاہیے اس سے سست ہے۔

Google (2024) کے مطابق، 53% صارفین ایپ بند کر دیتے ہیں اگر اسے لوڈ ہونے میں 3 سیکنڈ سے زیادہ لگتے ہیں۔ تاخیر کا ہر اضافی سیکنڈ زمروں میں اوسطاً 20% تبدیلی کو کم کرتا ہے۔ یہ کارکردگی کی نگرانی کو موبائل مصنوعات کے لیے صرف ایک تکنیکی عمل نہیں بلکہ ایک کاروباری ضرورت بناتا ہے۔

جدید کارکردگی کی نگرانی چار سطحوں پر محیط ہے: کلائنٹ سائیڈ (iOS، Android)، نیٹ ورک (API درخواستیں، WebSocket)، بیک اینڈ خدمات اور بنیادی ڈھانچہ۔ موبائل ڈیولپمنٹ میں، توجہ کلائنٹ سائیڈ میٹرکس پر ہے، کیونکہ زیادہ تر کارکردگی کے مسائل صارف کے آلے پر پیدا ہوتے ہیں۔

موبائل ایپ کے اہم میٹرکس

مکمل نگرانی کے لیے، میٹرکس کے پانچ گروپوں کو ٹریک کرنا ضروری ہے، ہر ایک صارف کے تجربے کے ایک مختلف پہلو کے لیے ذمہ دار ہے۔ FPS (فریم فی سیکنڈ) اینی میشن اور اسکرول کی ہمواری دکھاتا ہے — 30 فریم فی سیکنڈ سے نیچے کی قدریں آنکھ کو سستی محسوس ہوتی ہیں۔

وقت کے میٹرکس

کولڈ اسٹارٹ کا وقت — آئیکن کو چھونے کے لمحے سے UI کی مکمل تیاری تک۔ ہاٹ اسٹارٹ کا وقت — پس منظر سے واپسی۔ صارف کے عمل کا ردعمل کا وقت (ٹیپ ٹو ریسپانس)۔ Android پر اسٹارٹ اپ کا وقت ActivityManager کے ذریعے ماپا جاتا ہے، iOS پر — dyld اور premain وقت کے ذریعے۔ Firebase Performance کے مطابق، ٹاپ 100 ایپس کے لیے اوسط کولڈ اسٹارٹ کا وقت 1.8 سیکنڈ ہے۔

میموری اور CPU کے میٹرکس

RAM کی کھپت آلے پر دستیاب گنجائش کے 80% سے تجاوز نہیں کرنی چاہیے، ورنہ سسٹم ایپ کو پس منظر سے ہٹانا شروع کر دیتا ہے۔ میموری فٹ پرنٹ Xcode Instruments (iOS) اور Android Profiler کے ذریعے ٹریک کیا جاتا ہے۔ میموری لیک کا پتہ بار بار ہونے والی کارروائیوں کے دوران کھپت میں اضافے سے لگایا جاتا ہے — مثال کے طور پر، اسکرینوں کے درمیان سوئچ کرنا۔

نیٹ ورک کے میٹرکس

HTTP درخواست پر عملدرآمد کا وقت، ردعمل کا سائز، ٹائم آؤٹ کی تعدد اور غلطی کی شرح۔ نیٹ ورک لیٹنسی خاص طور پر ان موبائل ایپس کے لیے اہم ہے جو غیر مستحکم کنکشن کے حالات میں کام کرتی ہیں (3G، میٹرو، لفٹ، رومنگ)۔ p95 ردعمل کے وقت کو ٹریک کرنے کی سفارش کی جاتی ہے — یہ بدترین نیٹ ورک حالات میں سب سے «بھاری» صارفین کا تجربہ دکھاتا ہے۔

Real User Monitoring اور Synthetic Monitoring

Real User Monitoring (RUM) پروڈکشن ماحول میں حقیقی صارفین کے آلات سے ڈیٹا اکٹھا کرتا ہے۔ یہ طریقہ صارفین کے اپنے آلات، OS ورژنز، نیٹ ورک اور جغرافیائی محل وقوع کو مدنظر رکھتے ہوئے حقیقی تاخیر دکھاتا ہے۔ RUM سب سے درست کارکردگی کی تصویر فراہم کرتا ہے لیکن اس کا انحصار اس بات پر ہے کہ نمونے میں کون سے صارفین شامل ہیں۔

Synthetic Monitoring، دوسری طرف، کنٹرول شدہ حالات میں ٹیسٹ آلات پر پہلے سے طے شدہ منظرنامے انجام دیتا ہے۔ یہ صارفین تک پہنچنے سے پہلے بگاڑ کا پتہ لگانے اور مستقل ماحول میں مسائل کو دوبارہ پیدا کرنے کی اجازت دیتا ہے۔ Firebase Test Lab اور BrowserStack دستی عملدرآمد کے بغیر حقیقی آلات پر مصنوعی ٹیسٹ فراہم کرتے ہیں۔

بہترین حکمت عملی دونوں طریقوں کا امتزاج ہے: مصنوعی ٹیسٹ CI مرحلے میں بگاڑ کو پکڑتے ہیں، جبکہ RUM پروڈکشن میں حقیقی تصویر فراہم کرتا ہے۔ Datadog (2024) کے مطابق، دونوں طریقے استعمال کرنے والی ٹیمیں واقعہ بننے سے پہلے 35% زیادہ کارکردگی کے مسائل دریافت کرتی ہیں۔

Firebase Performance Monitoring سیٹ اپ

Firebase Performance Monitoring iOS اور Android پر کارکردگی کے میٹرکس جمع کرنے کا Google کا ایک مفت ٹول ہے۔ یہ کوڈ لکھے بغیر خود بخود ایپ اسٹارٹ اپ وقت، HTTP درخواستیں اور اسکرین رینڈرنگ کی پیمائش کرتا ہے۔ سیٹ اپ کرنے کے لیے، بس اپنے پروجیکٹ میں SDK شامل کریں اور Firebase کنسول میں Performance ماڈیول کو فعال کریں۔

خودکار میٹرک جمع

SDK کو ضم کرنے کے بعد، Firebase Performance URLSession (iOS) یا OkHttp (Android) کے ذریعے ہر HTTP درخواست کے لیے خود بخود ایک ٹریس بناتا ہے۔ اسکرین رینڈرنگ کو UIViewController اور Activity کے لیے ماپا جاتا ہے، onCreate/viewDidLoad سے پہلی رینڈر کی تکمیل تک کا وقت ریکارڈ کرتا ہے۔ تمام میٹرکس Firebase کنسول میں جمع کیے جاتے ہیں، ایپ ورژن، آلہ اور ملک کے لحاظ سے تقسیم کیے جاتے ہیں۔

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // ادائیگی پر عملدرآمد
        trace.stop()
    }
}

کوڈ رقم کی خصوصیت کے ساتھ ادائیگی کے منظر نامے کے لیے ایک کسٹم ٹریس بناتا ہے۔ Firebase کنسول میں اس ٹریس کا استعمال کرتے ہوئے، آپ ایپ ورژن اور آلہ کے لحاظ سے گروپ کردہ ادائیگی کے عملدرآمد کے اوسط اور p95 وقت دیکھ سکتے ہیں۔

HTTP نگرانی

Firebase خود بخود نیٹ ورک کی درخواستوں کو روکتا ہے اور URL، ردعمل کا کوڈ، پے لوڈ کا سائز اور عملدرآمد کا وقت ریکارڈ کرتا ہے۔ Android پر OkHttp کے لیے، خودکار انسٹرومینٹیشن اضافی ترتیب کے بغیر کام کرتی ہے۔ نیٹ ورک کی درخواستیں کنسول میں اینڈ پوائنٹ کے لحاظ سے گروپ کر کے ظاہر کی جاتی ہیں، جس سے کسی خاص API کی سستی کی فوری نشاندہی ممکن ہوتی ہے۔

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

معیاری میٹرکس مجموعی کارکردگی کا احاطہ کرتے ہیں، لیکن کاروباری عمل کی تشخیص کے لیے مخصوص منظرناموں کو انسٹرومینٹ کرنے کی ضرورت ہوتی ہے۔ کسٹم ٹریس تصدیق، نیوز فیڈ لوڈنگ، تصویری پروسیسنگ یا ڈیٹا سنکرونائزیشن کے عملدرآمد کے وقت کی پیمائش کرنے کی اجازت دیتے ہیں۔

ہر کسٹم ٹریس کا «منظر نامہ-عمل» کی شکل میں ایک بامعنی نام ہونا چاہیے اور فلٹرنگ کے لیے خصوصیات پر مشتمل ہونا چاہیے۔ مثال کے طور پر، «file_size» اور «compression_quality» خصوصیات کے ساتھ ایک «image-upload» ٹریس اپ لوڈ کے وقت کا تصویر کے سائز پر انحصار کی نشاندہی کرنے میں مدد کرے گا۔ فی اسکرین 20 سے زیادہ کسٹم ٹریس نہ بنانے کی سفارش کی جاتی ہے — ضرورت سے زیادہ انسٹرومینٹیشن شور پیدا کرتی ہے اور تجزیہ کو پیچیدہ بناتی ہے۔

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // تصویر لوڈ کرنا
    trace?.stop()
}

Swift کی مثال فائل کے سائز اور کمپریشن کی سطح کی خصوصیات کے ساتھ تصویر لوڈ کرنے کے لیے ایک ٹریس بناتی ہے۔ Firebase کنسول میں، یہ خصوصیات میٹرکس کو گروپ کرنے اور فلٹر کرنے کے لیے فیلڈز بن جاتی ہیں۔

حدود اور الرٹنگ

الرٹنگ سسٹم کے بغیر میٹرکس جمع کرنا بیکار ہے۔ الرٹنگ کو ٹیم کو مطلع کرنا چاہیے جب میٹرکس قابل قبول حدود سے تجاوز کر جائیں، حدود کو تین سطحوں میں تقسیم کیا گیا ہے: انتباہ، سنگین اور بندش۔ ہر سطح اطلاعی چینل کا تعین کرتی ہے: انتباہ — ٹیم کے Slack چینل پر، سنگین — ڈیوٹی انجینئر کے لیے PagerDuty پر، بندش — تمام اسٹیک ہولڈرز کو اجتماعی اطلاع۔

موبائل میٹرکس کے لیے، فیصد پر مبنی متحرک حدود استعمال کرنے کی سفارش کی جاتی ہے: p95 کولڈ اسٹارٹ کا وقت 4 سیکنڈ سے تجاوز کرے — سنگین الرٹ۔ جامد حدود (مثلاً، CPU > 90%) کم مؤثر طریقے سے کام کرتی ہیں کیونکہ وہ دن کے وقت اور ہفتے کے دن کے مطابق عام لوڈ کے اتار چڑھاؤ کو مدنظر نہیں رکھتیں۔ Firebase Performance Firebase Console کے ذریعے الرٹ کنفیگریشن کو سپورٹ کرتا ہے جس میں Slack، PagerDuty اور ای میل پر اطلاعات بھیجی جا سکتی ہیں، اور تصدیق نہ ہونے پر ایسکلیشن کے اختیارات موجود ہیں۔

انسڈنٹ مینجمنٹ سروے (2024) کے مطابق، جو ٹیمیں اوسط کے بجائے فیصد کی بنیاد پر الرٹ سیٹ کرتی ہیں وہ 45% کم واقعات سے محروم رہتی ہیں۔ اوسط قدر آؤٹ لائرز کو ہموار کرتی ہے — p95 صارفین کے لیے بدترین صورت حال دکھانے کی ضمانت دیتا ہے، دن کے وقت اور موسمی لوڈ کے اتار چڑھاؤ سے قطع نظر۔