ट्रेस की जांच करें

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

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

कॉल चार्ट या ट्रेस इवेंट को आसानी से नेविगेट करने के लिए, माउस और कीबोर्ड शॉर्टकट उपलब्ध हैं.

कॉल चार्ट का इस्तेमाल करके ट्रेस की जांच करना

कॉल चार्ट, किसी मेथड ट्रेस या फ़ंक्शन ट्रेस को ग्राफ़ के तौर पर दिखाता है. इसमें कॉल की अवधि और समय को हॉरिज़ॉन्टल ऐक्सिस पर दिखाया जाता है. साथ ही, इसके कॉल करने वालों को वर्टिकल ऐक्सिस पर दिखाया जाता है. सिस्टम एपीआई को किए गए कॉल, नारंगी रंग में दिखाए जाते हैं. आपके ऐप्लिकेशन के अपने तरीकों को किए गए कॉल, हरे रंग में दिखाए जाते हैं. साथ ही, तीसरे पक्ष के एपीआई (इसमें Java भाषा के एपीआई भी शामिल हैं) को किए गए कॉल, नीले रंग में दिखाए जाते हैं. चौथी इमेज में, कॉल चार्ट का उदाहरण दिखाया गया है. इसमें किसी दिए गए तरीके या फ़ंक्शन के लिए, सेल्फ़ टाइम, चाइल्ड टाइम, और कुल समय के कॉन्सेप्ट के बारे में बताया गया है. इन कॉन्सेप्ट के बारे में ज़्यादा जानने के लिए, टॉप डाउन और बॉटम अप का इस्तेमाल करके ट्रेस की जांच करने के तरीके वाले सेक्शन पर जाएं.

पहली इमेज. कॉल चार्ट का एक उदाहरण, जिसमें मेथड D के लिए खुद का, बच्चों का, और कुल समय दिखाया गया है.

अहम जानकारी: किसी तरीके या फ़ंक्शन के सोर्स कोड पर जाने के लिए, उस पर राइट क्लिक करें और सोर्स पर जाएं को चुनें. यह सुविधा, विश्लेषण पैनल के किसी भी टैब से काम करती है.

फ़्लेम चार्ट टैब का इस्तेमाल करके ट्रेस की जांच करना

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

इस कॉन्सेप्ट को बेहतर तरीके से समझने के लिए, इमेज 2 में दिए गए कॉल चार्ट को देखें. ध्यान दें कि D, B को कई बार कॉल करता है (B₁, B₂, और B₃). साथ ही, B को किए गए कुछ कॉल, C को कॉल करते हैं (C₁ और C₃).

दूसरी इमेज. एक कॉल चार्ट, जिसमें एक से ज़्यादा तरीके से कॉल किए गए हैं. इनमें कॉल करने वालों का क्रम एक जैसा है.

B₁, B₂, और B₃ में कॉल करने वालों का क्रम एक जैसा है (A → D → B). इसलिए, इन्हें एग्रीगेट किया जाता है. जैसा कि इमेज 3 में दिखाया गया है. इसी तरह, C₁ और C₃ को एग्रीगेट किया गया है, क्योंकि इनमें कॉलर का एक ही क्रम है (A → D → B → C). ध्यान दें कि C₂ को शामिल नहीं किया गया है, क्योंकि इसमें कॉलर का क्रम अलग है (A → D → C).

तीसरी इमेज. एक जैसे तरीकों को एग्रीगेट करना, जो एक ही कॉल स्टैक शेयर करते हैं.

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

चौथी इमेज. पांचवीं इमेज में दिखाए गए कॉल चार्ट को फ़्लेम चार्ट के तौर पर दिखाया गया है.

टॉप डाउन और बॉटम अप का इस्तेमाल करके ट्रेस की जांच करना

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

इमेज 5 में दिखाया गया है कि टॉप डाउन टैब में, तरीके A के नोड को बड़ा करने पर, इसके कॉलर, तरीके B और D दिखते हैं. इसके बाद, D नोड को बड़ा करने पर, इसके कॉलर, B और C तरीके दिखते हैं. इसी तरह, अन्य नोड को बड़ा करने पर उनके कॉलर दिखते हैं. फ़्लेम चार्ट टैब की तरह ही, टॉप डाउन ट्री में एक जैसे तरीकों के लिए ट्रेस की जानकारी इकट्ठा की जाती है. ये तरीके, एक ही कॉल स्टैक शेयर करते हैं. इसका मतलब है कि फ़्लेम चार्ट टैब, टॉप डाउन टैब को ग्राफ़ के तौर पर दिखाता है.

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

• सेल्फ़: यह वह समय होता है जब कोई तरीका या फ़ंक्शन कॉल, अपने कोड को लागू करने में खर्च करता है. इसमें कॉल किए गए फ़ंक्शन का समय शामिल नहीं होता. इसे फ़िगर 1 में, D तरीके के लिए दिखाया गया है.
• बच्चे: यह वह समय होता है जब कोई तरीका या फ़ंक्शन कॉल, अपने कोड को लागू करने के बजाय, अपने कॉलर को लागू करने में खर्च करता है. इसे फ़िगर 1 में, तरीके D के लिए दिखाया गया है.
• कुल: यह खुद और बच्चे के लिए तय किए गए समय का योग होता है. इससे पता चलता है कि ऐप्लिकेशन ने कॉल को पूरा करने में कुल कितना समय लिया. इसे इमेज 1 में, डी तरीके के लिए दिखाया गया है.

बॉटम अप टैब में, उन कॉल की सूची दिखती है जिनमें किसी फ़ंक्शन या तरीके के नोड को बड़ा करने पर, कॉल करने वालों की जानकारी दिखती है. आकृति 5 में दिखाए गए उदाहरण ट्रेस का इस्तेमाल करके, आकृति 6 में C तरीके के लिए बॉटम अप ट्री दिया गया है. बॉटम अप ट्री में, C तरीके के लिए नोड खोलने पर, इसके हर यूनीक कॉलर, B और D तरीके दिखते हैं. ध्यान दें कि B, C को दो बार कॉल करता है. हालांकि, बॉटम अप ट्री में C के नोड को बड़ा करने पर, B सिर्फ़ एक बार दिखता है. इसके बाद, B के नोड को बड़ा करने पर, इसके कॉलर, तरीके A और D दिखते हैं.

बॉटम अप टैब, उन तरीकों या फ़ंक्शन को क्रम से लगाने के लिए काम का होता है जो सबसे ज़्यादा (या सबसे कम) सीपीयू समय का इस्तेमाल करते हैं. हर नोड की जांच करके यह पता लगाया जा सकता है कि कौनसे कॉलर, उन तरीकों या फ़ंक्शन को लागू करने में सबसे ज़्यादा सीपीयू समय खर्च करते हैं. टॉप-डाउन ट्री की तुलना में, बॉटम-अप ट्री में हर तरीके या फ़ंक्शन के लिए समय की जानकारी, हर ट्री के सबसे ऊपर मौजूद तरीके (टॉप नोड) के हिसाब से होती है. सीपीयू टाइम को भी रिकॉर्डिंग के दौरान थ्रेड के कुल समय के प्रतिशत के तौर पर दिखाया जाता है. नीचे दी गई टेबल से, टॉप नोड और उसके कॉलर (सब-नोड) के लिए, टाइमिंग की जानकारी को समझने में मदद मिलती है.

	खुद की तरफ़ से	बच्चे	कुल
बॉटम अप ट्री (टॉप नोड) में सबसे ऊपर मौजूद तरीका या फ़ंक्शन	इससे पता चलता है कि किसी तरीके या फ़ंक्शन को अपना कोड चलाने में कितना समय लगा. इसमें, कॉल किए गए फ़ंक्शन का समय शामिल नहीं होता. ऊपर से नीचे की ओर दिखने वाले ट्री की तुलना में, समय की यह जानकारी, रिकॉर्डिंग की अवधि के दौरान इस तरीके या फ़ंक्शन के सभी कॉल के योग को दिखाती है.	यह उस कुल समय को दिखाता है जो किसी तरीके या फ़ंक्शन को अपने कॉलर को एक्ज़ीक्यूट करने में लगता है, न कि अपने कोड को. ऊपर से नीचे की ओर दिखने वाले ट्री की तुलना में, समय के बारे में दी गई यह जानकारी, रिकॉर्डिंग की अवधि के दौरान इस तरीके या फ़ंक्शन को कॉल करने वालों की संख्या को दिखाती है.	यह खुद के काम में लगा समय और बच्चों के काम में लगे समय का योग होता है.
कॉल करने वाले (सब-नोड)	इससे पता चलता है कि कॉल करने वाले व्यक्ति के कॉल करने पर, कॉल पाने वाले व्यक्ति को कितना समय लगा. इमेज 6 में दिए गए बॉटम अप ट्री का इस्तेमाल करके, यह उदाहरण दिया गया है कि मेथड B के लिए सेल्फ़ टाइम, मेथड C के हर एक्ज़ीक्यूशन के सेल्फ़ टाइम के योग के बराबर होगा. ऐसा तब होगा, जब B के ज़रिए C को कॉल किया जाएगा.	यह पैरामीटर, कॉल पाने वाले व्यक्ति के डिवाइस पर कॉल की घंटी बजने की कुल अवधि दिखाता है. इमेज 6 में दिए गए बॉटम अप ट्री को उदाहरण के तौर पर इस्तेमाल करके, यह बताया गया है कि B के लिए बच्चों का समय, B के ज़रिए कॉल किए जाने पर C के हर एक्ज़ीक्यूशन के लिए बच्चों के समय के योग के बराबर होगा.	यह खुद के काम में लगा समय और बच्चों के काम में लगे समय का योग होता है.

ध्यान दें: किसी रिकॉर्डिंग के लिए, Android Studio नया डेटा इकट्ठा करना तब बंद कर देता है, जब प्रोफ़ाइलर फ़ाइल के साइज़ की सीमा तक पहुंच जाता है. हालांकि, इससे रिकॉर्डिंग बंद नहीं होती. आम तौर पर, इंस्ट्रुमेंट किए गए ट्रेस को लागू करने पर, यह प्रोसेस ज़्यादा तेज़ी से होती है. ऐसा इसलिए, क्योंकि इस तरह की ट्रेसिंग, सैंपल किए गए ट्रेस की तुलना में कम समय में ज़्यादा डेटा इकट्ठा करती है. अगर आपने जांच की अवधि को रिकॉर्डिंग की उस अवधि तक बढ़ाया है जो सीमा तक पहुंचने के बाद हुई थी, तो ट्रेस पैन में समय का डेटा नहीं बदलता. ऐसा इसलिए होता है, क्योंकि कोई नया डेटा उपलब्ध नहीं होता. इसके अलावा, अगर आपने रिकॉर्डिंग का सिर्फ़ वह हिस्सा चुना है जिसके लिए कोई डेटा उपलब्ध नहीं है, तो ट्रेस पैन में समय की जानकारी के लिए NaN दिखता है.

इवेंट टेबल का इस्तेमाल करके ट्रेस की जांच करना

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

सातवीं इमेज. विश्लेषण पैन में इवेंट टैब देखना.

कॉलस्टैक फ़्रेम की जांच करना

कॉलस्टैक से यह समझने में मदद मिलती है कि कोड का कौन-सा हिस्सा एक्ज़ीक्यूट किया गया है और उसे क्यों शुरू किया गया. अगर किसी Java/Kotlin प्रोग्राम के लिए कॉलस्टैक सैंपल रिकॉर्डिंग इकट्ठा की जाती है, तो कॉलस्टैक में आम तौर पर सिर्फ़ Java/Kotlin कोड शामिल नहीं होता. इसमें JNI नेटिव कोड, Java वर्चुअल मशीन (जैसे, android::AndroidRuntime::start) और सिस्टम कर्नल ([kernel.kallsyms]+offset) के साथ इंटरैक्ट करता है. ऐसा इसलिए होता है, क्योंकि Java/Kotlin प्रोग्राम आम तौर पर Java वर्चुअल मशीन के ज़रिए काम करता है. प्रोग्राम को चलाने के लिए नेटिव कोड की ज़रूरत होती है. साथ ही, प्रोग्राम को सिस्टम और हार्डवेयर से कम्यूनिकेट करने के लिए भी इसकी ज़रूरत होती है. प्रोफ़ाइलर, सटीक जानकारी के लिए इन फ़्रेम को दिखाता है. हालांकि, आपकी जांच के आधार पर, हो सकता है कि आपको ये अतिरिक्त कॉल फ़्रेम काम के लगें या न लगें. प्रोफ़ाइलर, उन फ़्रेम को छोटा करने का तरीका उपलब्ध कराता है जिनमें आपकी दिलचस्पी नहीं है. इससे, ऐसी जानकारी को छिपाया जा सकता है जो आपकी जांच के लिए काम की नहीं है.

यहां दिए गए उदाहरण में, नीचे दिए गए ट्रेस में कई फ़्रेम को [kernel.kallsyms]+offset के तौर पर लेबल किया गया है. फ़िलहाल, ये डेवलपमेंट के लिए काम के नहीं हैं.

इन फ़्रेम को एक में छोटा करने के लिए, टूलबार में मौजूद फ़्रेम छोटा करें बटन को चुनें. इसके बाद, छोटा करने के लिए पाथ चुनें. इसके बाद, बदलाव लागू करने के लिए लागू करें बटन को चुनें. इस उदाहरण में, पाथ [kernel.kallsyms] है.

ऐसा करने से, चुने गए पाथ से जुड़े फ़्रेम, बाएं और दाएं, दोनों पैनल में छोटे हो जाते हैं. जैसा कि यहां दिखाया गया है.

सिस्टम ट्रेस की जांच करना

सिस्टम ट्रेस की जांच करते समय, थ्रेड टाइमलाइन में ट्रेस इवेंट की जांच की जा सकती है. इससे, हर थ्रेड पर होने वाले इवेंट की जानकारी देखी जा सकती है. इवेंट का नाम और हर स्थिति में बिताया गया समय देखने के लिए, किसी इवेंट पर अपना माउस पॉइंटर घुमाएं. विश्लेषण पैनल में ज़्यादा जानकारी देखने के लिए, किसी इवेंट पर क्लिक करें.

सिस्टम ट्रेस की जांच करना: सीपीयू कोर

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

आठवीं इमेज. रेंडर थ्रेड के लिए, सीपीयू की गतिविधि और ट्रेस इवेंट देखना.

सीपीयू कोर पैनल (जैसा कि इमेज 8 में दिखाया गया है) में, हर कोर पर शेड्यूल की गई थ्रेड गतिविधि दिखती है. किसी थ्रेड की गतिविधि पर माउस घुमाकर देखें कि उस समय यह कोर किस थ्रेड पर चल रही है.

सिस्टम ट्रेस की जानकारी की जांच करने के बारे में ज़्यादा जानने के लिए, systrace दस्तावेज़ का यूज़र इंटरफ़ेस (यूआई) की परफ़ॉर्मेंस से जुड़ी समस्याओं की जांच करना सेक्शन देखें.

सिस्टम ट्रेस की जांच करना: फ़्रेम रेंडरिंग की टाइमलाइन

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

सिस्टम ट्रेस की जांच करना: प्रोसेस मेमोरी (आरएसएस)

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

नौवीं इमेज. प्रोफ़ाइलर में फ़िज़िकल मेमोरी देखना.

कुल

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

Windows डेवलपर के लिए, Resident Set Size, Working Set Size के जैसा ही होता है.

बंटवारा किया गया

यह काउंटर ट्रैक करता है कि फ़िलहाल प्रोसेस के सामान्य मेमोरी असाइनमेंट के लिए कितनी फ़िज़िकल मेमोरी का इस्तेमाल किया जा रहा है. ये ऐसे असाइनमेंट होते हैं जो गुमनाम होते हैं (किसी फ़ाइल से जुड़े नहीं होते) और निजी होते हैं (शेयर नहीं किए जाते). ज़्यादातर ऐप्लिकेशन में, ये हीप ऐलोकेशन (malloc या new के साथ) और स्टैक मेमोरी से बने होते हैं. फ़िज़िकल मेमोरी से स्वैप किए जाने पर, इन ऐलोकेशन को सिस्टम स्वैप फ़ाइल में लिखा जाता है.

फ़ाइल मैपिंग

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

शेयर किए गए

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