किसी डिवाइस की परफ़ॉर्मेंस का आकलन करने के लिए, Simpleperf का इस्तेमाल करें. Simpleperf, Android पर ऐप्लिकेशन और नेटिव प्रोसेस, दोनों के लिए नेटिव प्रोफ़ाइलिंग टूल है. ऐप्लिकेशन के सीपीयू के इस्तेमाल और थ्रेड की गतिविधि की रीयल टाइम में जांच करने के लिए, सीपीयू प्रोफ़ाइलर का इस्तेमाल करें.
परफ़ॉर्मेंस के लिए, उपयोगकर्ता को दो इंडिकेटर दिखते हैं:
- अनुमानित और बेहतर परफ़ॉर्मेंस. क्या यूज़र इंटरफ़ेस (यूआई) फ़्रेम छोड़ता है या लगातार 60 एफ़पीएस पर रेंडर करता है? क्या ऑडियो, आर्टफ़ैक्ट या पॉपिंग के बिना चलता है? उपयोगकर्ता के स्क्रीन को छूने और डिसप्ले पर इफ़ेक्ट दिखने में कितना समय लगता है?
- लंबे समय तक चलने वाली कार्रवाइयों में लगने वाला समय (जैसे, ऐप्लिकेशन खोलना).
पहला, दूसरे से ज़्यादा ध्यान खींचता है. आम तौर पर, उपयोगकर्ताओं को ऐप्लिकेशन के खुलने में लगने वाले समय में होने वाली रुकावट का पता चल जाता है. हालांकि, वे यह नहीं बता पाएंगे कि ऐप्लिकेशन के खुलने में 500 मिलीसेकंड लगे या 600 मिलीसेकंड, जब तक कि वे एक साथ दो डिवाइसों को न देख रहे हों. टच रिस्पॉन्स में लगने वाला समय तुरंत पता चल जाता है और यह किसी डिवाइस की परफ़ॉर्मेंस को बेहतर बनाने में अहम भूमिका निभाता है.
इसलिए, तेज़ डिवाइस में यूज़र इंटरफ़ेस (यूआई) पाइपलाइन, सिस्टम में सबसे ज़्यादा अहम होती है. इसका मतलब है कि यूज़र इंटरफ़ेस (यूआई) की पाइपलाइन को ऐसे किसी भी काम को रोकना चाहिए जो फ़्लूइड यूज़र इंटरफ़ेस के लिए ज़रूरी नहीं है. यूज़र इंटरफ़ेस (यूआई) को बेहतर बनाने के लिए, बैकग्राउंड में सिंक करने, सूचना डिलीवर करने, और इसी तरह के अन्य कामों को तब तक रोकना चाहिए, जब तक यूआई से जुड़े काम पूरे नहीं हो जाते. यूज़र इंटरफ़ेस (यूआई) को बेहतर बनाने के लिए, लंबी अवधि तक चलने वाली कार्रवाइयों (एचडीआर+ रनटाइम, ऐप्लिकेशन स्टार्टअप वगैरह) की परफ़ॉर्मेंस को कम किया जा सकता है.
क्षमता बनाम गड़बड़ी
डिवाइस की परफ़ॉर्मेंस के बारे में सोचते समय, क्षमता और जटर, दो अहम मेट्रिक हैं.
क्षमता
डिवाइस में किसी संसाधन की कुल संख्या को कैपेसिटी कहा जाता है. यह संख्या, किसी तय समयावधि के दौरान डिवाइस में मौजूद होती है. इसमें सीपीयू संसाधन, जीपीयू संसाधन, I/O संसाधन, नेटवर्क संसाधन, मेमोरी बैंडविड्थ या ऐसी ही कोई मेट्रिक शामिल हो सकती है. पूरे सिस्टम की परफ़ॉर्मेंस की जांच करते समय, अलग-अलग कॉम्पोनेंट को अलग-अलग रखना और परफ़ॉर्मेंस तय करने वाली एक मेट्रिक को मानना मददगार हो सकता है. ऐसा खास तौर पर, किसी नए डिवाइस को ट्यून करते समय किया जा सकता है, क्योंकि उस डिवाइस पर चलने वाले वर्कलोड में बदलाव नहीं किया जा सकता.
किसी सिस्टम की क्षमता, ऑनलाइन कंप्यूटिंग संसाधनों के आधार पर अलग-अलग होती है. सीपीयू/जीपीयू की फ़्रीक्वेंसी बदलना, कैपेसिटी बदलने का मुख्य तरीका है. हालांकि, इसके अलावा भी कुछ तरीके हैं, जैसे कि सीपीयू कोर की संख्या को ऑनलाइन बदलना. इसलिए, किसी सिस्टम की क्षमता, बिजली की खपत से मेल खाती है. क्षमता में बदलाव करने पर, बिजली की खपत में भी हमेशा उसी तरह का बदलाव होता है.
किसी भी समय ज़रूरी क्षमता, रनिंग ऐप्लिकेशन के हिसाब से तय होती है. इसलिए, प्लैटफ़ॉर्म किसी भी टास्क के लिए ज़रूरी क्षमता में ज़्यादा बदलाव नहीं कर सकता. ऐसा करने के लिए, रनटाइम में होने वाले सुधारों (Android फ़्रेमवर्क, ART, Bionic, जीपीयू कंपाइलर/ड्राइवर, और कर्नेल) का ही इस्तेमाल किया जा सकता है.
सिग्नल में गड़बड़ी
किसी वर्कलोड के लिए ज़रूरी क्षमता को आसानी से देखा जा सकता है, लेकिन जिटर को समझना ज़्यादा मुश्किल है. हमारा सुझाव है कि सुपर कंप्यूटर की परफ़ॉर्मेंस में कमी का मामला: ASCI Q के 8, 192 प्रोसेसर पर बेहतरीन परफ़ॉर्मेंस हासिल करना शीर्षक वाला पेपर पढ़ें. इससे आपको पता चलेगा कि तेज़ सिस्टम में,गड़बड़ी की दर कैसे रुकावट बनती है. (इसमें यह जांच की गई है कि ASCI Q सुपरकंप्यूटर को उम्मीद के मुताबिक परफ़ॉर्मेंस क्यों नहीं मिली. साथ ही, इसमें बड़े सिस्टम को ऑप्टिमाइज़ करने के बारे में बेहतर तरीके से बताया गया है.)
इस पेज पर, 'जटर' शब्द का इस्तेमाल उस चीज़ के बारे में बताने के लिए किया गया है जिसे ASCI Q पेपर में नॉइज़ कहा गया है. जटर, सिस्टम के काम करने के तरीके में होने वाला अचानक बदलाव है. इसकी वजह से, काम ठीक से नहीं हो पाता. आम तौर पर, यह ऐसा काम होता है जिसे चलाना ज़रूरी होता है. हालांकि, हो सकता है कि इसके लिए समय से जुड़ी कोई ज़रूरी शर्त न हो, ताकि इसे किसी खास समय पर चलाया जा सके. यह रैंडम होता है. इसलिए, किसी दिए गए वर्कलोड के लिए, जिटर की मौजूदगी को गलत साबित करना बहुत मुश्किल होता है. यह साबित करना भी बहुत मुश्किल है कि परफ़ॉर्मेंस से जुड़ी किसी समस्या की वजह, झटके की कोई ऐसी वजह है जिसकी जानकारी पहले से है. आम तौर पर, ट्रैसिंग या लॉगिंग जैसे टूल का इस्तेमाल, 'जटर' की वजहों का पता लगाने के लिए किया जाता है. हालांकि, इन टूल की वजह से भी 'जटर' हो सकता है.
Android के असल दुनिया में लागू होने पर, जित्टर के सोर्स में ये शामिल हैं:
- शेड्यूलर में देरी
- इंटरप्ट हैंडलर
- ड्राइवर कोड, प्रीएंपशन या इंटरप्ट की सुविधा बंद होने के बावजूद बहुत ज़्यादा समय से चल रहा है
- लंबे समय तक चलने वाले सॉफ़्टइर्क्स
- लॉक का विवाद (ऐप्लिकेशन, फ़्रेमवर्क, कर्नेल ड्राइवर, बाइंडर लॉक, mmap लॉक)
- फ़ाइल डिस्क्रिप्टर कॉन्टेंट, जहां कम प्राथमिकता वाली थ्रेड किसी फ़ाइल पर लॉक रखती है, जिससे ज़्यादा प्राथमिकता वाली थ्रेड को चलने से रोका जाता है
- वर्कम्यू में यूज़र इंटरफ़ेस (यूआई) से जुड़ा अहम कोड चलाना, जहां इसकी प्रोसेस में देरी हो सकती है
- सीपीयू के आइडल ट्रांज़िशन
- लॉग इन हो रहा है
- I/O में लगने वाली देरी
- ग़ैर-ज़रूरी प्रोसेस बनाना (उदाहरण के लिए,
CONNECTIVITY_CHANGEब्रॉडकास्ट) - ज़रूरत के मुताबिक खाली मेमोरी न होने की वजह से, पेज कैश मेमोरी का तेज़ी से इस्तेमाल होना
कपैसिटी बढ़ने पर, किसी तय समयावधि के लिए जिटर की ज़रूरी अवधि कम हो सकती है या नहीं भी. उदाहरण के लिए, अगर कोई ड्राइवर i2c बस से डेटा पढ़ने के लिए इंतज़ार करते समय, इंटरप्ट को बंद रखता है, तो उसे एक तय समय लगेगा. भले ही, सीपीयू 384 MHz या 2 GHz पर हो. जब 'जटर' की समस्या होती है, तो परफ़ॉर्मेंस को बेहतर बनाने के लिए, कैपेसिटी बढ़ाना एक सही तरीका नहीं है. इस वजह से, आम तौर पर, तेज़ प्रोसेसर से, धीमे इंटरनेट की वजह से होने वाली रुकावटों के दौरान परफ़ॉर्मेंस बेहतर नहीं होगी.
आखिर में, क्षमता के उलट, जिटर का असर सिस्टम वेंडर पर पड़ता है.
मेमोरी का इस्तेमाल
आम तौर पर, खराब परफ़ॉर्मेंस के लिए मेमोरी खर्च को ज़िम्मेदार माना जाता है. हालांकि, प्रोसेस का इस्तेमाल करना, परफ़ॉर्मेंस से जुड़ी कोई समस्या नहीं है, लेकिन इससे कम मेमोरी वाले डिवाइसों पर, प्रोसेस के ओवरहेड, सेवा के फिर से शुरू होने, और पेज कैश मेमोरी के थ्रैशिंग की वजह से, पेज पर रुकावट आ सकती है. मेमोरी खर्च को कम करने से, परफ़ॉर्मेंस खराब होने की सीधी वजहों से बचा जा सकता है. हालांकि, इन वजहों से बचाने के लिए, कुछ और भी सुधार किए जा सकते हैं. उदाहरण के लिए, फ़्रेमवर्क को पिन करना, ताकि उसे पेज से बाहर न किया जाए, क्योंकि उसे जल्द ही पेज पर वापस लाया जाएगा.
डिवाइस की शुरुआती परफ़ॉर्मेंस का विश्लेषण करना
किसी ऐसे सिस्टम से शुरुआत करना जो काम तो करता है, लेकिन उसकी परफ़ॉर्मेंस खराब है और उपयोगकर्ता को दिखने वाली खराब परफ़ॉर्मेंस के अलग-अलग मामलों को देखकर, सिस्टम के व्यवहार को ठीक करने की कोशिश करना, एक सही रणनीति नहीं है. आम तौर पर, खराब परफ़ॉर्मेंस को दोहराना आसान नहीं होता. इसका मतलब है कि वीडियो में झटके आना या ऐप्लिकेशन से जुड़ी कोई समस्या होना. साथ ही, पूरे सिस्टम में मौजूद कई वैरिएबल की वजह से, इस रणनीति का असर नहीं पड़ता. इसलिए, समस्याओं की वजहों की गलत पहचान करना और छोटे सुधार करना बहुत आसान है. साथ ही, सिस्टम की परफ़ॉर्मेंस को ठीक करने के सिस्टम के अवसरों को भी अनदेखा किया जा सकता है.
इसके बजाय, नया डिवाइस जोड़ते समय, यह सामान्य तरीका अपनाएं:
- सिस्टम को यूज़र इंटरफ़ेस (यूआई) पर बूट करें. इसके लिए, सभी ड्राइवर चालू होने चाहिए और फ़्रीक्वेंसी गवर्नर की कुछ बुनियादी सेटिंग होनी चाहिए. अगर फ़्रीक्वेंसी गवर्नर की सेटिंग बदली जाती हैं, तो नीचे दिए गए सभी चरणों को दोहराएं.
- पक्का करें कि कर्नेल,
sched_blocked_reasonट्रेसपॉइंट के साथ-साथ डिसप्ले पाइपलाइन में मौजूद अन्य ट्रेसपॉइंट के साथ काम करता हो. इन ट्रेसपॉइंट से पता चलता है कि फ़्रेम को डिसप्ले पर कब डिलीवर किया गया. - कम और लगातार वर्कलोड (उदाहरण के लिए, UiBench या TouchLatency) चलाते समय, पूरी यूआई पाइपलाइन (IRQ के ज़रिए इनपुट पाने से लेकर फ़ाइनल स्कैनआउट तक) के लंबे ट्रैक लें.
- कम और लगातार वर्कलोड में फ़्रेम ड्रॉप की समस्या को ठीक करें.
- तीसरे से लेकर चौथे चरण तक, यह प्रक्रिया तब तक दोहराते रहें, जब तक एक बार में 20 सेकंड से ज़्यादा समय तक, वीडियो बिना किसी फ़्रेम के न चलने की समस्या ठीक न हो जाए.
- उपयोगकर्ता को दिखने वाले अन्य सोर्स पर जाएं.
डिवाइस को चालू करने के दौरान, ये आसान काम किए जा सकते हैं:
- पक्का करें कि आपके कर्नेल में sched_blocked_reason ट्रैसपॉइंट पैच हो. यह ट्रेसपॉइंट, systrace में शेड्यूल की गई ट्रेस कैटगरी के साथ चालू होता है. साथ ही, यह उस फ़ंक्शन की जानकारी देता है जो थ्रेड के रुकावट के बिना स्लीप मोड में जाने पर, स्लीप मोड को कंट्रोल करता है. यह परफ़ॉर्मेंस का विश्लेषण करने के लिए ज़रूरी है, क्योंकि बिना रुकावट के नींद मोड में रहना, जटर का एक सामान्य इंडिकेटर है.
- पक्का करें कि आपके पास जीपीयू और डिसप्ले पाइपलाइन के लिए ज़रूरत के मुताबिक ट्रैकिंग हो. हाल ही में रिलीज़ किए गए Qualcomm SOCs पर, ट्रैकपॉइंट इनका इस्तेमाल करके चालू किए जाते हैं:
adb shell "echo 1 > /d/tracing/events/kgsl/enable"adb shell "echo 1 > /d/tracing/events/mdss/enable"
systrace चलाने पर, ये इवेंट चालू रहते हैं, ताकि आप mdss_fb0 सेक्शन में, डिसप्ले पाइपलाइन (एमडीएसएस) के बारे में ट्रैक में ज़्यादा जानकारी देख सकें. Qualcomm SOCs पर, आपको स्टैंडर्ड systrace व्यू में GPU के बारे में कोई अतिरिक्त जानकारी नहीं दिखेगी. हालांकि, नतीजे ट्रैक में मौजूद होते हैं. ज़्यादा जानकारी के लिए, systrace को समझना लेख पढ़ें.
इस तरह की डिसप्ले ट्रैकिंग से आपको एक ऐसा इवेंट चाहिए जो सीधे तौर पर यह बताता हो कि डिसप्ले पर कोई फ़्रेम डिलीवर किया गया है. इससे, यह तय किया जा सकता है कि आपने फ़्रेम टाइम को सही से पूरा किया है या नहीं. अगर इवेंट Xn, इवेंट Xn-1 के 16.7 मिलीसेकंड के अंदर होता है (60 हर्ट्ज़ डिसप्ले के हिसाब से), तो इसका मतलब है कि आपके वीडियो में झटका नहीं आया. अगर आपका एसओसी ऐसे सिग्नल नहीं देता है, तो उन्हें पाने के लिए अपने वेंडर के साथ काम करें. फ़्रेम पूरा होने के सटीक सिग्नल के बिना, डिटरबेंस को डीबग करना बहुत मुश्किल होता है.
सिंथेटिक बेंचमार्क का इस्तेमाल करना
सिंथेटिक बेंचमार्क, यह पक्का करने के लिए काम के होते हैं कि डिवाइस की बुनियादी सुविधाएं मौजूद हैं या नहीं. हालांकि, डिवाइस की परफ़ॉर्मेंस का अनुमान लगाने के लिए, बेंचमार्क का इस्तेमाल करना फ़ायदेमंद नहीं है.
एसओसी के अनुभवों के आधार पर, एसओसी के बीच सिंथेटिक बेंचमार्क की परफ़ॉर्मेंस में अंतर, यूज़र इंटरफ़ेस (यूआई) की परफ़ॉर्मेंस (ड्रॉप किए गए फ़्रेम की संख्या, 99वें पर्सेंटाइल फ़्रेम का समय वगैरह) में अंतर से मेल नहीं खाता. सिंथेटिक मानदंड, सिर्फ़ क्षमता वाले मानदंड होते हैं. जटर का असर, इन मानदंडों की मेज़र की गई परफ़ॉर्मेंस पर सिर्फ़ तब पड़ता है, जब यह मानदंड के एक साथ कई अनुरोधों को प्रोसेस करने में लगने वाले समय को कम कर देता है. इसलिए, सिंथेटिक बेंचमार्क स्कोर, उपयोगकर्ता के हिसाब से परफ़ॉर्मेंस की मेट्रिक के तौर पर काम के नहीं होते.
मान लें कि दो एसओसी, बेंचमार्क X चला रहे हैं. यह बेंचमार्क, यूज़र इंटरफ़ेस (यूआई) के 1,000 फ़्रेम को रेंडर करता है और रेंडरिंग में लगने वाले कुल समय की जानकारी देता है. कम स्कोर बेहतर होता है.
- SOC 1, बेंचमार्क X के हर फ़्रेम को 10 एमएस में रेंडर करता है और उसे 10,000 का स्कोर मिलता है.
- SOC 2, 99% फ़्रेम को 1 मि॰से॰ में रेंडर करता है, लेकिन 1% फ़्रेम को 100 मि॰से॰ में रेंडर करता है. साथ ही, इसका स्कोर 19,900 है, जो काफ़ी बेहतर है.
अगर बेंचमार्क, यूज़र इंटरफ़ेस (यूआई) की असल परफ़ॉर्मेंस का संकेत देता है, तो SOC 2 का इस्तेमाल नहीं किया जा सकता. अगर 60 हर्ट्ज़ की रीफ़्रेश दर मानी जाती है, तो SOC 2 में हर 1.5 सेकंड में एक फ़्रेम में रुकावट आएगी. इस दौरान, SOC 1 (बेंचमार्क X के हिसाब से धीमा SOC) काफ़ी बेहतर तरीके से काम करेगा.
गड़बड़ी की रिपोर्ट का इस्तेमाल करना
गड़बड़ी की रिपोर्ट, परफ़ॉर्मेंस का विश्लेषण करने के लिए कभी-कभी काम की होती हैं. हालांकि, ये बहुत भारी होती हैं, इसलिए इन्हें कभी-कभी रुक-रुककर होने वाली समस्याओं को डीबग करने के लिए इस्तेमाल नहीं किया जा सकता. इनसे यह पता चल सकता है कि किसी खास समय पर सिस्टम क्या कर रहा था. ऐसा खास तौर पर तब होता है, जब ऐप्लिकेशन ट्रांज़िशन (जिसे गड़बड़ी की रिपोर्ट में लॉग किया जाता है) के दौरान रुकावट आती है. गड़बड़ी की रिपोर्ट से यह भी पता चल सकता है कि सिस्टम में कोई ऐसी समस्या है जिसकी वजह से उसकी परफ़ॉर्मेंस पर असर पड़ सकता है. जैसे, थर्मल ट्रॉथलिंग या मेमोरी फ़्रैगमेंटेशन.
TouchLatency का इस्तेमाल करना
खराब परफ़ॉर्मेंस के कई उदाहरण, TouchLatency से मिलते हैं. यह Pixel और Pixel XL के लिए, समय-समय पर होने वाले काम का पसंदीदा तरीका है. यह सुविधा frameworks/base/tests/TouchLatency पर उपलब्ध है. इसमें दो मोड हैं: टच में लगने वाला समय और बॉल बाउंस करना. मोड स्विच करने के लिए, सबसे ऊपर दाएं कोने में मौजूद बटन पर क्लिक करें.
बॉल के उछलने की जांच उतनी ही आसान है जितनी दिखती है: उपयोगकर्ता के इनपुट के बावजूद, बॉल हमेशा स्क्रीन पर उछलती रहती है. आम तौर पर, यह टेस्ट पूरी तरह से सही तरीके से चलाना अब तक सबसे मुश्किल होता है. हालांकि, अगर यह टेस्ट बिना किसी फ़्रेम के चलता है, तो आपका डिवाइस बेहतर होगा. स्क्रीन पर गेंद उछलने की जांच करना मुश्किल है, क्योंकि यह एक आसान लेकिन पूरी तरह से एक जैसा वर्कलोड है, जो बहुत कम क्लॉक पर चलता है. यह इस बात पर आधारित है कि डिवाइस में फ़्रीक्वेंसी गवर्नर है या नहीं. अगर डिवाइस, तय क्लॉक पर चल रहा है, तो पहली बार स्क्रीन पर गेंद उछलने की जांच करते समय, सीपीयू/जीपीयू को कम से कम क्लॉक पर सेट करें. जब सिस्टम शांत हो जाता है और क्लॉक, आइडल के करीब आ जाती हैं, तो हर फ़्रेम के लिए सीपीयू/जीपीयू का ज़रूरी समय बढ़ जाता है. गेंद को देखकर, आपको फ़्रेम में रुकावट दिखेगी. साथ ही, systrace में भी आपको छूटे हुए फ़्रेम दिखेंगे.
वर्कफ़्लो में कोई बदलाव नहीं होने की वजह से, यूज़र को दिखने वाले ज़्यादातर वर्कफ़्लो के मुकाबले, ज़्यादा आसानी से ज़्यादातर जटर सोर्स की पहचान की जा सकती है. इसके लिए, यूज़र इंटरफ़ेस (यूआई) की पाइपलाइन के बजाय, हर छूटे हुए फ़्रेम के दौरान सिस्टम पर चल रही प्रोसेस को ट्रैक करें. कम क्लॉक, फ़्रेम में रुकावट आने की संभावना को बढ़ाकर, जिटर के असर को बढ़ाती हैं. इस वजह से, TouchLatency का 60 एफ़पीएस (फ़्रेम प्रति सेकंड) के करीब होना, सिस्टम के खराब व्यवहार की संभावना को कम करता है. इससे बड़े ऐप्लिकेशन में, कभी-कभी होने वाली और फिर से दोहराने में मुश्किल होने वाली रुकावटों को कम किया जा सकता है.
अक्सर (हालांकि, हमेशा नहीं) जटर, क्लॉकस्पीड पर निर्भर नहीं करता. इसलिए, जटर का पता लगाने के लिए, ऐसे टेस्ट का इस्तेमाल करें जो बहुत कम क्लॉक पर चलता हो. ऐसा इन वजहों से करें:
- सभी जटर, क्लॉकस्पीड के हिसाब से नहीं होते. कई सोर्स सिर्फ़ सीपीयू का समय लेते हैं.
- गवर्नर को समय कम करके, औसत फ़्रेम टाइम को समयसीमा के करीब लाना चाहिए, ताकि यूज़र इंटरफ़ेस (यूआई) से जुड़े काम को पूरा करने में लगने वाला समय, फ़्रेम छोड़ने की सीमा से ज़्यादा न हो.