कई महान एकता प्रदर्शन लेख और ट्यूटोरियल हैं। हम उन्हें इस लेख के साथ बदलने या सुधारने की कोशिश नहीं कर रहे हैं, यह इन लेखों को पढ़ने के बाद हमारे द्वारा उठाए गए कदमों का एक संक्षिप्त सारांश है, साथ ही उन कदमों ने हमें अपनी समस्याओं को हल करने की अनुमति दी है। मैं दृढ़ता से सलाह देता हूं कि आप कम से कम https://learn.unity.com/ पर सामग्रियों का अध्ययन करें ।

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

• गैर-अनुकूलित शेड्स
• C # में अनधिकृत स्क्रिप्ट

अधिकांश समस्याएं दूसरे समूह की वजह से थीं, इसलिए मैंने इस लेख में C # स्क्रिप्ट पर ध्यान केंद्रित करने का फैसला किया (शायद इसलिए भी कि मैंने अपने जीवन में एक भी shader नहीं लिखा)।

कमजोरियों की खोज करें

इस लेख का उद्देश्य प्रोफाइलर का उपयोग करने के लिए ट्यूटोरियल लिखना नहीं है; मैं सिर्फ इस बारे में बात करना चाहता था कि प्रोफाइलिंग प्रक्रिया के दौरान हम मुख्य रूप से क्या रुचि रखते हैं।

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


रूपरेखा के लिए सेटिंग्स बनाएँ

यदि आप "रैंडम लैग इन यूनिटी" या इसी तरह के किसी अन्य अनुरोध को Google करने का प्रयास करते हैं, तो आप पाएंगे कि अधिकांश लोग कचरा संग्रहण पर ध्यान केंद्रित करने की सलाह देते हैं, यही कारण है कि मैंने ऐसा किया। हर बार जब आप किसी वस्तु (वर्ग उदाहरण) का उपयोग करना बंद करते हैं, तो कचरा उत्पन्न होता है, जिसके बाद एकता कचरा संग्रहकर्ता समय-समय पर गंदगी को साफ करने और स्मृति को मुक्त करने के लिए शुरू होता है, जो समय की एक पागल राशि लेता है और फ्रेम दर में गिरावट की ओर जाता है।

प्रोफाइलर में जंक स्क्रिप्ट कैसे खोजें?

बस CPU उपयोग का चयन करें -> पदानुक्रम दृश्य चुनें -> GC Alloc द्वारा क्रमबद्ध करें


कचरा संग्रहण के लिए प्रोफाइलर विकल्प

गेमप्ले दृश्य के लिए जीसी आवंटन कॉलम में कुछ शून्य हासिल करना आपका काम है।

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

प्रोफाइलिंग डेटा के आधार पर, मैंने अनुकूलन को दो भागों में विभाजित किया है:

• कूड़े का निस्तारण
• लीड समय में कमी

भाग 1: कचरा से लड़ना

इस भाग में मैं आपको बताऊंगा कि कचरे से छुटकारा पाने के लिए हमने क्या किया। यह सबसे मौलिक ज्ञान है जिसे किसी भी डेवलपर को समझना चाहिए; वे हर खींच / मर्ज अनुरोध में हमारे दैनिक विश्लेषण का एक महत्वपूर्ण हिस्सा बन गए हैं।

पहला नियम: अद्यतन विधियों में कोई नई वस्तु नहीं

आदर्श रूप से, अपडेट, फिक्स्डअपडेट और लेटअपडेट के तरीकों में "नए" कीवर्ड नहीं होने चाहिए । आपको हमेशा वही होना चाहिए जो आपके पास पहले से है।

कभी-कभी एक नई वस्तु का निर्माण कुछ आंतरिक एकता विधियों में छिपा होता है, इसलिए यह इतना स्पष्ट नहीं है। हम इस बारे में बाद में बात करेंगे।

दूसरा नियम: एक बार बनाएं और पुन: उपयोग करें!

संक्षेप में, इसका मतलब है कि आपको स्टार्ट और अवेक विधियों में आपके द्वारा की जाने वाली हर चीज के लिए मेमोरी आवंटित करनी चाहिए। यह नियम पहले के समान है। यह वास्तव में अद्यतन विधियों से "नए" कीवर्ड को खत्म करने का एक और तरीका है।

कोड है कि:

• नए उदाहरण बनाता है
• किसी भी खेल की वस्तुओं के लिए देख रहे हैं

आपको हमेशा अपडेट विधियों से प्रारंभ करने या जागने की कोशिश करनी चाहिए।

यहाँ हमारे परिवर्तनों के उदाहरण हैं:

प्रारंभ विधि में सूचियों के लिए स्मृति का आवंटन, उनका समाशोधन (स्पष्ट) और यदि आवश्यक हो तो पुन: उपयोग करें।

//Bad code private List<GameObject> objectsList; void Update() { objectsList = new List<GameObject>(); objectsList.Add(......) } //Better Code private List<GameObject> objectsList; void Start() { objectsList = new List<GameObject>(); } void Update() { objectsList.Clear(); objectsList.Add(......) } 

लिंक संग्रहीत करना और उनका पुन: उपयोग करना इस प्रकार है:

 //Bad code void Update() { var levelObstacles = FindObjectsOfType<Obstacle>(); foreach(var obstacle in levelObstacles) { ....... } } //Better code private Object[] levelObstacles; void Start() { levelObstacles = FindObjectsOfType<Obstacle>(); } void Update() { foreach(var obstacle in levelObstacles) { ....... } } 

वही FindGameObjectsWithTag विधि या किसी अन्य विधि पर लागू होता है जो एक नया सरणी देता है।

तीसरा नियम: तार से सावधान रहें और उन्हें समाप्‍त करने से बचें

जब कचरा पैदा करने की बात आती है, तो लाइनें भयानक होती हैं। यहां तक ​​कि सबसे सरल स्ट्रिंग ऑपरेशन बहुत अधिक कचरा पैदा कर सकते हैं। क्यों? स्ट्रिंग्स सिर्फ सरणियाँ हैं, और ये सरणियाँ अपरिवर्तनीय हैं। इसका मतलब यह है कि हर बार जब आप दो पंक्तियों को जोड़ते हैं, तो एक नई सरणी बनाई जाती है, और पुराना कचरा में बदल जाता है। सौभाग्य से, StringBuilder का उपयोग ऐसी कचरा निर्माण से बचने या कम करने के लिए किया जा सकता है।

यहाँ एक उदाहरण है कि आप स्थिति को कैसे सुधार सकते हैं:

 //Bad code void Start() { text = GetComponent<Text>(); } void Update() { text.text = "Player " + name + " has score " + score.toString(); } //Better code void Start() { text = GetComponent<Text>(); builder = new StringBuilder(50); } void Update() { //StringBuilder has overloaded Append method for all types builder.Length = 0; builder.Append("Player "); builder.Append(name); builder.Append(" has score "); builder.Append(score); text.text = builder.ToString(); } 

ऊपर दिखाए गए उदाहरण से सब कुछ ठीक है, लेकिन कोड में सुधार के लिए अभी भी कई संभावनाएं हैं। जैसा कि आप देख सकते हैं, लगभग पूरे स्ट्रिंग को स्थिर माना जा सकता है। हम स्ट्रिंग को दो UI.Text ऑब्जेक्ट्स के लिए दो भागों में विभाजित करते हैं। सबसे पहले, एक में केवल स्थिर पाठ "प्लेयर" + नाम + "का स्कोर" होता है , जिसे स्टार्ट विधि में सौंपा जा सकता है, और दूसरे में स्कोर मान होता है, जो प्रत्येक फ्रेम में अपडेट किया जाता है। हमेशा स्टैटिक लाइन्स को सही मायने में स्टैटिक बनाएं और उन्हें स्टार्ट या अवेक मेथड में जेनरेट करें । इस सुधार के बाद, लगभग सब कुछ क्रम में है, लेकिन Int.ToString (), Float.ToString (), आदि कॉल करते समय थोड़ा कचरा अभी भी उत्पन्न होता है।

हमने सभी संभावित लाइनों के लिए मेमोरी को उत्पन्न और पूर्व-आवंटित करके इस समस्या को हल किया। यह स्मृति की बेवकूफी की तरह लग सकता है, लेकिन ऐसा समाधान हमारी आवश्यकताओं से पूरी तरह मेल खाता है और समस्या को पूरी तरह हल करता है। तो, अंत में, हमें एक स्थिर सरणी मिली, जिस तक पहुंच को सीधे अनुक्रमित करके वांछित स्ट्रिंग के डीनोट नंबर का उपयोग करके एक्सेस किया जा सकता है:

 public static readonly string[] NUMBERS_THREE_DECIMAL = { "000", "001", "002", "003", "004", "005", "006",.......... 

चौथा नियम: कैश वैल्यूज एक्सेस मेथड्स द्वारा लौटाया गया

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

 //Bad Code void Update() { gameObject.tag; //or gameObject.name; } 

अद्यतन पद्धति में पहुँच विधियों का उपयोग करने से बचने का प्रयास करें। प्रारंभ विधि में केवल एक बार एक्सेस विधि को कॉल करें और रिटर्न मान को कैश करें।

सामान्य तौर पर, मैं सुझाव देता हूं कि अपडेट पद्धति में किसी भी स्ट्रिंग एक्सेस विधियों या सरणी एक्सेस विधियों को कॉल न करें । ज्यादातर मामलों में, प्रारंभ विधि में एक बार लिंक प्राप्त करना पर्याप्त है ।

यहां एक और अडॉप्टेड एक्सेस पद्धति कोड के दो और सामान्य उदाहरण दिए गए हैं:

 //Bad Code void Update() { //Allocates new array containing all touches Input.touches[0]; } //Better Code void Update() { Input.GetTouch(0); } //Bad Code void Update() { //Returns new string(garbage) and compare the two strings gameObject.Tag == "MyTag"; } //Better Code void Update() { gameObject.CompareTag("MyTag"); } 

पांचवां नियम: ऐसे कार्यों का उपयोग करें जो मेमोरी को आवंटित न करें

कुछ एकता कार्यों के लिए, गैर-मेमोरी विकल्प मिल सकते हैं। हमारे मामले में, ये सभी कार्य भौतिकी से संबंधित हैं। हमारी टक्कर की मान्यता पर आधारित है

 Physics2D. CircleCast(); 

इस विशेष मामले के लिए, आपको एक गैर-मेमोरी फ़ंक्शन कहा जा सकता है

 Physics2D. CircleCastNonAlloc(); 

कई अन्य कार्यों में भी समान विकल्प होते हैं, इसलिए हमेशा NonAlloc फ़ंक्शन के लिए दस्तावेज़ की जांच करें ।

छठा नियम: LINQ का उपयोग न करें

बस यह मत करो। मेरा मतलब है, आपको किसी भी कोड का उपयोग करने की आवश्यकता नहीं है जो अक्सर चलता है। मुझे पता है कि LINQ का उपयोग करते समय, कोड को पढ़ना आसान है, लेकिन कई मामलों में ऐसे कोड का प्रदर्शन और मेमोरी आवंटन भयानक है। बेशक, इसका उपयोग कभी-कभी किया जा सकता है, लेकिन, ईमानदार होने के लिए, हमारे खेल में हम LINQ का उपयोग बिल्कुल नहीं करते हैं।

सातवां नियम: एक बार बनाएं और पुन: उपयोग करें, भाग 2

इस बार हम पूलिंग ऑब्जेक्ट्स के बारे में बात कर रहे हैं। मैं पूलिंग के विवरण में नहीं जाऊंगा, क्योंकि यह कई बार कहा गया है, उदाहरण के लिए, इस ट्यूटोरियल का अध्ययन करें: https://learn.unity.com/tutorial/object-pooling

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

आठवां नियम: पैकेजिंग-परिवर्तन (बॉक्सिंग) के साथ अधिक चौकस!

बॉक्सिंग कचरा पैदा करता है! लेकिन बॉक्सिंग क्या है? अधिकांश बार, बॉक्सिंग तब होती है जब आप किसी प्रकार के ऑब्जेक्ट की अपेक्षा वाले फ़ंक्शन को मान प्रकार (int, float, bool, आदि) पास करते हैं।

यहाँ मुक्केबाजी का एक उदाहरण है जिसे हमें अपनी परियोजना में ठीक करने की आवश्यकता है:

हमने परियोजना में अपना संदेश प्रणाली लागू किया। प्रत्येक संदेश में असीमित मात्रा में डेटा हो सकता है। डेटा एक डिक्शनरी में स्टोर किया गया है जो इस प्रकार है:

 Dictionary<string, object> data; 

हमारे पास एक सेटर भी है जो इस डिक्शनरी में मान सेट करता है:

 public Action SetAttribute(string attribute, object value) { data[attribute] = value; } 

यहां बॉक्सिंग काफी स्पष्ट है। आप फ़ंक्शन को निम्नानुसार कॉल कर सकते हैं:

 SetAttribute("my_int_value", 12); 

तब मूल्य "12" बॉक्सिंग के अधीन है और यह कचरा उत्पन्न करता है।

हमने प्रत्येक आदिम प्रकार के लिए अलग-अलग डेटा कंटेनर बनाकर समस्या को हल किया, और पिछले ऑब्जेक्ट कंटेनर का उपयोग केवल संदर्भ प्रकारों के लिए किया जाता है।

 Dictionary<string, object> data; Dictionary<string, bool> dataBool; Dictionary<string, int> dataInt; ....... 

हमारे पास प्रत्येक डेटा प्रकार के लिए अलग-अलग निपटान हैं:

 SetBoolAttribute(string attribute, bool value) SetIntAttribute(string attribute, int value) 

और इन सभी उपनिवेशकों को इस तरह से लागू किया जाता है कि वे समान सामान्यीकृत कार्य कहते हैं:

 SetAttribute<T>(ref Dictionary<string, T> dict, string attribute, T value) 

मुक्केबाजी की समस्या का समाधान हो गया है!

इसके बारे में अधिक लेख में पढ़ें https://docs.microsoft.com/cs-cz/dotnet/csharp/programming-guide/types/boxing-and-unboxing ।

नौवां नियम: चक्र हमेशा संदेह के दायरे में होते हैं

यह नियम पहले और दूसरे के समान है। प्रदर्शन और स्मृति कारणों से सभी वैकल्पिक कोड को लूप से निकालने का प्रयास करें।

सामान्य स्थिति में, हम अपडेट विधियों में लूप से छुटकारा पाने का प्रयास करते हैं, लेकिन अगर हम उनके बिना नहीं कर सकते हैं, तो हम कम से कम ऐसे लूप में किसी भी मेमोरी आवंटन से बचेंगे। तो, नियम 1-8 का पालन करें और उन्हें सामान्य रूप से लूप में लागू करें , न कि केवल अपडेट के तरीके।

नियम 10: बाहरी पुस्तकालयों में कोई कचरा नहीं

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

भाग 2: रनटाइम को अधिकतम करना

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

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

ईमानदारी से, इन नियमों में से कुछ बहुत खराब पठनीय कोड होते हैं , और कभी-कभी सिफारिशों का उल्लंघन भी करते हैं , उदाहरण के लिए, नीचे दिए गए नियमों में से एक में कोड एम्बेडिंग का उल्लेख किया गया है।

इनमें से कई नियम लेख के पहले भाग में प्रस्तुत किए गए हैं। आमतौर पर, कचरा पैदा करने वाले कोड की तुलना में कचरा पैदा करने वाले कोड का प्रदर्शन कम होता है।

पहला नियम: सही निष्पादन आदेश

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

हमारे मामले में, यह कोड आमतौर पर जुड़ा हुआ है

• GetComponent <> को कॉल करता है
• गणना जो वास्तव में प्रत्येक फ्रेम में एक ही परिणाम लौटाते हैं
• समान वस्तुओं के कई उदाहरण, आमतौर पर सूचीबद्ध होते हैं
• GameObjects के लिए खोजें
• ट्रांसफ़र और अन्य एक्सेस विधियों का उपयोग करने के लिए लिंक प्राप्त करना

यहां नमूना कोड की एक सूची दी गई है जिसे हमने अपडेट विधियों से प्रारंभ विधियों तक ले जाया है:

 //There must be a good reason to keep GetComponent in Update gameObject.GetComponent<LineRenderer>(); gameObject.GetComponent<CircleCollider2D>(); //Examples of calculations returning same result every frame Mathf.FloorToInt(Screen.width / 2); var width = 2f * mainCamera.orthographicSize * mainCamera.aspect; var castRadius = circleCollider.radius * transform.lossyScale.x; var halfSize = GetComponent<SpriteRenderer>().bounds.size.x / 2f; //Finding objects var levelObstacles = FindObjectsOfType<Obstacle>(); var levelCollectibles = FindGameObjectsWithTag("COLLECTIBLE"); //References objectTransform = gameObject.transform; mainCamera = Camera.main; 

दूसरा नियम: आवश्यक होने पर ही कोड निष्पादित करें

हमारे मामले में, यह मुख्य रूप से UI अपडेट स्क्रिप्ट से संबंधित है। यहां एक उदाहरण दिया गया है कि हमने उस कोड के कार्यान्वयन को कैसे बदल दिया जो स्तर पर एकत्रित वस्तुओं की वर्तमान स्थिति को प्रदर्शित करता है।

 //Bad code Text text; GameState gameState; void Start() { gameState = StoreProvider.Get<GameState>(); text = GetComponent<Text>(); } void Update() { text.text = gameState.CollectedCollectibles.ToString(); } 

चूंकि प्रत्येक स्तर पर इकट्ठा करने के लिए केवल कुछ आइटम हैं, इसलिए प्रत्येक फ्रेम में UI पाठ को बदलने का कोई मतलब नहीं है। इसलिए, हम नंबर बदलने पर ही टेक्स्ट बदलते हैं।

 //Better code Text text; GameState gameState; int collectiblesCount; void Start() { gameState = StoreProvider.Get<GameState>(); text = GetComponent<Text>(); collectiblesCount = gameState.CollectedCollectibles; } void Update() { if(collectiblesCount != gameState.CollectedCollectibles) { //This code is ran only about 5 times each level collectiblesCount = gameState.CollectedCollectibles; text.text = collectiblesCount.ToString(); } } 

यह कोड बहुत बेहतर है, खासकर अगर कार्रवाई यूआई को बदलने की तुलना में बहुत अधिक जटिल है।

यदि आप अधिक व्यापक समाधान की तलाश कर रहे हैं, तो मैं C # घटनाओं ( https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/events/ ) का उपयोग करके ऑब्जर्वर टेम्पलेट को लागू करने की सलाह देता हूं।

वैसे भी, यह अभी भी हमारे लिए पर्याप्त नहीं था, और हम पूरी तरह से सामान्यीकृत समाधान को लागू करना चाहते थे, इसलिए हमने एक पुस्तकालय बनाया जो फ्लक्स इन यूनिटी को लागू करता है। इससे एक बहुत ही सरल समाधान हुआ, जिसमें खेल की पूरी स्थिति "स्टोर" ऑब्जेक्ट में संग्रहीत होती है, और सभी UI तत्वों और अन्य घटकों को अधिसूचित किया जाता है जब राज्य बदलता है और अपडेट विधि में कोड के बिना इस परिवर्तन पर प्रतिक्रिया करता है।

तीसरा नियम: चक्र हमेशा संदेह के दायरे में होते हैं

यह बिल्कुल वही नियम है जिसका मैंने लेख के पहले भाग में उल्लेख किया था। यदि कोड में एक लूप है जो पुनरावृत्त रूप से बड़ी संख्या में तत्वों को बायपास करता है, तो लूप के प्रदर्शन को बेहतर बनाने के लिए, लेख के दोनों हिस्सों से दोनों नियमों का उपयोग करें।

चौथा नियम: फॉरन से बेहतर है

Foreach लूप लिखना बहुत आसान है, लेकिन इसे निष्पादित करने के लिए "बहुत मुश्किल" है। Foreach लूप के अंदर, Enumerator का उपयोग डेटासेट को प्रोसेस करने और मान को वापस करने के लिए किया जाता है। यह एक साधारण लूप में सूचकांकों पर पुनरावृत्ति करने से अधिक जटिल है।

इसलिए, हमारी परियोजना में, जब भी संभव हो हमने फॉरच लूप्स की जगह ले ली है:

 //Bad code foreach (GameObject obstacle in obstacles) //Better code var count = obstacles.Count; for (int i = 0; i < count; i++) { obstacles[i]; } 

लूप के लिए बड़े के साथ हमारे मामले में, यह परिवर्तन बहुत महत्वपूर्ण है। लूप के लिए एक सरल कोड को दो बार गति देता है ।

पाँचवाँ नियम: सरणियाँ सूचियों से बेहतर हैं

हमारे कोड में, हमें पता चला कि अधिकांश सूचियाँ निरंतर लंबाई की हैं, या हम अधिकतम तत्वों की गणना कर सकते हैं। इसलिए, हमने उन्हें सरणियों के आधार पर फिर से लागू किया, और कुछ मामलों में इसने डेटा पर पुनरावृत्तियों को दोगुना कर दिया।

कुछ मामलों में, सूची या अन्य जटिल डेटा संरचनाओं से बचा नहीं जा सकता है। ऐसा होता है कि आपको अक्सर तत्वों को जोड़ना या निकालना पड़ता है, और इस मामले में सूचियों का उपयोग करना बेहतर होता है। लेकिन सामान्य तौर पर, एरे को हमेशा निश्चित लंबाई की सूचियों के लिए इस्तेमाल किया जाना चाहिए ।

छठा नियम: फ्लोट संचालन वेक्टर ऑपरेशन से बेहतर हैं

यह अंतर मुश्किल से ध्यान देने योग्य है यदि आप ऐसे हजारों ऑपरेशन नहीं करते हैं, जैसा कि हमारे मामले में हुआ था, इसलिए हमारे लिए उत्पादकता में वृद्धि महत्वपूर्ण थी।

हमने समान परिवर्तन किए:

 Vector3 pos1 = new Vector3(1,2,3); Vector3 pos2 = new Vector3(4,5,6); //Bad code var pos3 = pos1 + pos2; //Better code var pos3 = new Vector3(pos1.x + pos2.x, pos1.y + pos2.y, ......); Vector3 pos1 = new Vector3(1,2,3); //Bad code var pos2 = pos1 * 2f; //Better code var pos2 = new Vector3(pos1.x * 2f, pos1.y * 2f, ......); 

सातवां नियम: वस्तुओं को सही ढंग से देखें

हमेशा इस बारे में सोचें कि क्या आपको वास्तव में GameObject.Find () पद्धति का उपयोग करने की आवश्यकता है। यह विधि भारी है और एक पागल राशि लेता है। आपको अपडेट मेथड्स में इस विधि का उपयोग कभी नहीं करना चाहिए हमने पाया कि हमारे अधिकांश फाइंड कॉल को एडिटर में सीधे लिंक से बदला जा सकता है, जो निश्चित रूप से बहुत बेहतर है।

 //Bad Code GameObject player; void Start() { player = GameObject.Find("PLAYER"); } //Better Code //Assign the reference to the player object in editor [SerializeField] GameObject player; void Start() { } 

यदि ऐसा करना असंभव है, तो कम से कम टैग्स (टैग) का उपयोग करने पर विचार करें और GameObject.FindWithTag का उपयोग करके इसके लेबल द्वारा किसी ऑब्जेक्ट की खोज करें ।

तो, सामान्य स्थिति में: सीधा लिंक> GameObject.FindWithTag ()> GameObject.Find)

आठवां नियम: केवल प्रासंगिक वस्तुओं के साथ काम करें

हमारे मामले में, यह RayCast-s (CircleCast, आदि) का उपयोग करके टकरावों को पहचानने के लिए महत्वपूर्ण था। टक्करों को पहचानने और यह तय करने के बजाय कि उनमें से कौन से कोड में महत्वपूर्ण हैं, हमने गेम ऑब्जेक्ट्स को उचित परतों में स्थानांतरित कर दिया ताकि हम केवल आवश्यक वस्तुओं के लिए टकरावों की गणना कर सकें।

यहाँ एक उदाहरण है

 //Bad Code void DetectCollision() { var count = Physics2D.CircleCastNonAlloc( position, radius, direction, results, distance); for (int i = 0; i < count; i++) { var obj = results[i].collider.transform.gameObject; if(obj.CompareTag("FOO")) { ProcessCollision(results[i]); } } } //Better Code //We added all objects with tag FOO into the same layer void DetectCollision() { //8 is number of the desired layer var mask = 1 << 8; var count = Physics2D.CircleCastNonAlloc( position, radius, direction, results, distance, mask); for (int i = 0; i < count; i++) { ProcessCollision(results[i]); } } 

नौवां नियम: लेबल का सही उपयोग करें

इसमें कोई संदेह नहीं है कि लेबल बहुत उपयोगी हैं और कोड प्रदर्शन में सुधार कर सकते हैं, लेकिन याद रखें कि ऑब्जेक्ट लेबल की तुलना करने का केवल एक सही तरीका है !

 //Bad Code gameObject.Tag == "MyTag"; //Better Code gameObject.CompareTag("MyTag"); 

दसवां नियम: कैमरे से सावधान रहें!

Camera.main का उपयोग करना इतना आसान है, लेकिन इस क्रिया का प्रदर्शन बहुत खराब है। कारण यह है कि Camera.main के लिए प्रत्येक कॉल के दृश्यों के पीछे, एकता इंजन वास्तव में FindGameObjectsWithTag () परिणाम को खोजने के लिए निष्पादित करता है, इसलिए हम पहले से ही समझते हैं कि आपको इसे अक्सर कॉल करने की आवश्यकता नहीं है, और प्रारंभ विधि में लिंक को कैशिंग करके इस समस्या को हल करना सबसे अच्छा है। या जाग।

 //Bad code void Update() { Camera.main.orthographicSize //Some operation with camera } //Better Code private Camera cam; void Start() { cam = Camera.main; } void Update() { cam.orthographicSize //Some operation with camera } 

ग्यारहवाँ नियम: स्थानीयकरण बेहतर स्थिति से बेहतर है

जहां भी संभव हो, ट्रांसफॉर्मर का उपयोग करें। गेटपॉइंट के लिए ट्रांसफॉर्मर और बसने की जगह । ट्रांसपोजिशन । प्रत्येक Transform.Position कॉल के भीतर, बहुत अधिक संचालन किया जाता है, उदाहरण के लिए, गेट्टर कॉल के मामले में वैश्विक स्थिति की गणना या सेटर कॉल के मामले में वैश्विक से स्थानीय स्थिति की गणना करना। हमारी परियोजना में, यह पता चला है कि आप Transform.Position का उपयोग करके 99% मामलों में LocalPositions का उपयोग कर सकते हैं, और आपको कोड में कोई अन्य परिवर्तन करने की आवश्यकता नहीं है।

बारहवाँ नियम: LINQ का उपयोग न करें

यह पहले से ही पहले भाग में चर्चा की गई थी। बस इसका उपयोग न करें, बस इतना ही।

तेरहवें नियम: नियमों को तोड़ने के लिए कभी-कभी डरें नहीं

कभी-कभी एक साधारण फ़ंक्शन को कॉल करना भी महंगा हो सकता है। इस स्थिति में, आपको हमेशा कोड (कोड इनलाइनिंग) को एम्बेड करना चाहिए। इसका क्या मतलब है? वास्तव में, हम केवल फ़ंक्शन से कोड लेते हैं और इसे सीधे उस स्थान पर कॉपी करते हैं जहां हम अतिरिक्त विधियों को कॉल करने से बचने के लिए फ़ंक्शन का उपयोग करना चाहते हैं।

ज्यादातर मामलों में, इसका कोई प्रभाव नहीं होगा, क्योंकि कोड का एम्बेडिंग संकलन चरण में स्वचालित रूप से किया जाता है, लेकिन कुछ नियम हैं जिनके द्वारा कंपाइलर कोड को एम्बेड करने का निर्णय लेता है (उदाहरण के लिए, वर्चुअल तरीके कभी एम्बेड नहीं होते हैं; अधिक जानकारी के लिए, देखें https: //docs.unity3d.com/Manual/BestP PracticeUnderstandingPerformanceInUnity8.html )। तो बस प्रोफाइलर खोलें, गेम को लक्ष्य डिवाइस पर लॉन्च करें और देखें कि क्या कुछ सुधार किया जा सकता है।

हमारे मामले में, कई कार्य थे जिन्हें हमने प्रदर्शन में सुधार करने के लिए एकीकृत करने का निर्णय लिया, विशेष रूप से लूप के लिए।

निष्कर्ष

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