2010-04-07 12 views
10

मैं सुनता रहता हूं कि एंड्रॉइड अनुप्रयोगों को कचरा कलेक्टर पर वर्कलोड को कम करने के लिए बनाए गए ऑब्जेक्ट्स की संख्या को सीमित करने का प्रयास करना चाहिए। यह समझ में आता है कि आप सीमित स्मृति पदचिह्न पर नज़र रखने के लिए बड़ी संख्या में ऑब्जेक्ट्स बनाना नहीं चाहते हैं, उदाहरण के लिए पारंपरिक सर्वर एप्लिकेशन पर कुछ सेकंड के भीतर 100,000 ऑब्जेक्ट्स बनाए गए हैं, इसकी अनदेखी नहीं की जाएगी।एंड्रॉइड जीसी प्रदर्शन के कारण कोडिंग शैली बदलना, कितना दूर है?

समस्या यह है कि मुझे यह कितना दूर लेना चाहिए? मैंने एंड्रॉइड अनुप्रयोगों के कई उदाहरणों को स्थिर राज्य पर निर्भर करते हुए देखा है, "गति चीजें ऊपर"। क्या दर्जनों से सैकड़ों तक एकत्रित कचरे होने की आवश्यकता वाले मामलों की संख्या में वृद्धि करना वास्तव में उस अंतर को बड़ा बनाता है? मैं कल्पना कर सकता हूं कि अब मेरी कोडिंग शैली को बदलने के लिए सैकड़ों हजारों ऑब्जेक्ट्स बन गए हैं जैसे कि आपके पास एक पूर्ण उड़ाए गए जावा-ईई सर्वर पर हो सकता है लेकिन स्थिर स्थिति के समूह पर निर्भर करता है (माना जाता है) ऑब्जेक्ट्स की संख्या को कचरा इकट्ठा करने के लिए कम करता है अजीब।

प्रदर्शन एंड्रॉइड ऐप्स बनाने के लिए अपनी कोडिंग शैली को बदलने के लिए वास्तव में कितना आवश्यक है?

उत्तर

10

"आवंटन से बचें" सलाह आम तौर पर गेम लूप के संबंध में होती है। वीएम को कचरा इकट्ठा करने के लिए रोकना है, और आप नहीं चाहते हैं कि आपका गेम 30fps पर एनिमेट हो रहा हो। यदि आप किसी भी वस्तु को आवंटित नहीं करते हैं, तो वीएम को मुफ्त मेमोरी में कचरा इकट्ठा करने की आवश्यकता नहीं होगी। यदि आपके पास ऐसा गेम है जिसे उपयोगकर्ता के दृश्यमान हिचकी के बिना चलाने की आवश्यकता है, तो आपको आवंटन को कम करने या समाप्त करने के लिए प्रासंगिक भागों में कोड को बदलने पर विचार करना चाहिए।

यदि आप ऐसे ऐप बना रहे हैं जो व्यंजनों को दिखाता है या फ़ोटो दिखाता है, तो मैं इसके बारे में चिंता नहीं करता - जीसी हिचकुप ऐसा कुछ नहीं है जिसे उपयोगकर्ता संभवतः नोटिस करेगा।

दलविक जीसी (जैसे पीढ़ीगत संग्रह) में भविष्य में सुधार इस मुद्दे को कम करना चाहिए।

+3

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

+1

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

4

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

संबंधित मुद्दे