डीडीएमएस से अधिकतम का निचोड़

डीडीएमएस (Dalvik डिबग मॉनिटर सर्वर) डिबगिंग अनुप्रयोगों के लिए एक पागलपनपूर्ण उपयोगी उपकरण है, जो एंड्रॉइड एसडीके के साथ बंडल में आता है, जो किसी कारण के लिए विशेष रूप से हब पर उल्लिखित नहीं है, हालांकि, Google उदाहरणों में, इसे बहुत मामूली रूप में प्रस्तुत किया गया है। मैं उसकी क्षमताओं को प्रकट करना चाहता हूं और दिखाना चाहता हूं कि वह क्या करने में सक्षम है। संक्षेप में:

• काम कर रहे धागे के बारे में जानकारी का अध्ययन;
• मुक्त और अधिकृत मेमोरी की मात्रा के लिए ढेर का विश्लेषण करें;
• विश्लेषण जो वस्तुओं को अधिक बार बनाया जाता है, उनका आकार और अधिक (आवंटन ट्रैकर);
• कोड के समस्याग्रस्त खंड खोजें जो लंबे समय तक काम करते हैं और अनुकूलन (विधि प्रोफाइलिंग) की आवश्यकता होती है। यह मैं हर किसी को जानने की सलाह देता हूं।

इस लेख के ढांचे में इन बातों पर चर्चा की जाएगी। और संदर्भ के लिए, कम दिलचस्प, जो काफी तुच्छ है और जिसकी चर्चा इस लेख के ढांचे में नहीं की जाएगी:

• एमुलेटर या डिवाइस की फाइल सिस्टम के साथ काम करना;
• त्रुटि जानकारी प्राप्त करें (हैलो लॉगकैट );
• कॉल / एसएमएस / स्थान का अनुकरण करें;
• नेटवर्क स्टैटिस्टिक्स टूल का उपयोग करें।

धागे

डीडीएमएस में एक उपकरण है जो हमें प्रत्येक प्रक्रिया और उसके थ्रेड्स पर जानकारी का विश्लेषण करने की अनुमति देता है। यह हमारे आवेदन की आवश्यक प्रक्रिया का चयन करने और "अपडेट थ्रेड" पर क्लिक करने के लिए पर्याप्त है।





दाईं ओर आप "थ्रेड्स" टैब और चयनित प्रक्रिया के वर्किंग थ्रेड्स देख सकते हैं। प्रत्येक स्ट्रीम के लिए निम्न जानकारी उपलब्ध है:

• आईडी वर्चुअल मशीन द्वारा निर्दिष्ट अद्वितीय थ्रेड आइडेंटिफायर है। यदि पास में एक तारांकन चिह्न है, तो यह एक दानव धागा है;
• Tid - लिनक्स में थ्रेड आईडी। प्रक्रिया के मुख्य सूत्र में प्रक्रिया आईडी शामिल होगी;
• स्थिति - धारा की वर्तमान स्थिति;
• UIME - कुल समय जो थ्रेड उपयोगकर्ता कोड के निष्पादन पर खर्च होता है। माप जिफियों की इकाइयाँ , जिसकी अवधि प्रणाली द्वारा निर्धारित की जाती है और आमतौर पर 10ms होती है;
• Stime - समय खर्च कोडिंग सिस्टम कोड। इकाइयाँ भी जिफ़िज़ हैं;
• नाम - धारा का नाम। स्ट्रीम बनाते समय सार्थक नाम देना याद रखें।

इस प्रकार, हम समझ सकते हैं कि कौन सा थ्रेड सबसे अधिक सीपीयू समय की खपत करता है। यहाँ कुछ शब्द कुछ प्रवाह के बारे में कहा जाना चाहिए।

जीसी - आपने अनुमान लगाया, यह एक कचरा कलेक्टर धारा है। Android 3 से पहले, यह स्ट्रीम में देखने के लिए उपलब्ध नहीं है।

JDWP (जावा डिबग वायर प्रोटोकॉल) एक डिबगर और एक वर्चुअल मशीन के बीच बातचीत का एक प्रोटोकॉल है।



यह वास्तव में इसकी धारा है। इसकी उपस्थिति के बारे में चिंता न करें, यह एप्लिकेशन को डीबग करते समय ही बनाया जाता है।

आप अपने वर्तमान थ्रेड्स की निगरानी कर सकते हैं और मेमोरी लीक का पता लगा सकते हैं यदि आपका कोई भी धागा डुप्लिकेट में सूची में है (स्वाभाविक रूप से, यदि यह इरादा नहीं है)। मान लीजिए कि आपने स्क्रीन को चालू कर दिया है, लेकिन उसी समय स्ट्रीम के समापन को सही ढंग से संभालना भूल गए, और फिर इसकी एक प्रति बनाई। सूची में आपको ऐसे दोनों प्रवाह दिखाई देंगे। मैंने ऑनक्रिएट () में एक नियमित धागा शुरू किया और अतीत को रोके बिना स्क्रीन को चालू कर दिया और मुझे यह तस्वीर मिल गई।



शायद धाराओं के साथ टैब सब कुछ है। लेकिन यह जानकारी लेख की निरंतरता से निकटता से संबंधित है।

ढेर

हम ढेर डिबगिंग के लिए एक उपकरण है। ऐसा करने के लिए, आपको आवश्यक प्रक्रिया का चयन करना चाहिए और "अपडेट हीप" का चयन करना चाहिए।





अब हमारे पास हमारी प्रक्रिया में गतिशील मेमोरी के आवंटन की जानकारी है। हम कचरा संग्रह (कारण जीसी) शुरू करते हैं और देखते हैं कि क्या रहता है।





यहाँ सब कुछ बहुत सरल है:

• हीप आकार कुल हीप आकार है जिसे एंड्रॉइड ने इस प्रक्रिया के लिए आवंटित किया है;
• आवंटित - प्रयुक्त स्मृति;
• मुक्त - मुक्त स्मृति;
• प्रयुक्त - एक प्रतिशत के रूप में उपयोग की जाने वाली मेमोरी;
• ऑब्जेक्ट्स - ऑब्जेक्ट्स की कुल संख्या जो आवंटित आकार बनाती है।

स्क्रीनशॉट के नीचे, आकार और प्रकार द्वारा वस्तुओं का वितरण दिखाया गया है।

हीप साइज को वर्चुअल मशीन द्वारा आवश्यकतानुसार बढ़ाया जा सकता है। कभी-कभी उसे ट्रैक करने के कुछ मिनट यह समझने के लिए पर्याप्त होते हैं कि आपके पास मेमोरी लीक है।

मैं एक उदाहरण दूंगा। एक परियोजना में, मैं एक प्रसारण संदेश श्रोता का उपयोग करता हूं। मैंने ऑनपॉज में unregisterReceiver पर टिप्पणी की

// LocalBroadcastManager.getInstance(this).unregisterReceiver(receiver);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ब्रॉडकास्टसीवर खुद LocalBroadcastManager के माध्यम से पंजीकृत है

 LocalBroadcastManager.getInstance(this).registerReceiver(receiver, intentFilter);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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





आकृति के शीर्ष पर एप्लिकेशन की पहली शुरुआत दिखाई देती है। इसके बाद, मैंने 11 बार स्क्रीन चालू की, जिसके बाद ढेर काफी बढ़ गया। 12 बार के लिए, एप्लिकेशन ने जवाब देना बंद कर दिया। बढ़ती हुई ढेर एक दोधारी तलवार है। एक तरफ, यह अच्छा है कि यह इतना कम बढ़ सकता है (मुफ्त मेमोरी पर निर्भर करता है), दूसरी तरफ, एप्लिकेशन लंबे समय तक क्रैश नहीं हो सकता है और उपयोगकर्ता को परेशान करते हुए, धीरे-धीरे काम करेगा। बेशक, ढेर का विश्लेषण यह नहीं दिखाएगा कि आपके पास कहां रिसाव है, लेकिन यह स्पष्ट कर देगा कि यह अभी भी मौजूद है, और यह पहले से ही खराब नहीं है।

आवंटन ट्रैकर

अधिक जानकारी हमें आवंटन ट्रैकर द्वारा दी जा सकती है। यह आपको ट्रैक करने की अनुमति देता है कि चयनित समय के लिए चयनित प्रक्रिया द्वारा किन वस्तुओं का निर्माण किया गया है, जहां आप देख सकते हैं कि कौन सी वस्तुओं को अधिक बार बनाया गया था, उनका आकार, धागा जिसने उन्हें बनाया और कॉल स्टैक।





हम "स्टार्ट ट्रैक" चुनते हैं, जिसके बाद हम उस एप्लिकेशन के साथ कार्य करते हैं जिसे हम विश्लेषण करना चाहते हैं, फिर "आवंटन प्राप्त करें" पर क्लिक करें। इस अवधि के दौरान बनाई गई वस्तुओं की एक सूची नीचे दिखाई देती है।

इस स्क्रीनशॉट में, वस्तुओं को उनके आरंभीकरण के क्रम से या सृजन समय के अनुसार क्रमबद्ध किया गया है, मुझे नहीं पता कि मैं अपने आप को बेहतर कैसे व्यक्त करूं। आप कॉलम नाम पर क्लिक करके अपनी वस्तुओं को किसी भी सुविधाजनक तरीके से सॉर्ट कर सकते हैं। उपलब्ध जानकारी:

• आबंट आदेश - बनाई गई वस्तु की संख्या;
• आवंटन का आकार - वस्तु का आकार;
• आवंटित वर्ग - वस्तु का प्रकार;
• थ्रेड आईडी - वर्चुअल मशीन द्वारा निर्दिष्ट थ्रेड आईडी (टीआईडी ​​के साथ भ्रमित नहीं होना);
• आवंटित ईद - वह वर्ग और विधि जिसमें वस्तु बनाई गई थी।

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

विधि प्रोफाइलिंग

मैं अंत में अपने पसंदीदा कोड विश्लेषण उपकरण, विधि रूपरेखा के लिए मिला। यह उपकरण आपको उस समय का विश्लेषण करने की अनुमति देता है जो उनके काम के तरीकों पर खर्च किया गया था। इस प्रकार, हम अपने कोड में बाधाओं को समझ सकते हैं और उन्हें अनुकूलित कर सकते हैं।

मैं एक साधारण उदाहरण दिखाऊंगा। हमारी एक परियोजना में, मुझे NMEA प्रोटोकॉल से निपटना पड़ा। यह एक समुद्री प्रोटोकॉल है जो तथाकथित "कच्चे" जीपीएस डेटा प्रदान करता है। मैंने इस डेटा को पार्स किया। यह उन पंक्तियों में से एक है जिनकी मुझे आवश्यकता है।

$ GPGGA, 123519,4807.038, N, 01131.000, E, 1,08,0.9,545.4, M, 46.9, M, * 47

स्प्लिट कॉमा और सब कुछ ठीक है। या नहीं? हम आवश्यक प्रक्रिया का चयन करते हैं और मेथड प्रोफाइलिंग शुरू करते हैं।





1-2 मिनट के बाद (आप स्वयं उस समय को चुनते हैं जो आपको लगता है कि आवश्यक है), विधि रूपरेखा को रोकें, जिसके बाद हमें अपने तरीकों का पता चलता है, जैसा कि नीचे दिए गए चित्र में दिखाया गया है।





ऊपरी भाग धागे के समय को दर्शाता है। यहां आप स्ट्रीम की आईडी, उसका नाम और उसके चलने के समय का चित्रमय प्रतिनिधित्व पा सकते हैं। ट्रेस का निचला हिस्सा ज्यादा दिलचस्प है। बाएं से ऊपर तक, ऐसे तरीके दिखाए जाते हैं जो प्रोसेसर समय की अधिकतम मात्रा का उपभोग करते हैं;

• Incl Cpu समय% - वह समय जो किसी विधि में अपने कोड के निष्पादन पर खर्च किया जाता है, प्लस समय जो इस पद्धति (%) में अन्य विधियों के निष्पादन पर खर्च किया जाता है;
• एक्सेल सीपीयू समय% - वह समय जो विधि (%) में मूल कोड को निष्पादित करने पर खर्च किया जाता है;
• इंकल सीपीयू टाइम और एक्सेल सीपीयू टाइम - एक ही चीज, केवल मिलीसेकंड इकाइयाँ;
• कॉल + पुनरावृत्ति कॉल / कुल - कॉल की संख्या और उनके दोहराव;
• समय / कॉल - कुल बीता समय (ms)।

इस तालिका में यह ध्यान देने योग्य है, मेरी विधि कुल समय का 23.5% खर्च करती है। उस पर क्लिक करके, मुझे ऐसी तस्वीर मिली





जाहिर है, दोष विभाजन विधि है, जो उस पद्धति के कुल समय का 72% खर्च करता है जिसमें इसे बुलाया गया था। प्रतिस्थापन करने के लिए सामान्य संक्रमण ने हमें 2 बार इस विधि का अनुकूलन करने की अनुमति दी।





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

आप आबंटन ट्रैकर की तरह ही तरीकों को क्रमबद्ध कर सकते हैं, बस कॉलम नाम पर क्लिक करें।

आवेदन में कोड के केवल कुछ वर्गों का विश्लेषण करना संभव है। Android हमें इसके लिए दो तरीके प्रदान करता है:

 android.os.Debug.startMethodTracing(“trace_name”);  android.os.Debug.stopMethodTracing();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

StopMethodTracing पूर्ण होने के बाद, ट्रेस /sdcard/trace_name.trace में उपलब्ध होगा। यह बहुत उपयोगी हो सकता है यदि हम कोड के कुछ वर्गों को अनुकूलित करना चाहते हैं, या, उदाहरण के लिए, एप्लिकेशन स्टार्टअप गति में सुधार करें।



शायद अब के लिए बस इतना ही। दृश्य के पीछे ढेर डंप विश्लेषण ( डंप एचपीआरओएफ फ़ाइल ) है। यदि आप रुचि रखते हैं, तो मैं MAT के रूप में इस तरह के एक अद्भुत उपकरण के बारे में एक ही नस में एक लेख लिखने की कोशिश करूंगा, जो आपको लीक और अन्य चीजों के लिए ढेर डंप का विश्लेषण करने की अनुमति देता है। यह मेरी गतिविधि के सभी उदाहरण दिखाएगा जो स्क्रीन को घुमाए जाने के दौरान हीप में रखे गए थे।

मैंने Hierarchy Viewer टूल को भी दरकिनार कर दिया जिसके बारे में Habré पर पहले से ही एक लेख मौजूद है। मुझे उम्मीद है कि यह लेख उपयोगी निकला है और आपको अपने अनुप्रयोगों को अनुकूलित करने में मदद करेगा।



खुश डिबगिंग!