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