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, Cellular)। डेटा Firebase कंसोल के नेटवर्क अनुरोध डैशबोर्ड में एकत्रित किया जाता है।

धीमे अनुरोध — ऐसे अनुरोध जिनकी अवधि निर्धारित सीमा से अधिक है। डिफ़ॉल्ट रूप से, धीमे अनुरोध की सीमा 4000 ms है। यह मेट्रिक बैकएंड समस्याओं की पहचान करने के लिए महत्वपूर्ण है: यदि बैकएंड अपडेट के बाद धीमे अनुरोधों की संख्या 1% से 15% तक बढ़ जाती है, तो यह तत्काल सर्वर लॉग विश्लेषण का संकेत है। उपयोगकर्ता प्रतिक्रिया के लिए 5 सेकंड से अधिक प्रतीक्षा नहीं करेंगे — Firebase डेटा दिखाता है कि 53% उपयोगकर्ता ऐप बंद कर देते हैं यदि कोई अनुरोध 3 सेकंड से अधिक समय लेता है।

स्वचालित इंस्ट्रूमेंटेशन की सीमाएँ

iOS सीमाएँ: iOS पर, Performance SDK ड्रॉप किए गए फ़्रेम को माप नहीं सकता (यह एक निजी API है)। iOS पर jank मापने के लिए, MetricKit या CADisplayLink का उपयोग करें। साथ ही, iOS पर, SDK URLSession (जैसे SwiftNIO) का उपयोग न करने वाले तृतीय-पक्ष HTTP क्लाइंट के माध्यम से किए गए अनुरोधों को इंटरसेप्ट नहीं करता। ऐसे मामलों के लिए, 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 वर्णों तक की स्ट्रिंग हैं। ट्रेस शुरू होने से पहले विशेषताएँ निर्धारित की जानी चाहिए; शुरू होने के बाद विशेषता बदलना अनदेखा किया जाता है। यह सीमा प्रदर्शन से संबंधित है: शुरू होने के बाद विशेषताओं को स्थिर करने के लिए अतिरिक्त सिंक्रोनाइज़ेशन की आवश्यकता होगी।

प्रदर्शन सीमाएँ और अलर्ट

सीमाएँ (thresholds) मेट्रिक्स के लिए कॉन्फ़िगर करने योग्य सीमा मान हैं, जिन्हें पार करने पर 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 कंसोल में, प्रदर्शन अनुभाग पर जाएँ, 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 के माध्यम से ट्रेसिंग अक्षम करने की क्षमता को ध्यान में रखते हैं।

उपयोग करने से पहले, निर्भरता जोड़ें: implementation("com.google.firebase:firebase-perf") Firebase BOM के माध्यम से। स्वचालित इंस्ट्रूमेंटेशन के लिए, किसी अतिरिक्त सेटअप की आवश्यकता नहीं है — निर्भरता जोड़ने के बाद 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() के सभी कॉल एक स्टब ऑब्जेक्ट लौटाते हैं जो डेटा एकत्र नहीं करता। यह एक रैपर वर्ग के माध्यम से कार्यान्वित किया जाता है जो ट्रेस बनाने से पहले फ़्लैग की जाँच करता है। यह दृष्टिकोण पूरे दर्शकों को प्रभावित किए बिना विशिष्ट उपयोगकर्ताओं (बीटा परीक्षकों, डेवलपर्स) के लिए विस्तृत ट्रेसिंग सक्षम करने की अनुमति देता है।