Android Performance Tuner के बारे में ज़्यादा जानकारी

 

'Android की ज़रूरी जानकारी' में, परफ़ॉर्मेंस की अहम जानकारी एक नई सुविधा है. यह खास तौर पर, गेम डेवलपर के लिए बनाई गई है. साथ ही, यह उन डेवलपर के लिए भी बनाई गई है जिनके ऐप्लिकेशन में नेटिव कोड का इस्तेमाल किया जाता है. Android Performance Tuner से परफ़ॉर्मेंस की अहम जानकारी मिलती है. यह एक नया प्लग-इन है जिसकी मदद से गेम डेवलपर, 'Android की ज़रूरी जानकारी' को ज़्यादा बेहतर और असरदार तरीके से इस्तेमाल कर सकते हैं. 

नीचे दिया गया यह लेख Android Performance Tuner और परफ़ॉर्मेंस की अहम जानकारी के सबसे ज़रूरी सिद्धांतों के बारे में बताता है. साथ ही, इस लेख में बताया गया है कि जानकारी देने के लिए किन चीज़ों की मदद ली जाती है:

सबसे ज़रूरी सिद्धांतों के बारे में जानना

फ़िडेलिटी के पैरामीटर और क्वालिटी लेवल

आपके ऐप्लिकेशन के फ़िडेलिटी के पैरामीटर, आपके गेम की परफ़ॉर्मेंस और ग्राफ़िक्स की क्वालिटी से जुड़ी चीज़ों, जैसे कि जानकारी के लेवल का पता लगाना, गेम का रिज़ॉल्यूशन, और समस्याओं को ठीक करने के तरीके पर असर डालते हैं. ये लगातार (उदाहरण के लिए, 0 से 100 प्रतिशत), बाइनरी (हां/नहीं) या दूसरी वैल्यू का कोई सेट हो सकते हैं.

क्वालिटी लेवल, आपके फ़िडेलिटी के पैरामीटर के लिए पहले से तय की गई वैल्यू का सेट होता है. क्वालिटी लेवल की मदद से आप कई तरह के पैरामीटर की जानकारी पा सकते हैं. साथ ही, ये आपका ऐप्लिकेशन इस्तेमाल करने वाले लोगों के कुछ सबसेट के लिए, फ़्रेम रेंडर होने की स्थिर दर पर, इस्तेमाल किए जा सकने वाले फ़िडेलिटी लेवल देते हैं. कुछ ऐसे मिले-जुले पैरामीटर भी हो सकते हैं जिनसे ऐप्लिकेशन इस्तेमाल करने का, बहुत काम का अनुभव न मिले.

फ़िडेलिटी के पैरामीटर और क्वालिटी लेवल सेट करने का तरीका

Android Performance Tuner के इंटिग्रेशन के दौरान, आपके ऐप्लिकेशन के लिए फ़िडेलिटी के पैरामीटर और उनकी क्वालिटी के लेवल तय किए जाते हैं. आप इंटिग्रेशन के दौरान, क्वालिटी के ज़्यादा से ज़्यादा 15 लेवल तय कर सकते हैं. हालांकि, इस दौरान आप जितना चाहें उतने फ़िडेलिटी पैरामीटर का इस्तेमाल कर सकते हैं. लेवल को फ़िडेलिटी के बढ़ते क्रम में रखा गया है, जहां सबसे कम फ़िडेलिटी लेवल एक है.

Play Console में आप अपने ऐप्लिकेशन के क्वालिटी लेवल और फ़िडेलिटी के पैरामीटर देख सकते हैं (क्वालिटी > Android की ज़रूरी जानकारी > खास जानकारी > में क्वालिटी लेवल की जांच करें को चुनें), लेकिन इसे आप सिर्फ़ पढ़ सकते हैं. पैरामीटर में बदलाव करने के लिए आपको अपडेट रिलीज़ करना होगा; साथ ही, इसके बारे में ज़्यादा जानकारी पाने के लिए, इंटिग्रेशन करने का तरीका जानें पर जाएं.

फ़िडेलिटी के पैरामीटर और क्वालिटी लेवल को इस्तेमाल करने का तरीका

क्वालिटी लेवल का इस्तेमाल सत्रों को टैग करने के लिए किया जाता है, ताकि आप यह तय कर सकें कि डिवाइस के मॉडल जिस क्वालिटी लेवल पर चल रहे हैं वह बहुत ज़्यादा है या बहुत कम है. 

फ़िडेलिटी पैरामीटर का इस्तेमाल यह पहचान करने के लिए किया जाता है कि हर उपयोगकर्ता के डिवाइस को क्वालिटी लेवल से कैसे मैप करें.

ज़रूरी जानकारी: अगर आपके फ़िडेलिटी के पैरामीटर (और क्वालिटी लेवल), उपयोगकर्ता के डिवाइसों पर आपके ऐप्लिकेशन की सेटिंग को सही तरीके से नहीं दिखाते हैं, तो आपके सत्र पहले से तय किसी क्वालिटी लेवल से मैप नहीं किए जा सकते. ऐसे सत्र "अज्ञात" क्वालिटी लेवल पर दिखाए जाते हैं. "अज्ञात" क्वालिटी लेवल में फ़िडेलिटी के कई अलग-अलग लेवल शामिल हो सकते हैं, जिसकी वजह से "अज्ञात" क्वालिटी लेवल पर समस्याओं को ठीक करना आसान नहीं होता है. अगर ऐसा हो रहा है, तो हम आपको इंटिग्रेशन की जांच करने का सुझाव देते हैं.

क्वालिटी लेवल के बारे में ज़्यादा जानने के लिए, Android Performance Tuner से जुड़ी समस्याओं और अक्सर पूछे जाने वाले सवाल को हल करें पर जाएं. इसमें ऐप्लिकेशन इस्तेमाल करने वाले लोगों के लिए तय किए गए क्वालिटी लेवल भी शामिल हैं.

एनोटेशन

एनोटेशन, आपके गेम या ऐप्लिकेशन में दिखाए जाने वाले सीन में "टैग" के तौर लिखे जाते हैं. ये इस बारे में ज़रूरी जानकारी देते हैं कि आपका गेम, दिए गए फ़्रेम में क्या कर रहा है. नीचे दी गई चीज़ों के हिसाब से एनोटेशन को तैयार किया गया है:

  • एनोटेशन टाइप: एनोटेशन की वैल्यू
    • उदाहरण के लिए: “किरदार”: “हीरो का किरदार”

ध्यान दें: एक फ़्रेम में एक से ज़्यादा एनोटेशन हो सकते हैं.

एनोटेशन सेट करने का तरीका

इंटिग्रेशन के दौरान एनोटेशन तय किए जाते हैं. एनोटेशन में बदलाव करने के लिए आपको अपडेट रिलीज़ करना होगा; साथ ही, इसके बारे में ज़्यादा ज़रूरी जानकारी पाने के लिए, इंटिग्रेशन करने का तरीका जानें के सेक्शन पर जाएं.

फ़िडेलिटी के पैरामीटर और क्वालिटी लेवल को इस्तेमाल करने का तरीका

एनोटेशन का इस्तेमाल कैसे करते हैं

अगर आपके गेम के किसी खास सीन में समस्या हो रही है या हो सकती है, तो एनोटेशन उन्हें समझने में आपकी मदद कर सकते हैं. समस्याओं के बारे में सही स्तर की जानकारी पाने के लिए, आपको ऐसे एनोटेशन तय करने होंगे जिनमें काफ़ी जानकारी शामिल हो.

टारगेट फ़्रेम रेट और टारगेट फ़्रेम टाइम

आपके टारगेट फ़्रेम रेट का इस्तेमाल करके, यह तय किया जाता है कि सभी डिवाइस मॉडल पर कितना फ़्रेम टाइम लगना चाहिए. ऐसा करने के लिए, इसे टारगेट फ़्रेम टाइम में बदला जाता है. फिर इसमें एक छूट देकर फ़्रेम रेंडर होने की समयसीमा तय की जाती है, जिसकी मदद से धीमे रेंडर होने वाले फ़्रेम का पता चलता है.

फ़्रेम रेंडर होने की दर, "फ़्रेम प्रति सेकंड" (FPS) वाली मेट्रिक की इकाई है. फ़्रेम रेंडर होने में लगने वाला समय "मिलीसेकंड" में मापा जाता है. नीचे दिया गया फ़ॉर्मूला, इन दोनों को आपस में जोड़ता है:

  • फ़्रेम टाइम (मिलीसेकंड) = 1000/फ़्रेम रेंडर होने की दर (FPS)

फ़िलहाल, आप नीचे दिए गए फ़्रेम रेंडर होने की दर में से, किसी एक टारगेट फ़्रेम रेंडर होने की दर को चुन सकते हैं:

फ़्रेम रेंडर होने की टारगेट फ़्रेम रेट (FPS)

टारगेट फ़्रेम टाइम (मिलीसेकंड)

30

33.333

60

16.667

120

8.333

 

अगर आप तय नहीं कर पा रहे हैं कि किस टारगेट फ़्रेम दर को चुनना है, तो 30FPS से शुरू करें. यह कई गेम के लिए फ़्रेम रेंडर होने की दर का अच्छा आधार है. आप किसी भी समय फ़्रेम रेंडर होने की अपनी टारगेट दर में बदलाव कर सकते हैं. ध्यान रखें कि यह आपके बुनियादी डेटा में बदलाव नहीं करता है. यह सिर्फ़ आपकी अहम जानकारी और मेट्रिक में बदलाव करता है.

धीमे और तेज़ रेंडर होने वाले फ़्रेम के थ्रेशोल्ड

अहम जानकारी और फ़्रेम की मेट्रिक को तय करने के थ्रेशोल्ड, नीचे दी गई आपकी फ़्रेम रेंडर होने की टारगेट दर के हिसाब से तय किए जाते हैं:

  • धीमे रेंडर होने वाले फ़्रेम का थ्रेशोल्ड = फ़्रेम रेंडर होने का टारगेट समय + एक छूट
  • तेज़ रेंडर होने वाले फ़्रेम का थ्रेशोल्ड = टारगेट फ़्रेम टाइम के मुकाबले फ़्रेम रेंडर होने में 25 प्रतिशत कम समय लेते हैं (जिसमें हेडरूम के लिए भी कुछ जगह मिलती है)

दिए गए टारगेट फ़्रेम दर के लिए, थ्रेशोल्ड नीचे दिए गए हैं:

फ़्रेम रेंडर होने की टारगेट दर (FPS)

टारगेट फ़्रेम टाइम (मिलीसेकंड)

धीमे रेंडर होने वाले फ़्रेम का थ्रेशोल्ड (मिलीसेकंड) (SFT)

तेज़ रेंडर होने वाले फ़्रेम का थ्रेशोल्ड (मिलीसेकंड) (FFT)

30

33.333

35.37

25.0

60

16.667

18.54

12.5

120

8.333

10.12

6.25

धीमे रेंडर होने वाले फ़्रेम के थ्रेशोल्ड पर छूट लागू करने के फ़ायदे

सही और अहम जानकारी देने के लिए, फ़्रेम टाइम में कोई छूट देकर, मेज़रमेंट की गलती में बदलाव किया जाता है. साथ ही, यह पक्का करता है कि हम उपयोगकर्ता को न दिखने वाली समस्याओं के बजाय, सिर्फ़ उन समस्याओं को दिखाएंगे जो उपयोगकर्ता को दिख रही हैं.

मौके और तेज़ रेंडर होने वाले फ़्रेम का थ्रेशोल्ड

एक 25 प्रतिशत हेडरूम का इस्तेमाल किसी मौके को तय करने के लिए किया जाता है, लेकिन इसे आने वाले मौके के लिए मदद करने वाले के तौर पर देखा जाना चाहिए, न कि कोई गारंटी के तौर पर. आपको हमेशा डिवाइस के क्वालिटी लेवल को ऊपर ले जाने से पहले गहन जानकारी पाने और जांच चलाने की सलाह दी जाती है: भले ही किसी डिवाइस में हेडरूम हो, फिर भी एक तरह के फ़्रेम रेंडर होने की दर पर, अगले क्वालिटी लेवल को चलाने के लिए हेडरूम की जगह बहुत ज़्यादा नहीं हो सकती.

Android Performance Tuner के हिसाब के बारे में जानना

Android Performance Tuner को बेहतर बनाने वाले हिसाब को समझने से, आपको ज़्यादा से ज़्यादा जानकारी पाने में मदद मिलेगी.

मेज़र किया गया फ़्रेम टाइम

जब आपके ऐप्लिकेशन के लिए कई फ़्रेम पर, फ़्रेम टाइम को इकट्ठा किया जाता है, तो हम 90वें परसेंटाइल पर फ़्रेम टाइम के लिए रिपोर्ट करते हैं. आपके 90 प्रतिशत तेज़ फ़्रेम के लिए, यह सबसे ज़्यादा फ़्रेम टाइम के तौर पर तय किया गया है.

फ़िलहाल, 90 प्रतिशत का थ्रेशोल्ड, एक तय किया गया थ्रेशोल्ड है और इसे बदला नहीं जा सकता.

औसत से ज़्यादा पर्सेंटाइल के फ़ायदे

अच्छे उपयोगकर्ता अनुभव के लिए, पूरे सत्र के दौरान स्थिर और एक जैसे फ़्रेम रेंडर होने की दर की ज़रूरत होती है. औसत परसेंटाइल में लगातार एक जैसी अहम जानकारी नहीं मिलती, क्योंकि तेज़ और धीमे रेंडर होने वाले फ़्रेम एक-दूसरे की वैल्यू को बराबर कर सकते हैं. 90वें परसेंटाइल तक का इस्तेमाल करने से एक ऐसी मेट्रिक मिलती है जो यह बताती है कि ज़्यादातर फ़्रेम कैसा व्यवहार करते हैं.

फ़्रेम टाइम के लिए बकेटिंग

इस्तेमाल करने वाले के डिवाइस से भेजे जाने वाले डेटा को कम करने के लिए, फ़्रेम टाइम को इकट्ठा किया जाता है और हिस्टोग्राम बकेट में रिपोर्ट किया जाता है, न कि लगातार मिलने वाले वैरिएबल में. जिस फ़्रेम टाइम के लिए रिपोर्ट किया जाता है वह बकेट की ऊपरी सीमा होती है, जहां फ़्रेम टाइम को कैटगरी में रखा जाता है.

नतीजे के हिसाब से, आपके रिपोर्ट किए गए फ़्रेम टाइम को खास तरह की वैल्यू पर इकट्ठा किया जाता है, लेकिन ऐसा लगातार नहीं होता है.

डिफ़ॉल्ट बकेट को अच्छे विवरण का स्तर भेजने के लिए कॉन्फ़िगर किया जाता है, ताकि 30, 60, और 120FPS फ़्रेम के टारगेट पर समस्या को हल करने में मदद मिले. डिफ़ॉल्ट बकेट यह पक्का करने के लिए भी काफ़ी सटीक जानकारी देते हैं कि आपके फ़्रेम को कभी बढ़ा-चढ़ा कर नहीं बताया गया है. 

धीमे और तेज़ रेंडर होने वाले फ़्रेम की मेट्रिक

नीचे दिए गए फ़्रेम के थ्रेशोल्ड से तुलना करके, अलग-अलग फ़्रेम की गिनती धीमी या तेज़ के तौर पर की जाती है:

  • कोई फ़्रेम तब धीमा होता है, जब उसका फ़्रेम टाइम, धीमे फ़्रेम के थ्रेशोल्ड (SFT) से ज़्यादा हो
  • अगर फ़्रेम टाइम किसी तेज़ रेंडर होने वाले फ़्रेम के थ्रेशोल्ड (FFT) से कम है, तो फ़्रेम रेंडर होने की दर को तेज़ माना जाता है

फ़्रेम के मेट्रिक का हिसाब, आम तौर पर सिर्फ़ किसी खास समस्या या मौके के मुताबिक लगाया जाता है. उदाहरण के लिए:

  • क्वालिटी लेवल 4 में डिवाइस मॉडल X पर # और % धीमे रेंडर होने वाले फ़्रेम
  • सभी क्वालिटी लेवल में किसी एनोटेशन Y पर # और % तेज़ रेंडर होने वाले फ़्रेम
  • खास सुविधाओं वाले डिवाइस Z पर, % धीमे और तेज़ रेंडर होने वाले फ़्रेम

ध्यान दें: इसका एक अपवाद खास तरह की जानकारी में दिखाए गए धीमे रेंडर होने वाले फ़्रेम की मेट्रिक है, जिसे सभी फ़्रेम पर मापा जाता है.

एक समान नहीं

धीमे और तेज़ रेंडर होने वाले फ़्रेम एक-दूसरे से बिल्कुल अलग नहीं होते: उनके थ्रेशोल्ड और मानदंड अलग-अलग होते हैं. इसका मतलब है कि ठीक से काम न करने वाले डिवाइस मॉडल या एनोटेशन में अब भी तेज़ रेंडर होने वाले फ़्रेम हो सकते हैं. वहीं, इसके उलट किसी बेहतर काम करने वाले डिवाइस मॉडल या एनोटेशन में धीमे रेंडर होने वाले फ़्रेम हो सकते हैं:

 
 

मानदंड

रेंडर होने में ज़्यादा समय लेने वाले फ़्रेम (%)

रेंडर होने में कम समय लेने वाले फ़्रेम (%)

समस्या

90 प्रतिशत फ़्रेम टाइम > SFT

> जानकारी के हिसाब से 10 प्रतिशत

0-90 प्रतिशत से कहीं भी

मौका

90 प्रतिशत फ़्रेम टाइम < FFT

0-10 प्रतिशत से कहीं भी

> जानकारी के हिसाब से 90 प्रतिशत

 

ध्यान दें: कभी-कभी समस्या और मौके के बारे में ज़्यादा जानकारी देने के लिए, धीमे और तेज़ रेंडर होने वाले फ़्रेम की मेट्रिक दिए जाते हैं.

समस्याएं और मौके

समस्याओं और मौकों के हिसाब से, आप फ़्रेम टाइम की परफ़ॉर्मेंस पर कार्रवाई कर सकते हैं. कोई गड़बड़ी तब होती है, जब डिवाइस मॉडल या एनोटेशन (जैसा कि ऊपर बताया गया है) आपके फ़्रेम टाइम के टारगेट को पूरा नहीं करता. कोई डिवाइस मॉडल या एनोटेशन एक ऐसा अवसर है जो आपके फ़्रेम टाइम के टारगेट को लगातार काफ़ी बड़ी संख्या में बढ़ा देता है, ताकि फ़िडेलिटी को बढ़ाने के लिए हेडरूम को अनुमति मिल सके.

समस्याओं और मौके का पता लगाने के लिए, हम धीमे रेंडर होने वाले फ़्रेम (SFT) और तेज़ रेंडर होने वाले फ़्रेम (FFT) के थ्रेशोल्ड की मदद से, आपके 90 प्रतिशत पर्सेंटाइल फ़्रेम टाइम की तुलना करते हैं. ये थ्रेशोल्ड, नीचे दिए गए आपके फ़्रेम टाइम से मापे जाते हैं:

अहम जानकारी इतने तरह की है

जानकारी

इसका हिसाब कैसे लगाते हैं

समस्या:

  • ठीक से काम न करने वाले डिवाइस मॉडल
  • ठीक से काम न करने वाले एनोटेशन

“कम से कम 10 प्रतिशत फ़्रेम आपके फ़्रेम टाइम के टारगेट को पूरा नहीं कर रहे हैं”

90 प्रतिशत पर्सेंटाइल फ़्रेम टाइम > SFT

मौका:

  • ठीक से काम करने वाले डिवाइस मॉडल
  • ठीक से काम करने वाले एनोटेशन

"कम से कम 90 प्रतिशत फ़्रेम, आपके टारगेट किए गए फ़्रेम टाइम की तुलना में काफ़ी तेज़ हैं"

90 प्रतिशत पर्सेंटाइल फ़्रेम टाइम < FFT

समस्याओं और मौकों की खास सुविधाएं

समस्याओं और मौके के बारे में, सिर्फ़ नीचे दी गई बातों के हिसाब से बताया गया है:

  • डिवाइस मॉडल x क्वालिटी लेवल
  • एनोटेशन x क्वालिटी लेवल

यह आपको समस्या या मौके की जांच करने का एक तरीका बताता है. उदाहरण के लिए:

  • क्वालिटी के लेवल 4 पर डिवाइस मॉडल X की समस्या => डिवाइस मॉडल X में देखें
  • सभी क्वालिटी लेवल पर एनोटेशन Y का मौका => एनोटेशन Y में देखें

समस्याएं और मौके एक जैसे होते है. समस्याओं को मौके की तुलना में दिखने के लिए कम जगह होती है. साथ ही, डिवाइस मॉडल या बिना समस्या वाले एनोटेशन और मौके वाले एनोटेशन के बीच में एक बड़ा अंतर होता है.

एनोटेशन कुछ लेवल पर एक समस्या और अन्य पर एक मौका हो सकती है. डिवाइस मॉडल के हिसाब से भी यह बात सही साबित होती है, हालांकि एक से ज़्यादा QLs पर डिवाइस मॉडल के दिखने की स्थिति में यह एक जोखिम वाला मामला है.

समस्या और मौका, फ़्रेम रेंडर होने की टारगेट दर से जुड़े होते हैं. अगर इसमें बदलाव होते हैं, तो आपकी समस्याओं और मौकों में भी बदलाव होंगे. हालांकि, फ़्रेम टाइम के बुनियादी डेटा में कोई बदलाव नहीं होता है.

मिलते-जुलते कॉन्टेंट के बारे में जानना

क्या यह उपयोगी था?
हम उसे किस तरह बेहतर बना सकते हैं?

और मदद चाहिए?

मदद के दूसरे तरीकों के लिए साइन इन करें ताकि आपकी समस्या झटपट सुलझ सके