मेमोरी क्रैश को हल करने के लिए कैसे करें

Question

मैं एक ऐसा एप्लिकेशन बना रहा हूं जिसमें एकाधिक एनिमेशन हैं। 50 पृष्ठ हैं और प्रत्येक पृष्ठ पर एक अलग एनीमेशन है और प्रत्येक एनीमेशन कई छवियों का उपयोग करता है।

मैं UIPresentModelViewController का उपयोग कर का उपयोग कर छवियों को बदलने के लिए उपयोग कर रहा हूं।

जब मैं लगातार इस संदेश के साथ अनुप्रयोग क्रैश स्वाइप: -

Program received signal: “0”. 
Data Formatters temporarily unavailable, will re-try after a 'continue'. 

(Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib") 

मैं एक बहुत खोज की, लेकिन इस मुद्दे पर किसी भी उचित समाधान नहीं मिल सका।

Answer 1

बस अपने कोड है कि आप हर बार नए दृश्य जोड़कर कुछ गलती कर लेकिन इसे जारी करने की भूल कर रहे हैं के भीतर जाँच ...

Answer 2

आप (और शायद पोस्ट) स्टैक ट्रेस को देखने के लिए जब आप दुर्घटना की जरूरत है। और कोड जो छवि को बदलता है। यह मेमोरी ब्लोट की तरह लगता है (उसमें कोई वास्तविक रिसाव नहीं है जो अभी भी स्मृति का जिक्र कर रहा है)। विश्लेषण मेनू आइटम कुछ पकड़ सकता है (और आपको इसे निश्चित रूप से चलाया जाना चाहिए), लेकिन आपको आवंटन उपकरण चलाने और ढेर चेक देखने की आवश्यकता हो सकती है। अधिक के लिए http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ देखें।

Answer 3

यह मेरे लिए एक स्टैक ओवरफ्लो जैसा लगता है। प्रोजेक्ट की सी/सी ++ भाषा सेटिंग्स के "अन्य सी ध्वज" खंड में "-फस्टैक-चेक" के लिए ध्वज जोड़ें और देखें कि क्या यह किसी अनचाहे रिकर्सन को चालू करता है या नहीं।

Answer 4

सिग्नल 0 आमतौर पर बहुत अधिक मेमोरी का उपयोग करते हुए ऐप के रूप में स्मृति कम होने के कारण होता है। जांचें कि स्मृति चेतावनी विधि कहलाती है या नहीं।

डेटा फ़ॉर्मेटर thingy लोड की वजह से वहाँ इसे लोड करने के लिए पर्याप्त स्मृति नहीं है हो सकता है विफल रही है ..

Answer 5

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

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

ओएस को स्मृति प्रबंधित करने के लिए, यह दृश्यों को अनलोड कर सकता है और आवश्यकतानुसार उन्हें पुनः लोड कर सकता है। जब यह किया जाता है, तो विधियों को देखते हैं DidUnload, loadView, और viewDidLoad कहा जाता है।

viewDidUnload:

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

loadView:

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

चेक UIView कक्षा संदर्भ -

viewDidLoad:

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

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

Answer 6

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

Answer 7

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

गेम बनाने के लिए लोकप्रिय cocos2d या अन्य ढांचे में देखें, क्योंकि वे केवल UIKit की तुलना में एनिमेशन के लिए अधिक कुशल होंगे।

Answer 8

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