व्लादिमीर से जवाब वास्तव में बहुत अच्छा है, हालांकि, मैं यहां कुछ और पृष्ठभूमि ज्ञान देना चाहूंगा। हो सकता है कि एक दिन किसी को मेरा जवाब मिल जाए और उसे मदद मिल जाए।
कंपाइलर स्रोत फ़ाइलों (.c, .cc, .cpp, .m) को ऑब्जेक्ट फ़ाइलों (.o) में बदल देता है। स्रोत फ़ाइल प्रति एक ऑब्जेक्ट फ़ाइल है। ऑब्जेक्ट फ़ाइलों में प्रतीक, कोड और डेटा होते हैं। ऑब्जेक्ट फ़ाइलें ऑपरेटिंग सिस्टम द्वारा सीधे उपयोग करने योग्य नहीं हैं।
अब जब एक गतिशील पुस्तकालय (.dylib), एक फ्रेमवर्क, एक लोड करने योग्य बंडल (.bundle) या एक निष्पादन योग्य बाइनरी का निर्माण किया जाता है, तो इन ऑब्जेक्ट फ़ाइलों को लिंकर द्वारा एक साथ जोड़ा जाता है ताकि कुछ उत्पादन करने के लिए ऑपरेटिंग सिस्टम "उपयोग करने योग्य" समझे, जैसे कुछ यह कर सकता है। सीधे एक विशिष्ट मेमोरी पते पर लोड होता है।
हालाँकि, एक स्थैतिक पुस्तकालय का निर्माण करते समय, इन सभी ऑब्जेक्ट फ़ाइलों को केवल एक बड़ी संग्रह फ़ाइल में जोड़ा जाता है, इसलिए स्थैतिक पुस्तकालयों (संग्रह के लिए एक .a) का विस्तार होता है। तो एक .a फ़ाइल ऑब्जेक्ट (.o) फ़ाइलों के संग्रह से कुछ भी नहीं है। संपीड़न के बिना एक TAR संग्रह या एक ज़िप संग्रह के बारे में सोचें। यह .o फ़ाइलों की एक पूरी गुच्छा (जावा के समान, जहाँ आप सेट करते हैं, के आसपास एक .a फ़ाइल को कॉपी करना आसान होता है। फ़ाइलों को आसान वितरण के लिए एक .jar संग्रह में विभाजित करें)।
किसी बाइनरी को स्टैटिक लाइब्रेरी (= आर्काइव) से लिंक करते समय, लिंकर को आर्काइव में सभी प्रतीकों की एक तालिका मिल जाएगी और जाँच करें कि इन प्रतीकों में से कौन से बायनेरिज़ द्वारा संदर्भित हैं। केवल संदर्भित फ़ाइलों वाले ऑब्जेक्ट ऑब्जेक्ट्स को वास्तव में लिंकर द्वारा लोड किया जाता है और लिंकिंग प्रक्रिया द्वारा माना जाता है। उदाहरण के लिए, यदि आपके संग्रह में 50 ऑब्जेक्ट फ़ाइलें हैं, लेकिन केवल 20 में बाइनरी द्वारा उपयोग किए गए प्रतीक हैं, केवल 20 को लिंकर द्वारा लोड किया गया है, अन्य 30 को लिंकिंग प्रक्रिया में पूरी तरह से अनदेखा किया गया है।
यह C और C ++ कोड के लिए काफी अच्छी तरह से काम करता है, क्योंकि ये भाषाएं संकलन के समय में अधिक से अधिक करने की कोशिश करती हैं (हालांकि C ++ में कुछ रनटाइम-केवल विशेषताएं भी हैं)। ओब्ज-सी, हालांकि, एक अलग तरह की भाषा है। ओबज-सी रनटाइम फीचर्स पर बहुत अधिक निर्भर करता है और कई ओबज-सी फीचर्स वास्तव में रनटाइम केवल फीचर्स हैं। ओबज-सी कक्षाओं में वास्तव में सी फ़ंक्शन या वैश्विक सी चर (कम से कम वर्तमान ओब्ज-सी रनटाइम) के बराबर प्रतीक हैं। एक लिंकर यह देख सकता है कि एक वर्ग संदर्भित है या नहीं, इसलिए यह निर्धारित कर सकता है कि कोई वर्ग उपयोग में है या नहीं। यदि आप किसी स्थिर लायब्रेरी में ऑब्जेक्ट फ़ाइल से एक वर्ग का उपयोग करते हैं, तो यह ऑब्जेक्ट फ़ाइल लिंकर द्वारा लोड की जाएगी क्योंकि लिंकर उपयोग में एक प्रतीक देखता है। श्रेणियाँ एक रन-ही सुविधा हैं, श्रेणियां वर्ग या फ़ंक्शंस जैसे प्रतीक नहीं हैं और इसका अर्थ यह भी है कि कोई लिंकर यह निर्धारित नहीं कर सकता है कि कोई श्रेणी उपयोग में है या नहीं।
यदि लिंकर ओब्ज-सी कोड वाली ऑब्जेक्ट फ़ाइल को लोड करता है, तो उसके सभी ओबज-सी हिस्से हमेशा लिंकिंग स्टेज का हिस्सा होते हैं। इसलिए यदि श्रेणियों वाली कोई ऑब्जेक्ट फ़ाइल लोड की गई है, क्योंकि उसमें से किसी भी प्रतीक को "उपयोग में" माना जाता है (जैसा कि यह एक वर्ग है, यह एक फ़ंक्शन है, तो यह एक वैश्विक चर है), श्रेणियों को भी लोड किया जाता है और रनटाइम पर उपलब्ध होगा । फिर भी यदि ऑब्जेक्ट फ़ाइल स्वयं लोड नहीं है, तो उसमें श्रेणियां रनटाइम पर उपलब्ध नहीं होंगी। केवल श्रेणियों वाली एक ऑब्जेक्ट फ़ाइल कभी लोड नहीं होती है क्योंकि इसमें कोई प्रतीक नहीं होता है जो लिंकर कभी भी "उपयोग में" नहीं मानता है। और यह यहाँ पूरी समस्या है।
कई समाधान प्रस्तावित किए गए हैं और अब आप जानते हैं कि यह सब एक साथ कैसे चलता है, आइए प्रस्तावित समाधान पर एक और नज़र डालते हैं:
एक समाधान -all_loadलिंकर कॉल में जोड़ना है। वह लिंकर ध्वज वास्तव में क्या करेगा? वास्तव में यह लिंकर को बताता है कि " सभी अभिलेखागार की सभी ऑब्जेक्ट फ़ाइलों को लोड करें, भले ही आपको उपयोग में कोई प्रतीक दिखाई दे या नहीं '। बेशक, यह काम करेगा; लेकिन यह बड़े बायनेरिज़ का उत्पादन भी कर सकता है।
एक अन्य समाधान यह है -force_loadकि लिंकर कॉल को आर्काइव के पथ सहित जोड़ा जाए। यह ध्वज ठीक वैसे -all_loadही काम करता है , लेकिन केवल निर्दिष्ट संग्रह के लिए। बेशक यह भी काम करेगा।
सबसे लोकप्रिय समाधान -ObjCलिंकर कॉल में जोड़ना है। वह लिंकर ध्वज वास्तव में क्या करेगा? यह ध्वज लिंकर को बताता है " सभी अभिलेखागार से सभी ऑब्जेक्ट फ़ाइलों को लोड करें यदि आप देखते हैं कि उनमें कोई ओब्ज-सी कोड है "। और "किसी भी ओब्ज-सी कोड" में श्रेणियां शामिल हैं। यह भी काम करेगा और यह बिना ओबज-सी कोड वाली ऑब्जेक्ट फ़ाइलों को लोड करने के लिए बाध्य नहीं करेगा (ये अभी भी केवल मांग पर लोड हैं)।
एक और समाधान बल्कि नया Xcode बिल्ड सेटिंग है Perform Single-Object Prelink। यह सेटिंग क्या करेगी? यदि सक्षम किया गया है, तो सभी ऑब्जेक्ट फ़ाइलें (याद रखें, एक स्रोत फ़ाइल प्रति है) को एक ही ऑब्जेक्ट फ़ाइल में मिला दिया जाता है (जो कि वास्तविक लिंकिंग नहीं है, इसलिए नाम PreLink ) और यह एकल ऑब्जेक्ट फ़ाइल (कभी-कभी इसे "मास्टर ऑब्जेक्ट भी कहा जाता है") फ़ाइल ") तब संग्रह में जोड़ दी जाती है। यदि अब मास्टर ऑब्जेक्ट फ़ाइल के किसी भी प्रतीक को उपयोग में माना जाता है, तो पूरी मास्टर ऑब्जेक्ट फ़ाइल को उपयोग में माना जाता है और इस प्रकार सभी ऑब्जेक्टिव-सी भागों को हमेशा लोड किया जाता है। और चूंकि कक्षाएं सामान्य प्रतीक हैं, इसलिए ऐसी स्थिर लाइब्रेरी से एकल वर्ग का उपयोग करना भी सभी श्रेणियों को प्राप्त करना है।
अंतिम समाधान है व्लादिमीर व्लादिमीर ने अपने उत्तर के अंत में जोड़ा। केवल श्रेणियों को घोषित करने वाले किसी भी स्रोत फ़ाइल में एक " नकली प्रतीक " रखें । यदि आप रनटाइम में किसी भी श्रेणी का उपयोग करना चाहते हैं, तो सुनिश्चित करें कि आप किसी तरह फर्जी प्रतीक को संकलित समय पर संदर्भित करते हैं , क्योंकि इससे ऑब्जेक्ट फ़ाइल लिंकर द्वारा लोड की जाती है और इस तरह इसमें सभी ओब्ज-सी कोड भी होते हैं। उदाहरण के लिए, यह एक खाली फ़ंक्शन बॉडी के साथ एक फ़ंक्शन हो सकता है (जिसे कॉल किए जाने पर कुछ भी नहीं किया जाएगा) या यह एक वैश्विक चर एक्सेस किया जा सकता है (उदाहरण के लिए वैश्विक)intएक बार पढ़ने या एक बार लिखे जाने के बाद, यह पर्याप्त है)। उपरोक्त सभी अन्य समाधानों के विपरीत, यह समाधान इस बात को नियंत्रित करता है कि संकलित कोड के लिए कौन सी श्रेणियां रनटाइम पर उपलब्ध हैं (यदि वे चाहते हैं कि वे लिंक और उपलब्ध हों, तो यह प्रतीक तक पहुंचता है, अन्यथा यह प्रतीक तक नहीं पहुंचता है और लिंक करने वाला अनदेखा कर देगा यह)।
बस आज के लिए इतना ही।
ओह, रुको, एक और बात है:
लिंकर के पास नाम का एक विकल्प है -dead_strip। यह विकल्प क्या करता है? यदि लिंकर ने ऑब्जेक्ट फ़ाइल को लोड करने का निर्णय लिया है, तो ऑब्जेक्ट फ़ाइल के सभी प्रतीक लिंक किए गए बाइनरी का हिस्सा बन जाते हैं, चाहे उनका उपयोग किया जाए या नहीं। जैसे किसी ऑब्जेक्ट फ़ाइल में 100 फ़ंक्शंस होते हैं, लेकिन उनमें से केवल एक का उपयोग बाइनरी द्वारा किया जाता है, सभी 100 फ़ंक्शंस अभी भी बाइनरी में जोड़े जाते हैं क्योंकि ऑब्जेक्ट फ़ाइलों को या तो एक पूरे के रूप में जोड़ा जाता है या उन्हें बिल्कुल नहीं जोड़ा जाता है। ऑब्जेक्ट फ़ाइल को आंशिक रूप से जोड़ना आमतौर पर लिंकर्स द्वारा समर्थित नहीं है।
हालाँकि, यदि आप लिंकर को "डेड स्ट्रिप" बताते हैं, तो लिंकर सबसे पहले सभी ऑब्जेक्ट फ़ाइलों को बाइनरी में जोड़ देगा, सभी संदर्भों को हल कर देगा और अंत में बाइनरी को स्कैन करेगा प्रतीकों के लिए नहीं (या केवल अन्य प्रतीकों द्वारा उपयोग में नहीं है उपयोग)। तब उपयोग में नहीं आने वाले सभी प्रतीकों को अनुकूलन चरण के हिस्से के रूप में हटा दिया जाता है। ऊपर के उदाहरण में, 99 अप्रयुक्त कार्यों को फिर से हटा दिया जाता है। यह बहुत उपयोगी है यदि आप विकल्पों का उपयोग करते हैं -load_all, -force_loadया Perform Single-Object Prelinkक्योंकि ये विकल्प कुछ मामलों में नाटकीय रूप से बाइनरी आकार को आसानी से उड़ा सकते हैं और मृत स्ट्रिपिंग अप्रयुक्त कोड और डेटा को फिर से हटा देगा।
सी कोड के लिए डेड स्ट्रिपिंग बहुत अच्छी तरह से काम करता है (जैसे अप्रयुक्त कार्यों, चर और स्थिरांक को उम्मीद के अनुसार हटा दिया जाता है) और यह सी ++ के लिए भी काफी अच्छा काम करता है (जैसे अप्रयुक्त कक्षाएं हटा दी जाती हैं)। यह सही नहीं है, कुछ मामलों में कुछ प्रतीकों को हटाया नहीं जाता है भले ही उन्हें हटाना ठीक होगा, लेकिन ज्यादातर मामलों में यह इन भाषाओं के लिए काफी अच्छा काम करता है।
Obj-C के बारे में क्या? इसके बारे में भूल जाओ! Obj-C के लिए कोई मृत स्ट्रिपिंग नहीं है। चूंकि ओब्ज-सी एक रनटाइम-फीचर भाषा है, इसलिए कंपाइलर संकलन समय पर यह नहीं कह सकता है कि कोई प्रतीक वास्तव में उपयोग में है या नहीं। उदाहरण के लिए एक ओबज-सी वर्ग उपयोग में नहीं है यदि कोई कोड नहीं है जो सीधे इसे संदर्भित करता है, सही है? गलत! आप गतिशील रूप से एक वर्ग नाम युक्त स्ट्रिंग का निर्माण कर सकते हैं, उस नाम के लिए कक्षा सूचक का अनुरोध कर सकते हैं और कक्षा को गतिशील रूप से आवंटित कर सकते हैं। के बजाय
MyCoolClass * mcc = [[MyCoolClass alloc] init];
मैं भी लिख सकता था
NSString * cname = @"CoolClass";
NSString * cnameFull = [NSString stringWithFormat:@"My%@", cname];
Class mmcClass = NSClassFromString(cnameFull);
id mmc = [[mmcClass alloc] init];
दोनों मामलों mmcमें वर्ग "MyCoolClass" की एक वस्तु का संदर्भ है, लेकिन दूसरे कोड नमूने में इस वर्ग का कोई सीधा संदर्भ नहीं है (एक स्थिर स्ट्रिंग के रूप में वर्ग का नाम भी नहीं)। सब कुछ रनटाइम पर ही होता है। और है कि भले ही वर्गों है कर रहे हैं वास्तव में असली प्रतीकों। यह श्रेणियों के लिए और भी बुरा है, क्योंकि वे वास्तविक प्रतीक भी नहीं हैं।
इसलिए यदि आपके पास सैकड़ों वस्तुओं के साथ एक स्थिर पुस्तकालय है, फिर भी आपके अधिकांश बायनेरिज़ को उनमें से कुछ की आवश्यकता है, तो आप ऊपर दिए गए समाधानों (1) से (4) का उपयोग नहीं करना पसंद कर सकते हैं। अन्यथा आप इन सभी वर्गों वाले बहुत बड़े बायनेरिज़ के साथ समाप्त होते हैं, भले ही उनमें से अधिकांश का उपयोग कभी नहीं किया जाता है। कक्षाओं के लिए आपको आमतौर पर किसी विशेष समाधान की आवश्यकता नहीं होती है क्योंकि कक्षाओं में वास्तविक प्रतीक होते हैं और जब तक आप उन्हें सीधे (दूसरे कोड नमूने में नहीं) संदर्भित करते हैं, तब तक लिंकर अपने उपयोग की अच्छी तरह से पहचान कर लेगा। श्रेणियों के लिए, हालांकि, समाधान (5) पर विचार करें, क्योंकि यह केवल उन श्रेणियों को शामिल करना संभव बनाता है जिनकी आपको वास्तव में आवश्यकता है।
उदाहरण के लिए, यदि आप NSData के लिए एक श्रेणी चाहते हैं, उदाहरण के लिए, इसमें एक संपीड़न / अपघटन विधि जोड़कर, आप एक हेडर फ़ाइल बनाएंगे:
// NSData+Compress.h
@interface NSData (Compression)
- (NSData *)compressedData;
- (NSData *)decompressedData;
@end
void import_NSData_Compression ( );
और एक कार्यान्वयन फ़ाइल
// NSData+Compress
@implementation NSData (Compression)
- (NSData *)compressedData
{
// ... magic ...
}
- (NSData *)decompressedData
{
// ... magic ...
}
@end
void import_NSData_Compression ( ) { }
अब बस यह सुनिश्चित कर लें कि आपके कोड में कहीं भी import_NSData_Compression()कॉल किया गया है। इससे कोई फर्क नहीं पड़ता कि इसे कहाँ कहा जाता है या इसे कितनी बार कहा जाता है। वास्तव में यह वास्तव में बिल्कुल नहीं बुलाया जा सकता है, यह काफी है अगर लिंकर ऐसा सोचता है। उदाहरण के लिए आप अपनी परियोजना में कहीं भी निम्नलिखित कोड डाल सकते हैं:
__attribute__((used)) static void importCategories ()
{
import_NSData_Compression();
// add more import calls here
}
आपको कभी भी importCategories()अपने कोड में कॉल करने की आवश्यकता नहीं है , विशेषता कंपाइलर और लिंकर को विश्वास दिलाएगा कि इसे कहा जाता है, भले ही ऐसा न हो।
और एक अंतिम टिप:
यदि आप -whyloadअंतिम लिंक कॉल में जोड़ते हैं, तो लिंकर बिल्ड लॉग में प्रिंट करेगा कि किस लाइब्रेरी से किस ऑब्जेक्ट ने यह लोड किया है क्योंकि उपयोग में कौन सा प्रतीक है। यह केवल उपयोग में माना जाने वाला पहला प्रतीक मुद्रित करेगा, लेकिन यह आवश्यक रूप से उस ऑब्जेक्ट फ़ाइल के उपयोग में एकमात्र प्रतीक नहीं है।