यूनिटी 3 डी में मोबाइल उपकरणों के लिए 2 डी अनुप्रयोगों का अनुकूलन

हाल ही में, हमारे स्टूडियो ने एक बड़े अपडेट का विकास पूरा किया - कप्तान अंटार्कटिका: एंडलेस रन - आईओएस पर उपकरणों के लिए। प्रभावित प्रदर्शन को अद्यतन करने के लिए श्रमसाध्य कार्य, जो कमजोर उपकरणों पर बहुत कम निकला। मैंने इसके लिए एक सप्ताह तक संघर्ष किया और कम से कम 30 एफपीएस हासिल किए, साथ ही साथ आवेदन के आकार में उल्लेखनीय कमी आई। मैं आपको बताना चाहता हूं कि मैंने यह कैसे किया, और यह कैसे करना है इसके लायक नहीं है।
यह लेख किसी भी एकता डेवलपर्स (न केवल परियोजना प्रबंधक और तकनीकी विशेषज्ञ, बल्कि केवल प्रोग्रामर, कलाकार और डिजाइनर) के लिए भी उपयोगी है, क्योंकि यह सामान्य रूप से एकता पर अनुकूलन और विशेष रूप से मोबाइल उपकरणों के लिए 2d अनुप्रयोगों के अनुकूलन दोनों को प्रभावित करता है।

सब कुछ संभव है!

शुरू करने के लिए, हर बार जब मैं अनुकूलन शुरू करता हूं, तो पहले मुझे विश्वास नहीं होता है कि कुछ और अनुकूलित किया जा सकता है, खासकर अगर परियोजना इससे पहले ही कई अनुकूलन चक्रों से गुजर चुकी है। लेकिन एकता के आधिकारिक दस्तावेज, मंचों पर विषय और इंटरनेट पर लेखों को देखने से मुझे नए संभावित सुधारों के बारे में सोचना पड़ता है। इस प्रकार, मैं एक विशेष सूची रखता हूं जिसमें मुख्य विचार हैं जो एक एकता परियोजना में अनुकूलित किए जा सकते हैं, लगातार इसे अपडेट करते हैं और सबसे पहले मैं इसे अनुकूलन की बात आती है। मैं आपके साथ इन विचारों को साझा करना चाहता हूं। मुझे उम्मीद है कि यह लेख आपको अपनी परियोजना को और तेज़ बनाने में मदद करेगा।
मैं तुरंत इंगित करता हूं कि विकास यूनिटी 3.5.6 पर आयोजित किया गया था, लक्ष्य मंच iPhone 3GS और नए से Apple डिवाइस है।

बुनियादी नियम

सबसे पहले, मैं आपको कुछ नियम देता हूं, जिनका मैं विकास और अनुकूलन करते समय उपयोग करता हूं।
1. अग्रिम में अनुकूलन न करें ।
यह सुनहरा नियम किसी ऐसे व्यक्ति से परिचित होना चाहिए जिसने कभी अनुकूलन किया हो। 80/20 नियम को याद करें: 80% लाभ काम के 20% से आते हैं ।


संख्या बल्कि मनमानी है, लेकिन मेरा यह मतलब है: यह सबसे अधिक संभावना है कि आप परियोजना के प्रारंभिक चरण में जो अनुकूलन करने जा रहे हैं, उनमें से अधिकांश की संभावना अंतिम परियोजना को प्रभावित नहीं करेगी।

हालांकि, इस नियम के कुछ अपवाद हैं, जो मोबाइल उपकरणों के लिए विकसित होने पर विशेष रूप से महत्वपूर्ण हैं, क्योंकि यह नियम पीसी-परियोजनाओं के लिए अधिक उपयुक्त है। एक पीसी मोबाइल प्लेटफार्मों की तुलना में बहुत अधिक उत्पादक है और संसाधनों में कम सीमित है। तो, अपवाद हैं:

• मान लीजिए कि एक कोड, या एक डिज़ाइन है जिसे आप पहले से ही जानते हैं कि बेहतर कैसे लिखना है, कम मेमोरी / प्रोसेसर और इसी तरह। आप इसे अपने अनुभव से जानते हैं, क्योंकि आपके पास इस तरह के एक से अधिक बार अनुकूलित घटक हैं, और आप जानते हैं कि इससे उत्पादकता में वृद्धि होती है। तो अभी क्यों नहीं लिखा? आमतौर पर, ऐसी चीजें नियमों के एक सेट तक जोड़ देती हैं जैसे कि "कोड को सही तरीके से कैसे लिखा जाए और इसे कैसे लिखा जाए", और एक सक्षम प्रोग्रामर भविष्य में त्रुटियों से बचने के लिए लगातार इसका उपयोग करता है। कलाकारों, डिजाइनरों आदि के लिए कुछ ऐसा ही होता है।
• यदि कोई क्रिया है जो कई बार दोहराई जाएगी, और बहुत शुरुआत से आप इसे अनुकूलित कर सकते हैं, तो इसे तुरंत क्यों न करें। फिर सब कुछ स्वचालित रूप से चला जाएगा, और आपको एक ही चीज़ को कई बार ठीक करने की आवश्यकता नहीं होगी। इसमें उदाहरण के लिए, सहायक स्क्रिप्ट शामिल हैं जो डिजाइनरों को वस्तुओं के समूह के साथ एकसमान काम में तेजी लाने में मदद करती हैं।

2. वह ढूंढें जो आपको अनुकूलित करने की आवश्यकता है ।
कुछ साल पहले मेरे पास यह स्थिति थी: आप कोड, दृश्यों आदि के माध्यम से जाते हैं और जो कुछ संभव है उसे अनुकूलित करते हैं, और फिर प्रदर्शन को देखते हैं - यह शुरुआत अनुकूलक की गलती है ।
पहले आपको कुछ खोजने की ज़रूरत है जो सिस्टम को धीमा कर देती है, जिस पर प्रदर्शन स्पाइक्स हैं। इसमें प्रोफाइलर बहुत मदद करता है। बेशक, यह बल्कि मनमाना है और सिस्टम को थोड़ा लोड करता है, लेकिन इसके लाभ निर्विवाद हैं! यूनिटी प्रो में बिल्ट-इन प्रोलिफरेटर है, जो काफी सुविधाजनक है। लेकिन अगर आपके पास सामान्य एकता है, तो आप xCode प्रोफाइलर, या किसी अन्य उपयुक्त का उपयोग कर सकते हैं। प्रोफाइलर सबसे अधिक लोड होने वाले कोड को खोजने में मदद करता है, उपयोग की गई मेमोरी को दिखाता है, सिस्टम को कितना साउंड लोड करता है, लक्ष्य डिवाइस पर ड्राकॉल की संख्या, आदि। इस प्रकार, अनुकूलन करने से पहले, प्रोफाइलर के माध्यम से एप्लिकेशन को चलाएं। मुझे लगता है कि आप अपने प्रोजेक्ट के बारे में बहुत सी नई चीजें सीखेंगे)

मुझे प्रदर्शन समस्या को हल करने में क्या मदद मिली?

प्रोफाइलर के माध्यम से चलने से पहले भी, यह स्पष्ट था कि कमजोर बिंदु ड्रॉ कॉल की संख्या में था। औसतन, दृश्य में लगभग 70 ड्रॉकेल्स का उत्पादन हुआ, जो iPad1 स्तर और उससे कम के उपकरणों के लिए घातक है। उनके लिए सामान्य 30-40 ड्रॉ कॉल हैं । आप विंडो गेम के संपादक-> आँकड़े: में ड्रा कॉल की संख्या देख सकते हैं ।


संपादक में दिखाए गए ड्रा कॉल की संख्या अंतिम उपकरणों के समान है। प्रोफाइलर ने इसकी पुष्टि की। सामान्य तौर पर, इन आँकड़ों को देखने के लिए यह बहुत उपयोगी है, और न केवल प्रोग्रामर द्वारा, बल्कि डिजाइनरों द्वारा, खेल में "तंग" स्थानों को खोजने के लिए।
एक ही ड्रा कॉल में एक ही सामग्री के लिए कई ड्रा कॉल को समूहीकृत करना हमारे दृश्यों में अच्छी तरह से काम नहीं करता था। इसे डायनामिक बैचिंग कहा जाता है। मैंने "ड्रॉ ​​कॉल्स कैसे कम करें और उनके समूह में सुधार करें" विषय पर खुदाई शुरू की। नीचे सूचीबद्ध मूल नियम हैं, जिनका पालन करते हुए, आप ड्रा कॉल की स्वीकार्य संख्या प्राप्त कर सकते हैं। यहाँ वे हैं जिन्होंने मुझे बहुत मदद की:

1. कई बनावटों को एक बड़े में मिलाने के लिए एटलस का प्रयोग करें ।
वास्तव में, यह और भी महत्वपूर्ण है कि स्प्राइट / मॉडल केवल एक सामान्य बनावट का उपयोग नहीं करते हैं, बल्कि एक सामान्य सामग्री का उपयोग करते हैं । यह विभिन्न सामग्रियों की संख्या में है जो ड्रा कॉल की संख्या को मापा जाता है (आदर्श मामले में)। इसलिए, हमारी परियोजना में, उपयोग की जाने वाली छवियों को हमेशा एटलस में संयोजित किया जाता है, श्रेणियों में विभाजित किया जाता है: सभी दृश्यों में उपयोग की जाने वाली वस्तुएं, जीयूआई ऑब्जेक्ट, पृष्ठभूमि, और इसी तरह। यहाँ इस तरह के एटलस का एक उदाहरण दिया गया है:

इस तरह का विभाजन भविष्य में बनावट के लिए विभिन्न सेटिंग्स लागू करने के लिए भी उपयोगी होगा। लेकिन उस पर और बाद में।

2. आपको ट्रांसफॉर्म-> स्केल नहीं बदलना चाहिए ।
संशोधित स्केल वाली वस्तुएँ एक अलग श्रेणी में आती हैं जो ड्रा कॉल की संख्या को बढ़ाती हैं। जब मैंने ड्रॉ कॉल बैचिंग डॉक्यूमेंट को फिर से देखा, तो मैंने इसे देखा। यहां इसका फिर से पढ़ने का मतलब है;) मंच के चारों ओर घूमते हुए, मैंने बड़ी संख्या में ऐसी वस्तुओं की खोज की:

• यह पता चला कि डिजाइनरों ने ऑब्जेक्ट के फ्रंट पेज में स्केल राइट के माध्यम से कुछ सामान्य रूप से उपयोग की जाने वाली वस्तुओं में 1.2 गुना तक वृद्धि की है। नतीजतन, हम सीधे बनावट में उनके आकार को बढ़ाने के निर्णय पर आए। यह पिक्सेल-टू-पिक्सेल स्थिति के साथ भी अनुपालन करता है, जो 2 डी गेम के लिए बहुत महत्वपूर्ण है।
• ऐसी वस्तुएं थीं जिनमें एक ही छवि थी, लेकिन एक अलग पैमाने पर । ऐसी वस्तुओं के लिए एक विशेष स्क्रिप्ट लिखी गई थी, जिसने स्प्राइट के लिए उपयोग किए जाने वाले मेष से सीधे आवश्यक स्केल का अनुवाद किया, अर्थात। जाल आकार बदल दिया और स्केल = (1, 1, 1) छोड़ दिया।
• इसके अलावा, स्केल का उपयोग अक्सर हमारे साथ एक वस्तु को प्रतिबिंबित करने के लिए किया जाता है, उदाहरण के लिए, स्केल.x = -1, बाएं से दाएं की वस्तु को दर्शाता है। इस तरह के सभी पैमानों को उनके अनुरूप बदलावों से बदल दिया गया।
• कुछ वस्तुओं के लिए, स्केल को एनीमेशन में एक दो बार अनजाने में बदल दिया गया था। एनिमेशन की जांच करना न भूलें , अक्सर उनमें परिवर्तन निहित होते हैं, और केवल लॉन्च के बाद ही पता लगाया जा सकता है।

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

ड्रा कॉल की संख्या को कम करने के लिए कुछ और युक्तियां ( एकता दस्तावेज़ से उन सहित):

• स्थैतिक वस्तुओं को स्टेटिक के रूप में चिह्नित किया जा सकता है । फिर स्टैटिक बैचिंग का उपयोग किया जाएगा (केवल प्रो संस्करण में), जो ड्रा कॉल की संख्या को कम करने में भी मदद करेगा।
• कैमरे से समान दूरी पर समान सामग्री वाली वस्तुओं का उपयोग करने का प्रयास करें । उदाहरण: हमारे पास 10 इकाइयों की दूरी में अंतर है जो पहले से ही 1-2 अतिरिक्त ड्रॉ कॉल दे रही हैं। उसी समय, कोई विशेष पैटर्न सामने नहीं आया था, लेकिन मुझे संदेह है कि कैमरे के आकार, वस्तुओं के आकार, कैमरे से उनकी दूरी और ड्रा कॉल की संख्या के बीच एक संबंध है। प्रयोग!
• यह सुनिश्चित करने का प्रयास करें कि विभिन्न सामग्रियों वाली वस्तुएं एक-दूसरे को ओवरलैप न करें । यह विशेष रूप से पारभासी वस्तुओं के लिए ड्रा कॉल की संख्या भी बढ़ाता है।
• मल्टी-पास शेड्स ड्रा कॉल की संख्या में वृद्धि करते हैं । हमारे पास ऐसा नहीं है, लेकिन भविष्य में इसे ध्यान में रखना उपयोगी होगा।
• प्रत्येक कण प्रणाली 1 ड्रॉ Cal l देती है। (यह पुरानी एकता 3.5.6 कण प्रणाली को संदर्भित करता है जिसे हम आज तक उपयोग करते हैं। मुझे नहीं पता कि एकता 4 में चीजें कैसी हैं)। इसलिए, यदि एक ही समय में स्क्रीन पर एन कण सिस्टम हैं, तो यह स्वचालित रूप से कम से कम एन ड्रा कॉल है। आमतौर पर, एक ही प्रभाव अलग-अलग तरीकों से प्राप्त किया जा सकता है, जिसमें सिस्टम में कण प्रणाली और कणों की एक छोटी संख्या भी शामिल है। अक्सर मैंने एक वाह प्रभाव पैदा करने के लिए बड़ी संख्या में कणों (और स्वयं कणों का विशाल आकार) का उपयोग करते हुए शुरुआती प्रभाव डिजाइनरों को देखा। हालांकि, वे प्रदर्शन के बारे में नहीं सोचते हैं (विशेष रूप से यह देखते हुए कि यह सब एक पीसी पर एक संपादक में किया जाता है) और आमतौर पर कम कण समान प्रभाव को प्राप्त करने के लिए पर्याप्त हैं।

प्रदर्शन कूदता है

प्रदर्शन को प्रभावित करने वाला दूसरा कारक तथाकथित प्रदर्शन कूदता है। कभी-कभी खेल में 0.5-1 सेकंड के लिए "फ्रीज" होते थे, जो निश्चित रूप से अस्वीकार्य था और सीधे गेमप्ले को प्रभावित करता था। इसके अलावा, यह नवीनतम उपकरणों पर भी देखा गया था।
और इस मामले में, प्रोफाइलर ने मदद की! यहाँ प्रदर्शन spikes को कम करने के लिए नियमों की एक सूची है:

1. विशेष रूप से जटिल वस्तुओं के लिए झटपट () का उपयोग न करने की कोशिश करें ।
प्रदर्शन कूद मुख्य रूप से इंस्टेंट () के लिए कॉल में थे, जो कि सबफैब्स से नई वस्तुओं का निर्माण करते थे, या मौजूदा लोगों को क्लोन करते थे। इसके अलावा, कुछ वस्तुएँ बहुत भारी थीं, जो उनके निर्माण के समय को प्रभावित करती थीं। इसके बजाय, हमें सिस्टम को फिर से लिखना पड़ा ताकि वस्तुओं का पुन: उपयोग किया जा सके। यानी उपयोग की समाप्ति के बाद वस्तु की स्थिति (या उपयोग से पहले) प्रारंभिक एक पर कम हो गई थी। यह उपयोग की गई मेमोरी की मात्रा को कम करने में मदद करता है (चूंकि नई वस्तुओं को अब नई मेमोरी की आवश्यकता नहीं है) और नष्ट करने के लिए कॉल की संख्या () ।

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

3. gameObject.SetActiveRecursively () को कॉल कम करें ।
जटिल वस्तुओं के लिए, कॉल बहुत लंबी हो सकती है, क्योंकि इसमें न केवल वस्तुओं और उनके घटकों को सक्रिय करना शामिल है, बल्कि कुछ मामलों में आवश्यक संसाधनों को लोड करना भी शामिल है।

4. कम से कम Object.Find () कॉल ।
मुझे लगता है कि यह समझाने लायक नहीं है कि इस ऑपरेशन का समय दृश्य पर वस्तुओं की संख्या पर निर्भर करता है। इसमें GetComponent () जैसे फ़ंक्शन भी शामिल हैं।

5. संसाधनों को कम से कम करें ।UnloadUnusedAssets () और GC.Collect () ।
यदि कभी कोई नया संसाधन लोड करने के लिए पर्याप्त मेमोरी नहीं है या ओएस से अप्रयुक्त मेमोरी को मुक्त करने के लिए अनुरोध आया है, तो एकता कभी-कभी उनका समर्थन करती है। इस प्रकार, पहले 2 नियम स्वचालित रूप से ऐसी कॉल की संख्या को कम करते हैं। संसाधनों को कॉल करने के लिए सबसे अच्छी जगह। मैन्युअल रूप से लोड करने से पहले या इसे शुरू करने के तुरंत बाद संसाधन लोड करना। यह दृश्य के लिए अतिरिक्त मेमोरी को मुक्त करने में भी मदद करेगा, जो कभी-कभी महत्वपूर्ण होता है। इसी प्रदर्शन कूद को छिपाया जा सकता है, उदाहरण के लिए, बूट स्क्रीन द्वारा;)

ऊपर दिए गए नियमों का उपयोग करके प्रदर्शन स्पाइक्स और एक बहुत ही चिकनी गेमप्ले और तस्वीर को समाप्त किया गया।

अन्य अनुकूलन

नीचे अन्य नियम दिए गए हैं जो आपकी मदद कर सकते हैं। उनमें से ज्यादातर मैं अनुकूलन के पिछले चरणों में इस्तेमाल किया।

स्क्रिप्ट

• GetComponent <> () Update , FixedUpdate, और इसी तरह के अन्य कार्यों में उपयोग न करें। इसके बजाय, घटक को Awake () या प्रारंभ () में कैश करना बेहतर है। यदि स्क्रिप्ट का उपयोग करने वाले बहुत सारे ऑब्जेक्ट हैं, तो ऐसी कैशिंग स्क्रिप्ट के चलने के समय को काफी कम कर सकती है।
• कैशे बिल्ट-इन घटकों जैसे ट्रांसफॉर्मर , रेंडरर इत्यादि। खासकर यदि उनका उपयोग अपडेट () जैसे कार्यों में किया जाता है। प्रत्येक के लिए ऐसी कॉल GetComponent () के माध्यम से की जाती है । ऊपर का नियम देखें। यह किया जा सकता है, उदाहरण के लिए, इस तरह:

/// <summary> /// Cached transform /// </summary> protected new Transform transform { get { if(cachedTransform == null) cachedTransform = base.transform; return cachedTransform; } } private Transform cachedTransform = null; 

• परिमाण के बजाय वेक्टर 2 (3,4) का उपयोग करें।
• मेष रंगों का उपयोग करते समय Color और Mesh.colors के बजाय Color32 और Mesh.colors32 का उपयोग करें।
• आप OnBecameV अदृश्य / OnBecameInvigure का उपयोग उन स्क्रिप्ट के लिए कर सकते हैं जिन्हें तब अक्षम किया जा सकता है जब कैमरा ऑब्जेक्ट को नहीं देखता है।
• इनलाइन सरणियों का उपयोग करें। यह टाइप T [] के सरणियों को संदर्भित करता है। वे अन्य सभी संग्रहों की तुलना में बहुत तेज हैं।
• डिवाइस पर एप्लिकेशन चलाते समय लॉग को अक्षम करें। आमतौर पर, लॉग को प्रिंट करने के लिए फ़ाइल सिस्टम तक पहुंच की आवश्यकता होती है, और यदि बहुत सारे लॉग होते हैं, तो इससे प्रदर्शन के लिए दुःखद परिणाम हो सकते हैं।
• अपवादों को अक्षम करें। परिणामस्वरूप, उन्हें अपने कोड में उपयोग न करने का प्रयास करें। अपवादों को अक्षम करने से 30% तक प्रदर्शन को बचाया जा सकता है। लेकिन यह मत भूलो कि यदि कोई त्रुटि होती है और इसे एक अपवाद के साथ नियंत्रित नहीं किया जा सकता है, तो यह डिवाइस पर एप्लिकेशन का क्रैश है। इसलिए, आपको चुनना होगा - या तो अच्छा परीक्षण और प्रदर्शन लाभ, या विश्वसनीयता, लेकिन प्रदर्शन थोड़ा खराब है । मामले में जब प्रदर्शन संतोषजनक होता है, तो दूसरे विकल्प का लाभ देना बेहतर होता है।

भौतिक विज्ञान

• कम एक साथ सक्रिय Rigidbody , बेहतर। अप्रयुक्त को निष्क्रिय करें।
• समय की प्रति यूनिट फिक्स्डयूडेट की संख्या कम करें। निश्चित समय = 0.03333 प्रति सेकंड 30 गणनाओं की गति से भौतिकी की गारंटी देता है, जो आमतौर पर बहुत अच्छा होता है। यहां तक ​​कि 20 स्वीकार्य हो सकता है, जो निश्चित समय = 0.05 से मेल खाता है।
  
• निरंतर या गतिशील टकराव का पता लगाने का उपयोग कम से कम करें। वे बहुत संसाधन गहन हैं। 2 डी गेम के लिए, उन्हें आमतौर पर ज़रूरत नहीं होती है।

एनिमेशन

• स्क्रीन पर एनिमेटेड ऑब्जेक्ट्स की संख्या पर नज़र रखें। कम, बेहतर।
• एक जटिल वस्तु पर कुछ सरल एनिमेशन के बजाय, आप एक जटिल एक बना सकते हैं जो एक ही काम करता है।
• आप क्लिप की नमूना दर को कम करने की कोशिश कर सकते हैं। खासकर अगर एनिमेशन बहुत सारे हैं।
• रूलिंग प्रकार = रेंडरर्स के आधार पर या उपयोगकर्ता सीमा के आधार पर उपयोग करें। तब एनीमेशन तभी खेलेंगे जब वस्तु स्क्रीन पर दिखाई दे।
  
  यदि वह, निश्चित रूप से, सूट।

कण प्रणाली

• पार्टिकल रेंडरर में बिलबोर्ड की जगह वर्टिकल बिलबोर्ड का इस्तेमाल करें।
• मोबाइल पर शेड का उपयोग करें-> मोबाइल उपकरणों पर कण । यह न केवल कण प्रणाली पर लागू होता है।
• वांछित प्रभाव प्राप्त करने के लिए संभव के रूप में संभव के रूप में कुछ कण प्रणालियों और प्रणाली में कणों का उपयोग करें।
• कमजोर प्रणालियों के लिए, आप कुछ सूक्ष्म या गैर-आवश्यक कण प्रणालियों को अक्षम कर सकते हैं। यह आपको कई ड्रा कॉल को बचाने और दक्षता की कीमत पर उनकी उत्पादकता बढ़ाने की अनुमति देगा। मैं आपको आश्वासन देता हूं, मेगा कूल इफेक्ट्स की तुलना में गेम प्रक्रिया का आनंद लेना अक्सर अधिक सुखद होता है।

जीयूआई

• OnGUI () का उपयोग न करें। प्रत्येक ऐसी कॉल कुछ अतिरिक्त ड्रॉ कॉल होती है। वही GUILayout के लिए जाता है। सामान्य तौर पर, एकता का GUI समर्थन बहुत खराब तरीके से किया जाता है। उदाहरण के लिए, हमारे पास अपना स्वयं का स्प्राइट-आधारित GUI सिस्टम है। एसेट स्टोर में कई अन्य बहुत उपयोगी जीयूआई प्लगइन्स हैं।
• फ़ॉन्ट के लिए उत्पन्न बनावट का आकार केवल उपयोग किए गए वर्णों को जोड़कर कम किया जा सकता है। फ़ॉन्ट सेटिंग्स में, वर्ण सेट करें = कस्टम सेट , और कस्टम चार्ट में उपयोग किए गए वर्ण शामिल हैं:
  
• आप दृश्य ऑब्जेक्ट और GUI के लिए अलग-अलग कैमरों का उपयोग करने का प्रयास कर सकते हैं। यह GUI को ज़ूम-इंडिपेंडेंट बना देगा, जो आपको ज़ूम इन / आउट करते समय उस पर स्केल का उपयोग करने से मुक्त करता है। कभी-कभी यह उत्पादकता बढ़ा सकता है।

अन्य

• उपयोग में न होने पर एक्सीलेरोमीटर बंद कर दें। आप प्लेयर सेटिंग्स में माप आवृत्ति को भी कम कर सकते हैं।
• आप पुराने उपकरणों पर अधिकतम FPS सीमित कर सकते हैं। उदाहरण के लिए, इसे सेट करना: Application.targetFrameRate = 30 । यह आमतौर पर एक चिकनी तस्वीर में परिणत होता है। इसके अलावा, यह बैटरी नाली को कम करता है, जैसा कि एक ही समय में कम प्रोसेसर शक्ति की आवश्यकता होती है। सामान्य तौर पर, Apple उपकरणों पर FPS> 60 का कोई मतलब नहीं है, क्योंकि उनका स्क्रीन रिफ्रेश रेट 60 है।
• कभी-कभी, लगातार लगातार कचरा संग्रह प्रदर्शन को सुचारू करता है। क्योंकि सिस्टम स्वयं ऐसा शायद ही कभी करता है और जब सब कुछ पहले से ही पूरी तरह से खराब है, और विनाश के लिए बड़ी संख्या में ऑब्जेक्ट जमा हो सकते हैं, जिससे प्रदर्शन में उछाल आता है। यदि आप इसे अधिक बार करते हैं, तो नष्ट करने के लिए कम वस्तुएं होंगी, और स्मृति को मुक्त करना आसान होगा। दूसरी ओर, दृश्य की पूरी अवधि के लिए कचरा संग्रहण आवश्यक नहीं हो सकता है।

आवेदन का आकार कम करें

इसकी आवश्यकता क्यों हो सकती है? पहले, ऐसा इसलिए किया गया क्योंकि एप्लिकेशन <20Mb आकार में 3G नेटवर्क के माध्यम से iOS पर डाउनलोड किए जा सकते हैं। जो, सिद्धांत रूप में, डाउनलोड की संख्या में वृद्धि करनी चाहिए, हालांकि मैंने विशिष्ट आंकड़े नहीं देखे हैं। IPad3 की रिहाई के संबंध में, एप्लिकेशन "फैटर" बन गए, और सीमा 50Mb तक बढ़ा दी गई। यह मत भूलो कि AppStore में आवेदन भरने के बाद, इसे 4Mb के औसत से आकार में बढ़ाया जाएगा। XCode में AppStore में भरने के बाद एप्लिकेशन का वजन कितना होगा, यह जांचने के लिए, ऑर्गनाइज़र-> अभिलेखागार के पास एक विशेष बटन भी है, जिसे एस्टिमेट साइज़ कहा जाता है:


बिल्ड आकार को कम करने के लिए आपको जो कुछ भी चाहिए वह एकता डॉक्स में वर्णित है:

• खिलाड़ी का आकार अनुकूलन
• फ़ाइल का आकार कम करना

मैं यहाँ वर्णन करूँगा कि मैंने स्वयं का क्या उपयोग किया है। आइए प्रदर्शन को प्रभावित करने के साथ शुरू करें:

1. सही बनावट प्रारूप का उपयोग करें ।
इससे उपयोग की जाने वाली बनावट स्मृति की मात्रा भी कम हो जाएगी और, तदनुसार, उत्पादकता में वृद्धि होगी। कभी-कभी यह 16 बिट्स बनावट प्रारूप का उपयोग करने के लिए पर्याप्त होता है, खासकर यदि सभी ग्राफिक्स केवल कुछ रंगों में खींचे जाते हैं। की तुलना करें:

नीरस बनावट के लिए, आप केवल उसके ग्रे और अल्फा घटकों का उपयोग कर सकते हैं और एक विशेष रूप से लिखित shader और रंग द्वारा गुणन का उपयोग करके उनसे एक समाप्त वस्तु को मूर्तिकला कर सकते हैं:

पृष्ठभूमि और फजी वस्तुओं के लिए, संपीड़न का उपयोग किया जा सकता है। अब iOS पर PVRTC संपीड़न बहुत उन्नत है। यह याद रखने योग्य है कि बनावट जितनी बड़ी होगी, संपीड़न के बाद इसकी गुणवत्ता बेहतर होगी । छोटे बनावट पर, संपीड़न का उपयोग अस्वीकार्य हो सकता है।
इसे समझने के लिए, आपको ऑब्जेक्ट को "पृष्ठभूमि" प्रकार, GUI, गेम ऑब्जेक्ट के समूहों में विभाजित करना होगा, जिसके बारे में मैंने पहले ही लिखा था। फिर प्रत्येक प्रकार के लिए आप अपने स्वयं के एटलस बना सकते हैं और विभिन्न बनावट प्रारूप सेटिंग्स का उपयोग कर सकते हैं।

2. सही ध्वनि प्रारूप का उपयोग करें ।
मैंने इस बारे में पहले नहीं सोचा था। ध्वनियों पर संपीड़न का उपयोग करने से मुझे न केवल आवेदन के आकार को कम करने की अनुमति मिली, बल्कि इसके द्वारा उपयोग की जाने वाली स्मृति की मात्रा भी। मैं स्वयं निम्नलिखित नियमों का उपयोग करता हूं:

• ऑडियो प्रारूप का उपयोग करें = बहुत छोटी और छोटी ध्वनियों के लिए मूल ( <100 Kb )।
• बाकी के लिए, संपीड़न का उपयोग करें। संपीड़न = 96 केबीपीएस - यह पहले से ही बहुत स्वीकार्य है। नीचे - ध्यान देने योग्य विकृति।
• अधिकांश संकुचित ध्वनियों के लिए लोड प्रकार = मेमोरी में संपीड़ित का उपयोग करें। यह उपयोग की जाने वाली मेमोरी की मात्रा को कम करेगा, लेकिन प्रदर्शन को प्रभावित कर सकता है, क्योंकि इसे प्लेबैक के दौरान अनपैकिंग की आवश्यकता होती है।
• बैकग्राउंड म्यूजिक के लिए, डिस्क से लोड टाइप = स्ट्रीम का उपयोग करें, खासकर तेज HDD वाले सिस्टम पर। यह बहुत सारी मेमोरी को बचाएगा।
• अन्य सभी मामलों में लोड पर डीकंप्रेस का उपयोग करें। ध्वनि अधिक मेमोरी पर कब्जा कर लेगी, लेकिन यह व्यावहारिक रूप से सीपीयू को "प्लांट" नहीं करेगी, जो कभी-कभी प्रदर्शन कूद से छुटकारा पाने में मदद करेगी।
• बैकग्राउंड म्यूजिक के लिए हार्डवेयर डिकोडिंग का इस्तेमाल करें। IOS उपकरणों पर अंतर्निहित डिकोडर पृष्ठभूमि संगीत के लिए CPU उपयोग को कम करता है, लेकिन यह केवल एक बार में एक ट्रैक के लिए किया जा सकता है।
• अगर स्टीरियो की जरूरत नहीं है तो मोनो का उपयोग करें। या अगर यह फ़ाइल में मौजूद है, लेकिन अलग नहीं है। यह उपयोग किए गए स्थान की मात्रा (मेमोरी और डिस्क पर दोनों) को आधा कर देगा ।

बिल्ड आकार को कम करने के लिए निम्नलिखित अन्य चरण हैं। अधिकांश सेटिंग्स प्लेयर सेटिंग्स में बनाई गई हैं:

• स्ट्रिपिंग स्तर सेट करें = प्रोजेक्ट सेटिंग्स में माइक्रो mscorlib का उपयोग करें । यह केवल प्रो मालिकों के लिए है। अनावश्यक रूप से System.dll और System.Xml.dll की इकाइयों का उपयोग न करें। वे उपयोग माइक्रो mscolib के साथ संगत नहीं हैं।
• .Net 2.0 सबसेट में संगतता स्तर एपीआई स्थापित करें। लेकिन कभी-कभी इसके बाद यह कोड काम नहीं कर सकता है यदि संबंधित वर्ग / फ़ंक्शंस, आदि .net 2.0 सब्मिट में शामिल न हों। एक बार मेरे मामले में क्या हुआ।
• आपको अनावश्यक पुस्तकालयों से निर्भरता से भी छुटकारा चाहिए।
• स्क्रिप्ट कॉल ऑप्टिमाइज़ेशन स्तर को फास्ट पर सेट करें लेकिन अपवादों को अक्षम करने के लिए कोई अपवाद नहीं । इससे बिल्ड साइज भी कम होगा।
• Armv6 में लक्ष्य प्लेटफ़ॉर्म स्थापित करें (OpenGL ES1.1) । यदि आपको armv7 की आवश्यकता नहीं है। या इसके विपरीत, armv7 में, लेकिन एक ही समय में दोनों नहीं। यह देखते हुए कि Apple कम से कम armv6 वाले उपकरणों का समर्थन करता है, यह केवल armv7 को छोड़ने के लिए समझ में आता है।
• जेएस सरणियों का उपयोग न करें। जेएस का उपयोग न करने के लिए बेहतर है, सी # का उपयोग करें। आमतौर पर, JS से C # पर स्क्रिप्ट कोड लिखने के बाद, एक एप्लिकेशन का वजन कम होता है।

प्रयुक्त प्रेरणा के स्रोत

सबसे पहले, एकता दस्तावेजों का उपयोग किया गया था - स्वयं एकता डेवलपर्स के सबसे उपयोगी संसाधन। उन्हें पहली बार पढ़ने की ज़रूरत है, अधिमानतः कई बार, और थोड़ी देर बाद फिर से, क्योंकि वे लगातार अपडेट किए जाते हैं।

• स्क्रिप्ट प्रदर्शन अनुकूलन ।
• मोबाइल उपकरणों के लिए अनुकूलन ।
• मोबाइल उपकरणों के लिए अनुकूलन चेकलिस्ट ।
• IOS में प्रदर्शन अनुकूलन ।
• ग्राफिक्स अनुकूलन ।
• मोबाइल उपकरणों पर प्रोफाइलिंग ।
• Apple डिवाइस सेटिंग्स के बारे में उपयोगी जानकारी ।

अलग-अलग, मैं आवेदन के आकार को कम करने के लिए पहले से ही उल्लेख किए गए दस्तावेजों को खड़ा करता हूं:

• खिलाड़ी का आकार अनुकूलन
• फ़ाइल का आकार कम करना

अन्य स्रोत:

• एकता में 2d मोबाइल प्रदर्शन के लिए 46 टिप्स और ट्रिक्स । उपयोगी लेख जिसने मेरी सूची को बहुत प्रभावित किया।
• IOS के लिए एकता के साथ अनुकूलन ।
• एकता में कोड अनुकूलन ।

निष्कर्ष

मेरे द्वारा किए गए अनुकूलन ने मुझे खेल के प्रदर्शन और सामान्य रूप से खेलने की क्षमता को बढ़ाने की अनुमति दी। एक जोड़ा बोनस के रूप में आवेदन का आकार कम कर दिया गया है;) मुझे आशा है कि मेरा लेख आपको अपने एकता आवेदन को और भी बेहतर बनाने में मदद करेगा।
शायद किसी को मेरे पिछले लेखों को पढ़ने में दिलचस्पी होगी:

• दो दिनों में खेल
• छोटी ताकतों के साथ खेल का एक प्रचारक वीडियो कैसे बनाया जाए - अलेक्सई लूनिन द्वारा लिखित आलेख - type_2 ।
• यूनिटी 3 डी पर 2 डी
• मोबाइल प्लेटफार्मों के लिए खेल के विकास में अतिसूक्ष्मवाद के सिद्धांत

सबसे अधिक संभावना है, मेरा अगला लेख एकता में काम को आसान बनाने और त्रुटियों की संख्या को कम करने के बारे में एक लेख होगा।
यदि किसी के पास सवाल, सुझाव, संशोधन हैं - मैं हमेशा सुनने और चर्चा करने के लिए तैयार हूं।