किसी डिवाइस के प्रदर्शन का मूल्यांकन करने के लिए Simpleperf का उपयोग करें। Simpleperf एंड्रॉइड पर एप्लिकेशन और मूल प्रक्रियाओं दोनों के लिए एक मूल प्रोफ़ाइलिंग टूल है। वास्तविक समय में ऐप सीपीयू उपयोग और थ्रेड गतिविधि का निरीक्षण करने के लिए सीपीयू प्रोफाइलर का उपयोग करें।
प्रदर्शन के दो उपयोगकर्ता-दृश्यमान संकेतक हैं:
- पूर्वानुमानित, बोधगम्य प्रदर्शन । क्या उपयोगकर्ता इंटरफ़ेस (यूआई) फ़्रेम ड्रॉप करता है या लगातार 60FPS पर रेंडर करता है? क्या ऑडियो कलाकृतियों या पॉपिंग के बिना चलता है? उपयोगकर्ता द्वारा स्क्रीन को छूने और डिस्प्ले पर प्रभाव दिखने के बीच कितनी देर होती है?
- लंबे परिचालन (जैसे एप्लिकेशन खोलना) के लिए आवश्यक समय की लंबाई ।
पहला दूसरे की तुलना में अधिक ध्यान देने योग्य है। उपयोगकर्ता आम तौर पर जंक को नोटिस करते हैं लेकिन वे 500ms बनाम 600ms एप्लिकेशन स्टार्टअप समय नहीं बता पाएंगे जब तक कि वे दो डिवाइसों को एक साथ नहीं देख रहे हों। स्पर्श विलंबता तुरंत ध्यान देने योग्य है और डिवाइस की धारणा में महत्वपूर्ण योगदान देती है।
नतीजतन, एक तेज़ डिवाइस में, यूआई पाइपलाइन को कार्यात्मक बनाए रखने के लिए आवश्यक चीजों के अलावा सिस्टम में यूआई पाइपलाइन सबसे महत्वपूर्ण चीज है। इसका मतलब यह है कि यूआई पाइपलाइन को किसी अन्य कार्य को रोकना चाहिए जो द्रव यूआई के लिए आवश्यक नहीं है। यदि यूआई कार्य चलाया जा सकता है तो एक तरल यूआई बनाए रखने के लिए, बैकग्राउंड सिंकिंग, नोटिफिकेशन डिलीवरी और इसी तरह के सभी कार्यों में देरी होनी चाहिए। एक तरल यूआई बनाए रखने के लिए लंबे संचालन (एचडीआर + रनटाइम, एप्लिकेशन स्टार्टअप इत्यादि) के प्रदर्शन का व्यापार करना स्वीकार्य है।
क्षमता बनाम घबराना
डिवाइस के प्रदर्शन पर विचार करते समय, क्षमता और घबराहट दो सार्थक मीट्रिक हैं।
क्षमता
क्षमता कुछ संसाधनों की कुल मात्रा है जो डिवाइस के पास कुछ समय के लिए होती है। यह सीपीयू संसाधन, जीपीयू संसाधन, आई/ओ संसाधन, नेटवर्क संसाधन, मेमोरी बैंडविड्थ, या कोई समान मीट्रिक हो सकता है। पूरे सिस्टम के प्रदर्शन की जांच करते समय, व्यक्तिगत घटकों को अमूर्त करना और एक एकल मीट्रिक मानना उपयोगी हो सकता है जो प्रदर्शन निर्धारित करता है (विशेष रूप से एक नए डिवाइस को ट्यून करते समय क्योंकि उस डिवाइस पर चलने वाले वर्कलोड निश्चित होते हैं)।
किसी सिस्टम की क्षमता ऑनलाइन कंप्यूटिंग संसाधनों के आधार पर भिन्न होती है। सीपीयू/जीपीयू आवृत्ति को बदलना क्षमता बदलने का प्राथमिक साधन है, लेकिन सीपीयू कोर की संख्या को ऑनलाइन बदलना जैसे अन्य साधन भी हैं। तदनुसार, किसी सिस्टम की क्षमता बिजली की खपत से मेल खाती है; क्षमता बदलने से हमेशा बिजली की खपत में समान परिवर्तन होता है।
किसी निश्चित समय पर आवश्यक क्षमता काफी हद तक चल रहे एप्लिकेशन द्वारा निर्धारित होती है। परिणामस्वरूप, प्लेटफ़ॉर्म किसी दिए गए कार्यभार के लिए आवश्यक क्षमता को समायोजित करने के लिए बहुत कम कर सकता है, और ऐसा करने के साधन रनटाइम सुधार (एंड्रॉइड फ्रेमवर्क, एआरटी, बायोनिक, जीपीयू कंपाइलर/ड्राइवर, कर्नेल) तक सीमित हैं।
घबराना
जबकि कार्यभार के लिए आवश्यक क्षमता को देखना आसान है, घबराहट एक अधिक अस्पष्ट अवधारणा है। तेज़ सिस्टम में बाधा के रूप में घबराहट के अच्छे परिचय के लिए, लापता सुपरकंप्यूटर प्रदर्शन का मामला देखें: ASCl Q के 8,192 प्रोसेसर पर इष्टतम प्रदर्शन प्राप्त करना । (यह इस बात की जांच है कि एएससीआई क्यू सुपरकंप्यूटर ने अपना अपेक्षित प्रदर्शन क्यों हासिल नहीं किया और बड़े सिस्टम को अनुकूलित करने के लिए यह एक बेहतरीन परिचय है।)
एएससीआई क्यू पेपर जिसे शोर कहता है उसका वर्णन करने के लिए यह पृष्ठ जिटर शब्द का उपयोग करता है। जिटर एक यादृच्छिक सिस्टम व्यवहार है जो प्रत्यक्ष कार्य को चलने से रोकता है। यह अक्सर ऐसा कार्य होता है जिसे चलाया जाना चाहिए, लेकिन इसमें समय की सख्त आवश्यकताएं नहीं हो सकती हैं, जिसके कारण इसे किसी विशेष समय पर चलाया जा सकता है। क्योंकि यह यादृच्छिक है, किसी दिए गए कार्यभार के लिए घबराहट के अस्तित्व को अस्वीकार करना बेहद मुश्किल है। यह साबित करना भी बेहद मुश्किल है कि घबराहट का एक ज्ञात स्रोत किसी विशेष प्रदर्शन समस्या का कारण था। घबराहट के कारणों का निदान करने के लिए सबसे अधिक उपयोग किए जाने वाले उपकरण (जैसे ट्रेसिंग या लॉगिंग) अपनी खुद की घबराहट का परिचय दे सकते हैं।
एंड्रॉइड के वास्तविक-विश्व कार्यान्वयन में अनुभव किए गए घबराहट के स्रोतों में शामिल हैं:
- अनुसूचक विलंब
- संचालकों को बाधित करें
- ड्राइवर कोड प्रीएम्प्शन या इंटरप्ट अक्षम के साथ बहुत लंबे समय तक चल रहा है
- लंबे समय से चल रहे सॉफ़्टिरक्स
- लॉक विवाद (एप्लिकेशन, फ्रेमवर्क, कर्नेल ड्राइवर, बाइंडर लॉक, एमएमएपी लॉक)
- फ़ाइल डिस्क्रिप्टर विवाद जहां कम-प्राथमिकता वाला थ्रेड फ़ाइल पर लॉक रखता है, उच्च-प्राथमिकता वाले थ्रेड को चलने से रोकता है
- कार्य कतारों में यूआई-महत्वपूर्ण कोड चलाना जहां इसमें देरी हो सकती है
- सीपीयू निष्क्रिय संक्रमण
- लॉगिंग
- I/O में देरी
- अनावश्यक प्रक्रिया निर्माण (जैसे, CONNECTIVITY_CHANGE प्रसारण)
- अपर्याप्त मुक्त मेमोरी के कारण पेज कैश थ्रेशिंग
क्षमता बढ़ने पर घबराहट की एक निश्चित अवधि के लिए आवश्यक समय कम हो भी सकता है और नहीं भी। उदाहरण के लिए, यदि कोई ड्राइवर i2c बस से रीडिंग की प्रतीक्षा करते समय इंटरप्ट को अक्षम छोड़ देता है, तो इसमें एक निश्चित समय लगेगा, भले ही सीपीयू 384MHz या 2GHz पर हो। जब घबराहट शामिल हो तो प्रदर्शन को बेहतर बनाने के लिए क्षमता बढ़ाना कोई व्यवहार्य समाधान नहीं है। परिणामस्वरूप, तेज़ प्रोसेसर आमतौर पर घबराने वाली स्थितियों में प्रदर्शन में सुधार नहीं करेंगे।
अंत में, क्षमता के विपरीत, जिटर लगभग पूरी तरह से सिस्टम विक्रेता के डोमेन के भीतर है।
मेमोरी खपत
खराब प्रदर्शन के लिए परंपरागत रूप से मेमोरी खपत को दोषी ठहराया जाता है। जबकि उपभोग स्वयं एक प्रदर्शन समस्या नहीं है, यह लोमेमोरीकिलर ओवरहेड, सेवा पुनरारंभ और पेज कैश थ्रैशिंग के माध्यम से घबराहट पैदा कर सकता है। मेमोरी खपत को कम करने से खराब प्रदर्शन के प्रत्यक्ष कारणों से बचा जा सकता है, लेकिन ऐसे अन्य लक्षित सुधार भी हो सकते हैं जो उन कारणों से बचते हैं (उदाहरण के लिए, जब इसे जल्द ही पृष्ठांकित किया जाएगा तो इसे पृष्ठांकित होने से रोकने के लिए फ्रेमवर्क को पिन करना)।
प्रारंभिक डिवाइस प्रदर्शन का विश्लेषण
एक कार्यात्मक लेकिन खराब प्रदर्शन करने वाले सिस्टम से शुरुआत करना और उपयोगकर्ता द्वारा दिखाई देने वाले खराब प्रदर्शन के व्यक्तिगत मामलों को देखकर सिस्टम के व्यवहार को ठीक करने का प्रयास करना एक अच्छी रणनीति नहीं है। क्योंकि खराब प्रदर्शन आमतौर पर आसानी से प्रतिलिपि प्रस्तुत करने योग्य नहीं होता है (यानी, घबराना) या एक एप्लिकेशन समस्या, पूर्ण सिस्टम में बहुत सारे चर इस रणनीति को प्रभावी होने से रोकते हैं। परिणामस्वरूप, पूरे सिस्टम में प्रदर्शन को ठीक करने के प्रणालीगत अवसरों को खोते हुए कारणों की गलत पहचान करना और मामूली सुधार करना बहुत आसान है।
इसके बजाय, कोई नया उपकरण लाते समय निम्नलिखित सामान्य दृष्टिकोण का उपयोग करें:
- सभी ड्राइवरों के चलने और कुछ बुनियादी फ़्रीक्वेंसी गवर्नर सेटिंग्स के साथ यूआई में सिस्टम बूटिंग प्राप्त करें (यदि आप फ़्रीक्वेंसी गवर्नर सेटिंग्स बदलते हैं, तो नीचे दिए गए सभी चरणों को दोहराएं)।
- सुनिश्चित करें कि कर्नेल
sched_blocked_reasonट्रेसप्वाइंट के साथ-साथ डिस्प्ले पाइपलाइन में अन्य ट्रेसप्वाइंट का समर्थन करता है जो दर्शाता है कि फ्रेम को डिस्प्ले पर कब वितरित किया जाता है। - हल्के और सुसंगत कार्यभार (उदाहरण के लिए, यूआईबेंच या टचलेटेंसी में बॉल टेस्ट) चलाते समय संपूर्ण यूआई पाइपलाइन (आईआरक्यू के माध्यम से इनपुट प्राप्त करने से लेकर अंतिम स्कैनआउट तक) के लंबे निशान लें।
- हल्के और लगातार काम के बोझ में पाए गए फ़्रेम ड्रॉप को ठीक करें।
- चरण 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 अनुभाग में डिस्प्ले पाइपलाइन (एमडीएसएस) के बारे में ट्रेस में अतिरिक्त जानकारी देख सकें। क्वालकॉम एसओसी पर, आपको मानक सिस्ट्रेस दृश्य में जीपीयू के बारे में कोई अतिरिक्त जानकारी नहीं दिखाई देगी, लेकिन परिणाम ट्रेस में ही मौजूद हैं (विवरण के लिए, सिस्ट्रेस को समझना देखें)।
इस प्रकार की डिस्प्ले ट्रेसिंग से आप जो चाहते हैं वह एक एकल घटना है जो सीधे इंगित करती है कि डिस्प्ले पर एक फ्रेम वितरित किया गया है। वहां से, आप यह निर्धारित कर सकते हैं कि आपने अपना फ़्रेम समय सफलतापूर्वक पूरा कर लिया है या नहीं; यदि इवेंट X n-1 (60Hz डिस्प्ले मानकर) के बाद इवेंट X n 16.7ms से कम होता है, तो आप जानते हैं कि आपने जंक नहीं किया है। यदि आपका एसओसी ऐसे संकेत प्रदान नहीं करता है, तो उन्हें प्राप्त करने के लिए अपने विक्रेता के साथ काम करें। फ़्रेम पूर्ण होने के निश्चित संकेत के बिना जिटर को डीबग करना बेहद कठिन है।
सिंथेटिक बेंचमार्क का उपयोग करना
किसी डिवाइस की बुनियादी कार्यक्षमता मौजूद है यह सुनिश्चित करने के लिए सिंथेटिक बेंचमार्क उपयोगी होते हैं। हालाँकि, कथित डिवाइस प्रदर्शन के लिए बेंचमार्क को प्रॉक्सी के रूप में मानना उपयोगी नहीं है।
एसओसी के साथ अनुभवों के आधार पर, एसओसी के बीच सिंथेटिक बेंचमार्क प्रदर्शन में अंतर बोधगम्य यूआई प्रदर्शन (गिराए गए फ्रेम की संख्या, 99 वें प्रतिशत फ्रेम समय, आदि) में समान अंतर से संबंधित नहीं है। सिंथेटिक बेंचमार्क केवल क्षमता वाले बेंचमार्क हैं; जिटर केवल बेंचमार्क के थोक संचालन से समय चुराकर इन बेंचमार्क के मापा प्रदर्शन को प्रभावित करता है। परिणामस्वरूप, सिंथेटिक बेंचमार्क स्कोर उपयोगकर्ता-कथित प्रदर्शन के मीट्रिक के रूप में अधिकतर अप्रासंगिक हैं।
बेंचमार्क एक्स चलाने वाले दो एसओसी पर विचार करें जो यूआई के 1000 फ्रेम प्रस्तुत करते हैं और कुल रेंडरिंग समय की रिपोर्ट करते हैं (कम स्कोर बेहतर है)।
- एसओसी 1 बेंचमार्क एक्स के प्रत्येक फ्रेम को 10 एमएस में प्रस्तुत करता है और 10,000 स्कोर देता है।
- SOC 2 1ms में 99% फ़्रेम प्रस्तुत करता है, लेकिन 100ms में 1% फ़्रेम प्रस्तुत करता है और 19,900 स्कोर करता है, जो नाटकीय रूप से बेहतर स्कोर है।
यदि बेंचमार्क वास्तविक यूआई प्रदर्शन का संकेतक है, तो एसओसी 2 अनुपयोगी होगा। 60Hz ताज़ा दर मानते हुए, SOC 2 में हर 1.5 सेकंड के ऑपरेशन में एक जानकी फ्रेम होगा। इस बीच, एसओसी 1 (बेंचमार्क एक्स के अनुसार धीमी एसओसी) पूरी तरह से तरल होगी।
बग रिपोर्ट का उपयोग करना
बग रिपोर्ट कभी-कभी प्रदर्शन विश्लेषण के लिए उपयोगी होती हैं, लेकिन क्योंकि वे बहुत भारी होती हैं, वे छिटपुट जंक मुद्दों को डीबग करने के लिए शायद ही कभी उपयोगी होती हैं। वे इस बारे में कुछ संकेत दे सकते हैं कि सिस्टम किसी निश्चित समय पर क्या कर रहा था, खासकर यदि जंक एक एप्लिकेशन ट्रांज़िशन के आसपास था (जो बग रिपोर्ट में लॉग किया गया है)। बग रिपोर्ट यह भी संकेत दे सकती है कि सिस्टम में कुछ अधिक व्यापक रूप से गलत है जो इसकी प्रभावी क्षमता को कम कर सकता है (जैसे थर्मल थ्रॉटलिंग या मेमोरी फ़्रेग्मेंटेशन)।
टच लेटेंसी का उपयोग करना
खराब व्यवहार के कई उदाहरण TouchLatency से आते हैं, जो कि Pixel और Pixel XL के लिए उपयोग किया जाने वाला पसंदीदा आवधिक कार्यभार है। यह frameworks/base/tests/TouchLatency पर उपलब्ध है और इसके दो मोड हैं: टच लेटेंसी और बाउंसिंग बॉल (मोड स्विच करने के लिए, ऊपरी-दाएं कोने में बटन पर क्लिक करें)।
बाउंसिंग बॉल टेस्ट बिल्कुल उतना ही सरल है जितना कि यह दिखाई देता है: उपयोगकर्ता इनपुट की परवाह किए बिना, एक गेंद स्क्रीन के चारों ओर हमेशा के लिए उछलती रहती है। यह आमतौर पर पूरी तरह से चलाने के लिए अब तक का सबसे कठिन परीक्षण भी है, लेकिन यह बिना किसी गिरे हुए फ्रेम के चलने के जितना करीब आएगा, आपका डिवाइस उतना ही बेहतर होगा। बाउंसिंग बॉल परीक्षण कठिन है क्योंकि यह एक तुच्छ लेकिन पूरी तरह से सुसंगत कार्यभार है जो बहुत कम घड़ी पर चलता है (यह मानता है कि डिवाइस में आवृत्ति गवर्नर है; यदि डिवाइस निश्चित घड़ियों के साथ चल रहा है, तो सीपीयू/जीपीयू को लगभग न्यूनतम तक डाउनक्लॉक करें पहली बार बाउंसिंग बॉल टेस्ट चलाते समय)। जैसे-जैसे सिस्टम बंद हो जाता है और घड़ियाँ निष्क्रिय होने लगती हैं, प्रति फ्रेम आवश्यक सीपीयू/जीपीयू समय बढ़ जाता है। आप गेंद को देख सकते हैं और जंक चीजों को देख सकते हैं, और आप सिस्ट्रेस में छूटे हुए फ़्रेमों को भी देख पाएंगे।
क्योंकि कार्यभार इतना सुसंगत है, आप यूआई पाइपलाइन के बजाय प्रत्येक छूटे हुए फ्रेम के दौरान सिस्टम पर वास्तव में क्या चल रहा है, इस पर नज़र रखकर अधिकांश उपयोगकर्ता-दृश्यमान कार्यभार की तुलना में घबराहट के अधिकांश स्रोतों को अधिक आसानी से पहचान सकते हैं। निचली घड़ियाँ घबराहट के प्रभाव को बढ़ाती हैं जिससे यह अधिक संभावना हो जाती है कि कोई भी घबराहट फ्रेम के गिरने का कारण बनती है। परिणामस्वरूप, TouchLatency 60FPS के जितना करीब होगी, आपके खराब सिस्टम व्यवहार की संभावना उतनी ही कम होगी जो बड़े अनुप्रयोगों में छिटपुट, कठिन-से-पुनः उत्पन्न होने वाले जंक का कारण बनेगी।
चूँकि घबराहट अक्सर (लेकिन हमेशा नहीं) क्लॉकस्पीड-अपरिवर्तनीय होती है, निम्नलिखित कारणों से घबराहट का निदान करने के लिए एक परीक्षण का उपयोग करें जो बहुत कम घड़ियों पर चलता है:
- सभी घबराहट क्लॉकस्पीड-अपरिवर्तनीय नहीं हैं; कई स्रोत केवल CPU समय का उपभोग करते हैं।
- गवर्नर को क्लॉकिंग डाउन करके औसत फ्रेम समय को समय सीमा के करीब लाना चाहिए, ताकि गैर-यूआई कार्य चलाने में लगने वाला समय इसे फ्रेम को गिराने के लिए किनारे पर धकेल सके।