2008-12-12 8 views
34

पर मेमोरी खपत को समझना मैं ओपनजीएल ईएस का उपयोग कर 2 डी आईफोन गेम पर काम कर रहा हूं और मैं 24 एमबी मेमोरी सीमा को मारता रहता हूं - मेरा एप्लीकेशन त्रुटि कोड 101 के साथ दुर्घटनाग्रस्त रहता है। मैंने यह पता लगाने के लिए कड़ी मेहनत की कोशिश की कि स्मृति कहां जाती है , लेकिन इंस्ट्रूमेंट्स की संख्या अभी भी अपेक्षा की तुलना में काफी बड़ी है।आईफोन

मैंने मेमोरी मॉनीटर, ऑब्जेक्ट ऑलोक, लीक्स और ओपनजीएल ES उपकरणों के साथ एप्लिकेशन चलाया। जब एप्लिकेशन लोड हो जाता है, तो मुफ्त भौतिक मेमोरी 37 एमबी से 23 एमबी तक गिर जाती है, ऑब्जेक्ट ऑलोक लगभग 7 एमबी तक रहता है, लीक्स आकार में कुछ बाइट्स को दो या तीन लीक दिखाता है, गार्ट ऑब्जेक्ट साइज लगभग 5 एमबी है और मेमोरी मॉनिटर का कहना है कि आवेदन वास्तविक स्मृति के बारे में 14 एमबी लेता है। मैं परेशान हूं क्योंकि स्मृति कहां जाती है - जब मैं ऑब्जेक्ट आवंटन में खोदता हूं, तो अधिकांश स्मृति बनावट में होती है, जैसा कि मैं अपेक्षा करता हूं। लेकिन मेरे स्वयं के बनावट आवंटन काउंटर और गार्ट ऑब्जेक्ट साइज दोनों सहमत हैं कि बनावट लगभग 5 एमबी के आसपास लेनी चाहिए।

मुझे कुछ भी आवंटित करने के बारे में पता नहीं है जो उल्लेखनीय होगा, और ऑब्जेक्ट ऑलोक सहमत है। स्मृति कहां जाती है? (मैं और अधिक विवरण देने की खुशी होगी अगर यह पर्याप्त नहीं है।)


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

मैंने पहले से ही usualsuspects, यानी कोशिश की है। UIImage इसके कैशिंग के साथ, लेकिन इससे मदद नहीं मिली। क्या स्मृति उपयोग "डीबगर-स्टाइल", रेखा से लाइन को ट्रैक करने का कोई तरीका है, मेमोरी उपयोग पर प्रत्येक कथन के प्रभाव को देखते हुए?


मैं अब तक क्या पाया है:

  1. मैं वास्तव में बजे कि अधिक स्मृति का उपयोग कर। वास्तविक स्मृति खपत को मापना आसान नहीं है, लेकिन बहुत सारी गिनती के बाद मुझे लगता है कि स्मृति खपत वास्तव में उच्च है। मेरी गलती।

  2. मुझे उपयोग की गई स्मृति को मापने का कोई आसान तरीका नहीं मिला। मेमोरी मॉनिटर नंबर सटीक हैं (ये वे संख्याएं हैं जो वास्तव में मायने रखती हैं), लेकिन मेमोरी मॉनीटर आपको यह नहीं बता सकता कि वास्तव में स्मृति कहां जाती है। ऑब्जेक्ट ऑलोक टूल वास्तविक स्मृति उपयोग को ट्रैक करने के लिए लगभग बेकार है। जब मैं बनावट बनाता हूं, आवंटित स्मृति काउंटर थोड़ी देर के लिए चला जाता है (स्मृति में बनावट को पढ़ना), फिर बूंदें (बनावट डेटा को ओपनजीएल, फ्रीिंग में पास करना)। यह ठीक है, लेकिन हमेशा नहीं होता है - कभी-कभी मेमोरी उपयोग ओपनजीएल पर बना दिया गया है और "मेरी" मेमोरी से मुक्त होने के बाद भी उच्च रहता है। इसका मतलब है कि ऑब्जेक्ट ऑलोक टूल द्वारा दिखाए गए स्मृति की कुल राशि असली कुल मेमोरी खपत से छोटी है, लेकिन असली खपत शून्य बनावट (real – textures < object alloc < real) से बड़ी है। जाओ पता लगाओ।

  3. मैं प्रोग्रामिंग गाइड को गलत तरीके से पढ़ता हूं। 24 एमबी की स्मृति सीमा बनावट और सतहों पर लागू होती है, न कि संपूर्ण आवेदन। वास्तविक लाल रेखा थोड़ा आगे है, लेकिन मुझे कोई कठोर संख्या नहीं मिल सका। सर्वसम्मति यह है कि 25-30 एमबी छत है।

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

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

कृपया ध्यान दें कि ये केवल मेरे विचार हैं जिन्हें अधिक सटीक नहीं होना चाहिए। अगर मुझे इस विषय पर कुछ और कहना है, तो मैं सवाल अपडेट कर दूंगा। यदि कोई व्यक्ति जो इस मुद्दे को समझता है, तो मैं सवाल खुलता रहूंगा, क्योंकि ये सब कुछ और कामकाज और अनुमान हैं।

उत्तर

11

मैं अत्यधिक शक इस उपकरण में एक बग है।

पहले, इस blog post by Jeff Lamarche about openGL textures पढ़ें:

  • के कारण लीक बिना
  • कैसे "छोटे" छवियों की समझ देता है कैसे बनावट लोड करने के लिए एक सरल उदाहरण है, एक बार वे में लोड किए गए हैं मिलता है OpenGL, वास्तव में स्मृति के "एक बहुत" का उपयोग

अंश:

+०१२३५१६४१०

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

दूसरा, उपकरण के साथ बनावट स्मृति को डीबग करना संभव है। दो प्रोफाइलिंग कॉन्फ़िगरेशन हैं: OpenGL ES Analyzer और OpenGL ES Driver। आपको इन्हें डिवाइस पर चलाने की आवश्यकता होगी, क्योंकि सिम्युलेटर ओपनजीएल का उपयोग नहीं करता है। बस एक्सकोड से उत्पाद-> प्रोफ़ाइल चुनें और एक बार इंस्ट्रूमेंट लॉन्च होने के बाद इन प्रोफाइलों को देखें। - इस स्पष्ट रूप से इस समस्या का कारण होगा

  • चेक है कि आप नहीं leaking memory कर रहे हैं:


    है कि ज्ञान, यहाँ के साथ सशस्त्र कि मुझे क्या करना होता है।

  • सुनिश्चित करें कि आपके accessing autoreleased memory - क्रैश का सामान्य कारण सुनिश्चित करें।
  • एक अलग परीक्षण ऐप बनाएं और लोडिंग बनावट (और संयोजन में) के साथ खेलने के लिए यह पता लगाने के लिए कि कौन सी बनावट (या संयोजन) समस्या का कारण बन रही है।

अद्यतन: अपने प्रश्न के बारे में सोच के बाद, मैं Apple's OpenGL ES Programming Guide पढ़ रहा है और यह बहुत अच्छा जानकारी नहीं है। अत्यधिक सिफारिशित!

+0

लेख का लिंक मर चुका है, कोई विचार जहां मुझे यह जानकारी मिल सकती है? – cheeesus

+0

मैंने लेख के बारे में कुछ बातों के बारे में कुछ जानकारी जोड़ा। मैंने मृत लिंक भी हटा दिया। – bentford

+0

मैं ओपनजीएल ES विश्लेषक और ओपनजीएल ईएस ड्राइवर कॉन्फ़िगरेशन देख रहा हूं, और मुझे प्रयुक्त बनावट मेमोरी की मात्रा नहीं मिल रही है। किसी आईओएस ऐप के लिए वास्तविक प्रयुक्त ओपनजीएल बनावट मेमोरी कैसे प्राप्त होती है? –

0

यह विशेष रूप से आपकी सहायता नहीं करता है, लेकिन यदि आपको लगता है कि मेमोरी टूल आपको आवश्यक सभी डेटा प्रदान नहीं करते हैं, तो कृपया bugreport.apple.com पर एक बग दर्ज करें। अपने ऐप की एक प्रति संलग्न करें और आपके विश्लेषण से उपकरण कैसे कम हो रहे हैं और ऐप्पल देखेंगे कि वे टूल को बेहतर बना सकते हैं या नहीं। धन्यवाद!

2

Hrmm, कि नहीं बहुत सी जानकारियां है, लेकिन अगर लीक आप प्रदर्शित नहीं करता है जहां लीक कर रहे हैं, वहाँ दो महत्वपूर्ण विकल्प हैं:

[i] लीक लीक याद [ii] स्मृति नहीं है वास्तव में लीक किया जा रहा है

फिक्सिंग [i] काफी कठिन है, लेकिन एरिक अल्बर्ट ने कहा कि ऐप्पल के साथ एक बग रिपोर्ट दर्ज करने में मदद मिलेगी। [ii] का अर्थ है कि आप जिस मेमोरी का उपयोग कर रहे हैं वह अभी भी कहीं भी सुलभ है, लेकिन शायद आप इसके बारे में भूल गए हैं। पुरानी प्रविष्टियों को फेंकने के बिना, कोई सूचियां बढ़ रही हैं? क्या कोई बफर realloc() ed बहुत कर रहे हैं?

+0

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

3

एक तरीका है कोड को टिप्पणी करना शुरू करना और यह देखने के लिए कि बग अभी भी होता है या नहीं। हां यह कठिन और प्राथमिक है, लेकिन अगर आपको पता था कि बग कहां था तो यह मदद कर सकता है।

यह कहाँ क्रैश हो रहा है क्यों यह क्रैश हो रहा है, आदि है

+0

दुर्भाग्यवश यह काम नहीं करता है, मैं बस आवंटन पर टिप्पणी नहीं कर सकता हूं और आशा करता हूं कि एप्लिकेशन नोटिस नहीं करेगा। – zoul

+0

असल में, यह एक बुरी सलाह नहीं है। यदि एप्लिकेशन अधिक से अधिक स्मृति का उपभोग करता है, तो स्मृति आवंटन कोड के हिस्सों पर टिप्पणी करना संभव है और संभावित संदिग्धों को एक वर्ग या रेखा तक सीमित करना संभव है। – zoul

2

वर्ष 2012 के बाद यह देख उन लोगों के लिए:

स्मृति वास्तव में डिवाइस के भौतिक स्मृति में लोड वीएम ट्रैकर साधन में निवासी मेमोरी है।

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

कृपया डब्ल्यूडब्ल्यूडीसी 2012 सत्र 242 आईओएस ऐप प्रदर्शन देखें: ऐप्पल से जानकारी प्राप्त करने के लिए मेमोरी।