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

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

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

Systrace टूल दो तरह से उपलब्ध है:

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

Systrace एक लो-लेवल टूल है, जो:

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

सबसे बेहतर सेटिंग

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

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

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

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

• कस्टम इवेंट: अगर कस्टम इवेंट इवेंट को अपने गेम में कैप्चर करने के लिए, इन्हें चालू करें -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 MB या 512 MB उपलब्ध होना चाहिए (निर्भर सीपीयू में 4 कोर है या 8 कोर, और हर 64 एमबी की मेमोरी के लिए ज़रूरी है कि आस-पास के हिस्से के तौर पर उपलब्ध होनी चाहिए.

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

   • am: गतिविधि मैनेजर
   • binder_driver: बाइंडर कर्नेल ड्राइवर
   • dalvik: Delvik वीएम
   • freq: सीपीयू की फ़्रीक्वेंसी
   • gfx: ग्राफ़िक
   • hal: हार्डवेयर मॉड्यूल
   • idle: सीपीयू (CPU) इस्तेमाल नहीं किया जा रहा
   • 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 पर काम करते समय यह सबसे अच्छे तरीके से काम करता है डिवाइस. इस वजह से, सिंगल-थ्रेड गेम अक्सर धीमे लोड होते हैं. साथ ही, गेम में एक जैसी फ़्रेम दर के साथ.

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

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

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

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

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

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

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

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

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

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

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

ऊर्जा की खपत

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

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

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

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

कम मेहनत वाले सीपीयू (CPU) का इस्तेमाल करने के लिए, कम समय वाले काम को टालें

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

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

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

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

ज़्यादातर डिवाइसों में, तेज़ स्पीड वाले सीपीयू से पहले, धीमे सीपीयू का इस्तेमाल किया जाता है. हालांकि, यह उम्मीद नहीं की जा सकती आपके डिवाइस का एसओसी इस क्रम का इस्तेमाल करता है. यह देखने के लिए, इससे मिलते-जुलते निर्देश चलाएं इस सीपीयू टोपोलॉजी डिस्कवरी में दिखाया गया है कोड 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() तरीके में शुरू करें. ऑब्जेक्ट में थर्मल स्टेटस लिसनर जोड़ें.

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

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

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() या नेटिव Thermal API का इस्तेमाल करें.

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
            }
        }
    }
}

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. ऐसी Systrace रिपोर्ट जनरेट करें जिसमें gfx और input कैटगरी शामिल हों. इन कैटगरी में खास तौर पर, काम के आकलनों से यह तय करने में मदद मिलती है कि टच-टू-डिसप्ले इंतज़ार का समय.

2. Systrace की रिपोर्ट के SurfaceView सेक्शन की जांच करें. बहुत ज़्यादा बफ़र लंबित बफ़र की संख्या 1 और 2 के बीच आने लगती है, जैसा कि दिखाया गया है इमेज 5 में:

   

फ़्रेम पेसिंग में इस अंतर को कम करने के लिए, बताई गई कार्रवाइयां करें ये सेक्शन पढ़ें:

Android फ़्रेम पेसिंग एपीआई को अपने गेम के साथ इंटिग्रेट करें

Android Frame Pacing API, इन कामों में आपकी मदद करता है फ़्रेम स्वैप करें और स्वैप अंतराल परिभाषित करें, ताकि आपका गेम और एक जैसे फ़्रेमरेट की सुविधा देता है.

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

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

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

रेंडर हो रहा है

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

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

इस स्थिति से निपटने के लिए, Android फ़्रेम पेसिंग का इस्तेमाल करें API, जो हमेशा VSync वेवफ़्रंट.

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

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

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

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

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

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

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

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

अन्य संसाधन

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

वीडियो

• गेम के लिए Sytrace प्रज़ेंटेशन Android गेम डेवलपर समिट 2018 की ओर से