2010-12-04 7 views
11

ऐप्पल के व्यू कंट्रोलर प्रोग्रामिंग गाइड/मैसेजिंग मेमोरी कुशलता से;didReceiveMemoryWarning और viewDidUnload

didReceiveMemoryWarning

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

viewDidUnload

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

http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/BasicViewControllers/BasicViewControllers.html

  1. didReceiveMemoryWarning के लिए, हम गैर-महत्वपूर्ण डेटा संरचनाओं पुनःआवंटन की सिफारिश कर रहे हैं। तो, महत्वपूर्ण क्या है और क्या गैर-महत्वपूर्ण है?

  2. इसके अलावा, यह रिलीज़ करने के लिए कहता है कि हमने पहले से ही VisualDnload में रिलीज़ नहीं किया था। लेकिन जब मेमोरी चेतावनी होती है तो रिसीव मेमरी चेतावनी कहा जाता है और दृश्य को अनलोड किया जा सकता है तो viewDidUnload कहा जाता है। तो, क्या यह उन कोडों को पूर्व घटना की विधि (didReceiveMemoryWarning) में ले जाने के बारे में बात कर रहा है या क्या मुझे घटनाओं के क्रम के बारे में कुछ याद आ रहा है?

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

उत्तर

16

पहले, ये सिर्फ दिशा निर्देशों, इसलिए यदि आप नहीं लगता कि यह अच्छा समझ में आता है तो यह मत करो didReceiveMemoryWarning में कुछ रिलीज करने के लिए आ रहे हैं। लेकिन ध्यान रखें कि यदि आपका आवेदन वह है जो स्मृति की चेतावनी को पहली जगह बना रहा है तो अंततः इसे ओएस द्वारा समाप्त कर दिया जाएगा।

पुन (1): गंभीर बनाम गैर-आलोचना पूरी तरह से आपकी कॉल है। केवल आप ही निर्धारित कर सकते हैं कि आप कौन सा डेटा धारण कर रहे हैं जिसे आप महत्वपूर्ण मानते हैं। यद्यपि यह शायद आपके (3) से निकटता से संबंधित होने जा रहा है, यानी, जो आसानी से पुनर्निर्मित किया जाता है वह शायद बहुत महत्वपूर्ण नहीं है।

पुन (2): मुझे नहीं लगता कि कथन कॉल के आदेश के संदर्भ में है। जैसा कि आपने महसूस किया है, सामान्य रूप से, viewDidUnloaddidReceiveMemoryWarning के बाद कॉल करने जा रहा है (didReceiveMemoryWarningviewDidUnload कहलाए जाने के कारण)। उदाहरण के तौर पर, viewDidUnload में एक निब से यूआई तत्वों को आयोजित संदर्भ जारी करेगा। तो उन्हें didReceiveMemoryWarning में भी जारी न करें।

पुन (3): यदि कोई दृश्य उपयोग में है और इस प्रकार इसे अनलोड नहीं किया जा सकता है, तो हां, जाहिर है, यह didReceiveMemoryWarning में इसे रिलीज़ करने के लिए ज़रूरी नहीं है। हालांकि, आपके पास वास्तव में ऐसे उदाहरण हो सकते हैं जहां दृश्य को अनलोड नहीं किया जा सकता है, लेकिन यह दिखाई नहीं दे रहा है (बहुत सामान्य नहीं), इस मामले में यह इसके डेटा को उतारने के लिए समझ में आता है और दृश्य फिर से दिखाई देने पर इसे फिर से बना सकता है ।

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

मेरा अपना व्यक्तिगत दृष्टिकोण आम तौर पर यह है:

  • viewDidUnload - एक निब से लोड UI तत्व के सभी संदर्भ छोड़ें। viewDidLoad में मैंने बनाए गए किसी भी UI तत्वों को रिलीज़ करें।
  • didReceiveMemoryWarning - यूआई की प्रस्तुति में उपयोग किए जाने वाले किसी भी डेटा को रिलीज़ करें जिसे मैं फिर से बना सकता हूं अगर viewDidLoad को फिर से कॉल किया जाता है (या कुछ अन्य ऐप विशिष्ट ईवेंट)। कुछ भी जारी न करें जिसे मैं संभव नहीं कर सकता।
+0

जैसा कि आप इंगित करते हैं कि वे इसे समकक्ष कहते हैं लेकिन इसे स्मृति चेतावनी के बिना नहीं कहा जाता है। – lockedscope

+0

तो आपका मतलब है "यह दिखाई देने योग्य नहीं है (बहुत सामान्य नहीं)" इसके द्वारा मोडल विचार, है ना? क्या कोई अन्य मामला है? – lockedscope

+0

एक पूर्ण स्क्रीन मोडल के तहत दृश्य एक मामला हो सकता है, हां। मुझे यकीन नहीं है कि क्या अन्य मामले हैं। – imaginaryboy

1

मेरे द्वारा बनाए जा रहे ऐप्स लेआउट क्रोम के संदर्भ में ग्राफिक्स-गहन, और डेटा से जुड़े चित्रों में मैं डाउनलोड और प्रदर्शित कर रहा हूं।

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

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