एआरसी, प्री-आईओएस 6 का उपयोग करते समय अभी भी 'dealloc' और 'viewDidUnload' विधियों की आवश्यकता है?

Question

मैं 4.3 और बाद के लक्ष्य आईओएस पर्यावरण के साथ आईओएस विरासत कोड पर काम कर रहे एक बड़ी टीम के हिस्से के रूप में काम करता हूं। मैंने अन्य डेवलपर्स को NSObject से नीचे आने वाली कक्षाओं में चेक किया है लेकिन dealloc विधि नहीं है। मैंने UIViewController वंश भी देखे हैं जिनमें viewDidUnload विधियां शामिल नहीं हैं। जब मैं इस कोड के बारे में पूछता हूं तो सामान्य प्रतिक्रिया "चिंता न करें, एआरसी अब उसका ख्याल रखता है।"

मैं समझता हूँ कि viewDidUnloadviewDidLoad फोन करके जब iOS अनुभव कम स्मृति की स्थिति कहा जाता है, वस्तुओं है कि निर्मित किया जा सकता है जारी करके स्मृति को मुक्त के लक्ष्य के साथ, और जब एक वस्तु की गिनती को बनाए रखने के शून्य हो जाती है dealloc कहा जाता है कि। UIViewController ऑब्जेक्ट्स और वंशजों के लिए इसका अर्थ यह हो सकता है कि 'viewDidUnload' dealloc से पहले कहा जा सकता है या नहीं।

तो मेरा प्रश्न यहां है: क्या dealloc और viewDidUnload आईओएस 6 से पहले आईओएस संस्करणों पर एआरसी का उपयोग करते समय अभी भी आवश्यक विधियों की आवश्यकता है?

यदि उत्तर "हाँ है!" तो मुझे तर्क लेने के लिए अच्छे कारणों और/या दस्तावेज़ीकरण की आवश्यकता होगी।

आपके प्रतिक्रियाओं की प्रतीक्षा कर रहे हैं। (मेरे प्रश्न को कसने में मदद करने के लिए टॉमी के लिए धन्यवाद।)

Answer 1

viewDidUnloadis deprecated। तो एआरसी की परवाह किए बिना आपको न केवल एक की आवश्यकता है बल्कि एक का उपयोग नहीं करना चाहिए। उल्लिखित औचित्य यह है कि कम स्मृति चेतावनियों पर विचारों को शुद्ध नहीं किया जाता है (संभवतः क्योंकि वे अब प्रतिक्रिया के हिट के लायक होने के लिए कुल में बहुत कम योगदान देते हैं); औपचारिकता का हिस्सा यह था कि मुझे आश्चर्य नहीं होगा कि बहुत से लोगों ने माना है कि वे viewDidLoad में viewDidUnload के भीतर बनाए गए सभी संसाधनों को छोड़ सकते हैं और वह अकेले लीक को रोक देगा। यह सच नहीं है क्योंकि viewDidUnload केवल तभी कॉल किया जाता है जब कम स्मृति चेतावनी की वजह से दृश्य को अनलोड किया जाता है । इसे सामान्य जीवन चक्र में नहीं कहा जाता है।

ARC's new rules के तहत:

आप एक dealloc विधि लागू कर सकते हैं अगर आप उदाहरण चर रिहा अलावा अन्य संसाधनों का प्रबंधन करने की जरूरत है। आप की जरूरत नहीं है (वास्तव में आप नहीं कर सकते हैं) उदाहरण चर

संपादित जारी: 4.3+ विशेष रूप से इस पर टिप्पणी करने ...

एआरसी आप के लिए viewDidUnload का एक संस्करण को लागू नहीं होंगे।viewDidLoad/viewDidUnload चक्र के बात यह थी कि यदि आप retain किसी भी कारण से दृश्य पदानुक्रम के किसी भी हिस्से तो आप कारण है कि एक कम स्मृति चेतावनी पर स्वचालित रूप से जारी होने की नहीं है, लेकिन ऐसा करने से आप किसी भी लाभ है क्योंकि खरीद नहीं होगा जैसे ही आपके द्वारा बनाए गए दृश्य को अगली बार लोड किया जाएगा, उसे एक नई प्रति के साथ बदल दिया जाएगा। तो अगर आप बार देखा गया है कि वैसे भी तो आदर्श आप चाहें तो उसे शून्य बाहर viewDidUnload दौरान self.view नीचे पदानुक्रम के भीतर कर रहे हैं करने के लिए strongIBOutlet रों है। यहां तक ​​कि यदि आपके पास weak संदर्भ हैं जो किसी भी खतरनाक पॉइंटर्स को आगे बढ़ाने से रोकने के लिए एक अच्छी जगह है।

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

आप उपयोग कर सकते हैं सिम्युलेटर के 'अनुकरण मेमोरी चेतावनी' एक हद तक परीक्षण और डिबग करने के लिए सामान।

dealloc कि एआरसी प्रदान करता है iOS संस्करण की परवाह किए बिना एक ही हो जाएगा। हालांकि यह केवल उद्देश्य-सी वस्तुओं को कवर करेगा। जब वे कहते हैं कि आप आवृत्ति चर जारी नहीं कर सकते हैं तो उनका मतलब है कि उन्हें release संदेश भेजने के बहुत ही शाब्दिक अर्थ में। मान लीजिए कि आपके पास कोर फाउंडेशन ऑब्जेक्ट्स हैं या आपने शुद्ध सी मेमोरी आवंटन किया है, तो आप उन सभी का निपटान करने वाले dealloc को कार्यान्वित करना चाहते हैं।

जाहिर उपकरण और लीक उपकरण तरीकों का परीक्षण और डिबग कि क्षेत्र के लिए कर रहे हैं; किसी भी समय मेमोरी लीक हो जाती है यह जांचने के लिए सावधान रहें कि उस मेमोरी को बनाने वाले ऑब्जेक्ट का प्रकार भी लीक हो रहा है या नहीं। तत्काल वस्तु ठीक हो सकती है लेकिन इसकी आवंटन लीक सूची में दिखाई देगी यदि यह dealloc नहीं था क्योंकि किसी और ने इसे लीक किया था।

Answer 2

viewDidUnload अब बहिष्कृत है और अब सिस्टम (आईओएस 6 के रूप में) द्वारा नहीं कहा जाता है। ऐप्पल की उम्मीद के मुकाबले यह उतना ही उपयोगी नहीं था, और इससे अधिक परेशानी थी। एआरसी के साथ इसका कोई लेना-देना नहीं है।

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