2008-08-09 13 views
118

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

release, retain और autorelease काम और उनके उपयोग के बारे में सम्मेलन क्या हैं?

(या कि नाकाम रहने, तुम क्या पढ़ा है जो मदद की तुम इसे पाने के?)

उत्तर

148

चलिए retain और release से शुरू करते हैं; एक बार जब आप बुनियादी अवधारणाओं को समझते हैं तो autorelease वास्तव में केवल एक विशेष मामला है।

कोको में, प्रत्येक ऑब्जेक्ट ट्रैक करता है कि कितनी बार संदर्भित किया जा रहा है (विशेष रूप से, NSObject बेस क्लास इसे लागू करता है)। किसी ऑब्जेक्ट पर retain पर कॉल करके, आप यह कह रहे हैं कि आप इसकी संदर्भ गणना एक करके करना चाहते हैं। release पर कॉल करके, आप उस ऑब्जेक्ट को बताते हैं जिसे आप इसे छोड़ रहे हैं, और इसकी संदर्भ गणना कम हो गई है। यदि, release पर कॉल करने के बाद, संदर्भ संख्या अब शून्य है, तो उस ऑब्जेक्ट की स्मृति सिस्टम द्वारा मुक्त हो जाती है।

यह malloc और free से भिन्न मूल तरीका यह है कि किसी दिए गए ऑब्जेक्ट को सिस्टम के अन्य हिस्सों के बारे में चिंता करने की आवश्यकता नहीं है क्योंकि आपने स्मृति को मुक्त कर दिया है। मान लें कि सभी नियमों के अनुसार खेल रहे हैं और बनाए/जारी कर रहे हैं, जब कोड का एक टुकड़ा बरकरार रहता है और फिर ऑब्जेक्ट को जारी करता है, तो कोड का कोई भी अन्य भाग भी ऑब्जेक्ट का संदर्भ नहीं देगा।

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

उदाहरण:

NSString* s = [[NSString alloc] init]; // Ref count is 1 
[s retain];        // Ref count is 2 - silly 
             // to do this after init 
[s release];       // Ref count is back to 1 
[s release];       // Ref count is 0, object is freed 
अब autorelease के लिए

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

यह ध्यान रखना महत्वपूर्ण है कि (फिर से, सम्मेलन द्वारा) सभी ऑब्जेक्ट सृजन कक्षा विधियां एक ऑटोरेलेज्ड ऑब्जेक्ट लौटाती हैं। उदाहरण के लिए, निम्नलिखित उदाहरण में, परिवर्तनीय "एस" की संदर्भ संख्या 1 है, लेकिन ईवेंट लूप पूर्ण होने के बाद, इसे नष्ट कर दिया जाएगा।

NSString* s = [NSString stringWithString:@"Hello World"]; 

आपको लगता है कि स्ट्रिंग पर मस्ती करना चाहते हैं, तो आप retain स्पष्ट रूप से कॉल करने के लिए स्पष्ट रूप से release काम पूरा हो जाने आवश्यकता होगी, और फिर इसे।

पर विचार करें कोड की निम्न (बहुत काल्पनिक) बिट, और आप एक स्थिति है जहाँ autorelease आवश्यक है देखेंगे:

- (NSString*)createHelloWorldString 
{ 
    NSString* s = [[NSString alloc] initWithString:@"Hello World"]; 

    // Now what? We want to return s, but we've upped its reference count. 
    // The caller shouldn't be responsible for releasing it, since we're the 
    // ones that created it. If we call release, however, the reference 
    // count will hit zero and bad memory will be returned to the caller. 
    // The answer is to call autorelease before returning the string. By 
    // explicitly calling autorelease, we pass the responsibility for 
    // releasing the string on to the thread's NSAutoreleasePool, which will 
    // happen at some later time. The consequence is that the returned string 
    // will still be valid for the caller of this function. 
    return [s autorelease]; 
} 

मुझे पता है यह सब एक सा भ्रामक है - कुछ बिंदु पर है, हालांकि, यह क्लिक करेगा। आपको जाने के लिए यहां कुछ संदर्भ दिए गए हैं:

  • Apple's introduction स्मृति प्रबंधन के लिए।
  • Cocoa Programming for Mac OS X (4th Edition), हारून हिलेगैस द्वारा - बहुत सारे महान उदाहरणों के साथ एक बहुत अच्छी तरह लिखित पुस्तक। यह एक ट्यूटोरियल की तरह पढ़ता है।
  • यदि आप वास्तव में डाइविंग कर रहे हैं, तो आप Big Nerd Ranch पर जा सकते हैं। यह ऊपर वर्णित पुस्तक के लेखक हारून हिलेगलेस द्वारा संचालित एक प्रशिक्षण सुविधा है। मैंने कई साल पहले कोको कोर्स के परिचय में भाग लिया था, और यह सीखने का एक शानदार तरीका था।
+8

आपने लिखा: "autorelease को कॉल करके, हम अस्थायी रूप से संदर्भ गणना को टक्कर देते हैं"। मुझे लगता है कि यह गलत है; ऑटोरेलीज केवल भविष्य में ऑब्जेक्ट को रिलीज़ करने के लिए चिह्नित करता है, यह रेफ गिनती में वृद्धि नहीं करता है: http://cocoadev.com/index.pl?AutoRelease – LKM

+2

"अब ऑटोरेलीज के लिए। Autorelease को सुविधाजनक (और कभी-कभी जरूरी) थोड़ी देर के बाद इस वस्तु को मुक्त करने के लिए सिस्टम को बताने का तरीका। " लीड-इन वाक्य के रूप में, यह गलत है। यह सिस्टम को "मुक्त [इसे] ऊपर" नहीं बताता है, यह इसे बनाए रखने की गिनती को कम करने के लिए कहता है। – mmalc

+0

इसी तरह, आपका अंतिम कोड उदाहरण NSString को कई बार रिलीज़ करता है - एक बार एनएसयूटोरोज़ी पूल में ऑटोरेलीज के माध्यम से और सीधे रिलीज के माध्यम से :( – rpetrich

6

ऑब्जेक्टिव-सी Reference Counting का उपयोग करता है, जिसका अर्थ है प्रत्येक वस्तु एक संदर्भ संख्या अधिक है। जब कोई ऑब्जेक्ट बनाया जाता है, तो इसकी संदर्भ गणना "1" होती है। बस बोलते हुए, जब किसी ऑब्जेक्ट को संदर्भित किया जाता है (यानी, कहीं भी संग्रहीत), यह "बनाए रखा" हो जाता है जिसका अर्थ है कि इसकी संदर्भ संख्या एक से बढ़ी है। जब किसी वस्तु की आवश्यकता नहीं होती है, तो यह "जारी" होता है जिसका अर्थ है कि इसकी संदर्भ संख्या एक से कम हो जाती है।

जब कोई ऑब्जेक्ट संदर्भ संदर्भ 0 है, तो ऑब्जेक्ट मुक्त हो जाता है। यह मूल संदर्भ गिनती है।

कुछ भाषाओं के लिए, संदर्भ स्वचालित रूप से बढ़ जाते हैं और घटते हैं, लेकिन उद्देश्य-सी उन भाषाओं में से एक नहीं है। इस प्रकार प्रोग्रामर बनाए रखने और जारी करने के लिए ज़िम्मेदार है।

एक विधि लिखने के लिए एक विशिष्ट तरीका है:

id myVar = [someObject someMessage]; 
.... do something ....; 
[myVar release]; 
return someValue; 

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

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

ऊपर कोड ले रहा है, तो आप को फिर से लिखने कर सकते हैं कह कर यह छोटी और पढ़ने में आसान होने के लिए:

id myVar = [[someObject someMessage] autorelease]; 
... do something ...; 
return someValue; 

क्योंकि वस्तु autoreleased है, इसलिए अब हम स्पष्ट रूप से उस पर "रिलीज" कॉल करने के लिए की जरूरत है। ऐसा इसलिए है क्योंकि हम जानते हैं कि कुछ ऑटोरेलीज पूल बाद में हमारे लिए यह करेंगे।

उम्मीद है कि इससे मदद मिलती है। विकिपीडिया लेख संदर्भ गणना के बारे में बहुत अच्छा है। autorelease pools can be found here के बारे में अधिक जानकारी। यह भी ध्यान रखें कि यदि आप मैक ओएस एक्स 10.5 और बाद में निर्माण कर रहे हैं, तो आप कचरा संग्रह सक्षम करने के लिए एक्सकोड को बता सकते हैं, जिससे आप पूरी तरह से बनाए/रिलीज़/ऑटोरेलीज को अनदेखा कर सकते हैं।

+2

यह गलत है। दिखाए गए उदाहरणों में से कुछ में ऑब्जेक्ट रिलीज या ऑटोरलीज भेजने की आवश्यकता नहीं है। – mmalc

6

जोशुआ (# 65 9 1) - मैक ओएस एक्स 10.5 में कचरा संग्रह सामग्री बहुत अच्छी लगती है, लेकिन आईफोन के लिए उपलब्ध नहीं है (या यदि आप चाहते हैं कि आपका ऐप मैक ओएस एक्स के प्री -10.5 संस्करणों पर चलाना चाहे) ।

इसके अलावा, यदि आप लाइब्रेरी लिख रहे हैं या फिर कुछ उपयोग किया जा सकता है, तो जीसी मोड का उपयोग करके जीसी मोड का उपयोग करके कोड का उपयोग करने वाले किसी भी व्यक्ति को लॉक कर दिया जाता है, इसलिए जैसा कि मैं इसे समझता हूं, कोई भी व्यापक रूप से पुन: प्रयोज्य कोड लिखने की कोशिश कर रहा है मैन्युअल रूप से स्मृति प्रबंधन के लिए जाने के लिए।

+2

जीसी और संदर्भ गिनती दोनों का समर्थन करने वाले हाइब्रिड फ्रेमवर्क को लिखना पूरी तरह से संभव है। – mmalc

4

NilObject का उत्तर एक अच्छी शुरुआत है। आईफोन पर मैन्युअल मेमोरी प्रबंधन () से संबंधित कुछ पूरक जानकारी यहां दी गई है।

आप व्यक्तिगत रूप से alloc/init एक वस्तु है, यह 1. का एक संदर्भ गिनती आप इसे बाद सफाई जब यह अब जरूरत है, या तो [foo release] या [foo autorelease] फोन करके के लिए जिम्मेदार हैं के साथ आता है। रिलीज इसे तुरंत साफ कर देता है, जबकि autorelease ऑब्जेक्ट को ऑटोरेलीज पूल में जोड़ता है, जो बाद में इसे स्वचालित रूप से रिलीज़ कर देगा।

autorelease जब आप एक विधि प्रश्न में वस्तु (ताकि आप नहीं मैन्युअल रूप से इसे जारी कर सकते हैं अन्यथा आप एक शून्य वस्तु लौट जाएगा) वापस जाने के लिए की जरूरत है कि के लिए मुख्य रूप है, लेकिन आप नहीं करना चाहते हैं इसे पकड़ो, या तो।

आप एक वस्तु जहां alloc/init फोन नहीं किया इसे पाने के लिए प्राप्त - उदाहरण के लिए:

foo = [NSString stringWithString:@"hello"]; 

लेकिन आप इस वस्तु के लिए पर-मस्ती करना चाहते हैं, तो आप कॉल करने की आवश्यकता [foo बनाए रखने] । अन्यथा, यह संभव है कि इसे autoreleased मिलेगा और आप एक शून्य संदर्भ पर होंगे (जैसा कि यह ऊपर stringWithString उदाहरण में होगा)। जब आपको इसकी आवश्यकता नहीं है, तो [foo release] पर कॉल करें।

5

Matt Dillard wrote:

वापसी [[रों autorelease] रिहाई];

Autorelease ऑब्जेक्ट को बनाए रखता है। Autorelease बस इसे बाद में जारी करने के लिए कतार में डालता है। आप वहां एक रिलीज स्टेटमेंट नहीं चाहते हैं।

8

यदि आप डेस्कटॉप के लिए कोड लिख रहे हैं और आप मैक ओएस एक्स 10.5 को लक्षित कर सकते हैं, तो आपको कम से कम उद्देश्य-सी कचरा संग्रह का उपयोग करना चाहिए। यह वास्तव में आपके अधिकांश विकास को सरल बना देगा - यही कारण है कि ऐप्पल ने इसे पहले स्थान पर बनाने और इसे अच्छी तरह से करने में सभी प्रयास किए।

स्मृति प्रबंधन नियमों का सवाल है जब जी सी का उपयोग नहीं:

  • आप +alloc/+allocWithZone:, +new, -copy या -mutableCopy या यदि आप -retain एक वस्तु का उपयोग कर एक नई वस्तु बनाने हैं, तो आप इसके बारे में स्वामित्व ले जा रहे हैं और चाहिए सुनिश्चित करें कि यह -release भेजा गया है।
  • आप किसी अन्य तरीके से एक वस्तु प्राप्त करते हैं, आप नहीं यह के स्वामी हैं और सुनिश्चित नहीं चाहिए यह -release भेजा जाता है।
  • क्या आप वाकई एक वस्तु भेज दिया जाता है -release आप भेज सकते हैं या तो है कि अपने आप को, या आप वस्तु -autorelease और वर्तमान autorelease पूल भेज सकते हैं बनाना चाहते हैं भेज देंगे -release (एक बार प्राप्त -autorelease प्रति) जब पूल बहा दिया जाता है ।

आमतौर -autorelease सुनिश्चित करना है कि वस्तुओं वर्तमान घटना की लंबाई के लिए रहते हैं का एक तरीका के रूप में इस्तेमाल किया जाता है, लेकिन बाद में साफ कर रहे हैं, के रूप में वहाँ एक autorelease पूल कि कोको के कार्यक्रम प्रसंस्करण चारों ओर से घेरे है। कोको में, यह दूर एक कॉलर को ऑब्जेक्ट्स लौटने के लिए अधिक आम है, जो ऑटोज़ेटेड हैं, कॉलर को खुद को रिलीज़ करने की आवश्यकता है।

10

यदि आप बनाए रखने/रिलीज की प्रक्रिया को समझते हैं तो दो सुनहरे नियम हैं जो कि कोको प्रोग्रामर स्थापित करने के लिए "डुह" स्पष्ट हैं, लेकिन दुर्भाग्य से नए लोगों के लिए यह स्पष्ट रूप से स्पष्ट रूप से लिखा गया है।

  1. एक समारोह जो एक वस्तु देता है alloc, create या copy अपने नाम में तो है, तो वस्तु आपकी है। जब आप इसके साथ समाप्त हो जाते हैं तो आपको [object release] पर कॉल करना होगा। या CFRelease(object), यदि यह कोर-फाउंडेशन ऑब्जेक्ट है।

  2. यदि इसमें इन शब्दों में से कोई एक नाम नहीं है तो वस्तु किसी और से संबंधित है। यदि आप ऑब्जेक्ट को अपने फ़ंक्शन के अंत के बाद रखना चाहते हैं तो आपको [object retain] पर कॉल करना होगा।

आपको अपने आप को बनाए गए कार्यों में इस सम्मेलन का पालन करने के लिए अच्छी तरह से सेवा दी जाएगी।

(नाइटपिकर्स: हां, दुर्भाग्यवश कुछ एपीआई कॉल हैं जो इन नियमों के अपवाद हैं लेकिन वे दुर्लभ हैं)। cocoadev पर अच्छी जानकारी के

+11

यह अपूर्ण और गलत है। मैं यह समझने में असफल रहा हूं कि क्यों लोग प्रासंगिक दस्तावेज को इंगित करने के बजाय नियमों को दोहराने का प्रयास करते हैं: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html – mmalc

+4

कोर फाउंडेशन नियम विशेष रूप से कोको के उन लोगों से अलग हैं; http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html – mmalc

+1

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

6

हमेशा की तरह, जब लोगों को फिर से शब्द के लिए संदर्भ सामग्री वे लगभग हमेशा कुछ गलत की कोशिश कर रहा शुरू करने या एक अधूरा विवरण प्रदान करें।

ऐप्पल Memory Management Programming Guide for Cocoa में कोको की मेमोरी प्रबंधन प्रणाली का पूरा विवरण प्रदान करता है, जिसके अंत में Memory Management Rules का एक संक्षिप्त लेकिन सटीक सारांश है।

+0

आपके लिंक टूटे हैं। –

+0

आज़माएं: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html –

+1

और सारांश नियमों के लिए: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt /Articles/mmRules.html#//apple_ref/doc/uid/20000994 –

2

ऊपर दिए गए उत्तर दस्तावेज़ों के बारे में स्पष्ट जानकारी देते हैं; सबसे नए लोग जो समस्याएं चलाते हैं वह समस्या अनियंत्रित मामलों में होती है। उदाहरण के लिए:

  • autorelease: "। भविष्य में कुछ बिंदु पर" डॉक्स कहते हैं कि यह एक रिलीज ट्रिगर किया जाएगा कब?! असल में, जब तक आप अपने कोड को सिस्टम इवेंट लूप में वापस नहीं निकाल लेते हैं तब तक आप ऑब्जेक्ट पर भरोसा कर सकते हैं। सिस्टम वर्तमान घटना चक्र के बाद किसी भी समय ऑब्जेक्ट को जारी कर सकता है। (मुझे लगता है कि मैट ने कहा था, पहले।)

  • स्टेटिक तार: NSString *foo = @"bar"; - क्या आपको इसे बनाए रखना या छोड़ना है? सं कैसे

    के बारे में
    -(void)getBar { 
        return @"bar"; 
    } 
    

    ...

    NSString *foo = [self getBar]; // still no need to retain or release 
    
  • निर्माण नियम: यदि आप इसे बनाया है, वह आपका ही है, और इसे जारी करने की उम्मीद कर रहे हैं।

सामान्य में, जिस तरह से नई कोको प्रोग्रामर में गड़बड़ नहीं समझ जो एक retainCount > 0 के साथ एक ऑब्जेक्ट दिनचर्या के द्वारा है।

यहाँ Very Simple Rules For Memory Management In Cocoa से एक टुकड़ा है:

रिटेंशन गणना नियमों

  • दिए गए ब्लॉक के भीतर, -copy, -alloc के उपयोग और -retain के उपयोग के बराबर होना चाहिए - रिलीज और --autorelease।
  • सुविधा रचनाकारों का उपयोग करके बनाए गए ऑब्जेक्ट्स (उदा। एनएसएसटींग की स्ट्रिंगविथस्ट्रिंग) को ऑटोरेलेज्ड माना जाता है।
  • लागू एक -dealloc विधि instancevariables जारी करने के लिए आप खुद

1 गोली का कहना है: अगर आप alloc (या new fooCopy) कहा जाता है, तो आप उस वस्तु पर जारी कॉल करने के लिए की जरूरत है।

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

तीसरा आत्म-स्पष्टीकरण होना चाहिए।

+0

"Autorelease: दस्तावेज़ कहते हैं कि यह एक रिलीज ट्रिगर करेगा" भविष्य में किसी बिंदु पर। "कब ?!" दस्तावेज़ उस बिंदु पर स्पष्ट हैं: "autorelease का मतलब है" बाद में एक रिलीज संदेश भेजें "(बाद में देखें" Autorelease पूल "की कुछ परिभाषा के लिए)।" जब स्वायत्त पूल स्टैक पर निर्भर करता है ... – mmalc

+0

... "सिस्टम वर्तमान घटना चक्र के बाद किसी भी समय ऑब्जेक्ट को रिलीज़ कर सकता है।" यह सिस्टम की तुलना में अपेक्षाकृत कम निर्धारिती बनाता है ... – mmalc

+0

... NSString * foo = [self getBar]; // अभी भी को बनाए रखने या रिलीज़ करने की कोई आवश्यकता नहीं है यह गलत है। जो कोई भी GetBar को आमंत्रित करता है उसे कार्यान्वयन विवरण नहीं पता है, इसलिए * मौजूदा स्कोप के बाहर इसका उपयोग करना चाहते हैं, तो * * को बनाए रखना/रिलीज़ करना (आमतौर पर एक्सेसर्स के माध्यम से) चाहिए। – mmalc

4

वहाँ मैं/अन्य रिहाई बनाए रखने आप $ 50 छोड़ने और Hillegass पुस्तक प्राप्त करने के बारे में सोचने के लिए चाहते हो सकता है की तुलना में विशिष्ट करने के लिए जोड़ नहीं करेंगे iDeveloperTV नेटवर्क

Memory Management in Objective-C

+1

दुर्भाग्यवश यह लिंक अब 404 है। –

+0

धन्यवाद; पृष्ठ चले गए। लिंक सही – Abizern

+0

और मैंने लिंक को फिर से सही किया है। – Abizern

6

से एक नि: शुल्क स्क्रीनकास्ट उपलब्ध है, लेकिन मैं दृढ़ता से सुझाव देता हूं कि आपके आवेदन के विकास में बहुत जल्दी उपकरण उपकरण का उपयोग करना (यहां तक ​​कि आपका पहला भी!)। ऐसा करने के लिए, रन-> प्रदर्शन टूल के साथ शुरू करें। मैं लीक्स के साथ शुरू करूंगा जो कि उपलब्ध कई उपकरणों में से एक है लेकिन जब आप रिलीज करना भूल गए हैं तो आपको दिखाने में मदद मिलेगी। यह चुनौतीपूर्ण है कि आपको कितनी जानकारी प्रस्तुत की जाएगी। लेकिन इस ट्यूटोरियल की जाँच ऊपर और तेजी से चलते रहने के लिए:
COCOA TUTORIAL: FIXING MEMORY LEAKS WITH INSTRUMENTS

वास्तव में,, बल की कोशिश कर रहा लीक की एक बेहतर तरीका हो सकता है बदले में उन्हें रोकने के लिए सीखने!गुड लक;)

0

के रूप में कई लोगों को पहले ही उल्लेख किया, एप्पल के Intro to Memory Management अब तक का सबसे अच्छी जगह शुरू करने के लिए है।

एक उपयोगी लिंक मैंने अभी तक उल्लेख नहीं किया है Practical Memory Management है। यदि आप उनके माध्यम से पढ़ते हैं, तो आप इसे ऐप्पल के दस्तावेज़ों के बीच में पाएंगे, लेकिन यह सीधे लिंकिंग के लायक है। यह उदाहरण प्रबंधन और सामान्य गलतियों के साथ स्मृति प्रबंधन नियमों का एक शानदार कार्यकारी सारांश है (मूल रूप से यहां अन्य उत्तर क्या समझाए जाने की कोशिश कर रहे हैं, लेकिन साथ ही नहीं)।

+0

धन्यवाद, यही वह जगह है जहां मेरा पुराना चरणबद्ध लेख समाप्त हो गया ... – mmalc