Trace me if you can: Automated instrumentation and field profiling

राहुल रविकुमार

गुड आफ़्टरनून,

मेरा नाम राहुल है.

मैं Android डेवलपर एक्सपीरियंस टीम में इंजीनियर हूं.

मेरा फ़ोकस ऐप्लिकेशन और लाइब्रेरी की परफ़ॉर्मेंस पर होता है. इस बातचीत में, ट्रेसिंग के बारे में बताया गया है.

ट्रेसिंग के बारे में ज़्यादा जानने से पहले, मैं कुछ ऐसे शब्दों के बारे में बताना चाहता हूं जो हम सभी इस्तेमाल करते हैं. इससे आपको समझने में आसानी होगी.

इसलिए, इस बातचीत में जब भी मैं ट्रेसिंग की बात करूं, तो इसका मतलब है कि मैं साफ़ तौर पर ट्रेसिंग की बात कर रहा हूं. इसमें कोड को मैन्युअल तरीके से इंस्ट्रुमेंट किया जाता है, ताकि आपको पता चल सके कि ऐप्लिकेशन क्या कर रहा है.

मैं ऑटोमैटिक प्रोफ़ाइलर के बारे में बात नहीं कर रहा हूं. इसके बारे में मैं बाद में बताऊंगा.

मैन्युअल ट्रेसिंग, आपके कोड बेस में ब्रेडक्रंब छोड़ने की कला है. इससे आपको बाद में परफ़ॉर्मेंस से जुड़ी समस्या या किसी अन्य समस्या का पता लगाने में मदद मिलती है.

आम तौर पर, यह लॉग से बेहतर होता है.

इसलिए, मुझे नहीं पता कि आपने किसी बड़े ऐप्लिकेशन का Logcat आउटपुट देखा है या नहीं.

आम तौर पर, यह टेक्स्ट का एक बड़ा हिस्सा होता है, जिसे आसानी से नहीं समझा जा सकता.

वहीं दूसरी ओर, ट्रेसिंग काफ़ी बेहतर है.

इससे डेटा को विज़ुअलाइज़ करना आसान हो जाता है.

आपके पास अवधि है.

आपके पास कुछ स्ट्रक्चर है.

आपके पास कुछ टूल हैं. इसलिए, डेटा को अलग-अलग हिस्सों में बांटकर, यह देखा जा सकता है कि किस समय क्या हुआ.

इसलिए, यह ज़्यादा बेहतर है.

साथ ही, अपने एजेंट को किसी ट्रेस पर ले जाकर सवाल पूछने के लिए कहा जा सकता है.

ट्रेस प्रोसेसर और मानदंड जैसे टूल इस्तेमाल किए जा सकते हैं. साथ ही, ट्रेस को मेट्रिक में बदला जा सकता है.

इसलिए, ट्रेस की मदद से ऐसे कई काम किए जा सकते हैं जो Logcat की मदद से करना मुश्किल होता है.

दूसरी ओर, प्रोफ़ाइलिंग और ऑटोमैटिक प्रोफ़ाइलिंग, आम तौर पर किसी ऐसी समस्या का जवाब होती है जिसके बारे में आपको पता होता है.

उदाहरण के लिए, आपने देखा होगा कि आपका ऐप्लिकेशन धीरे-धीरे शुरू होता है या उसमें कुछ गड़बड़ी है. ऐसे में, आपको इस समस्या को कम करना है और यह पता लगाना है कि क्या हो रहा है.

अगर इस समय आपके पास मैन्युअल ट्रेस की सुविधा नहीं है, तो ऑटोमैटिक प्रोफ़ाइलिंग की सुविधा का इस्तेमाल किया जा सकता है.

ऐसा हो सकता है कि आपने एआरटी के तरीकों की सूची का इस्तेमाल किया हो. इसमें हर तरीके की एंट्री और एग्ज़िट को इंस्ट्रुमेंट किया जाता है.

इसके अलावा, हो सकता है कि आप Simpleperf जैसे टूल की मदद से स्टैक सैंपलिंग देख रहे हों.

इसलिए, हर तरीके की एंट्री और एग्ज़िट का इस्तेमाल करने और ज़्यादा ओवरहेड होने के बजाय, कॉल स्टैक के सैंपल देखें. साथ ही, देखें कि आपके ऐप्लिकेशन के हॉट पाथ पर क्या है.

साल 2026 में, रैम की समस्या हर जगह है. इसलिए, हो सकता है कि आपको मेमोरी, मेमोरी लीक, और हीप प्रोफ़ाइलें देखनी पड़ें.

इसलिए, यह एक और प्रोफ़ाइलर है जिसका फ़ायदा लिया जा सकता है.

आपको पता है कि हीप रिटेंशन पाथ देखे जा सकते हैं.

यह देखा जा सकता है कि कौनसा कोड मेमोरी को ऐलोकेट कर रहा है. इस टूल की मदद से, इस तरह के सभी विश्लेषण किए जा सकते हैं.

दाईं ओर.

अब हमारे पास वह शब्दावली है.

अब बात करते हैं कि हमने नई लाइब्रेरी क्यों बनाई.

ट्रेसिंग एपीआई, 1.0 एपीआई को मूल रूप से Android Jelly Bean में पेश किया गया था.

यह 2012 की बात है.

यह 14 साल से भी पहले की बात है.

इसके बाद से, एपीआई में उतना बदलाव नहीं हुआ है जितना आपको लगता है.

हमने कुछ एक्सटेंशन जोड़े हैं.

Android 10 में, एसिंक्रोनस इवेंट और काउंटर जोड़े गए.

यह 2019 की बात है.

बस इतना ही.

इसके बाद से, एपीआई में कोई बदलाव नहीं किया गया है.

हालांकि, अब इस नेटवर्क में काफ़ी बदलाव आ गया है.

इसलिए, प्लैटफ़ॉर्म ट्रेसिंग में काफ़ी सुधार हुआ है. हालांकि, एपीआई में जोड़े गए किसी भी फ़ंक्शन का फ़ायदा आपको नहीं मिला है.

हम इस स्थिति को बदलना चाहते हैं.

दूसरी बड़ी समस्या यह है कि ट्रेसिंग में 1.0 में एक तय ट्रेसिंग बैक एंड होता है. इसका मतलब है कि जब भी कोड में ट्रेस सेक्शन जोड़ा जाता है, तो वह हमेशा सिस्टम ट्रेस बफ़र में खत्म होता है.

Atrace, Android का ट्रेसिंग सबसिस्टम है. इसके पास डेटा का मालिकाना हक होता है.

इसलिए, अगर आपको अपने ट्रेस को फ़ील्ड टेलीमेट्री में बदलना है, तो यह बहुत मुश्किल है. इसकी वजह यह है कि अब आपको यह समझना होगा कि atrace उस डेटा को कैसे सेव करता है.

यह अच्छी तरह से तैयार किया गया फ़ॉर्मैट है, लेकिन इसे समझना मुश्किल हो सकता है.

इसलिए, हम इस समस्या को ठीक करना चाहते हैं.

इसलिए, हम आपको ऐसे टूल उपलब्ध कराना चाहते हैं जिनकी मदद से, ट्रेसिंग डेटा को अपनी पसंद के मुताबिक कहीं भी ले जाया जा सके.

इसके अलावा, ट्रेसिंग 1.0 में एक पाबंदी थी. इसके तहत, लेबल में 128 से ज़्यादा वर्ण नहीं हो सकते थे.

साल 2012 में यह पाबंदी शायद सही थी, लेकिन साल 2026 में यह अजीब लगती है.

इससे भी ज़्यादा खराब बात यह है कि ट्रेस में कोई अतिरिक्त मेटाडेटा नहीं जोड़ा जा सकता. इससे और भी ज़्यादा समस्या होती है.

इसके बाद, ओवरहेड की बारी आती है.

इसलिए, जब भी ऐप्लिकेशन को ट्रेस किया जाए, तो आपको ओवरहेड के बारे में बहुत ज़्यादा जानकारी होनी चाहिए. ऐसा इसलिए, क्योंकि किसी सिस्टम को मॉनिटर करने से, सिस्टम के बैकग्राउंड में होने वाली प्रोसेस में कोई बदलाव नहीं होना चाहिए.

इसलिए, अगर आपको किसी रेस कंडिशन को फिर से जनरेट करना है, तो ट्रेस करने से रेस कंडिशन खत्म नहीं होनी चाहिए.

इसलिए, आपको यह पक्का करना होगा कि आपने सभी सिमैंटिक को सुरक्षित रखा हो.

ट्रेसिंग 1.0 में ओवरहेड काफ़ी ज़्यादा था. इसलिए, हम इसे बेहतर बनाना चाहते थे.

ठीक है।

मैंने समस्याओं के बारे में बहुत बात की.

अब, कुछ समस्याओं को विज़ुअल के तौर पर देखते हैं और यह समझते हैं कि असल में ये समस्याएं कैसे बढ़ती हैं.

यहां हमारे पास एक Perfetto ट्रेस है.

यह com.example.app ऐप्लिकेशन के लिए है.

हमारे पास एक मुख्य थ्रेड है और initializeComponent नाम का एक स्लाइस है.

अब हमें कुछ और जानकारी चाहिए.

इसलिए, चलिए इसमें कुछ जानकारी जोड़ते हैं.

इसलिए, अब हमें पता है कि initializeComponent, performInitialize को कॉल करता है.

हमें अब भी नहीं पता कि कौनसा कॉम्पोनेंट शुरू किया जा रहा है.

अब हमारे टूल बेल्ट में, Tracing 1 वाला सिर्फ़ एक टूल है. इसका नाम है, स्लाइस का नाम. इसलिए, हम इसे स्लाइस के नाम में जोड़ते हैं.

ध्यान रखें कि ट्रेसिंग स्लाइस के नाम में 128 से ज़्यादा वर्ण नहीं होने चाहिए. अगर ऐसा होता है, तो आपके ट्रेस में नाम छोटा हो जाता है.

अब, जले पर नमक छिड़कने के लिए, ट्रंकेट करने का ओवरहेड भी अब ओवरहेड है जो आपको ट्रेस करते समय होता है.

इसलिए, अब आपको यह समस्या जल्दी ही आ जाती है.

इसलिए, हम इस समस्या को ठीक करना चाहते थे.

आपने Perfetto ट्रेस देखा और यह भी देखा कि यह विज़ुअल तौर पर कैसा दिखता है.

अब, ट्रेस सेक्शन को एमिट करने के लिए कोड लिखने के नज़रिए से देखते हैं.

हमारे पास initializeComponent एपीआई भी है.

यह कॉन्टेक्स्ट और नाम लेता है. इसके बाद, performInitialize को कॉल करता है.

अब तक सब ठीक है.

अब हमें Tracing 1.0 API की मदद से एक ट्रेस जोड़ना है. इसके लिए, androidx.tracing.trace को इंपोर्ट करें और ट्रेस ब्लॉक का इस्तेमाल करें.

इसे कोई नाम दें.

यहां performInitialize है.

हालांकि, जैसा कि हम पहले करना चाहते थे, हमें कॉम्पोनेंट का नाम जानना था. इसलिए, हम Kotlin के स्ट्रिंग इंटरपोलेशन का इस्तेमाल करेंगे और नाम जोड़ेंगे.

पहली समस्या यह है.

इसलिए, यहां 128 वर्णों की सीमा है.

राहुल रविकुमार

हम Tracing 2 की मदद से इसे ठीक कर सकते हैं.

androidx.tracing.trace के बजाय, Tracer का इस्तेमाल किया जा रहा है.

एपीआई काफ़ी हद तक एक जैसा दिखता है.

आपके पास trace के बजाय, Tracer.global.trace है.

आपके पास कोई कैटगरी है.

हम कैटगरी के बारे में आगे और डिटेल में बात करेंगे. हालांकि, बुनियादी तौर पर आपके पास एक नाम होता है.

इसके बाद, आपके पास कोड का वह ब्लॉक अब भी मौजूद होता है जिसे आपको ट्रेस करना है.

अब आपको 128 वर्णों की सीमा का पालन करने की ज़रूरत नहीं है.

मैंने ट्रेसिंग ओवरहेड के बारे में बात की.

मैं इस बारे में थोड़ा और विस्तार से बताना चाहता हूं कि हमने इसे कैसे बेहतर बनाया है.

Android 16 पर चलने वाले Pixel 6a पर, एक शुरुआत और एक आखिरी सेक्शन को शामिल करने में करीब 1,200 नैनोसेकंड लगे.

यह समय ज़्यादा नहीं लग सकता है. हालांकि, अगर आपके पास ऐसा कोड है जो बहुत सारे ट्रेस सेक्शन जोड़ रहा है, तो यह वह समय है जो आपका ऐप्लिकेशन फ़्रेम रेंडर करने में खर्च कर सकता है.

इसलिए, हम आपका वह समय नहीं लेना चाहते.

हमने AndroidX Perfetto SDK की मदद से, इस समस्या को काफ़ी हद तक कम कर दिया है.

यह एक एक्सपेरिमेंटल एसडीके था, जिसे हमने कंपोज़िशन ट्रेसिंग के लिए पेश किया था. इससे हमें काफ़ी मदद मिली.

हम नहीं चाहते कि आप इसे शिप करें, क्योंकि यह JNI बाइंडिंग वाला Perfetto C SDK टूल है. साथ ही, C SDK टूल आपके APK में करीब 4 एमबी का है.

हम नहीं चाहते थे कि आप कभी भी इस तरह का कॉन्टेंट अपलोड करें.

इसलिए, अब Tracing 2 के साथ, हमारे पास एक खास लाइब्रेरी है.

हमने ओवरहेड को काफ़ी बेहतर बनाया है. अब आपको यह जानकर खुशी होगी कि Tracing 2 सात गुना ज़्यादा तेज़ है. इसका मतलब है कि आपके पास उन चीज़ों को करने के लिए ज़्यादा समय है जो आपको करनी थीं. साथ ही, इंफ़्रास्ट्रक्चर में कम समय लगता है.

इस तरह की सुविधा से क्या मुमकिन हो पाया है, जो पहले मुमकिन नहीं था?

उदाहरण के लिए, Metro की रनटाइम ट्रेसिंग सुविधा.

मेट्रो, डिपेंडेंसी इंजेक्शन लाइब्रेरी है.

यह Kotlin Multiplatform के साथ काम करता है.

यह Kotlin कंपाइलर प्लगिन का इस्तेमाल करता है.

यह डिपेंडेंसी इंजेक्शन के लिए पूरा कोड जनरेट करता है. साथ ही, यह Tracing 2.0 के साथ इंटिग्रेट होता है, ताकि आपके कोड में मौजूद हर @Inject की लागत को आसानी से विज़ुअलाइज़ किया जा सके.

यहां एक उदाहरण दिया गया है.

मान लें कि हमारे पास एक ऐप्लिकेशन ग्राफ़ है.

Metro में, हर चीज़ को ग्राफ़ के दायरे में रखा जाता है. इसलिए, हमारे पास एक ही फ़ील्ड, AnalyticsTracker है.

हमारे पास एक प्रोवाइड्स बाइंडिंग भी है.

हमारे पास एक नेटवर्क क्लाइंट है, जिसमें OkHttpClient को impl के तौर पर इस्तेमाल किया गया है. इसके बाद, AnalyticsTracker को AnalyticsTrackerImpl से लागू किया जाता है. हमें नेटवर्क क्लाइंट के एक इंस्टेंस की ज़रूरत है, जिसे उपलब्ध कराने का तरीका ग्राफ़ को पता है.

इसलिए, कंपाइलर प्लगिन ऐसा कोड जनरेट करता है जो इस तरह दिखता है.

इसलिए, अगर आपके पास AnalyticsTracker है, तो गेटर, नेटवर्क क्लाइंट का एक इंस्टेंस बनाता है और उसे AnalyticsTrackerImpl के कंस्ट्रक्टर को पास करता है. यह एक अच्छी बात है.

हालांकि, अब ट्रेसिंग की सुविधा चालू होने पर, ट्रैकर इंप्लिमेंटेशन के साथ-साथ, हर डिपेंडेंसी को बनाने की लागत देखी जा सकती है.

इसलिए, अब हम आपके लिए यह संभव बनाते हैं कि आप न सिर्फ़ टाइप को इंस्टैंशिएट करने की लागत देख सकें, बल्कि ट्रेस में उसकी सभी डिपेंडेंसी भी देख सकें. यह वाकई बहुत असरदार है.

इस जानकारी का इस्तेमाल करके, फ़ाइनेंस से जुड़े ऐप्लिकेशन Wise ने अपने ऐप्लिकेशन के स्टार्टअप को 45% तक बेहतर बनाया.

उन्होंने उन चीज़ों को टाल दिया जिन्हें ऐप्लिकेशन के स्टार्टअप के दौरान शुरू करना ज़रूरी नहीं था. साथ ही, उन्होंने कुछ ऐसे आइटम की पहचान की जिन्हें गलत तरीके से स्कोप किया गया था. इनमें ऐसी चीज़ें शामिल थीं जिन्हें सिंगलटन होना चाहिए था, लेकिन वे गलती से सिंगलटन नहीं थीं. ये ऐसी चीज़ें हैं जिन्हें अपने कोड में देखा जा सकता है और आसानी से ठीक किया जा सकता है.

अगर आप उनके स्टार्टअप की मेट्रिक देखें, तो वे वाकई शानदार हैं.

इससे न सिर्फ़ शुरुआती फ़्रेम दिखने में लगने वाले समय में सुधार हुआ, बल्कि पूरा डिसप्ले दिखने में लगने वाले समय में भी सुधार हुआ.

एक अन्य पार्टनर, BandLab, सीआई पर इसी जानकारी का इस्तेमाल करता है.

इसलिए, आपको न सिर्फ़ हर एक @Inject बाइंडिंग की लागत पता होती है, बल्कि यह भी पता होता है कि किस थ्रेड की वजह से वह लागत आई है.

इसलिए, जब आपको यह पता चल जाए, तो आपको मुख्य थ्रेड पर सभी महंगे @Inject बाइंडिंग मिल सकते हैं. साथ ही, अपने सीआई में, क्वेरी चलाकर यह कहा जा सकता है कि मुझे सभी महंगे बाइंडिंग की सूची दें. इसके बाद, इसे उस बदलाव के लिए एट्रिब्यूट करें जिसने उन्हें पेश किया है. इसके बाद, अब असल बदलाव को दोष दिया जा सकता है और उसे ठीक करने की कोशिश की जा सकती है.

राहुल रविकुमार

ठीक है।

अब तक, मैंने उन सभी चीज़ों के बारे में बात की है जिन्हें हमने Tracing 1 के मुकाबले बेहतर बनाया है. हालांकि, अब मैं Tracing 2 में मौजूद उन नई सुविधाओं के बारे में बात करने जा रहा हूं जो पहले कभी संभव नहीं थीं.

इसलिए, इसकी मुख्य सुविधाओं में से एक को कॉन्टेक्स्ट प्रोपेगेशन कहा जाता है. साथ ही, आधुनिक ऐप्लिकेशन ज़्यादा से ज़्यादा जटिल होते जा रहे हैं, इसलिए वर्कलोड कई थ्रेड, कई कोरूटीन, और कई प्रोसेस में चलते हैं.

आपको यह देखना है कि हर थ्रेड और प्रोसेस के बीच कोई अनुरोध कैसे आगे बढ़ता है.

कॉन्टेक्स्ट प्रोपेगेशन की मदद से ऐसा किया जा सकता है.

इसलिए, अगर मैं आपको स्लाइस की एक सूची दूं और यह न बताऊं कि किस वजह से क्या हुआ, तो वे काम की तो हैं, लेकिन उनके बारे में तर्क करना बहुत आसान नहीं है.

लेकिन अगर मैं आपको बताऊं कि यह इवेंट की वजह से होने वाली घटनाओं का क्रम है, तो आपके लिए यह समझना बहुत आसान हो जाएगा कि क्या हो रहा था. इसके बाद, हर स्लाइस की लागत को जोड़ा जा सकता है.

कॉन्टेक्स्ट प्रोपेगेशन की मदद से, यह जानकारी उपलब्ध कराई जाती है.

आपको यह जानकर खुशी होगी कि कॉन्टेक्स्ट प्रोपेगेशन पूरी तरह से काम करता है. यहां इसका एक असल उदाहरण दिया गया है.

com.example.app Perfetto ट्रेस को फिर से देखें. मान लें कि performInitialize में बहुत ज़्यादा समय लग रहा था और आपको लागत को टालना था या उसे किसी दूसरे थ्रेड पर ले जाना था.

यह काम आप आसानी से कर सकते हैं.

मान लें कि मैंने performInitialize को किसी दूसरे थ्रेड में भेज दिया.

अब आपके पास स्लाइस का हैरारकी वाला नेचर नहीं है.

इसलिए, अब यह नहीं कहा जा सकता कि initializeComponent की वजह से performInitialize हुआ. हालांकि, कोड देखकर यह पता लगाया जा सकता है.

एक आदर्श दुनिया में, आपको एक तीर चाहिए होगा जो आपको बताए कि A की वजह से B हुआ. इसके बाद, आप घटनाओं की वजहों के बारे में सोच सकते हैं.

आपने शायद सिस्टम ट्रेस करने की प्रक्रिया देखी हो, जिसमें हम प्लैटफ़ॉर्म पर बाइंडर ट्रांज़ैक्शन के लिए ऐसा करते हैं.

यहां देखा जा सकता है कि Compose बेंचमार्क, फ़्रेम तैयार करने के लिए system_server को बाइंडर ट्रांज़ैक्शन भेजता है.

इसलिए, प्लैटफ़ॉर्म ट्रेसिंग के नज़रिए से यह हमेशा से संभव रहा है. हालांकि, हमने ऐप्लिकेशन डेवलपर के लिए टूल कभी उपलब्ध नहीं कराए.

इसलिए, अब Tracing 2.0 में Kotlin कोरूटीन कॉन्टेक्स्ट प्रोपेगेशन की सुविधा पूरी तरह से काम करती है.

आपको कुछ नहीं करना है.

यह सुविधा आपको पहले से ही मिलती है.

इसलिए, यहां हमारे पास fetchProfile नाम का एक सस्पेंड मेथड है.

यह client.get को कॉल करता है, जो कि निलंबित करने का एक और तरीका है. इसके बाद, यह जवाब को डीसीरियलाइज़ करने के लिए, Dispatchers.Default पर स्विच करता है.

यह बहुत ही सामान्य कोरूटीन कोड है. शायद आपको हर दिन इस तरह के कोड का इस्तेमाल करना पड़ता हो.

अब मान लीजिए कि हमें इसे ट्रेस करना है.

हम एक ट्रेस सेक्शन जोड़ते हैं.

इसलिए, यहां ट्रेस के बजाय, हम traceCoroutine एपीआई का इस्तेमाल करेंगे. ऐसा इसलिए, क्योंकि यह कोड का सस्पेंडिंग ब्लॉक है. इसके बाद, Dispatchers.Default पर स्विच करने से पहले, इनर कॉल के लिए, हम उसी traceCoroutine एपीआई का इस्तेमाल करके, एक और इनर ट्रेस सेक्शन जोड़ेंगे.

अब आपको ट्रेस में कुछ ऐसा दिखेगा.

आपको दिखेगा कि हमारा काम worker-1 में शुरू हुआ और फिर, यह कॉन्टेक्स्ट-स्विच होकर worker-3 पर चला गया. आपको ट्रेस में मददगार ऐरो दिखेंगे, जो इस बात की ओर इशारा करते हैं.

इतना ही नहीं, अगर बीच में मौजूद स्क्वेयर को ज़ूम इन किया जाए, तो देखा जा सकता है कि डीसीरियलाइज़ेशन असल में वर्कर-1 में शुरू हुआ था. साथ ही, withContext को किए गए कॉल की वजह से कॉन्टेक्स्ट स्विच हुआ. इसके बाद, यह वर्कर-3 पर जारी रहा और फिर fetchProfile वर्कर-3 पर फिर से शुरू हुआ. ऐसा इसलिए हुआ, क्योंकि कोरूटीन मशीनरी, कॉन्टेक्स्ट स्विच की संख्या को कम से कम करना चाहती है.

इससे आपको यह पता चलता है कि कोई कोरूटीन कब निलंबित हुआ और कब फिर से शुरू हुआ. साथ ही, आपको इवेंट की पूरी चेन दिखती है.

Tracing 2 की मदद से, ट्रेस में कस्टम मेटाडेटा भी जोड़ा जा सकता है.

इसलिए, पहले आपके पास सिर्फ़ ट्रेस सेक्शन के नाम का टूल था. हालांकि, अब इसके साथ-साथ मेटाडेटा ब्लॉक भी जोड़ा जा सकता है. इससे आपको जितनी चाहें उतनी मेटाडेटा एंट्री जोड़ने की सुविधा मिलती है.

इसके बाद, उसे ट्रेस में जोड़ा जा सकता है.

असल ट्रेस को देखने पर, यहां आपको दिखेगा कि आपने जो मेटाडेटा जोड़ा है वह असल में ट्रेस में मौजूद है. इससे सभी टूल, ट्रेस को इस्तेमाल कर सकते हैं.

इसलिए, अब आपके पास अपनी जानकारी और अन्य ज़रूरी जानकारी को एम्बेड करने का विकल्प है.

मैंने आपको ट्रेसिंग की मदद से मिलने वाली कई सुविधाओं के बारे में बताया. हालांकि, Jetpack Compose में एक नई सुविधा जोड़ी गई है, जिसे रीकंपोज़िशन ट्रेसिंग कहा जाता है.

इसे Compose 1.13 के हिस्से के तौर पर शिप किया गया है. इसलिए, यह आज से ही इस्तेमाल के लिए उपलब्ध है.

यहां एक उदाहरण दिया गया है.

यह कंपोज़िशन ट्रेसिंग है, जिसके बारे में आप सभी जानते होंगे.

यह Compose के शुरुआती दिनों से मौजूद है.

इससे आपको कंपोज़ेबल और उसके सभी सबस्लाइस की लागत के बारे में पता चलता है. साथ ही, यह भी पता चलता है कि जिस थ्रेड में वे हो रहे थे उसमें हर एक की लागत कितनी थी.

इसलिए, यह काफ़ी आसान है.

इससे आपको कॉन्टेक्स्ट का पता नहीं चलता.

इससे आपको यह नहीं पता चलता कि ऐसा क्यों हुआ.

यह आपको यह नहीं बताता कि चीज़ों को फिर से क्यों कंपोज़ किया गया.

अगर मैं ज़ूम आउट करूं, तो यह वही इलाका है जिसे हम पिछली स्लाइड में देख रहे थे.

बाईं ओर, आपको डिस्पैच इनपुट इवेंट दिखेगा.

शायद इसी वजह से कुछ स्टेट में बदलाव हुआ और शायद इसी वजह से रीकंपोज़िशन हुआ.

हालांकि, इस बारे में साफ़ तौर पर कुछ नहीं कहा जा सकता.

आपको पक्के तौर पर नहीं पता.

हालांकि, रीकंपोज़िशन ट्रेसिंग की मदद से, अब हम ट्रेस में कस्टम मेटाडेटा जोड़ते हैं. इससे आपको पता चलता है कि रीकंपोज़िशन क्यों हुआ.

इतना ही नहीं, अब आपके लिए यह बताना बहुत आसान हो गया है कि ये इवेंट एक-दूसरे से जुड़े हैं.

इसके बाद, उन पर क्लिक करने से आपको पता चलेगा कि किस स्थिति में बदलाव हुआ है.

यह आपको बताएगा कि यह एक स्टेट थी. यह एक ऐसी म्यूटेबल स्टेट वैल्यू थी जिसे 'गलत है' पर स्विच किया गया था. पहले यह 'सही है' पर सेट थी.

इतना ही नहीं, हम आपको उस कॉल स्टैक के बारे में भी बताएंगे जिसकी वजह से ऐसा हुआ.

यहां देखा जा सकता है कि AbstractClickableNode.performClick हुआ. इसकी वजह से, म्यूटेबल स्टेट में बदलाव हुआ और फिर से कंपोज़िशन हुआ.

यह वाकई बहुत शानदार है. हम पहले ऐसा नहीं कर पाते थे.

ये टूल भी उपलब्ध हैं. माफ़ करें, ये सभी सुविधाएं नए Android Performance Analyzer टूल में भी उपलब्ध हैं. अगर आपको एजेंटिक टूल इस्तेमाल करने हैं, तो उन्हें आज़माएं.

और दाईं ओर.

मैंने आपको बताया था कि Kotlin कोरूटीन के लिए, कॉन्टेक्स्ट प्रोपेगेशन की सुविधा पूरी तरह से काम करती है.

लेकिन, उस कोड का क्या जो कोरूटीन और नॉन-कोरूटीन कोड के मिश्रण का इस्तेमाल करता है या शायद आप खुद थ्रेड चला रहे हैं या शायद आपके पास कुछ ब्राउनफ़ील्ड कोड है, जो बहुत पुराना है और किसी वजह से कॉलबैक का इस्तेमाल करता है?

ठीक है।

इसलिए, अच्छी बात यह है कि आपको अब भी कॉन्टेक्स्ट प्रोपेगेशन के सभी फ़ायदे मिल सकते हैं.

मान लें कि हमारे पास एक ब्राउनफ़ील्ड एपीआई है, जो कॉलबैक और एक्ज़ीक्यूटर का इस्तेमाल करता है.

लागू करने के लिए, executor.execute का इस्तेमाल किया जाता है. साथ ही, runCatching को कॉल किया जाता है. यह लागू करने की जानकारी है. इसके बाद, रिस्पॉन्स मिलता है और फिर कॉलबैक को रिस्पॉन्स के बारे में बताया जाता है.

ठीक है।

अब अगर मुझे इसे ट्रेस करना है, तो मैं Tracer.global.trace का इस्तेमाल करूंगा, इसे एक लेबल दूंगा, और फिर ब्लॉक को घेर दूंगा.

हालांकि, मुझे इवेंट की कैज़ुअल चेन को भी सुरक्षित रखना है. इसलिए, मैं एक नया और वैकल्पिक टाइप स्वीकार करूंगा. इसे प्रोपेगेशन टोकन कहा जाता है.

इसके बाद, मैं टोकन को इनर ट्रेस एपीआई को पास कर दूंगा.

इसलिए, जो भी इस तरीके को कॉल कर रहा है वह मुझे प्रोपेगेशन टोकन दे सकता है, ताकि मैं होने वाले इवेंट की कैज़ुअल चेन को सुरक्षित रख सकूं.

ठीक है।

अब उस एपीआई को कॉल करने वाला एपीआई, सस्पेंड करने वाला एपीआई हो सकता है.

इसलिए, यहां मेरे पास एक suspend fun profileRequest है, जो अब उस एपीआई को कॉल करेगा जो कॉलबैक और एक्ज़ीक्यूटर का इस्तेमाल करता है.

यहां मैं दो अलग-अलग दुनिया को जोड़ रहा हूं. मैं सस्पेंडिंग फ़ंक्शन की दुनिया को कॉलबैक की दुनिया से जोड़ रहा हूं. इसलिए, मैं suspendCoroutine बिल्डर का इस्तेमाल करूंगा.

मुझे एक कंटीन्यूएशन मिलेगा. इसके बाद, मैं एपीआई को शुरू करूंगा और जवाब मिलने पर, कॉलबैक में कंटीन्यूएशन को फिर से शुरू करूंगा.

इसके बाद, यहां वह एक्ज़ीक्यूटर है जिसे मैंने profileRequestContext के तौर पर तय किया है.

यह एक सिंगल-थ्रेड एक्ज़ीक्यूटर है.

traceCoroutine, कोरूटीन कॉन्टेक्स्ट में प्रोपेगेशन टोकन को एम्बेड करता है. इसलिए, मैं कोरूटीन कॉन्टेक्स्ट से प्रोपेगेशन टोकन हासिल कर सकता हूं. इसके बाद, उसे ब्राउनफ़ील्ड एपीआई में इनपुट के तौर पर पास कर सकता हूं. इससे मैं इवेंट की कैज़ुअल चेन को अब भी सुरक्षित रख सकता हूं.

ट्रेस में यह साफ़ तौर पर दिखता है.

इसलिए, यहां आपके पास कुछ ऐसा है जो worker-3 में शुरू हुआ और सिंगल-थ्रेडेड एक्ज़ीक्यूटर पर स्विच हो गया. ऐसा तब हुआ, जब हमने कॉन्टेक्स्ट स्विच किया और फिर वर्कर पर वापस आ गए.

इसलिए, यह काफ़ी अच्छा है.

राहुल रविकुमार

ठीक है।

इसके अलावा, Tracer.global को अपनी पसंद के मुताबिक बनाया जा सकता है.

अब तक, Tracing 2.0 API आपको Tracer.global के लिए बहुत अच्छे डिफ़ॉल्ट देता है, लेकिन अगर आप इसे कभी भी पसंद के मुताबिक बनाना चाहते हैं, तो आप कर सकते हैं.

साथ ही, Tracing 2.0, जेवीएम और Android के साथ काम करता है. ऐसा इसलिए, क्योंकि हम चाहते हैं कि ट्रेसिंग की सुविधा, Java और Android, दोनों लाइब्रेरी के साथ पूरी तरह काम करे.

इनिशलाइज़ेशन के तीन चरण हैं. पहला, ट्रेस सिंक बनाना.

ट्रेस सिंक, ट्रेस पैकेट को स्टोर करने का एक तरीका है.

यह वायर फ़ॉर्मैट और आउटपुट ट्रेस की जगह तय करता है, जहां उन्हें सेव किया जाता है.

हम आपको ट्रेस सिंक के लिए, पहले से तैयार एक इंप्लिमेंटेशन देते हैं. यह Perfetto फ़ॉर्मैट के साथ काम करता है. हालांकि, आपके पास अपना ट्रेस सिंक लिखने का विकल्प भी होता है.

यह समस्या को हल करने की कोशिश करने के लिए वापस जाता है. यह समस्या यह थी कि Tracing 1 में atrace ही एकमात्र बैकएंड उपलब्ध था.

हम इस समस्या को ठीक करना चाहते थे.

इसलिए, अब अगर आपको OpenTelemetry सिंक लिखना है या अपना सिंक लाना है, तो ऐसा किया जा सकता है.

आपके पास इसे बदलने का विकल्प होता है.

सिंक बनाने के बाद, ट्रेस ड्राइवर बनाया जा सकता है और उसे सिंक दिया जा सकता है.

इसके बाद, आपके पास यह चुनने का विकल्प भी होता है कि आपको कौनसी कैटगरी चालू करनी हैं.

इसलिए, इस मामले में कैटगरी काफ़ी काम आती हैं.

इसलिए, यह तय किया जा सकता है कि डीबग की तुलना में, रिलीज़ में कुछ कैटगरी ज़्यादा अहम हैं. साथ ही, यह भी तय किया जा सकता है कि आपको कौनसी कैटगरी चालू करनी हैं.

इसके अलावा, यह भी कहा जा सकता है कि "मुझे सभी कैटगरी चालू करनी हैं, भले ही वे कहीं से भी आई हों."

यह बिलकुल ठीक है.

आपके पास ऐसे कस्टम एट्रिब्यूट जोड़ने का विकल्प भी होता है जो आपके ट्रेस के लिए ग्लोबल हों.

इसलिए, addAttribute एपीआई का इस्तेमाल करके, ट्रेस में बिल्ड वर्शन, फ़्लेवर या कोई अन्य मेटाडेटा अटैच किया जा सकता है.

आखिर में, setGlobalTracer पर कॉल करके ट्रेसर को रजिस्टर किया जा सकता है.

यह Tracer.global को ट्रेसर के इस इंस्टेंस से बाइंड करता है. इसके बाद, यह प्रोसेस के लिए उपलब्ध होता है.

Android पर, प्रोसेस की लाइफ़साइकल को बेहतर तरीके से तय किया जाता है. इसलिए, आपको सिर्फ़ AbstractTraceDriver.Factory को लागू करना होगा और इसके create तरीके को बदलना होगा. इसके बाद, आपको वही करना होगा जो आपने पहले किया था.

इसलिए, सिंक और ड्राइवर को अलग-अलग बनाया जाता है.

आपको यहां रजिस्टर करने की ज़रूरत नहीं है.

हम आपके लिए रजिस्ट्रेशन कर देंगे, क्योंकि हमें पता है कि पहले यही हुआ था.

ठीक है।

ठीक है, हम फिर से बताना चाहते हैं कि ट्रेसिंग की सुविधा, कई प्लैटफ़ॉर्म पर उपलब्ध है.

हमने ऐसा जान-बूझकर किया है, क्योंकि हमें पता है कि Compose कई प्लैटफ़ॉर्म पर काम करता है. हम चाहते हैं कि आप ज़्यादा से ज़्यादा जगहों पर ट्रेस कर सकें.

फ़िलहाल, हम Android और जेवीएम के साथ काम करते हैं. हालांकि, हमने इसे इस तरह से लागू किया है कि आने वाले समय में हम अन्य प्लैटफ़ॉर्म के साथ भी काम कर सकें.

राहुल रविकुमार

आपको यह जानकर खुशी होगी कि Android पर सोर्स कोड को छोटा और ऑप्टिमाइज़ करने के लिए इस्तेमाल किया जाने वाला टूल R8, Tracing 2.0 का इस्तेमाल करता है.

ट्रेस का फ़ायदा उठाकर, हमने R8 को ऑप्टिमाइज़ किया है, ताकि आपके कोड को 25% तेज़ी से छोटा और ऑप्टिमाइज़ किया जा सके.

इसका मतलब है कि बिल्ड बनाने में कम समय लगता है और ऑप्टिमाइज़ेशन पास के लिए कम इंतज़ार करना पड़ता है.

मैं R8 में किए गए हर ऑप्टिमाइज़ेशन के बारे में नहीं बताऊंगा. हालांकि, मैं सिर्फ़ एक ऑप्टिमाइज़ेशन के बारे में बताऊंगा, ताकि आपको पता चल सके कि ट्रेसिंग से क्या-क्या किया जा सकता है.

इसलिए, R8 बुनियादी तौर पर एक सोर्स-टू-सोर्स ट्रांसफ़ॉर्मर है.

इसलिए, आपको JARs का एक बंडल मिलता है. इसके बाद, उन्हें छोटा और ऑप्टिमाइज़ किया जाता है. साथ ही, JARs का एक और सेट बनाया जाता है जिसे dex किया जा सकता है.

इसलिए, यहां एजीपी, JARs को पढ़कर शुरू होता है. इसमें सिर्फ़ आपका ऐप्लिकेशन नहीं, बल्कि उसकी सभी डिपेंडेंसी भी शामिल होती हैं.

इसलिए, यह सभी इनपुट JAR को पढ़ना शुरू करने के लिए, Gradle वर्कर का इस्तेमाल करता है.

आपके पास पढ़ने के लिए कई JAR हैं.

इसके बाद, JARs को पढ़ने के बाद, R8 कोड को पार्स करना शुरू करता है. साथ ही, आपके कोड और उसके सभी एंट्री पॉइंट को दिखाने वाला मॉडल बनाता है, ताकि वह आपके कोड को ऑप्टिमाइज़ और छोटा करना शुरू कर सके.

अब, यह स्लाइस, इंतज़ार करें, यह दिखाता है कि R8 ऑप्टिमाइज़ेशन की प्रोसेस शुरू करने के लिए वाकई तैयार है, है न?

आपको बीच में कुछ खाली जगह दिख रही होगी. आपको लग रहा होगा कि हमने सीपीयू के इस्तेमाल के समय को खाली क्यों छोड़ा है.

इसकी वजह यह है कि पुराने एपीआई के काम करने का तरीका यह था कि हम सभी वर्कर के लिए, सभी फ़ाइलों को पढ़ने का इंतज़ार करते थे. इसके बाद ही, हम किसी चीज़ को पार्स करते थे.

ज़ाहिर है कि हम इसे ठीक कर सकते हैं और हमने ऐसा ही किया.

इसलिए, AGP 9 में, इनपुट JARs को पढ़ने के बाद, हम उन्हें तुरंत प्रोसेस करना शुरू कर देते हैं.

साथ ही, हमें हर वर्कर के इनपुट पढ़ने का इंतज़ार नहीं करना पड़ता.

इससे, सभी इनपुट को पढ़ने में लगने वाला समय काफ़ी कम हो गया.

इसलिए, यह एक ऐसा ऑप्टिमाइज़ेशन है जो ट्रेस को देखने पर साफ़ तौर पर दिखता है. हालांकि, सिर्फ़ सोर्स कोड को देखने पर यह साफ़ तौर पर नहीं दिखता कि किस चीज़ को ऑप्टिमाइज़ करना चाहिए.

AndroidX इंजीनियर के तौर पर, हम हर दिन Metalava टूल का भी इस्तेमाल करते हैं.

Metalava एक ऐसा टूल है जिसका इस्तेमाल हम यह पक्का करने के लिए करते हैं कि हम जो भी एपीआई उपलब्ध कराएं वे आपकी उम्मीद के मुताबिक काम करें. साथ ही, बाहरी लोग उनका इस्तेमाल बिना किसी परेशानी के कर सकें.

यह टूल, हर सार्वजनिक एपीआई और प्रतिबंधित एपीआई पर चलता है. इसलिए, यहां बचाया गया समय, AndroidX इंजीनियर के तौर पर हमें वापस मिल जाता है.

Metalava ने भी ट्रेसिंग का इस्तेमाल किया, ताकि पोस्ट-सबमिट के समय को 15% तक कम किया जा सके.

साथ ही, ट्रेस में जाकर यह पता लगाया जा सकता है कि क्या हुआ. Metalava दो तरह की जांच करता है: पहली जांच में, यह प्रतिबंधित एपीआई की जांच करता है और दूसरी जांच में, यह सार्वजनिक एपीआई की जांच करता है.

हालांकि, आपको एक पैटर्न दिख रहा होगा.

हम दो बार जांच करने के लिए, कई तरह के सेटअप कर रहे हैं.

इसलिए, प्रोग्राम के सभी इनपुट पढ़े जाते हैं. हम पीएसआई बनाते हैं, जो प्रोग्राम स्ट्रक्चर इंटरफ़ेस है. इसके अलावा, आपके कोड का आकार क्या है, इसके बारे में भी बताया जा सकता है.

इसके बाद, हम एएसटी बनाते हैं. फिर हम लिंट की मदद से सभी जांच शुरू करते हैं.

हम इस महंगे काम को दो बार कर रहे हैं.

हमने इस समस्या को कैसे ठीक किया?

हमने ऐसा सिर्फ़ एक बार किया.

इसलिए, हमने सेटअप का सारा काम दो बार करने के बजाय, सिर्फ़ एक बार किया. साथ ही, हमने उन इनपुट का इस्तेमाल, प्रतिबंधित और सार्वजनिक, दोनों तरह की जांचों के लिए किया. इससे हमें काफ़ी बचत हुई.

हाँ।

ठीक है।

राहुल रविकुमार

अब जब मैंने आपको Tracing 2.0 की सुविधाओं के बारे में बता दिया है, तो यह जानना ज़रूरी है कि ट्रेसिंग ज़रूरी है, लेकिन यह जानना भी उतना ही ज़रूरी है कि क्या ट्रेस करना है.

आपको हर जगह ट्रेस नहीं डालने चाहिए.

आपको बहुत सावधानी से चुनना होगा कि आपको क्या ट्रेस करना है. मैं आपको कुछ दिशा-निर्देश देने की कोशिश करूंगी कि क्या ट्रेस करना सही रहेगा.

इसलिए, सबसे पहले आपको अपने ट्रेस में मौजूद उन गैप का पता लगाना चाहिए जिनकी वजह आपको नहीं पता है.

इसलिए, जब भी आपके थ्रेड चल रहे हों या चलने की स्थिति में हों और आपको सिस्टम ट्रेस करने की प्रोसेस में साफ़ तौर पर गैप दिखें, लेकिन आपको उनकी वजह न पता हो और यह भी न पता हो कि आपका ऐप्लिकेशन क्या कर रहा है, तो इसकी जांच करना ज़रूरी हो सकता है.

ऐसे में, मैं सिस्टम ट्रेस करने की प्रक्रिया के साथ तरीकों की सूची को ओवरले कर सकता हूं. साथ ही, यह देख सकता हूं कि किस चीज़ को ट्रेस करना सही रहेगा. इसके बाद, मैं ट्रेस के उन ज़रूरी सेक्शन को जोड़ सकता हूं.

आपको उपयोगकर्ता अनुभव के हिसाब से भी प्राथमिकता तय करनी है.

इसलिए, आपको ऐप्लिकेशन के स्टार्टअप पर ध्यान देना चाहिए.

आपको अपने ऐप्लिकेशन के मुख्य उपयोगकर्ता अनुभव को देखना है. साथ ही, आपको यह पता लगाना है कि क्या ट्रेस देखकर, उन्हें समझाया जा सकता है.

इसलिए, जब भी आपको किसी चीज़ के बारे में तर्क न मिले, तो उसे ट्रेस करना ज़रूरी है.

आपको ट्रेस से डीप कॉल स्टैक या सीपीयू के इस्तेमाल की ऐसी जानकारी भी देखनी चाहिए जिसके बारे में आपको पता न हो. साथ ही, यह पता लगाने की कोशिश करनी चाहिए कि असल में क्या हो रहा है. इसके बाद, आपको अपने कोड बेस के उन हिस्सों को ट्रेस में बदलना चाहिए.

इसलिए, उन्हें ट्रेस किया जा सकता है.

इसके बाद, जब भी आपके थ्रेड स्लीप मोड में हों, तो आपको यह पक्का करना होगा कि आपको पता हो कि वे स्लीप मोड में क्यों हैं.

उन्हें I/O या बाइंडर ट्रांज़ैक्शन का इंतज़ार करना चाहिए. इसके अलावा, उन्हें कुछ ऐसे बाहरी इनपुट इवेंट का इंतज़ार करना चाहिए जो आपके हिसाब से होने वाले हैं.

हालांकि, अगर आपको नींद से जुड़ी कोई ऐसी समस्या है जिसकी वजह आपको नहीं पता है, तो उसकी जांच कराना बेहद ज़रूरी है. ऐसा इसलिए, क्योंकि हो सकता है कि आपको कोई गंभीर समस्या हो.

इसके बाद, जब आप उस कोड में सभी ट्रेस सेक्शन जोड़ लें, तो आपको उन्हें मानदंड में बदलना चाहिए, ताकि आप उनमें होने वाले बदलावों को ट्रैक कर सकें.

इसलिए, जैसे-जैसे आपका कोड बेस बेहतर होता है, वैसे-वैसे आपको यह देखने को मिलता है कि मेट्रिक में बदलाव हो रहा है या नहीं. साथ ही, यह भी पता चलता है कि आपके डैशबोर्ड में बड़े बदलाव दिख रहे हैं या नहीं. इससे आपको पता चलता है कि कोई अहम बदलाव हुआ है.

इसके अलावा, पिछले सभी चरणों को छोड़कर, अपने एजेंट से यह काम कराया जा सकता है.

इन दिशा-निर्देशों को लें और इन्हें एक स्किल में बदलें. इसके बाद, अपने पसंदीदा एजेंट को इस स्किल का इस्तेमाल करने के लिए कहें और उसे आज़माएं.

हाँ।

राहुल रविकुमार

अगर आपको लगता है कि ट्रेसिंग एक ज़रूरी काम है और आपको इसे करना चाहिए, तो यहां प्रोजेक्ट सेटअप करने का तरीका बताया गया है.

यह काफ़ी आसान है.

ट्रेसिंग एक आसान और पारंपरिक Java लाइब्रेरी है. इसलिए, आपको androidx.tracing:tracing-wire पर डिपेंडेंसी तय करनी होगी. यह Perfetto के साथ काम करने वाला ट्रेस ड्राइवर और ट्रेसिंग कॉम्बो है. इसका मौजूदा स्टेबल वर्शन 2.0.5 है.

अगर आप Java लाइब्रेरी हैं, तो यह बिलकुल एक जैसी चीज़ है; फिर से, यह पूरी तरह से मल्टीप्लैटफ़ॉर्म एपीआई है.

हम इसे अन्य प्लैटफ़ॉर्म पर भी उपलब्ध कराना चाहते हैं.

हां, मैं बस एक बार फिर से बताना चाहता हूं.

मैंने उन सभी नई सुविधाओं के बारे में बताया जो हमने जोड़ी हैं.

इसलिए, कॉन्टेक्स्ट प्रोपेगेशन वाकई बहुत असरदार है.

हमारे पास कस्टम जानकारी, मेटाडेटा, कॉल स्टैक की जानकारी, और अन्य सभी तरह की चीज़ें एम्बेड करने की सुविधा है.

मैंने कई चीज़ों के बारे में बात नहीं की है.

ज़ाहिर है कि ट्रेसिंग फ़ॉर्मैट को बदला जा सकता है. साथ ही, ट्रेस सिंक को भी बदला जा सकता है. इसके अलावा, ट्रेसिंग डेटा को OpenTelemetry में भी ले जाया जा सकता है.

ये सभी काम किए जा सकते हैं.

ट्रेसिंग की सुविधा, कई प्लैटफ़ॉर्म पर काम करती है.

यह भी एक बहुत ही सोच-समझकर लिया गया फ़ैसला है, क्योंकि हम चाहते हैं कि ज़्यादा से ज़्यादा लोग इसका फ़ायदा उठा सकें.

हम जो भी टूल उपलब्ध कराते हैं वे सभी Tracing 2.0 के साथ काम करते हैं. इनमें Perfetto, AndroidX बेंचमार्क, परफ़ॉर्मेंस का विश्लेषण करने वाला नया टूल, और पुराना Android प्रोफ़ाइलर शामिल है.

इसके साथ ही, हमें सुनने के लिए आपका बहुत-बहुत धन्यवाद.

हमें उम्मीद है कि आपको Dev Summit में हिस्सा लेकर अच्छा लगेगा. धन्यवाद.