स्वचालित संदर्भ गणना: भाग 1

नमस्कार साथियों!

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


चूंकि Apple ने इस नवाचार की घोषणा की, इसलिए पाठकों ने मुझे स्वचालित संदर्भ गणना (ARC) तंत्र के बारे में लिखने के लिए प्रोत्साहित किया। समय आ गया है। आज हम Apple के नए मेमोरी मैनेजमेंट सिस्टम के बारे में बात करेंगे: यह कैसे काम करता है और इसे अपने लिए कैसे काम करता है।

संकल्पना

क्लैंग स्टैटिक एनालाइज़र आपके कोड में मेमोरी प्रबंधन त्रुटियों को खोजने के लिए एक बहुत ही उपयोगी उपकरण है। यदि आप और मैं एक जैसे हैं, तो, विश्लेषक के आउटपुट को देखते हुए, हम सोचते हैं: "यदि विश्लेषक ने त्रुटि का पता लगाया, तो मेरे बजाय इसे ठीक क्यों नहीं किया जाना चाहिए?"

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

एआरसी तंत्र कहीं न कहीं कचरा कलेक्टर और मैनुअल मेमोरी प्रबंधन के बीच है। कचरा संग्रहकर्ता की तरह, एआरसी डेवलपर्स के लिए रिटेन / रिलीज / ऑटोरेलिज कॉल लिखने की आवश्यकता को समाप्त करता है । हालांकि, कचरा कलेक्टर के विपरीत, एआरसी लूप को बनाए रखने के लिए किसी भी तरह से प्रतिक्रिया नहीं करता है। एक दूसरे के साथ मजबूत लिंक वाली दो वस्तुओं को कभी भी एआरसी द्वारा संसाधित नहीं किया जाएगा, भले ही कोई और उन्हें संदर्भित न करे। जबकि एआरसी अधिकांश मेमोरी प्रबंधन कार्यों के प्रोग्रामर को राहत देता है, डेवलपर को अभी भी ऑब्जेक्ट को सख्त परिपत्र संदर्भों से बचने या मैन्युअल रूप से नष्ट करने की आवश्यकता है।

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

Xcode

एआरसी एक्सकोड 4.2 बीटा के साथ शुरू होने पर उपलब्ध है, और केवल जब क्लैंग (उर्फ "ऐप्पल एलएलवीएम कंपाइलर") का उपयोग करके संकलन चुनना है। इसका उपयोग करने के लिए, स्पष्ट नाम "उद्देश्य-सी स्वचालित संदर्भ गणना" के साथ सेटिंग को नोट करना पर्याप्त है।
यदि आप पहले से ही किसी मौजूदा कोड बेस के साथ काम कर रहे हैं, तो इस सेटिंग को बदलने से बड़ी संख्या में त्रुटियां हो सकती हैं। एआरसी न केवल आपके स्थान पर स्मृति का प्रबंधन करता है, बल्कि आपको इसे स्वयं करने से भी रोकता है। एआरसी का उपयोग वस्तुओं को बनाए रखने / जारी करने / ऑटोरेलिज संदेश भेजने के लिए पूरी तरह से अस्वीकार्य है। इस तथ्य के आधार पर कि कोको इस तरह के संदेशों से भरा है, आप अनिवार्य रूप से त्रुटियों की एक टन प्राप्त करेंगे।
सौभाग्य से, Xcode मौजूदा कोड को बदलने के लिए एक उपकरण प्रदान करता है। ऐसा करने के लिए, बस Edit -> Refactor ... -> Convert to Objective-C ARC ... - का चयन करें और Xcode आपको चरण-दर-चरण अपना कोड बदलने की अनुमति देगा। बहुत अड़चनों को छोड़कर, जहां आपको यह निर्दिष्ट करने की आवश्यकता होगी कि क्या करना है, यह प्रक्रिया काफी हद तक स्वचालित है।

बुनियादी कार्यक्षमता

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

वे (नियम) प्रक्रिया के स्वचालन में बहुत योगदान करते हैं। यदि आप लिखते हैं:

Foo *foo = [[Foo alloc] init]; [foo something]; return; 

संकलक एक असंतुलित आवंटन देखता है और निम्नलिखित में परिवर्तित होता है:

  Foo *foo = [[Foo alloc] init]; [foo something]; [foo release]; return; 

वास्तव में, संकलक ऑब्जेक्ट को रिलीज़ संदेश भेजने के लिए कोड सम्मिलित नहीं करता है। इसके बजाय, यह एक विशेष रनटाइम फ़ंक्शन के लिए एक कॉल सम्मिलित करता है:

  Foo *foo = [[Foo alloc] init]; [foo something]; objc_release(foo); return; 

यहां आप कुछ अनुकूलन लागू कर सकते हैं। ज्यादातर मामलों में जब - रिलीज को पुनर्परिभाषित नहीं किया जाता है, तो objc_release उद्देश्य-सी संदेश तंत्र को बायपास कर सकता है, जिसके परिणामस्वरूप गति में मामूली वृद्धि हो सकती है।

इस तरह के स्वचालन से कोड को सुरक्षित बनाने में मदद मिलेगी। कई कोको डेवलपर्स ने खंड 2 से "काफी लंबे समय" शब्द की व्याख्या की है, उदाहरण के चर या इसी तरह के स्थानों में संग्रहीत वस्तुओं को लागू करना। आमतौर पर हम स्थानीय अस्थायी वस्तुओं पर रख - रखाव और रिलीज लागू नहीं करते हैं:

  Foo *foo = [self foo]; [foo bar]; [foo baz]; [foo quux]; 

हालाँकि, निम्न निर्माण काफी खतरनाक है:

  Foo *foo = [self foo]; [foo bar]; [foo baz]; [self setFoo: newFoo]; [foo quux]; // crash 

यह - foo के लिए एक गेटर होने से तय किया जा सकता है, जिसमें मूल्य वापस नहीं होने तक रिटेन / ऑटोरेलिज भेजा जाता है। यह एक कामकाजी विकल्प है, लेकिन कई अस्थायी वस्तुओं का उत्पादन कर सकता है जो स्मृति का सक्रिय रूप से उपयोग करते हैं। हालाँकि, ARC यहाँ अतिरिक्त कॉल करेगा।

  Foo *foo = objc_retainAutoreleasedReturnValue([self foo]); [foo bar]; [foo baz]; [self setFoo: newFoo]; [foo quux]; // fine objc_release(foo); 

इसके अलावा, भले ही आपने एक साधारण गेटर लिखा हो, ARC इसे यथासंभव सुरक्षित बना देगा:

  - (Foo *)foo { return objc_retainAutoreleaseReturnValue(_foo); } 

हालांकि, यह अत्यधिक संख्या में अस्थायी वस्तुओं की समस्या को पूरी तरह से हल नहीं करता है! हम, पहले की तरह, गेट्टर में अनुरक्षण / ऑटोरेलेज संयोजन और कॉलिंग कोड में अनुरक्षण / रिलीज संयोजन का उपयोग करते हैं। यह निस्संदेह अप्रभावी है!

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

जब objc_retainAutoreleaseReturnValue चल रहा है, तो यह स्टैक की निगरानी करता है और कॉल करने वाले के पते को याद करता है। यह उसे यह जानने की अनुमति देता है कि इसके पूरा होने के बाद क्या होगा। संकलन अनुकूलन चालू होने के साथ, objc_retainAutoreleaseReturnValue को कॉल करना टेल-कॉल ऑप्टिमाइज़ेशन का कारण हो सकता है।

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

नोट: यह अनुकूलन उस कोड के साथ पूरी तरह से संगत है जो ARC तंत्र का उपयोग नहीं करता है।
ऐसी घटना में जिसका गेट्टर एआरसी का उपयोग नहीं करता है, उपरोक्त ध्वज सेट नहीं है और कॉल करने वाला अनुरक्षण / रिलीज संदेशों के पूर्ण संयोजन का उपयोग कर सकता है।
ऐसी घटना में जिसका गेट्टर एआरसी का उपयोग करता है, लेकिन कॉल करने वाला नहीं करता है, तो गेट्टर देखता है कि यह उस कोड पर वापस नहीं जाता है जो तुरंत विशेष विशेष रनटाइम फ़ंक्शन को कॉल करता है, और इसलिए रिटेन / ऑटोरेलिज संदेशों के पूर्ण संयोजन का उपयोग कर सकता है।
कुछ प्रदर्शन खो गया है, लेकिन कोड अभी भी पूरी तरह से सही है।

उसके शीर्ष पर, ARC इंजन स्वचालित रूप से सभी वर्गों के लिए -Dealloc पद्धति बनाता है या उसके सभी इंस्टेंस चर को मुक्त करता है। इसी समय, मैन्युअल रूप से लिखने की संभावना अभी भी है -Dealloc (और यह बाहरी संसाधनों का प्रबंधन करने वाली कक्षाओं के लिए आवश्यक है), लेकिन भविष्य में वर्ग आवृत्ति चर को मैन्युअल रूप से जारी करने की कोई आवश्यकता (या संभावना) नहीं है। एआरसी अंत में एक [सुपर डीलॉक] कॉल भी डालेगा , जो आपको इसके बारे में चिंता करने से बचाएगा।

हम बताते हैं कि क्या कहा गया है।
पहले, आपके पास निम्नलिखित निर्माण हो सकते हैं:

  - (void)dealloc { [ivar1 release]; [ivar2 release]; free(buffer); [super dealloc]; } 

लेकिन आपको बस लिखने की ज़रूरत है:

  - (void)dealloc { free(buffer); } 

यदि आपकी -dealloc विधि सिर्फ उदाहरण के चर को मुक्त करती है, तो यह निर्माण (ARC का उपयोग करके) आपके लिए वही करेगा।

लूप्स और कमजोर लिंक

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

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

  @interface Foo : NSObject { __weak Bar *_weakBar; } 

स्थानीय चर समान तरीके से बनाए जाते हैं:

  __weak Foo *_weakFoo = [object foo]; 

आप बाद में उन्हें नियमित चर के रूप में उपयोग कर सकते हैं, लेकिन आवश्यकता पड़ने पर उनका मूल्य स्वतः शून्य हो जाएगा:

  [_weakBar doSomethingIfStillAlive]; 

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

  if(_weakBar) [self mustNotBeNil: _weakBar]; 

इसके बजाय, एक स्थानीय मजबूत लिंक का उपयोग करें और फिर जांचें:

  Bar *bar = _weakBar; if(bar) [self mustNotBeNil: bar]; 

यह पूरे समय के लिए उपयोग किए जाने वाले ऑब्जेक्ट को लाइव (और गैर- शून्य चर) बनाने की गारंटी है, क्योंकि इस मामले में बार एक मजबूत संदर्भ है।

कमजोर लिंक को हटाने के एआरसी में कार्यान्वयन को उद्देश्य-सी में संदर्भ लेखा प्रणाली और कमजोर लिंक के नल प्रणाली के बीच घनिष्ठ समन्वय की आवश्यकता होती है। इसका मतलब यह है कि एक वर्ग जो बनाए रखता है और जारी रखता है वह एक अशक्त कमजोर संदर्भ की वस्तु नहीं हो सकता है। हालांकि असामान्य, कुछ कोको वर्ग इससे ग्रस्त हैं (जैसे NSWindow )।

सौभाग्य से, यदि आप इसी तरह की गलती करते हैं, तो प्रोग्राम आपको इसके बारे में तुरंत एक संदेश जारी करके इसके बारे में बता देगा, जब यह दुर्घटनाग्रस्त हो जाता है, तो:

  objc[2478]: cannot form weak reference to instance (0x10360f000) of class NSWindow 

यदि आपको वास्तव में समान वर्गों के लिए एक कमजोर संदर्भ की आवश्यकता है, तो आप __weak के बजाय __unsafe_unretain का उपयोग कर सकते हैं। यह एक कमजोर लिंक बनाएगा जो रीसेट नहीं किया जाएगा। लेकिन आपको यह सुनिश्चित करना चाहिए कि आप इस पॉइंटर का उपयोग नहीं कर रहे हैं (यह बेहतर है कि आप इसे मैन्युअल रूप से रीसेट कर दें) ऑब्जेक्ट को नष्ट करने वाले बिंदु के बाद ।
सावधान रहें: गैर-अशक्त कमजोर लिंक का उपयोग करके, आप आग से खेलते हैं।

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

यह देखते हुए कि अशक्त कमजोर लिंक बहुत खतरनाक हैं, यह सीमा इन प्रणालियों पर एआरसी का उपयोग करने के आकर्षण को बहुत कम कर देती है, जैसा कि मेरे लिए।

---

यहाँ मैं अनुवाद का पहला भाग समाप्त करूँगा, क्योंकि पाठ बड़ा नहीं निकला। मैंने इसे यथासंभव सर्वोत्तम तरीके से रूसी में अनुवाद करने की कोशिश की, जो कि विशेष रूप से सरल नहीं है अगर 99% सामग्री अंग्रेजी में है।
जैसा कि वे कहते हैं, देखते रहें।