क्या एक "गैर-कमजोर के शून्यीकरण संदर्भ"

Question

OS X v10.11 beta release notes में है, मैं निम्नलिखित है:

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

यह मुझे समझ में नहीं आता है। यदि यह एक गैर-कमजोर संदर्भ है, तो क्या यह एक मजबूत संदर्भ नहीं होगा? तो NSNotificationCenter अभी भी एक मालिक होगा, इसलिए ऑब्जेक्ट को मैन्युअल रूप से अनियंत्रित नहीं किया जाएगा, इसलिए इस संदर्भ में यह "शून्यकरण" कहने के लिए गैरकानूनी है।

यदि यह __unsafe_unretained संदर्भ का एक प्रकार का जिक्र कर रहा है, तो सवाल यह है कि ... NSNotificationCenter एक ज़ोंबी मैसेजिंग से कैसे बचेंगे?

Answer 1

इसका उत्तर उद्देश्य-सी रनटाइम के भीतर गहरा है, और __weak चर वास्तव में कैसे काम करते हैं। व्याख्या करने के लिए, के objc_weak.mm पर एक छोटा सा नजर डालते हैं:,

id 
weak_read_no_lock(weak_table_t *weak_table, id *referrer_id) 
{ 
    ... 

    if (! referent->ISA()->hasCustomRR()) { 
     if (! referent->rootTryRetain()) { 
      return nil; 
     } 
    } 
    else { 
     BOOL (*tryRetain)(objc_object *, SEL) = (BOOL(*)(objc_object *, SEL)) 
      object_getMethodImplementation((id)referent, 
              SEL_retainWeakReference); 
     if ((IMP)tryRetain == _objc_msgForward) { 
      return nil; 
     } 
     if (! (*tryRetain)(referent, SEL_retainWeakReference)) { 
      return nil; 
     } 
    } 

    return (id)referent; 
} 

आप देख सकते हैं, जब कस्टम -retain और -release प्रणालियां किसी ऑब्जेक्ट द्वारा उपयोग किया जाता है कि यह गारंटी नहीं है कि वे सभी पर कमजोर संदर्भ का समर्थन (भी है कि आप ध्यान दें किसी ऑब्जेक्ट के कमजोर संदर्भों के लिए पूरी तरह से अलग ऑब्जेक्ट का उपयोग कर सकते हैं, हालांकि यह किसी अन्य समय के लिए विषय है)।

ऐसा इसलिए है क्योंकि कमजोर संदर्भ objc_destructInstance द्वारा साफ किए जाते हैं, जो objc_clearDeallocating पर कॉल करता है, जो weak_clear_no_lock पर कॉल करता है।

अब, objc_destructInstance कस्टम ऑब्जेक्ट कार्यान्वयन द्वारा कॉल करने की आवश्यकता नहीं है, हालांकि अधिकांश ऑब्जेक्ट्स इसे कॉल करेंगे।

इस प्रकार, रनटाइम आप विधि -allowsWeakReference (और retainWeakReference) अपने वस्तु को कमजोर संदर्भ, जिस स्थिति में यह सबसे अधिक संभावना वस्तु पर -dealloc swizzling से बाहर zero'd है निष्क्रिय करने के लिए लागू करने के लिए अनुमति देता है। बेशक, यह सभी कार्यान्वयन विवरण है, इसलिए NSNotificationCenter के पास चीजों को करने का अपना अभिनव तरीका हो सकता है, लेकिन यह NSNotificationCenter को अलग करने का प्रयास किए बिना मेरा सबसे अच्छा अनुमान है।

Answer 2

एक संपत्ति को मजबूत घोषित करना उस संपत्ति को एक मजबूत संदर्भ बनाता है। इसे कमजोर घोषित करने से शून्यिंग कमजोर संदर्भ का उपयोग होता है। unsafe_unretained संशोधक एक गैर शून्यीकरण को कमजोर संदर्भ का उपयोग करता

संक्षेप में: non-weak zeroing reference == unsafe_unretained refernce

संदर्भ:

https://mikeash.com/pyblog/friday-qa-2011-09-30-automatic-reference-counting.html http://www.jessesquires.com/UIKit-changes-in-iOS-9/