Firebase Performance: یہ کیا ہے، میٹرکس اور کیسے ٹریک کیا جائے

Firebase Performance Monitoring کیا ہے

Firebase Performance Monitoring ایک SDK اور کلاؤڈ پلیٹ فارم ہے جو موبائل ایپ کی کارکردگی میٹرکس کو گرد، اکٹھا اور بصری کرتا ہے۔ SDK ایپ میں ضم ہوتا ہے اور خود بخود اہم نکات کو انسٹریمنٹ کرتا ہے: Activity لائف سائیکل (Android) یا ViewController (iOS)، URLSession (iOS) یا OkHttp (Android) کے ذریعے نیٹورک درخواستیں، اور سسٹم کالز۔ گرد شدہ ڈیٹا Firebase سرور پر بھیجا جاتا ہے، جہاں اسے ایپ ورژن، آلہ، ملک اور دیگر خصوصیات کے مطابق اکٹھا کیا جاتا ہے۔

Performance SDK کی تعمیر انتہائی کم اوورہیڈ کے اصول پر مبنی ہے: انسٹریمنٹیشن ناپے گئے آپریشنوں کے انتقالی وقت میں 1–2% سے زیادہ اضافہ نہیں کرتا۔ ڈیٹا غیر ہم زمان گرد کیا جاتا ہے اور بھیجنے سے پہلے آلہ پر بفر کیا جاتا ہے، جو UI تھریڈ کی کارکردگی پر کسی بھی اثر کو ختم کرتا ہے۔ ڈیٹا ایک نظام کے مطابق (30 منٹ کے بعد) یا بفر 100 KB پہنچنے پر بھیجا جاتا ہے۔

Firebase Performance اور Android Studio پروفائلرز (CPU Profiler) یا Xcode Instruments کے درمیان بنیادی فرق پروڈکشن نگرانی ہے۔ Firebase Performance صرف ڈیولپر آلات سے نہیں، بلکہ حقیقی صارف آلات سے ڈیٹا گرد کرتا ہے۔ اس سے ایسے مسائل کا پتہ لگایا جا سکتا ہے جو صرف مخصوص ماڈلز، OS ورژنز یا مختلف علاقوں میں ہوتے ہیں — ایسے مسائل جو قابو میں ماحول میں دوبارہ پیدا نہیں کیے جا سکتے۔

SDK کوڈ میں ترمیم کیے بغیر ڈیٹا کیسے گرد کرتا ہے

خودکار انسٹریمنٹیشن Firebase Performance کی اہم خوبی ہے۔ Android کے لیے، SDK خود بخود ActivityLifecycleCallbacks کو رجسٹر کرتا ہے اور onCreate اور onResume کے درمیان وقت (سکرین رینڈرنگ کا وقت) ناپتا ہے۔ iOS کے لیے، یہ viewDidLoad اور viewDidAppear کے طریقوں کو سوئزل کرتا ہے۔ نیٹورک درخواستیں OkHttpInterceptor (Android) یا NSURLProtocol (iOS) کی سطح پر روکی جاتی ہیں۔ ڈیولپر کو معیاری میٹرکس کے لیے start/stop کالز شامل کرنے کی ضرورت نہیں ہے۔

Performance SDK کو فعال اور غیر فعال کرنا Google Services پلگ ان (Android) یا Info.plist (iOS) کے ذریعے منظم ہوتا ہے۔ ڈیبگنگ کے لیے، آپ Performance SDK کی مفصل لاگنگ کو فعال کر سکتے ہیں، جو دیکھاتی ہے کہ کون سے میٹرکس گرد اور بھیجے جا رہے ہیں۔ پروڈکشن میں، لاگز کو ضرورت سے زائد معلومات سے بچنے کے لیے انتباہ کی سطح پر رکھنے کی سفارش کی جاتی ہے۔ Flutter یا React Native کے منصوبوں کے لیے، خودکار انسٹریمنٹیشن محدود ہو سکتا ہے — مزید تفصیلات کوڈ کی مثالیں کے سیکشن میں۔

مفت حدیں اور قیمت کا تعین

Firebase Performance مفت Spark ٹائر پر ٹریسز یا ڈیٹا کے حجم پر کسی پابندی کے بغیر دستیاب ہے۔ ادا ئگی والا Blaze ٹائر بھی Performance Monitoring کے لیے چارج نہیں کرتا — یہ چند Firebase خدمات میں سے ایک ہے جو دونوں ٹائرز پر مکمل طور پر مفت ہے۔ صرف ایک پابندی ہے: ڈیٹا 30 دن (Spark) اور 365 دن (Blaze) تک محفوظ ہوتا ہے۔ طویل مدت کے تجزیے کے لیے، BigQuery export کے ذریعے ڈیٹا برآمد کریں۔

مفت ہونا Firebase Performance کو کسی بھی منصوبے کے لیے ایک بہترین انتخاب بناتا ہے — پروٹوٹائپ سے لے کر لاکھوں صارفین کے انٹرپرائز ایپلیکیشن تک۔ واحد اخراجی Performance SDK کا خارج ہونے والا ٹریفک ہے، لیکن یہ ایپ کے دوسرے نیٹورک آپریشنوں کے مقابلے میں ناچیز ہے (فی آلہ فی ماہ 1 MB سے کم)۔ BigQuery export ذخیرہ اور کوئریز کے لیے چارج کرتا ہے، لیکن Performance SDK خود مفت ہے۔

خودکار میٹرکس: کوڈ کے بغیر کیا ناپا جاتا ہے

Firebase Performance بغیر کسی کوڈ کے پانچ قسموں کے میٹرکس کو خود بخود گرد کرتا ہے: ایپ شروع ی وقت، سست HTTP درخواستیں، سکرین رینڈرنگ کی رفتار، میموری کا استعمال (صرف Android) اور فریم ریٹ (صرف Android)۔ یہ میٹرکس SDK کی شاملت اور پہلے صارف سیشن کے فورنے بعد Firebase کنسول میں دستیاب ہوتے ہیں۔

ایپ شروع ی وقت — عمل شروع کرنے سے لے کر UI کے بات چیت کے لیے مکمل طور پر تیار ہونے تک کا وقت۔ یہ کولڈ سٹارٹ (ایپ صفر سے شروع ہوتی ہے) اور وارم سٹارٹ (ایپ پش منظر کی حالت سے دوبارہ شروع ہوتی ہے) میں تقسیم کیا گیا ہے۔ کولڈ سٹارٹ میں DEX فائلوں کو لوڈ کرنا، سٹیٹک فیلڈز کو ابتدائی کرنا، Application.onCreate اور Activity.onCreate کو کال کرنا شامل ہے۔ Firebase خود بخود شروع کی قسم کو درجہ بند کرتا ہے اور ہر قسم کے لیے وقت کی تقسیم دیکھاتا ہے۔

سکرین رینڈرنگ کا وقت — سکرین لوڈنگ کے شروع (Android کے لیے onCreate، iOS کے لیے viewDidLoad) سے لے کر سکرین کے بات چیت کے لیے تیار ہونے (onResume، viewDidAppear) تک کا وقت۔ Firebase ہر سکرین (کلاس کے نام یا کسٹم سکرین نام سے) کے مطابق ڈیٹا اکٹھا کرتا ہے، جو اس بات کی شناسی کے قابل بناتا ہے کہ کون سی سکرین سب سے زیادہ وقت لیتی ہے۔ Android کے لیے، گرائے گئے فریم بھی ناپے جاتے ہیں — سکرین رینڈرنگ کے دوران چھوٹ گئے فریم کی تعداد (jank)۔

نیٹورک درخواستیں (HTTP/HTTPS)

Performance SDK خود بخود URLSession، OkHttp یا URLConnection کے ذریعے ایپ سے بھیجی گئی ہر HTTP/HTTPS درخواست کو روکتا اور ناپتا ہے۔ ہر درخواست کے لیے درج کیا جاتا ہے: URL (حفاظت کے لیے سوال کے پیرامیٹرز کے بغیر راستہ)، HTTP طریقہ، جواب کا کوڈ، بائٹس میں جواب کا حجم، درخواست کی مدت اور کنیکشن کی سپیڈ (WiFi، سیلولر)۔ ڈیٹا Firebase کنسول کے نیٹورک درخواستیں ڈیش بورڈ میں اکٹھا کیا جاتا ہے۔

سست درخواستیں — ایسی درخواستیں جن کی مدت مقرر کردہ حد سے تجاوز کر جاتی ہے۔ پہلے سے طے کے مطابق، سست درخواست کی حد 4000 ms ہے۔ یہ میٹرک بیک اینڈ مسائل کی شناسی کے لیے بہت اہم ہے: اگر بیک اینڈ اپ ڈیٹ کے بعد سست درخواستوں کی تعداد 1% سے 15% تک بڑھ جاتی ہے، تو یہ فوری سرور لاگز کے تجزیے کا اشارہ ہے۔ صارف جواب کے لیے 5 سیکنڈ سے زیادہ انتظار نہیں کریں گے — Firebase کا ڈیٹا دیکھاتا ہے کہ 53% صارف ایپ بند کر دیتے ہیں اگر ایک درخواست کو 3 سیکنڈ سے زیادہ وقت لگتا ہے۔

خودکار انسٹریمنٹیشن کی حدود

iOS کی حدود: iOS پر، Performance SDK گرائے گئے فریم کو نہیں ناپ سکتا (یہ ایک پرائیویٹ API ہے)۔ iOS پر jank ناپنے کے لیے MetricKit یا CADisplayLink استعمال کریں۔ مزید برآں، iOS پر، SDK ان درخواستوں کو نہیں روکتا جو URLSession استعمال نہ کرنے والے تیسرے فریق کے HTTP کلائنٹس (SwiftNIO) کے ذریعے کی گئی ہیں۔ ایسے معاملوں کے لیے، HTTP خصوصیات کے ساتھ کسٹم ٹریسز استعمال کریں۔

Android کی حدود: Android پر، خودکار میموری کی پیمائش صرف Android 8.0+ (API 26+) والے آلات پر دستیاب ہے۔ پرانے ورژنز کے لیے، Debug.getMemoryInfo() کے ذریعے حاصل کردہ ڈیٹا کے ساتھ کسٹم ٹریسز استعمال کریں۔ مزید برآں، SDK WebSocket کنیکشنز کو نہیں روکتا — انہیں علیحدہ ٹریسز کی ضرورت ہے۔ ان حدود کے باوجود، خودکار میٹرکس کارکردگی نگرانی کی 80% ضروریات کو پورا کرتے ہیں۔

کسٹم ٹریسز اور HTTP خصوصیات

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

ہر ٹریس کا ایک نام (از زیادہ 100 حروف) ہوتا ہے اور اس میں 5 تک کسٹم میٹرکس (ٹریس کے اندر ریکارڈ کی گئی عددی قیمتیں) ہو سکتی ہیں۔ مثال کے طور پر، ایک “image_processing” ٹریس میں، آپ “original_file_size” اور “processed_file_size” جیسے میٹرکس ناپ سکتے ہیں۔ میٹرکس Firebase کنسول میں تقسیمات (کم سے کم، زیادہ سے زیادہ، اوسط، فیصدی حصے) کے طور پر ظاہر ہوتے ہیں، جو صرف مدت ہی نہیں، بلکہ آپریشن کی خوبیوں کا بھی تجزیہ کرنے کی اجازت دیتے ہیں۔

HTTP خصوصیات — SDK کے ذریعے خود بخود نہ روکی گئی نیٹورک درخواستوں (WebSocket یا تیسرے فریق کی لائبریریوں کے ذریعے) کے لیے ایک خاص قسم کا کسٹم ٹریس ہے۔ HTTP خصوصیات میں URL، HTTP طریقہ، جواب کا کوڈ اور جواب کا حجم شامل ہے۔ Firebase انہیں خود بخود گرد کردہ درخواستوں کے ساتھ نیٹورک درخواستیں سیکشن میں ظاہر کرتا ہے، نیٹورک بات چیت کی ایک متحد تصویر فراہم کرتا ہے۔

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

کسٹم ٹریسز درج ذیل کی پیمائش کے لیے ناگزیر ہیں: مقامی ڈیٹابیس (Room، CoreData) سے ڈیٹا لوڈ کا وقت، پیچیدہ حسابوں (خفا کرنا، کمپریشن) کی مدت، اینیمیشن اور ٹرانزیشن کی کارکردگی، تیسرے فریق کے SDK (نقشے، ادائیگی، تجزیہ) کا جوابی وقت۔ ایسے ہر منظر کے لیے، ایک ٹریس بنائیں، ناپے گئے کوڈ کو start/stop میں لپیٹیں اور بعد میں تقسیم کے لیے خصوصیات شامل کریں۔

کسٹم ٹریسز کا غلط استعمال نہ کریں۔ ہر ٹریس بہتری اور ٹریفک کے اضافی استعمال کا سبب بنتا ہے۔ پروڈکشن ورژن میں 10–15 سے زیادہ فعال ٹریسز نہ رکھنے کی سفارش کی جاتی ہے۔ ڈیبگنگ کے لیے، آپ مزید ٹریسز شامل کر سکتے ہیں، لیکن ریلیز سے پہلے Remote Config (performance_tracing_enabled فلیگ) کے ذریعے ضرورت سے زیادہ ٹریسز کو غیر فعال کر دیں۔ یہ صرف منتخب صارفین یا سیشنوں کے لیے مفصل ٹریسنگ کو فعال کرنے کی اجازت دیتا ہے۔

تقسیم کے لیے ٹریس کی خصوصیات

کسٹم خصوصیات کلید ویلیو جوڑے ہیں جو Firebase کنسول میں بعد میں فلٹر کرنے کے لیے ایک ٹریس میں شامل کی جا سکتی ہیں۔ مثال کے طور پر، “feed_load” ٹریس کے لیے، آپ “feed_type” (main, explore, following) اور “cache_status” (cold, warm) جیسی خصوصیات شامل کر سکتے ہیں۔ کنسول میں، ٹریس کے ڈیٹا کو ان خصوصیات کے مطابق فلٹر کیا جا سکتا ہے تاکہ یہ طے کیا جا سکے کہ کون سی فیڈ کی قسم سب سے دھیمی لوڈ ہوتی ہے۔

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

کارکردگی کی سیماں اور انتباہات

سیماں میٹرکس کے لیے ترتیب پذیر حد کی قیمتیں ہیں، جن کو تجاوز کرنے پر Firebase Performance ایک انتباہ پیدا کرتا ہے۔ سیماں Firebase کنسول (Performance > Thresholds) میں ہر خودکار میٹرک کے لیے مقرر کی جاتی ہیں: ایپ شروع ی وقت (کولڈ/وارم)، سکرین رینڈرنگ کا وقت، سست HTTP درخواستیں، HTTP جوابی وقت۔ آپ تمام ایپ ورژنز کے لیے عالمی سیماں یا مخصوص ورژنز کے لیے مخصوص سیماں مقرر کر سکتے ہیں۔

انتباہات خودکار اطلا عات ہیں جو Firebase حد کے تجاوز کرنے پر بھیجتا ہے۔ انتباہات کو ای میل، Slack webhook، PagerDuty یا Cloud Functions (کسٹم ہینڈلنگ کے لیے) کے ذریعے ترتیب دیا جا سکتا ہے۔ ہر انتباہ میں شامل ہے: میٹرک کا نام، موجودہ قیمت، حد کی قیمت، ایپ ورژن، حصہ (آلہ، ملک)۔ انتباہات کارکردگی میں بگڑنے پر پرداخت کرنے کی اجازت دیتے ہیں اس سے پہلے کہ یہ صارفین کو نظر آئے۔

سفارش شدہ سیماں صنعتی معیار (Google I/O 2025) کے مطابق: کولڈ سٹارٹ — 2 سیکنڈ سے کم، وارم سٹارٹ — 1 سیکنڈ سے کم، سکرین رینڈرنگ — 500 ms سے کم، HTTP درخواست کی مدت — 3000 ms سے کم (95واں فیصدی)، سست درخواستوں کا تناسب — 5% سے کم۔ انتہائی مسابقہ والی ایپس (سوشل، ای کامرس) کے لیے، ہدف کی سیماں مزید سخت ہو سکتی ہیں: کولڈ سٹارٹ <1.5 سیکنڈ، HTTP <1000 ms۔

Firebase کنسول میں سیماں مقرر کرنا

Firebase کنسول میں، Performance سیکشن پر جائیں، Thresholds ٹیب کو کھولیں۔ ہر میٹرک کے لیے، مطلوبہ حد کی قیمت اور صارفین کا فیصد مقرر کریں جو تجاوز سے متاثر ہونا چاہیے۔ مثال کے طور پر: “کولڈ سٹارٹ کو سست سمجھیں اگر یہ 10% صارفین کے لیے 2 سیکنڈ سے تجاوز کرتا ہے”۔ Firebase حقیقی سیماں چننے میں مدد کے لیے موجودہ میٹرک قیمتیں اور تجاوز کی تاریخ دیکھائے گا۔

اہم: سیماں ڈیٹا گرد کرنے کو متاثر نہیں کرتیں، وہ صرف اطلا ع کی پیدائش کو کنٹرول کرتی ہیں۔ اگر حد بہت کم ہے (مثال کے طور پر، کولڈ سٹارٹ 1 سیکنڈ، جبکہ 50% آلات 3 سیکنڈ میں شروع ہوتے ہیں)، انتباہات مسلسل آئیں گے اور “شور” بن جائیں گے جسے ڈیولپرز نوٹس کرنا بند کر دیں گے۔ سیماں موجودہ کارکردگی کے مطابق مقرر کریں، پھر آپ ایپ کو بہتر بنانے کے ساتھ آہستہ آہستہ انہیں سخت کریں۔

Firebase کنسول میں کارکردگی کا ڈیش بورڈ

کارکردگی کا ڈیش بورڈ اہم میٹرکس کو وقتی سلسلے کے طور پر ظاہر کرتا ہے جو ایپ ورژن، آلہ، ملک، کنیکشن کی قسم اور OS ورژن کے مطابق تقسیم کیا گیا ہے۔ ہر میٹرک کے لیے دستیاب ہیں: اوسط، میڈین، 95واں فیصدی، 99واں فیصدی۔ 95واں فیصدی کارکردگی کے جائزے کے لیے سب سے زیادہ معلوماتی میٹرک ہے، کیونکہ یہ غیر موردی قیمتوں کو نظر انداز کرتے ہوئے کمزور آلات پر ایپ کی کارکردگی کو دیکھاتا ہے۔

ڈیش بورڈ ورژن کا موازنہ کی سہولت فراہم کرتا ہے: میٹرکس کے مرئی موازنے کے لیے دو ایپ ورژن (موجودہ اور پچھلا) منتخب کریں۔ اگر اپ ڈیٹ کے بعد 95واں فیصدی شروع ی وقت 2.1 سیکنڈ سے 3.4 سیکنڈ تک بڑھ جاتا ہے — ریگریشن واضح ہے اور آپ وہ کمٹ ڈھونڈنے کی ضرورت ہے جس نے سستی کا سبب بنایا۔ Firebase Performance GitHub، GitLab اور Bitbucket کے ساتھ مربوط ہوتا ہے، جو میٹرکس میں تبدیلیوں کو مخصوص کمٹس سے منسوب کرنے کی اجازت دیتا ہے۔

پرفارمنس مانیٹرنگ کے لیے کوڈ کی مثالیں

Kotlin کا استعمال کرتے ہوئے ایک Android ایپ میں Firebase Performance Monitoring کے انضمام کی مثالیں دیکھیں۔ کوڈ خبروں کی فیڈ لوڈنگ کو ناپنے کے لیے کسٹم ٹریس بنانا، خود بخود نہ روکی گئی درخواست کے لیے HTTP خصوصیت شامل کرنا اور امیج پروسیسنگ کا وقت ناپنے کے لیے Trace کا استعمال ظاہر کرتا ہے۔ تمام مثالیں Remote Config کے ذریعے ٹریسنگ کو غیر فعال کرنے کی صلاحیت کو مدنظر رکھتی ہیں۔

استعمال سے پہلے، Firebase BOM کے ذریعے انحصار شامل کریں: implementation("com.google.firebase:firebase-perf")۔ خودکار انسٹریمنٹیشن کے لیے، اضافی سیٹ اپ کی ضرورت نہیں ہے — انحصار شامل کرنے کے بعد SDK خود بخود معیاری آپریشنوں کو روکتا ہے۔

فیڈ لوڈنگ کے لیے کسٹم ٹریس

پہلی مثال — سرور سے خبروں کی فیڈ کے لوڈ وقت کی پیمائش۔ ٹریس غیر ہم زمان fetchFeed آپریشن کو لپیٹتا ہے، جو نیٹورک سے ڈیٹا لاتا اور JSON پارس کرتا ہے۔ ٹریس میں کسٹم خصوصیات شامل کی گئی ہیں: ڈیٹا کا ذریعہ (cache یا network) اور موصولہ پوسٹوں کی تعداد۔ یہ ڈیٹا کو تقسیم کرنے اور سمجھنے کی اجازت دیتا ہے کہ فیڈ کن حالات میں سب سے دھیمی لوڈ ہوتی ہے۔

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

فنکشن loadFeedWithTrace ایک source پیرامیٹر (“cache” یا “network”) لیتا ہے، جو ٹریس خصوصیت کے طور پر استعمال ہوتا ہے۔ غیر ہم زمان آپریشن مکمل ہونے کے بعد، ٹریس finally بلاک میں رک جاتا ہے، جو استثنا کی صورت میں بھی رکنے کی ضمانت دیتا ہے۔ items_count میٹرک پوسٹوں کی تعداد کے لوڈ وقت پر اثر کا تجزیہ کرنے کی اجازت دیتا ہے۔ Firebase کنسول میں، آپ source خصوصیت کے مطابق ٹریسز کو فلٹر کر سکتے ہیں اور دیکھ سکتے ہیں کہ نیٹورک لوڈنگ کیش سے 3 گنا دھیمی ہے۔

غیر معیاری درخواست کے لیے HTTP خصوصیت

دوسری مثال — WebSocket کے ذریعے کی گئی درخواست کے لیے HTTP خصوصیت (خود بخود نہیں روکی گئی)۔ HttpMetric کلاس استعمال کی جاتی ہے، جو ایک URL درخواست، اس کے طریقہ، جواب کے کوڈ اور حجم کو دستی طور پر رجسٹر کرنے کی اجازت دیتی ہے۔ Firebase اس درخواست کو خود بخود روکی گئی درخواستوں کے ساتھ نیٹورک درخواستیں سیکشن میں ظاہر کرے گا۔

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

مثال میں، sendWithHttpMetric ایک غیر معیاری HTTP کال رجسٹر کرنے کے لیے newHttpMetric استعمال کرتا ہے۔ SDK اسے خود بخود نہیں روکتا، اس لیے ڈیولپر URL، طریقہ، جواب کا کوڈ اور حجم دستی طور پر مقرر کرتا ہے۔ URL کو سوال کے پیرامیٹرز کے بغیر مقرر کرنا اہم ہے (حفاظت اور اکٹھا کرنے کے لیے) — یعنی /data، نہ کہ /data?token=abc۔ Firebase خود بخود ایک جیسے URL پیٹرن کو گروپ کرتا ہے۔

امیج پروسیسنگ کا وقت ناپنا

تیسری مثال کسٹم ٹریس کا استعمال کرتے ہوئے امیج پروسیسنگ (کمپریشن، سائز تبدیل کرنا) کے وقت کی پیمائش ظاہر کرتی ہے۔ اس صورت میں، ٹریس ایک ہم زمان آپریشن کو لپیٹتا ہے، لیکن پروڈکشن کے لیے UI تھریڈ کو بلاک کرنے سے بچنے کے لیے coroutines یا RxJava استعمال کریں۔

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

فنکشن compressImage 80% کوالٹی پر JPEG امیج کمپریشن کا وقت ناپتا ہے۔ format خصوصیت مستقبل میں JPEG بمقابلہ WebP کمپریشن وقت کا موازنہ کرنے کی اجازت دیتی ہے۔ output_size_kb میٹرک دیکھاتا ہے کہ کمپریشن کتنا موثر ہے۔ Firebase کنسول میں، آپ تقسیم دیکھ سکتے ہیں: کمزور آلات (بجٹ Android) پر، کمپریشن فلیگ شپ کے مقابلے میں 4 گنا زیادہ وقت لیتا ہے، جو سرور پر امیج اپ لوڈ کرتے وقت تاخیر کا سبب بن سکتا ہے۔

ڈیٹا کی بنیاد پر کارکردگی کیسے بہتر کریں

Firebase Performance ڈیٹا فراہم کرتا ہے لیکن تیار حل نہیں دیتا۔ میٹرکس کے تجزیے کے لیے ہر میٹرک کی کارکردگی بگڑنے کی عام وجوہات کو سمجھنا ضروری ہے۔ اہم بگڑنے کے پیٹرن اور Performance Monitoring ڈیٹا کا استعمال کرتے ہوئے ان کی تشخیص کے طریقے دیکھیں۔ نقطہ نظر: میٹرک میں انوملی ڈھونڈیں → عام وجوہات چیک کریں → بہتری لگائیں → ایک ہفتے بعد نتیجہ تصدیق کریں۔

سست کولڈ سٹارٹ (2 سیکنڈ سے زیادہ): وجوہات — Application.onCreate میں بھاری SDK ابتدائی (تجزیہ، کریش رپورٹنگ، نقشہ SDK)، بڑے وسائل لوڈ کرنا (فانٹس، تھیمز)، شروع میں مین تھریڈ پر ہم زمان آپریشن۔ حل: سست SDK ابتدائی، تاخیری وسائل لوڈنگ، ابتدائی کے دوران placeholder ظاہر کرنے کے لیے SplashScreen API (Android 12+) کا استعمال۔ Firebase Performance دیکھائے گا کہ کون سا ایپ ورژن سست ہونا شروع ہوا — چیک کریں کہ کون سے انحصار شامل یا اپ ڈیٹ کیے گئے۔

سست سکرین رینڈرنگ (500 ms سے زیادہ): وجوہات — پیچیدہ View درجہ بندی (اندرونی ConstraintLayout، متعدد Fragment)، UI تھریڈ میں ڈیٹا لوڈ کرنا (نیٹورک یا ڈسک)، بھاری ڈرا آپریشن (بڑی امیجز، کسٹم View)۔ حل: لے آؤٹ درجہ بندی کو بہتر بنائیں (Android Studio میں Layout Inspector)، ڈیٹا کو بیک گراؤنڈ تھریڈ پر منتقل کریں، Glide یا Coil کے ذریعے امیجز کیش کریں۔ Firebase میں سکرین رینڈرنگ فلٹر کا استعمال کرتے ہوئے سب سے سست سکرین ڈھونڈیں اور پہلے اسے بہتر کریں۔

نیٹورک درخواستوں کو بہتر بنانا

سست HTTP درخواستیں (3 سیکنڈ سے زیادہ): وجوہات — سست سرور، بڑے پے لوڈز، کیشنگ کی کمی، غیر موزوں پروٹوکول (HTTP/2 کی بجائے HTTP/1.1)، DNS حل۔ حل: سرور کی طرف چیک کریں (اپ ٹائم، لیٹنسی)، جواب کا حجم کم کریں (پیجینیشن، GraphQL، JSON کی بجائے protobuf)، HTTP ہیڈرز (Cache-Control) کے ذریعے کیشنگ فعال کریں، OkHttp Interceptor کا استعمال کرتے ہوئے ٹائم آؤٹ اور دوبارہ کوشش منطق شامل کریں۔

Firebase Performance درخواست کے وقت کی تقسیم دیکھاتا ہے: DNS حل، TCP مصافحہ، TLS مصافحہ، درخواست بھیجنا، جواب وصول کرنا۔ اگر زیادہ تر وقت DNS پر خرچ ہوتا ہے — DNS پری لوڈنگ (OkHttp DNS-over-HTTPS) استعمال کریں۔ اگر TLS پر — سیشن دوبارہ شروع اور سائفر سویٹس ٹیوننگ استعمال کریں۔ اگر جواب وصول کرنے پر — جواب کا حجم اور صارف کی نیٹورک سپیڈ چیک کریں۔ Firebase ڈیٹا صرف “درخواست سست ہے” کہنے کے بجائے پروٹوکول کی سطح پر مسئلہ مقامی کرنے کی اجازت دیتا ہے۔

ٹریسنگ کو غیر فعال کرنے کے لیے Remote Config انضمام

پروڈکشن کے لیے، ایک Remote Config فلیگ performance_tracing_enabled شامل کرنے کی سفارش کی جاتی ہے، جو کسٹم ٹریسز کو دور سے غیر فعال کرنے کی اجازت دیتا ہے۔ اگر کلائنٹ پر Firebase Performance SDK بہت زیادہ ڈیٹا پیدا کرتا ہے یا کارکردگی کو متاثر کرتا ہے (کمزور آلات پر)، آپ تمام صارفین کے لیے ٹریسز کو غیر فعال کر سکتے ہیں، صرف خودکار میٹرکس چھوڑ کر، جن کا کم سے کم اوورہیڈ ہوتا ہے۔

مثال منطق: ایپ شروع کرتے وقت، Remote Config پیرامیٹر performance_tracing_enabled چیک کریں۔ اگر false — Firebase.performance.newTrace() کی تمام کالز ایک سٹب آبجیکٹ لوٹاتی ہیں جو ڈیٹا نہیں گرد کرتا۔ یہ ایک ریپر کلاس کے ذریعے عمل میں لایا جاتا ہے جو ٹریس بنانے سے پہلے فلیگ چیک کرتا ہے۔ یہ نقطہ نظر پورے سامعین کو متاثر کیے بغیر مخصوص صارفین (بیٹا ٹیسٹرز، ڈیولپرز) کے لیے مفصل ٹریسنگ کو فعال کرنے کی اجازت دیتا ہے۔