सार्वजनिक स्थैतिक क्षेत्र का उपयोग, अच्छा प्रोग्रामिंग अभ्यास/तेज़?

Question

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

उदाहरण के लिए कक्षा कैमरे में एक एक्स और वाई स्थिति है जो परिभाषित करता है कि उपयोगकर्ता किस मानचित्र को देख रहा है और स्क्रीन पर क्या खींचा जाना चाहिए। वर्तमान में मैं 50 000 इकाइयों के साथ बेंचमार्किंग कर रहा हूं और मेरे पास उन्हें आकर्षित करने के लिए निम्नलिखित विकल्प हैं।

1: प्रत्येक इकाई में कैमरे के उदाहरण के लिए एक संदर्भ स्टोर और getX() और Gety() फोन जब यह तैयार किया जाना चाहिए:

public void paint() 
{ 
    paint(x - camera.getX(), y - camera.getY()); 
} 

2: तर्क के रूप में कैमरे के निर्देशांक की आपूर्ति

public void paint(int cameraX, int cameraY) 
{ 
    paint(x - cameraX, y - cameraY); 
} 

3: कैमरा वर्ग के x और y चर स्थिर करें:

public void paint() 
{ 
    paint(x - Camera.x, y - Camera.y); 
} 

प्रत्येक इकाई जब यह तैयार किया जाना चाहिए करने के लिए

मुझे दिलचस्पी है कि आमतौर पर सबसे अच्छा समाधान के रूप में देखा जाता है और यदि यह प्रदर्शन को प्रभावित करता है। शायद ऐसा करने के और तरीके हैं मैंने अभी तक नहीं सोचा है?

धन्यवाद!

Answer 1

मैं तुम्हें एक पेंटर वर्ग बना सकते हैं और निम्न कार्य सुझाव देंगे:

public void paint(Painter painter) 
{ 
    painter.draw(x, y, unit_sprite); 
} 

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

यह एक अच्छा विचार क्यों है?

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

अपने प्रस्तावित समाधान के बारे में:

1. अपने वस्तु पर कैमरे के लिए एक संदर्भ भंडारण मान लिया गया है वहाँ केवल कभी एक कैमरा होगा। क्या होगा यदि आप एक विभाजित दृश्य की तरह कुछ लागू करते हैं? यह असंभव हो सकता है, लेकिन संदर्भ को संग्रहीत करके आप अनावश्यक रूप से अपने आप को एक परिप्रेक्ष्य में लॉक कर सकते हैं।
2. चर को विभाजित करने में समस्या यह है कि तर्कसंगत रूप से दो टुकड़े एक आइटम हैं। इससे यह पता लगाना मुश्किल हो जाता है कि क्या हो रहा है, यदि आपको किसी दिन अधिक पैरामीटर की आवश्यकता होती है, तो समस्याएं पैदा होती हैं, और उस इकाई को जानकारी भी देती है जिसकी वास्तव में आवश्यकता नहीं होती है।
3. यह # 1 की समान समस्याओं से ग्रस्त है, यह आपको एक ही कैमरे में स्थानांतरित करता है जो पूरे स्थान पर उपयोग किया जा रहा है। कैमरे का उपयोग कैसे किया जाता है यह परिभाषित करने के लिए इकाई जिम्मेदार नहीं होनी चाहिए।

   अंतर लगभग कुछ भी नहीं होने जा रहा है:

प्रदर्शन के बारे में

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

सामान्य रूप में स्थैतिक चर के बारे में:

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

कुछ दिशानिर्देश:

1. आप पाते हैं अपने आप को, एक वस्तु के अंदर डेटा का उपयोग करने की आवश्यकता होगी, तो अर्थात एक्स, वाई मूल्य विचार करें कि क्या आप के बजाय उस वस्तु बता कुछ एक विधि लागू किया जा करने के लिए करना चाहिए। अर्थात। पूछो मत पूछो।
2. यदि कोई ऑब्जेक्ट (पेंटर की तरह) केवल किसी ऑब्जेक्ट द्वारा किसी विशेष कार्य के लिए उपयोग किया जाता है तो यह पैरामीटर होना चाहिए जो सदस्य चर नहीं है।

Answer 2

यदि आपके पास हर समय केवल एक कैमरा है, तो मैं तीसरा तरीका चुनूंगा। अन्यथा मैं दूसरा रास्ता चुनूंगा।

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

Answer 3

कुल मिलाकर दूसरे को एक अच्छा संतुलन प्रदान करना चाहिए; यह भी सुनिश्चित करेगा कि जब आप अनुमान लगाते हैं तो आप कैमरे के संदर्भ में गलती से संदर्भ नहीं डालते हैं, या आप राज्य के स्थिर क्षेत्रों के साथ संघर्ष में नहीं भागते हैं।

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

Answer 4

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

Answer 5

आप अपने संदर्भ में बेंचमार्क के लिए है सुनिश्चित करने के लिए करता हूँ, लेकिन यहाँ मेरा अनुभव है:

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

Answer 6

बस समय और देखें।

long startTime = System.currentTimeMillis(); 
for(int i=0; i<1000000; i++){ 
    // Call your code 

} 
System.out.println("Total time " + (System.currentTimeMillis() - startTime) + " ms"); 

मेरा अनुमान है कि जेआईटी मतभेदों का ख्याल रखेगा और वे सभी लगभग बराबर होंगे। अपने आप को समय के लिए कोई विकल्प नहीं है। इसके अतिरिक्त, मैं ऐप को प्रोफाइल करने की सलाह दूंगा और देख सकता हूं कि इस तरह के माइक्रो प्रदर्शन tweaks करने से पहले अपने ऐप को चलाने के दौरान समय कहाँ बिताया जाता है।

Answer 7

पूर्णांक वाउल का उपयोग करके m.server पर मिलीसेकंड की गणना करें और गणना करें।

जो कि किसी भी पुस्तक को देखे बिना अतिथि है।

Answer 8

मेरे पास एक ही कारण (एक बड़ा जावा गेम) के लिए एक ही प्रश्न था।

मैंने एक चर के लिए दो तरीकों का परीक्षण किया है जो अंतिम फ्रेम के बाद से समय का प्रतिनिधित्व करता है, यह हर फ्रेम पर प्रत्येक ऑब्जेक्ट के हर उदाहरण में उपयोग किया जाता है।

एक तरीका एक स्थैतिक है, दूसरा तरीका यह है कि मुख्य लूप से प्रत्येक ऑब्जेक्ट के प्रत्येक उप-वर्ग में तर्क के रूप में भिन्न होता है। http://i.stack.imgur.com/WtSue.png

मैं हर तरह 3 बार परीक्षण किया है:

यहाँ मेरी परिणाम हैं। जैसा कि आप देख सकते हैं कि परिणाम 130 और 210 के बीच छोड़कर बहुत समान हैं, मैं वास्तव में क्यों नहीं समझा सकता हूं।