डिवाइस के प्रदर्शन का मूल्यांकन करने के लिए Simpleperf का उपयोग करें। Simpleperf Android पर अनुप्रयोगों और मूल प्रक्रियाओं दोनों के लिए एक मूल रूपरेखा उपकरण है। वास्तविक समय में ऐप सीपीयू उपयोग और थ्रेड गतिविधि का निरीक्षण करने के लिए सीपीयू प्रोफाइलर का उपयोग करें।
प्रदर्शन के दो उपयोगकर्ता-दृश्यमान संकेतक हैं:
- अनुमानित, बोधगम्य प्रदर्शन । क्या यूजर इंटरफेस (यूआई) फ्रेम को गिराता है या लगातार 60FPS पर प्रस्तुत करता है? क्या ऑडियो कलाकृतियों या पॉपिंग के बिना चलता है? उपयोगकर्ता द्वारा स्क्रीन को छूने और डिस्प्ले पर दिखने वाले प्रभाव के बीच कितना समय लगता है?
- लंबे समय तक संचालन के लिए आवश्यक समय की लंबाई (जैसे कि आवेदन खोलना)।
पहला दूसरे की तुलना में अधिक ध्यान देने योग्य है। उपयोगकर्ता आमतौर पर जंक नोटिस करते हैं, लेकिन वे 500ms बनाम 600ms एप्लिकेशन स्टार्टअप समय नहीं बता पाएंगे, जब तक कि वे दो उपकरणों को एक साथ नहीं देख रहे हों। स्पर्श विलंबता तुरंत ध्यान देने योग्य है और डिवाइस की धारणा में महत्वपूर्ण योगदान देता है।
नतीजतन, एक तेज डिवाइस में, यूआई पाइपलाइन को कार्यात्मक रखने के लिए जो आवश्यक है, उसके अलावा सिस्टम में यूआई पाइपलाइन सबसे महत्वपूर्ण चीज है। इसका मतलब यह है कि UI पाइपलाइन को किसी अन्य कार्य को पूर्व-मुक्त करना चाहिए जो कि द्रव UI के लिए आवश्यक नहीं है। फ्लुइड UI बनाए रखने के लिए, बैकग्राउंड सिंकिंग, नोटिफिकेशन डिलीवरी, और इसी तरह के सभी कामों में देरी होनी चाहिए, अगर UI काम चलाया जा सकता है। तरल यूआई बनाए रखने के लिए लंबे समय तक संचालन (एचडीआर + रनटाइम, एप्लिकेशन स्टार्टअप, आदि) के प्रदर्शन का व्यापार करना स्वीकार्य है।
क्षमता बनाम घबराना
डिवाइस के प्रदर्शन पर विचार करते समय, क्षमता और घबराहट दो सार्थक मीट्रिक हैं।
क्षमता
क्षमता कुछ संसाधनों की कुल राशि है जो डिवाइस के पास कुछ समय के लिए होती है। यह CPU संसाधन, GPU संसाधन, I/O संसाधन, नेटवर्क संसाधन, मेमोरी बैंडविड्थ, या कोई समान मीट्रिक हो सकता है। पूरे सिस्टम के प्रदर्शन की जांच करते समय, यह अलग-अलग घटकों को अमूर्त करने के लिए उपयोगी हो सकता है और एक एकल मीट्रिक मान सकता है जो प्रदर्शन को निर्धारित करता है (विशेषकर जब किसी नए डिवाइस को ट्यून करते हैं क्योंकि उस डिवाइस पर चलने वाले वर्कलोड की संभावना तय होती है)।
एक सिस्टम की क्षमता ऑनलाइन कंप्यूटिंग संसाधनों के आधार पर भिन्न होती है। सीपीयू/जीपीयू आवृत्ति बदलना क्षमता बदलने का प्राथमिक साधन है, लेकिन अन्य भी हैं जैसे सीपीयू कोर की संख्या को ऑनलाइन बदलना। तदनुसार, एक प्रणाली की क्षमता बिजली की खपत से मेल खाती है; क्षमता बदलने से हमेशा बिजली की खपत में समान परिवर्तन होता है।
किसी निश्चित समय पर आवश्यक क्षमता चल रहे एप्लिकेशन द्वारा अत्यधिक निर्धारित की जाती है। नतीजतन, प्लेटफ़ॉर्म किसी दिए गए कार्यभार के लिए आवश्यक क्षमता को समायोजित करने के लिए बहुत कम कर सकता है, और ऐसा करने के साधन रनटाइम सुधार (एंड्रॉइड फ्रेमवर्क, एआरटी, बायोनिक, जीपीयू कंपाइलर/ड्राइवर, कर्नेल) तक सीमित हैं।
घबराना
जबकि कार्यभार के लिए आवश्यक क्षमता को देखना आसान है, घबराहट एक अधिक अस्पष्ट अवधारणा है। तेजी से सिस्टम के लिए एक बाधा के रूप में जिटर के अच्छे परिचय के लिए, लापता सुपरकंप्यूटर प्रदर्शन का मामला देखें: ASCl Q के 8,192 प्रोसेसर पर इष्टतम प्रदर्शन प्राप्त करना । (यह इस बात की जांच है कि एएससीआई क्यू सुपरकंप्यूटर ने अपने अपेक्षित प्रदर्शन को हासिल क्यों नहीं किया और बड़ी प्रणालियों को अनुकूलित करने के लिए एक महान परिचय है।)
यह पृष्ठ एएससीआई क्यू पेपर शोर को क्या कहता है, इसका वर्णन करने के लिए जिटर शब्द का उपयोग करता है। जिटर यादृच्छिक प्रणाली व्यवहार है जो बोधगम्य कार्य को चलने से रोकता है। यह अक्सर काम होता है जिसे चलाया जाना चाहिए, लेकिन इसमें सख्त समय की आवश्यकताएं नहीं हो सकती हैं जो इसे किसी विशेष समय पर चलाने का कारण बनती हैं। क्योंकि यह यादृच्छिक है, किसी दिए गए कार्यभार के लिए घबराहट के अस्तित्व को नकारना बेहद मुश्किल है। यह साबित करना भी बेहद मुश्किल है कि घबराहट का एक ज्ञात स्रोत किसी विशेष प्रदर्शन समस्या का कारण था। घबराहट के कारणों (जैसे ट्रेसिंग या लॉगिंग) के निदान के लिए सबसे अधिक उपयोग किए जाने वाले उपकरण अपने स्वयं के घबराहट का परिचय दे सकते हैं।
Android के वास्तविक-विश्व कार्यान्वयन में अनुभव किए गए घबराहट के स्रोतों में शामिल हैं:
- अनुसूचक देरी
- इंटरप्ट हैंडलर
- ड्राइवर कोड बहुत लंबे समय से चल रहा है, जिसमें छूट या व्यवधान अक्षम है
- लंबे समय से चल रहे सॉफ्टिरक्स
- लॉक विवाद (एप्लिकेशन, फ्रेमवर्क, कर्नेल ड्राइवर, बाइंडर लॉक, एमएमएपी लॉक)
- फ़ाइल डिस्क्रिप्टर विवाद जहां एक निम्न-प्राथमिकता वाला थ्रेड फ़ाइल पर लॉक रखता है, उच्च-प्राथमिकता वाले थ्रेड को चलने से रोकता है
- वर्कक्यू में यूआई-महत्वपूर्ण कोड चलाना जहां इसे विलंबित किया जा सकता है
- सीपीयू निष्क्रिय संक्रमण
- लॉगिंग
- आई/ओ देरी
- अनावश्यक प्रक्रिया निर्माण (जैसे, CONNECTIVITY_CHANGE प्रसारण)
- अपर्याप्त मुक्त स्मृति के कारण पृष्ठ कैश थ्रैशिंग
किसी निश्चित अवधि के लिए समय की आवश्यक मात्रा क्षमता बढ़ने पर घट सकती है या नहीं भी हो सकती है। उदाहरण के लिए, यदि कोई ड्राइवर i2c बस से पढ़ने के लिए प्रतीक्षा करते समय इंटरप्ट को अक्षम छोड़ देता है, तो सीपीयू 384 मेगाहर्ट्ज या 2GHz पर है या नहीं, इसमें एक निश्चित समय लगेगा। घबराहट शामिल होने पर प्रदर्शन में सुधार के लिए क्षमता बढ़ाना एक व्यवहार्य समाधान नहीं है। नतीजतन, तेज प्रोसेसर आमतौर पर घबराहट-विवश स्थितियों में प्रदर्शन में सुधार नहीं करेंगे।
अंत में, क्षमता के विपरीत, घबराहट लगभग पूरी तरह से सिस्टम विक्रेता के डोमेन के भीतर है।
मेमोरी खपत
मेमोरी खपत को पारंपरिक रूप से खराब प्रदर्शन के लिए दोषी ठहराया जाता है। जबकि खपत अपने आप में एक प्रदर्शन समस्या नहीं है, यह लोमेमोरीकिलर ओवरहेड, सर्विस रीस्टार्ट और पेज कैश थ्रैशिंग के माध्यम से घबराहट पैदा कर सकता है। स्मृति खपत को कम करने से खराब प्रदर्शन के प्रत्यक्ष कारणों से बचा जा सकता है, लेकिन अन्य लक्षित सुधार भी हो सकते हैं जो उन कारणों से भी बचते हैं (उदाहरण के लिए, फ्रेमवर्क को पिन करना ताकि इसे पृष्ठबद्ध होने से रोका जा सके जब इसे जल्द ही पृष्ठबद्ध किया जाएगा)।
प्रारंभिक डिवाइस प्रदर्शन का विश्लेषण
एक कार्यात्मक लेकिन खराब प्रदर्शन करने वाली प्रणाली से शुरू करना और उपयोगकर्ता-दृश्यमान खराब प्रदर्शन के अलग-अलग मामलों को देखकर सिस्टम के व्यवहार को ठीक करने का प्रयास करना एक अच्छी रणनीति नहीं है। क्योंकि खराब प्रदर्शन आमतौर पर आसानी से प्रतिलिपि प्रस्तुत करने योग्य नहीं होता है (अर्थात, घबराहट) या कोई अनुप्रयोग समस्या, पूर्ण सिस्टम में बहुत अधिक चर इस रणनीति को प्रभावी होने से रोकते हैं। नतीजतन, कारणों की गलत पहचान करना और पूरे सिस्टम में प्रदर्शन को ठीक करने के प्रणालीगत अवसरों को गायब करते हुए मामूली सुधार करना बहुत आसान है।
इसके बजाय, नया उपकरण लाते समय निम्नलिखित सामान्य दृष्टिकोण का उपयोग करें:
- चल रहे सभी ड्राइवरों और कुछ बुनियादी फ़्रीक्वेंसी गवर्नर सेटिंग्स के साथ UI में सिस्टम बूटिंग प्राप्त करें (यदि आप फ़्रीक्वेंसी गवर्नर सेटिंग्स बदलते हैं, तो नीचे दिए गए सभी चरणों को दोहराएं)।
- सुनिश्चित करें कि कर्नेल
sched_blocked_reasonट्रेसपॉइंट के साथ-साथ डिस्प्ले पाइपलाइन में अन्य ट्रेसपॉइंट्स का समर्थन करता है जो दर्शाता है कि फ्रेम को डिस्प्ले पर कब पहुंचाया जाता है। - हल्के और सुसंगत कार्यभार (जैसे, UiBench या TouchLatency में बॉल टेस्ट ) चलाते समय संपूर्ण UI पाइपलाइन (IRQ के माध्यम से इनपुट प्राप्त करने से लेकर अंतिम स्कैनआउट तक) के लंबे निशान लें।
- हल्के और सुसंगत कार्यभार में पाए गए फ़्रेम ड्रॉप्स को ठीक करें।
- चरण 3-4 को तब तक दोहराएं जब तक आप एक बार में 20+ सेकंड के लिए शून्य गिराए गए फ़्रेम के साथ नहीं चल सकते।
- जंक के अन्य उपयोगकर्ता-दृश्यमान स्रोतों पर जाएं।
अन्य सरल चीजें जो आप डिवाइस लाने में जल्दी कर सकते हैं उनमें शामिल हैं:
- सुनिश्चित करें कि आपके कर्नेल में sched_blocked_reason ट्रेसपॉइंट पैच है। यह ट्रेसपॉइंट सिस्ट्रेस में शेड्यूल ट्रेस श्रेणी के साथ सक्षम है और जब वह थ्रेड निर्बाध नींद में प्रवेश करता है तो सोने के लिए जिम्मेदार फ़ंक्शन प्रदान करता है। यह प्रदर्शन विश्लेषण के लिए महत्वपूर्ण है क्योंकि निर्बाध नींद घबराहट का एक बहुत ही सामान्य संकेतक है।
- सुनिश्चित करें कि आपके पास GPU और डिस्प्ले पाइपलाइन के लिए पर्याप्त ट्रेसिंग है। हाल ही में क्वालकॉम एसओसी पर, ट्रेसपॉइंट्स का उपयोग करके सक्षम किया गया है:
adb shell "echo 1 > /d/tracing/events/kgsl/enable"adb shell "echo 1 > /d/tracing/events/mdss/enable"
जब आप सिस्ट्रेस चलाते हैं तो ये इवेंट सक्षम रहते हैं ताकि आप mdss_fb0 खंड में डिस्प्ले पाइपलाइन (MDSS) के बारे में ट्रेस में अतिरिक्त जानकारी देख सकें। क्वालकॉम एसओसी पर, आपको मानक सिस्ट्रेस दृश्य में जीपीयू के बारे में कोई अतिरिक्त जानकारी नहीं दिखाई देगी, लेकिन परिणाम ट्रेस में ही मौजूद हैं (विवरण के लिए, सिस्ट्रेस को समझना देखें )।
इस तरह के डिस्प्ले ट्रेसिंग से आप जो चाहते हैं वह एक एकल घटना है जो सीधे इंगित करती है कि एक फ्रेम डिस्प्ले पर पहुंचा दिया गया है। वहां से, आप यह निर्धारित कर सकते हैं कि आपने अपने फ्रेम टाइम को सफलतापूर्वक पूरा किया है या नहीं; यदि ईवेंट X n , ईवेंट X n-1 (60 हर्ट्ज़ डिस्प्ले मानकर) के बाद 16.7ms से कम होता है, तो आप जानते हैं कि आपने जंक नहीं किया। यदि आपका एसओसी ऐसे संकेत प्रदान नहीं करता है, तो उन्हें प्राप्त करने के लिए अपने विक्रेता के साथ काम करें। फ्रेम पूरा होने के निश्चित संकेत के बिना डिबगिंग जिटर बेहद मुश्किल है।
सिंथेटिक बेंचमार्क का उपयोग करना
डिवाइस की बुनियादी कार्यक्षमता मौजूद है यह सुनिश्चित करने के लिए सिंथेटिक बेंचमार्क उपयोगी होते हैं। हालांकि, कथित डिवाइस प्रदर्शन के लिए बेंचमार्क को प्रॉक्सी के रूप में मानना उपयोगी नहीं है।
एसओसी के साथ अनुभवों के आधार पर, एसओसी के बीच सिंथेटिक बेंचमार्क प्रदर्शन में अंतर प्रत्यक्ष यूआई प्रदर्शन (गिराए गए फ्रेम की संख्या, 99वां प्रतिशत फ्रेम समय, आदि) में समान अंतर से संबंधित नहीं है। सिंथेटिक बेंचमार्क केवल क्षमता वाले बेंचमार्क हैं; घबराहट केवल बेंचमार्क के थोक संचालन से समय की चोरी करके इन बेंचमार्क के मापा प्रदर्शन को प्रभावित करती है। नतीजतन, सिंथेटिक बेंचमार्क स्कोर उपयोगकर्ता-कथित प्रदर्शन के मीट्रिक के रूप में अधिकतर अप्रासंगिक होते हैं।
बेंचमार्क एक्स चलाने वाले दो एसओसी पर विचार करें जो यूआई के 1000 फ्रेम प्रस्तुत करता है और कुल प्रतिपादन समय की रिपोर्ट करता है (कम स्कोर बेहतर है)।
- SOC 1 बेंचमार्क X के प्रत्येक फ्रेम को 10ms और स्कोर 10,000 में प्रस्तुत करता है।
- SOC 2 99% फ़्रेम को 1ms में प्रस्तुत करता है लेकिन 1% फ़्रेम 100ms में और स्कोर 19,900, एक नाटकीय रूप से बेहतर स्कोर।
यदि बेंचमार्क वास्तविक UI प्रदर्शन का सूचक है, तो SOC 2 अनुपयोगी होगा। 60Hz रिफ्रेश रेट को मानते हुए, SOC 2 में ऑपरेशन के हर 1.5s में एक जानदार फ्रेम होगा। इस बीच, SOC 1 (बेंचमार्क X के अनुसार धीमा SOC) पूरी तरह से तरल होगा।
बग रिपोर्ट का उपयोग करना
बग रिपोर्ट कभी-कभी प्रदर्शन विश्लेषण के लिए उपयोगी होती हैं, लेकिन क्योंकि वे बहुत भारी होती हैं, वे छिटपुट जंक मुद्दों को डीबग करने के लिए शायद ही कभी उपयोगी होती हैं। वे कुछ संकेत प्रदान कर सकते हैं कि सिस्टम किसी निश्चित समय पर क्या कर रहा था, खासकर यदि जंक एक एप्लिकेशन संक्रमण के आसपास था (जो एक बग रिपोर्ट में लॉग किया गया है)। बग रिपोर्ट यह भी संकेत दे सकती है कि जब सिस्टम में कुछ अधिक व्यापक रूप से गलत है जो इसकी प्रभावी क्षमता को कम कर सकता है (जैसे थर्मल थ्रॉटलिंग या मेमोरी फ़्रेग्मेंटेशन)।
टच लेटेंसी का उपयोग करना
बुरे व्यवहार के कई उदाहरण TouchLatency से आते हैं, जो कि Pixel और Pixel XL के लिए उपयोग किया जाने वाला पसंदीदा आवधिक कार्यभार है। यह frameworks/base/tests/TouchLatency पर उपलब्ध है और इसमें दो मोड हैं: स्पर्श विलंबता और बाउंसिंग बॉल (मोड स्विच करने के लिए, ऊपरी-दाएं कोने में बटन पर क्लिक करें)।
बाउंसिंग बॉल टेस्ट बिल्कुल उतना ही सरल है जितना कि यह प्रतीत होता है: एक गेंद स्क्रीन के चारों ओर हमेशा के लिए उछलती है, उपयोगकर्ता इनपुट की परवाह किए बिना। यह आमतौर पर पूरी तरह से चलाने के लिए अब तक का सबसे कठिन परीक्षण भी है , लेकिन यह बिना किसी गिराए गए फ्रेम के चलने के जितना करीब आता है, आपका डिवाइस उतना ही बेहतर होगा। बाउंसिंग बॉल टेस्ट मुश्किल है क्योंकि यह एक तुच्छ लेकिन पूरी तरह से सुसंगत कार्यभार है जो बहुत कम घड़ी पर चलता है (यह मानता है कि डिवाइस में फ़्रीक्वेंसी गवर्नर है; यदि डिवाइस इसके बजाय निश्चित घड़ियों के साथ चल रहा है, तो सीपीयू/जीपीयू को लगभग-न्यूनतम तक डाउनक्लॉक करें। पहली बार बाउंसिंग बॉल टेस्ट चलाते समय)। जैसे ही सिस्टम बंद हो जाता है और घड़ियां निष्क्रिय होने के करीब आ जाती हैं, प्रति फ्रेम आवश्यक CPU/GPU समय बढ़ जाता है। आप गेंद को देख सकते हैं और चीजों को बेकार देख सकते हैं, और आप सिस्ट्रेस में भी छूटे हुए फ्रेम देख पाएंगे।
चूंकि कार्यभार इतना सुसंगत है, आप यूआई पाइपलाइन के बजाय प्रत्येक छूटे हुए फ्रेम के दौरान सिस्टम पर वास्तव में क्या चल रहा है, इस पर नज़र रखकर अधिकांश उपयोगकर्ता-दृश्यमान वर्कलोड की तुलना में घबराहट के अधिकांश स्रोतों की पहचान कर सकते हैं। निचली घड़ियाँ घबराने के प्रभाव को और अधिक बढ़ा देती हैं जिससे यह अधिक संभावना हो जाती है कि कोई भी घबराना एक गिरा हुआ फ्रेम का कारण बनता है। परिणामस्वरूप, TouchLatency 60FPS के जितना करीब होगा, आपके सिस्टम में खराब व्यवहार होने की संभावना उतनी ही कम होगी जो बड़े अनुप्रयोगों में छिटपुट, हार्ड-टू-रीप्रोड्यूस जंक का कारण बनते हैं।
चूंकि घबराहट अक्सर (लेकिन हमेशा नहीं) घड़ी की गति-अपरिवर्तनीय होती है, निम्न कारणों से घबराहट का निदान करने के लिए बहुत कम घड़ियों पर चलने वाले परीक्षण का उपयोग करें:
- सभी जिटर क्लॉकस्पीड-अपरिवर्तनीय नहीं हैं; कई स्रोत सिर्फ CPU समय का उपभोग करते हैं।
- गवर्नर को क्लॉक डाउन करके समय सीमा के करीब औसत फ्रेम समय प्राप्त करना चाहिए, इसलिए गैर-यूआई कार्य चलाने में लगने वाला समय इसे फ्रेम को गिराने के लिए किनारे पर धकेल सकता है।