सिस्टम ट्रेस करने की सुविधा कॉन्फ़िगर करें

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

गेम के आधार पर सिस्टम ट्रेस करने की प्रक्रिया सेट अप करना

Systrace टूल को दो तरीकों से ऐक्सेस किया जा सकता है:

• कमांड-लाइन प्रोग्राम
• उपयोगकर्ता के डिवाइस पर मौजूद सेवा

Systrace एक लो-लेवल टूल है, जो ये काम करता है:

• ज़मीनी हकीकत के बारे में जानकारी देता है. Systrace, आउटपुट को सीधे तौर पर कर्नल से कैप्चर करता है. इसलिए, यह जिन मेट्रिक को कैप्चर करता है वे उन मेट्रिक से मिलती-जुलती होती हैं जिन्हें सिस्टम कॉल की सीरीज़ रिपोर्ट करती है.
• कम संसाधनों का इस्तेमाल करता है. Systrace, डिवाइस पर बहुत कम ओवरहेड डालता है. आम तौर पर, यह 1% से भी कम होता है. इसकी वजह यह है कि यह डेटा को इन-मेमोरी बफ़र में स्ट्रीम करता है.

ऑप्टिमल सेटिंग

टूल को सही तरीके से काम करने के लिए, सही तर्क देना ज़रूरी है:

• कैटगरी: गेम पर आधारित सिस्टम के लिए, ट्रेस करने की सुविधा चालू करने के लिए सबसे सही कैटगरी का सेट यह है: {sched, freq, idle, am, wm, gfx, view, sync, binder_driver, hal, dalvik}.

• बफ़र का साइज़: सामान्य नियम यह है कि हर सीपीयू कोर के लिए 10 एमबी के बफ़र साइज़ से, करीब 20 सेकंड का ट्रेस किया जा सकता है. उदाहरण के लिए, अगर किसी डिवाइस में दो क्वाड-कोर सीपीयू (कुल आठ कोर) हैं, तो systrace प्रोग्राम में पास करने के लिए सही वैल्यू 80,000 केबी (80 एमबी) है.

  अगर आपका गेम कॉन्टेक्स्ट-स्विचिंग की सुविधा का इस्तेमाल करता है, तो हर सीपीयू कोर के लिए बफ़र को 15 एमबी तक बढ़ाएं.

  ध्यान दें: बड़े बफ़र साइज़ का अनुरोध करने के लिए, डिवाइस में सभी कोर के लिए काफ़ी मेमोरी उपलब्ध होनी चाहिए. साथ ही, हर कोर के लिए मेमोरी का हर हिस्सा लगातार होना चाहिए. उदाहरण के लिए, अगर आपको 80 एमबी के बफ़र साइज़ वाले आठ कोर वाले डिवाइस पर सिस्टम ट्रेस कैप्चर करना है, तो डिवाइस में 640 एमबी उपलब्ध होना चाहिए. साथ ही, मेमोरी के हर 80 एमबी के हिस्से को लगातार चंक के तौर पर उपलब्ध होना चाहिए.

• कस्टम इवेंट: अगर आपको अपने गेम में कैप्चर करने के लिए कस्टम इवेंट तय करने हैं, तो -a फ़्लैग चालू करें. इससे Systrace, आउटपुट रिपोर्ट में इन कस्टम इवेंट को शामिल कर पाएगा.

अगर systrace कमांड-लाइन प्रोग्राम का इस्तेमाल किया जा रहा है, तो सिस्टम ट्रेस कैप्चर करने के लिए इस कमांड का इस्तेमाल करें. इससे, कैटगरी सेट, बफ़र साइज़, और कस्टम इवेंट के लिए सबसे सही तरीके लागू होते हैं:

python systrace.py -a com.example.myapp -b 80000 -o my_systrace_report.html \
  sched freq idle am wm gfx view sync binder_driver hal dalvik

अगर किसी डिवाइस पर Systrace सिस्टम ऐप्लिकेशन का इस्तेमाल किया जा रहा है, तो यहां दिया गया तरीका अपनाएं. इससे, सिस्टम ट्रेस करने की प्रक्रिया को कैप्चर किया जा सकेगा. इसमें कैटगरी सेट, बफ़र साइज़, और कस्टम इवेंट के लिए सबसे सही तरीके लागू होते हैं:

1. डीबग किए जा सकने वाले ऐप्लिकेशन को ट्रेस करें विकल्प चालू करें.

   इस सेटिंग का इस्तेमाल करने के लिए, डिवाइस में 256 एमबी या 512 एमबी मेमोरी उपलब्ध होनी चाहिए. यह इस बात पर निर्भर करता है कि सीपीयू में चार या आठ कोर हैं. साथ ही, मेमोरी के हर 64 एमबी के हिस्से को लगातार उपलब्ध होना चाहिए.

2. कैटगरी चुनें. इसके बाद, यहां दी गई सूची में मौजूद कैटगरी चालू करें:

   • am: गतिविधि मैनेजर
   • binder_driver: Binder Kernel driver
   • dalvik: Dalvik VM
   • freq: सीपीयू फ़्रीक्वेंसी
   • gfx: ग्राफ़िक्स
   • hal: हार्डवेयर मॉड्यूल
   • idle: सीपीयू कुछ समय से इस्तेमाल में नहीं है
   • sched: सीपीयू शेड्यूलिंग
   • sync: सिंक करना
   • view: सिस्टम देखें
   • wm: विंडो मैनेजर

3. रिकॉर्ड ट्रेसिंग की सुविधा चालू करें.

4. अपना गेम लोड करें.

5. गेमप्ले के दौरान इंटरैक्शन करें. इससे आपको उस गेमप्ले के दौरान डिवाइस की परफ़ॉर्मेंस का पता चलेगा.

6. गेम में गड़बड़ी होने के तुरंत बाद, सिस्टम ट्रेसिंग बंद कर दें.

आपने परफ़ॉर्मेंस के उन आंकड़ों को कैप्चर कर लिया है जिनकी मदद से समस्या का विश्लेषण किया जा सकता है.

डिस्क में बचा स्टोरेज बचाने के लिए, उपयोगकर्ता के डिवाइस पर मौजूद सिस्टम ट्रेस करने की प्रक्रिया, फ़ाइलों को कंप्रेस किए गए ट्रेस फ़ॉर्मैट (*.ctrace) में सेव करती है. रिपोर्ट जनरेट करते समय इस फ़ाइल को अनकंप्रेस करने के लिए, कमांड-लाइन प्रोग्राम का इस्तेमाल करें और --from-file विकल्प को शामिल करें:

python systrace.py --from-file=/data/local/traces/my_game_trace.ctrace \
  -o my_systrace_report.html

परफ़ॉर्मेंस के कुछ खास पहलुओं को बेहतर बनाना

इस सेक्शन में, मोबाइल गेम की परफ़ॉर्मेंस से जुड़ी कई सामान्य समस्याओं के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि अपने गेम में इन समस्याओं की पहचान कैसे करें और उन्हें कैसे ठीक करें.

वेबसाइट लोड होने में लगने वाला समय

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

• लेज़ी लोडिंग का इस्तेमाल करें. अगर आपको अपने गेम में लगातार सीन या लेवल में एक ही ऐसेट का इस्तेमाल करना है, तो इन ऐसेट को सिर्फ़ एक बार लोड करें.
• अपनी ऐसेट का साइज़ कम करें. इस तरह, इन ऐसेट के बिना कंप्रेस किए गए वर्शन को अपने गेम के APK के साथ बंडल किया जा सकता है.
• डिस्क पर कम जगह लेने वाले कंप्रेशन के तरीके का इस्तेमाल करें. इस तरह के तरीके का एक उदाहरण zlib है.
• मोनो के बजाय IL2CPP का इस्तेमाल करें. (यह सिर्फ़ तब लागू होता है, जब Unity का इस्तेमाल किया जा रहा हो.) IL2CPP, आपकी C# स्क्रिप्ट के लिए बेहतर परफ़ॉर्मेंस देता है.
• अपने गेम को मल्टीथ्रेड बनाएं. ज़्यादा जानकारी के लिए, फ़्रेमरेट में एकरूपता सेक्शन देखें.

फ़्रेमरेट में एकरूपता

गेमप्ले के अनुभव का सबसे अहम हिस्सा, लगातार फ़्रेमरेट बनाए रखना है. इस लक्ष्य को आसानी से हासिल करने के लिए, इस सेक्शन में बताई गई ऑप्टिमाइज़ेशन की तकनीकों का इस्तेमाल करें.

मल्टीथ्रेडिंग

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

पहली इमेज में दिखाया गया Systrace, एक ऐसे गेम का है जो एक समय में सिर्फ़ एक सीपीयू पर चलता है:

पहली इमेज. सिंगल-थ्रेड वाले गेम के लिए Systrace रिपोर्ट

अपने गेम की परफ़ॉर्मेंस को बेहतर बनाने के लिए, अपने गेम को मल्टीथ्रेड बनाएं. आम तौर पर, दो थ्रेड वाला मॉडल सबसे सही होता है:

• गेम थ्रेड, जिसमें आपके गेम के मुख्य मॉड्यूल शामिल होते हैं और रेंडर करने के निर्देश भेजे जाते हैं.
• एक रेंडर थ्रेड, जिसे रेंडर करने के निर्देश मिलते हैं. यह उन्हें ग्राफ़िक्स कमांड में बदलता है. डिवाइस का जीपीयू, इन कमांड का इस्तेमाल करके सीन को डिसप्ले कर सकता है.

Vulkan API, इस मॉडल को बेहतर बनाता है. इसकी वजह यह है कि यह दो सामान्य बफ़र को एक साथ पुश कर सकता है. इस सुविधा का इस्तेमाल करके, कई रेंडर थ्रेड को कई सीपीयू में डिस्ट्रिब्यूट किया जा सकता है. इससे सीन को रेंडर करने में लगने वाला समय और कम हो जाता है.

अपने गेम की मल्टीथ्रेडिंग परफ़ॉर्मेंस को बेहतर बनाने के लिए, इंजन के हिसाब से कुछ बदलाव भी किए जा सकते हैं:

• अगर Unity गेम इंजन का इस्तेमाल करके गेम बनाया जा रहा है, तो मल्टीथ्रेड रेंडरिंग और जीपीयू स्किनिंग विकल्प चालू करें.
• अगर कस्टम रेंडरिंग इंजन का इस्तेमाल किया जा रहा है, तो पक्का करें कि रेंडर कमांड पाइपलाइन और ग्राफ़िक्स कमांड पाइपलाइन सही तरीके से अलाइन की गई हों. ऐसा न होने पर, गेम के सीन दिखाने में देरी हो सकती है.

इन बदलावों को लागू करने के बाद, आपको अपना गेम कम से कम दो सीपीयू पर एक साथ चलता हुआ दिखना चाहिए. जैसा कि इमेज 2 में दिखाया गया है:

दूसरी इमेज. मल्टी-थ्रेड वाले गेम के लिए Systrace रिपोर्ट

यूज़र इंटरफ़ेस (यूआई) एलिमेंट लोड हो रहा है

तीसरी इमेज. एक साथ कई यूज़र इंटरफ़ेस (यूआई) एलिमेंट रेंडर करने वाले गेम की Systrace रिपोर्ट

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

तीसरी इमेज में दिखाई गई Systrace रिपोर्ट, यूज़र इंटरफ़ेस (यूआई) फ़्रेम का एक उदाहरण है. इसमें मोबाइल डिवाइस की क्षमताओं के हिसाब से, बहुत ज़्यादा एलिमेंट रेंडर करने की कोशिश की जा रही है.

यूआई अपडेट होने में लगने वाले समय को 2 से 3 मिलीसेकंड तक कम करना एक अच्छा लक्ष्य है. इस तरह के अपडेट तुरंत पाने के लिए, यहां दिए गए ऑप्टिमाइज़ेशन की तरह ही ऑप्टिमाइज़ेशन करें:

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

ऊर्जा की खपत

पिछले सेक्शन में बताए गए ऑप्टिमाइज़ेशन करने के बाद भी, आपको लग सकता है कि गेम खेलने के पहले 45 से 50 मिनट में, आपके गेम का फ़्रेमरेट कम हो जाता है. इसके अलावा, समय के साथ डिवाइस गर्म हो सकता है और बैटरी की खपत बढ़ सकती है.

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

मेमोरी का ज़्यादा इस्तेमाल करने वाली थ्रेड को एक ही सीपीयू पर रखना

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

कम समय के लिए किए जाने वाले काम को कम पावर वाले सीपीयू पर ट्रांसफ़र करना

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

ज़्यादातर सिस्टम-ऑन-अ-चिप डिवाइसों में कम से कम दो शेयर की गई घड़ियां होती हैं. इनमें से एक डिवाइस के तेज़ सीपीयू के लिए और दूसरी डिवाइस के धीमे सीपीयू के लिए होती है. इस आर्किटेक्चर का नतीजा यह होता है कि अगर किसी तेज़ सीपीयू को ज़्यादा से ज़्यादा स्पीड पर काम करना है, तो सभी तेज़ सीपीयू भी ज़्यादा से ज़्यादा स्पीड पर काम करते हैं.

चौथी इमेज में दिखाई गई उदाहरण रिपोर्ट में, एक ऐसा गेम दिखाया गया है जो तेज़ सीपीयू का फ़ायदा उठाता है. हालांकि, इस तरह की ज़्यादा गतिविधि से बहुत ज़्यादा ऊर्जा और गर्मी बहुत कम समय में पैदा होती है.

चौथी इमेज. Systrace रिपोर्ट में, डिवाइस के सीपीयू को थ्रेड का सबऑप्टिमल असाइनमेंट दिखाया गया है

ध्यान दें: Systrace रिपोर्ट में, अगर सीपीयू की किसी लाइन में कोई थ्रेड चुना जाता है, तो Systrace उस थ्रेड के एक्ज़ीक्यूट होने के दौरान सीपीयू की स्थिति दिखाता है. "3" की स्थिति, सीपीयू की सबसे ज़्यादा स्पीड दिखाती है.

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

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

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

#include <sched.h>
#include <sys/types.h>
#include <unistd.h>

pid_t my_pid; // PID of the process containing your thread.

// Assumes that cpu0, cpu1, cpu2, and cpu3 are the "slow CPUs".
cpu_set_t my_cpu_set;
CPU_ZERO(&my_cpu_set);
CPU_SET(0, &my_cpu_set);
CPU_SET(1, &my_cpu_set);
CPU_SET(2, &my_cpu_set);
CPU_SET(3, &my_cpu_set);
sched_setaffinity(my_pid, sizeof(cpu_set_t), &my_cpu_set);

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

थर्मल स्ट्रेस

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

थर्मल एपीआई का इस्तेमाल करके, डिवाइस के तापमान में होने वाले बदलावों को मॉनिटर करें. साथ ही, कम बैटरी इस्तेमाल करने और डिवाइस के तापमान को कम रखने के लिए कार्रवाई करें. जब डिवाइस, ज़्यादा गरम होने की सूचना देता है, तो बैकग्राउंड में जारी गतिविधियों को बंद कर दें, ताकि बिजली की खपत कम हो सके. उदाहरण के लिए, फ़्रेम रेट या पॉलीगॉन टेसेलेशन कम करें.

सबसे पहले, PowerManager ऑब्जेक्ट को डिक्लेयर करें और उसे onCreate() तरीके में शुरू करें. ऑब्जेक्ट में थर्मल स्टेटस लिसनर जोड़ें.

Kotlin

class MainActivity : AppCompatActivity() {
    lateinit var powerManager: PowerManager

    override fun onCreate(savedInstanceState: Bundle?) {
        powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
        powerManager.addThermalStatusListener(thermalListener)
    }
}

Java

public class MainActivity extends AppCompatActivity {
    PowerManager powerManager;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        ...
        powerManager = (PowerManager) getSystemService(Context.POWER_SERVICE);
        powerManager.addThermalStatusListener(thermalListener);
    }
}

लिसनर के स्टेटस में बदलाव का पता चलने पर की जाने वाली कार्रवाइयां तय करें. अगर आपके गेम में C/C++ का इस्तेमाल किया जाता है, तो onThermalStatusChanged() में थर्मल स्टेटस लेवल में कोड जोड़ें. इसके बाद, JNI का इस्तेमाल करके अपने नेटिव गेम कोड को कॉल करें या नेटिव Thermal API का इस्तेमाल करें.

Kotlin

val thermalListener = object : PowerManager.OnThermalStatusChangedListener() {
    override fun onThermalStatusChanged(status: Int) {
        when (status) {
            PowerManager.THERMAL_STATUS_NONE -> {
                // No thermal status, so no action necessary
            }

            PowerManager.THERMAL_STATUS_LIGHT -> {
                // Add code to handle light thermal increase
            }

            PowerManager.THERMAL_STATUS_MODERATE -> {
                // Add code to handle moderate thermal increase
            }

            PowerManager.THERMAL_STATUS_SEVERE -> {
                // Add code to handle severe thermal increase
            }

            PowerManager.THERMAL_STATUS_CRITICAL -> {
                // Add code to handle critical thermal increase
            }

            PowerManager.THERMAL_STATUS_EMERGENCY -> {
                // Add code to handle emergency thermal increase
            }

            PowerManager.THERMAL_STATUS_SHUTDOWN -> {
                // Add code to handle immediate shutdown
            }
        }
    }
}

Java

PowerManager.OnThermalStatusChangedListener thermalListener =
    new PowerManager.OnThermalStatusChangedListener () {

    @Override
    public void onThermalStatusChanged(int status) {

        switch (status)
        {
            case PowerManager.THERMAL_STATUS_NONE:
                // No thermal status, so no action necessary
                break;

            case PowerManager.THERMAL_STATUS_LIGHT:
                // Add code to handle light thermal increase
                break;

            case PowerManager.THERMAL_STATUS_MODERATE:
                // Add code to handle moderate thermal increase
                break;

            case PowerManager.THERMAL_STATUS_SEVERE:
                // Add code to handle severe thermal increase
                break;

            case PowerManager.THERMAL_STATUS_CRITICAL:
                // Add code to handle critical thermal increase
                break;

            case PowerManager.THERMAL_STATUS_EMERGENCY:
                // Add code to handle emergency thermal increase
                break;

            case PowerManager.THERMAL_STATUS_SHUTDOWN:
                // Add code to handle immediate shutdown
                break;
        }
    }
};

टच करने के बाद डिसप्ले दिखने में लगने वाला समय

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

यह पता लगाने के लिए कि क्या आपके गेम के फ़्रेम पेसिंग को बेहतर बनाया जा सकता है, यह तरीका अपनाएं:

1. gfx और input कैटगरी वाली Systrace रिपोर्ट जनरेट करें. इन कैटगरी में, टच-टू-डिसप्ले लेटेन्सी का पता लगाने के लिए खास तौर पर काम आने वाली मेज़रमेंट शामिल हैं.

2. Systrace रिपोर्ट के SurfaceView सेक्शन को देखें. बफ़र में ज़रूरत से ज़्यादा डेटा होने पर, बफ़र में मौजूद डेटा को प्रोसेस करने के लिए, एक या दो थ्रेड का इस्तेमाल किया जाता है. जैसा कि इमेज 5 में दिखाया गया है:

   

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

फ़्रेम पेसिंग में होने वाली इस गड़बड़ी को ठीक करने के लिए, यहां दिए गए सेक्शन में बताई गई कार्रवाइयां करें:

अपने गेम में Android Frame Pacing API को इंटिग्रेट करना

Android Frame Pacing API की मदद से, फ़्रेम स्वैप किए जा सकते हैं. साथ ही, स्वैप इंटरवल तय किया जा सकता है, ताकि आपके गेम का फ़्रेमरेट ज़्यादा स्थिर रहे.

अपने गेम की नॉन-यूआई ऐसेट का रिज़ॉल्यूशन कम करें

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

हालांकि, अपने गेम के यूज़र इंटरफ़ेस (यूआई) एलिमेंट का रिज़ॉल्यूशन कम न करें. इन एलिमेंट पर लाइन की मोटाई को बनाए रखना ज़रूरी है, ताकि सभी खिलाड़ियों के लिए टच टारगेट का साइज़ काफ़ी बड़ा हो.

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

रेंडरिंग स्मूदनेस

जब SurfaceFlinger, आपके गेम में कोई सीन दिखाने के लिए डिसप्ले बफ़र का इस्तेमाल करता है, तो सीपीयू की गतिविधि कुछ समय के लिए बढ़ जाती है. अगर सीपीयू की गतिविधि में ये स्पाइक एक समान नहीं होते हैं, तो गेम में अटकने की समस्या दिख सकती है. इमेज 6 में दिए गए डायग्राम में, इस समस्या की वजह बताई गई है:

छठी इमेज. Systrace रिपोर्ट में दिखाया गया है कि कोई फ़्रेम, Vsync को कैसे मिस कर सकता है

अगर किसी फ़्रेम को रेंडर होने में कुछ मिलीसेकंड की भी देरी होती है, तो हो सकता है कि वह अगले डिसप्ले विंडो में न दिखे. इसके बाद, फ़्रेम को डिसप्ले होने के लिए अगले Vsync तक इंतज़ार करना पड़ता है. अगर गेम 30 FPS पर चल रहा है, तो इसमें 33 मिलीसेकंड लगते हैं. इससे, खिलाड़ी को साफ़ तौर पर देरी महसूस होती है.

इस समस्या को ठीक करने के लिए, Android Frame Pacing API का इस्तेमाल करें. यह हमेशा VSync वेवफ़्रंट पर एक नया फ़्रेम दिखाता है.

मेमोरी की स्थिति

लंबे समय तक गेम खेलने पर, डिवाइस में मेमोरी से जुड़ी गड़बड़ियां हो सकती हैं.

इस स्थिति में, Systrace रिपोर्ट में सीपीयू की गतिविधि देखें. साथ ही, यह देखें कि सिस्टम कितनी बार kswapd डेमॉन को कॉल कर रहा है. अगर गेम के चालू होने के दौरान कई कॉल किए जाते हैं, तो यह देखना सबसे अच्छा है कि आपका गेम मेमोरी को कैसे मैनेज और साफ़ कर रहा है.

ज़्यादा जानकारी के लिए, मेमोरी मैनेजमेंट के बारे में जानकारी लेख पढ़ें.

थ्रेड की स्थिति

Systrace रिपोर्ट के सामान्य एलिमेंट में नेविगेट करते समय, रिपोर्ट में थ्रेड को चुनकर यह देखा जा सकता है कि किसी थ्रेड ने हर थ्रेड की संभावित स्थिति में कितना समय बिताया. जैसा कि इमेज 7 में दिखाया गया है:

सातवीं इमेज. Systrace रिपोर्ट में दिखाया गया है कि किसी थ्रेड को चुनने पर, रिपोर्ट में उस थ्रेड के लिए स्थिति की खास जानकारी कैसे दिखती है

जैसा कि इमेज 7 में दिखाया गया है, आपको यह पता चल सकता है कि आपके गेम के थ्रेड, "चल रहे हैं" या "चलाए जा सकते हैं" स्थिति में उतनी बार नहीं हैं जितनी बार होने चाहिए. यहां दी गई सूची में, किसी थ्रेड के समय-समय पर असामान्य स्थिति में बदलने की कुछ सामान्य वजहें बताई गई हैं:

• अगर कोई थ्रेड लंबे समय तक स्लीप मोड में रहती है, तो हो सकता है कि उसे लॉक कंटेंशन की समस्या हो या वह जीपीयू गतिविधि का इंतज़ार कर रही हो.
• अगर कोई थ्रेड लगातार I/O पर ब्लॉक हो रहा है, तो इसका मतलब है कि एक बार में डिस्क से बहुत ज़्यादा डेटा पढ़ा जा रहा है या आपका गेम थ्रैशिंग कर रहा है.

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

अन्य संसाधन

अपने गेम की परफ़ॉर्मेंस को बेहतर बनाने के बारे में ज़्यादा जानने के लिए, यहां दिए गए अतिरिक्त संसाधन देखें:

वीडियो

• Android Game Developer Summit 2018 में Systrace for Games के बारे में दी गई जानकारी