Objective - C categories in static library

Odpowiedź od Vladimira jest całkiem dobra, jednak chciałbym dać trochę więcej wiedzy na ten temat. Może kiedyś ktoś znajdzie moją odpowiedź i może okazać się pomocna.

Kompilator przekształca pliki źródłowe (.c,. cc,.cpp,m) do plików obiektowych (.o). Na jeden plik źródłowy przypada jeden plik obiektowy. Pliki obiektowe zawierają symbole, kod i dane. Pliki obiektowe nie są używane bezpośrednio przez system operacyjny.

Teraz podczas budowania dynamicznej biblioteki (.dylib), ramy, ładowany pakiet (.bundle) lub wykonywalny plik binarny, te pliki obiektowe są połączone ze sobą przez łącznik, aby wytworzyć coś, co system operacyjny uważa za" użyteczne", np. coś, co może bezpośrednio załadować do określonego adresu pamięci.

Jednak podczas budowania biblioteki statycznej, wszystkie te pliki obiektowe są po prostu dodawane do dużego pliku archiwum, stąd rozszerzenie bibliotek statycznych (.a dla archiwum). Więc an .plik jest niczym innym jak archiwum obiektu (.o) pliki. Pomyśl o archiwum TAR lub Archiwum ZIP bez kompresji. Po prostu łatwiej jest skopiować pojedynczy ./ align = "left" / o pliki (podobne do Javy, gdzie się pakuje .pliki klas do a .archiwum jar dla łatwej dystrybucji).

Podczas linkowania binarnego do statycznej biblioteki (=archiwum), linker otrzyma tabelę wszystkich symboli w archiwum i sprawdzi, które z tych symboli są odwołane przez binaria. Tylko pliki obiektowe zawierające odniesienia symboli są faktycznie ładowane przez łącznik i są brane pod uwagę w procesie łączenia. Np. jeśli Twoje archiwum ma 50 plików obiektowych, ale tylko 20 zawiera symbole używane przez binarne, tylko te 20 jest ładowane przez łącznik, pozostałe 30 są całkowicie ignorowane w procesie łączenia.

Działa to całkiem dobrze dla kodu C i C++, ponieważ te języki starają się zrobić jak najwięcej podczas kompilacji (choć C++ ma również pewne funkcje tylko dla środowiska uruchomieniowego). Obj-C to jednak inny rodzaj języka. Obj-C w dużym stopniu zależy od funkcji runtime i wielu Obj-C funkcje są w rzeczywistości funkcjami tylko uruchomieniowymi. Klasy Obj-C mają w rzeczywistości symbole porównywalne z funkcjami C lub globalnymi zmiennymi C (przynajmniej w bieżącym uruchomieniu Obj-C). Linker może sprawdzić, czy klasa jest odwołana, czy nie, więc może określić klasę, która jest w użyciu, czy nie. Jeśli używasz klasy z pliku Obiektowego w bibliotece statycznej, ten plik obiektowy zostanie załadowany przez łącznik, ponieważ łącznik widzi używany symbol. Kategorie to funkcja tylko dla środowiska uruchomieniowego, Kategorie nie są symbolami takimi jak Klasy czy funkcje, a to również oznacza, że linker nie może określić, czy kategoria jest używana, czy nie.

Jeśli łącznik ładuje plik obiektowy zawierający kod Obj - C, wszystkie jego części Obj-C są zawsze częścią etapu łączenia. Więc jeśli plik obiektowy zawierający Kategorie jest ładowany, ponieważ każdy symbol z niego jest uważany za "w użyciu" (czy to klasa, czy to funkcja, czy to zmienna globalna), kategorie są również ładowane i będą dostępne w czasie wykonywania. Jednak jeśli sam plik obiektowy nie zostanie załadowany, kategorie w nim nie będą dostępne w czasie wykonywania. Plik obiektowy zawierający tylko Kategorie jest nigdy załadowany, ponieważ zawiera brak symboli linker mógłby kiedykolwiek rozważyć "w użyciu". I to jest cały problem.

Zaproponowano kilka rozwiązań, a teraz, gdy wiesz, jak to wszystko gra razem, spójrzmy jeszcze raz na proponowane rozwiązanie:]}

1. Jednym z rozwiÄ…zaÅ„ jest dodanie -all_load do wywoÅ‚ania linkera. Co? czy ta flaga naprawdÄ™ wystarczy? W rzeczywistoÅ›ci mówi linkerowi nastÄ™pujÄ…ce "Load all object files of all archives niezależnie od tego, czy widzisz jakiÅ› symbol w użyciu, czy nie ". OczywiÅ›cie, to zadziaÅ‚a, ale może również produkować dość duże pliki binarne.

2. Innym rozwiÄ…zaniem jest dodanie -force_load do wywoÅ‚ania linkera wraz ze Å›cieżkÄ… do archiwum. Ta flaga dziaÅ‚a dokÅ‚adnie tak jak -all_load, ale tylko dla okreÅ›lonego archiwum. OczywiÅ›cie to również zadziaÅ‚a.

3. Na najpopularniejszym rozwiÄ…zaniem jest dodanie -ObjC do wywoÅ‚ania linkera. Co wÅ‚aÅ›ciwie zrobi ta flaga linkera? Ta flaga mówi linkerowi " zaÅ‚aduj wszystkie pliki obiektowe ze wszystkich archiwów, jeÅ›li widzisz, że zawierajÄ… one dowolny kod Obj-C ". I "dowolny kod Obj-C" obejmuje kategorie. To również zadziaÅ‚a i nie wymusi zaÅ‚adowania plików obiektowych, które nie zawierajÄ… kodu Obj-C (sÄ… one Å‚adowane tylko na żądanie).

4. Innym rozwiÄ…zaniem jest raczej nowe ustawienie kompilacji Xcode Perform Single-Object Prelink. Co bÄ™dzie to ustawienie wystarczy? JeÅ›li jest wÅ‚Ä…czona, wszystkie pliki obiektowe (pamiÄ™taj, że jest jeden na plik źródÅ‚owy) sÄ… scalane razem w jeden plik obiektowy (który nie jest prawdziwym poÅ‚Ä…czeniem, stÄ…d nazwa PreLink) i ten pojedynczy plik obiektowy (czasami nazywany również "plikiem obiektu głównego") jest nastÄ™pnie dodawany do archiwum. JeÅ›li teraz jakikolwiek symbol głównego pliku obiektowego jest rozważany w użyciu, caÅ‚y plik obiektu głównego jest rozważany w użyciu, a zatem wszystkie jego części Objective-C sÄ… zawsze Å‚adowane. A ponieważ zajÄ™cia sÄ… normalne symbole, wystarczy użyć jednej klasy z takiej statycznej biblioteki, aby również uzyskać wszystkie kategorie.

5. Ostatecznym rozwiÄ…zaniem jest trik, który Vladimir dodaÅ‚ na samym koÅ„cu swojej odpowiedzi. Umieść " faÅ‚szywy symbol " w dowolnym pliku źródÅ‚owym deklarujÄ…cym tylko Kategorie. JeÅ›li chcesz użyć którejÅ› z kategorii w czasie wykonywania, upewnij siÄ™, że w jakiÅ› sposób odwoÅ‚ujesz siÄ™ do faÅ‚szywego symbolu podczas kompilacji, ponieważ powoduje to, że plik obiektowy jest Å‚adowany przez linker, a tym samym wszystkie Kod Obj-C w nim. Np. może to być funkcja z pustym ciaÅ‚em funkcji (która nic nie zrobi, gdy zostanie wywoÅ‚ana) lub może to być zmienna globalna, do której można uzyskać dostÄ™p (np. globalna int raz przeczytana lub raz zapisana, to wystarczy). W przeciwieÅ„stwie do wszystkich innych powyższych rozwiÄ…zaÅ„, To rozwiÄ…zanie przenosi kontrolÄ™ nad kategoriami dostÄ™pnymi w czasie wykonywania do skompilowanego kodu (jeÅ›li chce, aby byÅ‚y one poÅ‚Ä…czone i dostÄ™pne, uzyskuje dostÄ™p do symbolu, w przeciwnym razie nie uzyskuje dostÄ™pu do symbolu i linker zignoruje it).

JeÅ›li jednak powiesz linkerowi "martwy Pasek", linker najpierw doda wszystkie pliki obiektowe do pliku binarnego, rozwiąże wszystkie odwoÅ‚ania i na koniec przeskanuje binarne symbole w poszukiwaniu nieużywanych (lub tylko używanych przez inne symbole nieużywane). Wszystkie symbole, które nie sÄ… używane, sÄ… nastÄ™pnie usuwane w ramach etapu optymalizacji. W powyższym przykÅ‚adzie usuwa siÄ™ 99 nieużywanych funkcji jeszcze raz. Jest to bardzo przydatne, jeÅ›li używasz opcji takich jak -load_all, -force_load lub Perform Single-Object Prelink ponieważ te opcje mogÄ… Å‚atwo wysadzić rozmiary binarne dramatycznie w niektórych przypadkach i martwy stripping usunie nieużywany kod i dane ponownie.

Dead stripping działa bardzo dobrze dla kodu C (np. nieużywane funkcje, zmienne i stałe są usuwane zgodnie z oczekiwaniami), a także działa całkiem dobrze dla C++ (np. nieużywane klasy są usuwane). Nie jest idealny, w niektórych przypadkach niektóre symbole nie są usuwane, mimo że byłoby w porządku, aby je usunąć, ale w większości przypadków działa to całkiem dobrze dla tych języków.

MyCoolClass * mcc = [[MyCoolClass alloc] init];

Też bym napisał

NSString * cname = @"CoolClass";
NSString * cnameFull = [NSString stringWithFormat:@"My%@", cname];
Class mmcClass = NSClassFromString(cnameFull);
id mmc = [[mmcClass alloc] init];

W obu przypadkach {[15] } jest odniesieniem do obiektu klasy "MyCoolClass", ale nie ma bezpośredniego odniesienia do tej klasy w drugiej próbce kodu (nawet nazwa klasy jako statyczny łańcuch). Wszystko dzieje się tylko w czasie wykonywania. I to nawet jeśli klasy są w rzeczywistości prawdziwymi symbolami. Jeszcze gorzej jest z kategoriami, ponieważ nie są one nawet prawdziwe symbole.

Więc jeśli masz statyczną bibliotekę z setkami obiektów, ale większość twoich binariów potrzebuje tylko kilku z nich, możesz nie używać powyższych rozwiązań (1) do (4). W przeciwnym razie skończysz z bardzo dużymi binariami zawierającymi wszystkie te klasy, mimo że większość z nich nigdy nie jest używana. Dla klas zwykle nie potrzebujesz żadnego specjalnego rozwiązania, ponieważ klasy mają prawdziwe Symbole i tak długo, jak odwołujesz się do nich bezpośrednio (nie jak w drugiej próbce kodu), linker będzie zidentyfikuj ich użycie całkiem dobrze na własną rękę. W przypadku kategorii rozważ rozwiązanie (5), ponieważ umożliwia ono dołączanie tylko tych kategorii, których naprawdę potrzebujesz.

Np. jeśli chcesz mieć kategorię dla NSData, np. dodając do niej metodę kompresji/dekompresji, utworzysz plik nagłówkowy:

// NSData+Compress.h
@interface NSData (Compression)
    - (NSData *)compressedData;
    - (NSData *)decompressedData;
@end

void import_NSData_Compression ( );

I plik implementacji

// NSData+Compress
@implementation NSData (Compression)
    - (NSData *)compressedData 
    {
        // ... magic ...
    }

    - (NSData *)decompressedData
    {
        // ... magic ...
    }
@end

void import_NSData_Compression ( ) { }

Teraz upewnij siÄ™, że gdziekolwiek w Twoim kodzie import_NSData_Compression() jest wywoÅ‚any. Nie ma znaczenia, gdzie jest wywoÅ‚ywany i jak czÄ™sto jest wywoÅ‚ywany. WÅ‚aÅ›ciwie to nie musi być w ogóle nazywany, wystarczy, jeÅ›li linker tak myÅ›li. Możesz np. umieÅ›cić w dowolnym miejscu swojego projektu nastÄ™pujÄ…cy kod:

__attribute__((used)) static void importCategories ()
{
    import_NSData_Compression();
    // add more import calls here
}

Nie musisz nigdy wywoÅ‚ywać importCategories() w swoim kodzie, atrybut sprawi, że kompilator i linker uwierzÄ…, że zostaÅ‚ wywoÅ‚any, nawet jeÅ›li tak nie jest.

I ostatnia wskazówka:
JeÅ›li dodasz -whyload do koÅ„cowego wywoÅ‚ania Å‚Ä…cza, linker wyÅ›wietli w dzienniku budowy plik obiektu, z którego biblioteki zostaÅ‚ zaÅ‚adowany, ponieważ w tym symbol w użyciu. WyÅ›wietli tylko pierwszy symbol rozważany w użyciu, ale niekoniecznie jest to jedyny symbol używany w tym pliku obiektowym.

Ten problem zostaÅ‚ naprawiony w LLVM . Poprawka jest dostarczana jako część LLVM 2.9 pierwszÄ… wersjÄ… Xcode zawierajÄ…cÄ… poprawkÄ™ jest Xcode 4.2 WysyÅ‚ka z LLVM 3.0. użycie -all_load LUB -force_load nie jest już potrzebne podczas pracy z XCode 4.2 -ObjC jest nadal potrzebny.

Oto, co musisz zrobić, aby całkowicie rozwiązać ten problem podczas kompilacji statycznej biblioteki:

Albo przejdź do Xcode Build Settings i ustaw Wykonywanie pojedynczego obiektu Prelink na yes lub GENERATE_MASTER_OBJECT_FILE = YES w pliku konfiguracyjnym build.

Domyślnie linker generuje .o plik dla każdego .plik M. Więc kategorie się różnią .o files. Gdy linker patrzy na statyczną bibliotekę .o plikach, nie tworzy indeksu wszystkich symboli na klasę (Runtime będzie, nie ma znaczenia co).

Ta dyrektywa poprosi linkera o spakowanie wszystkich obiektów w jeden duży .o pliku i przez to wymusza linker, który przetwarza bibliotekę statyczną, aby uzyskać indeks wszystkich kategorii klas.

Jednym z czynników, o którym rzadko się wspomina, gdy pojawia się dyskusja o linkowaniu biblioteki statycznej, jest fakt, że musiszrównież zawierać same kategorie w fazach budowania->Kopiuj pliki i kompilować źródła samej biblioteki statycznej .

Apple również nie podkreśla tego faktu w swoich niedawno opublikowanych przy użyciu bibliotek statycznych w iOS .

Spędziłem cały dzień próbując różnych odmian-objC i-all_load itp.. ale nic nie wyszło z to.. To pytanie zwróciło moją uwagę na tę kwestię. (nie zrozum mnie źle.. nadal musisz robić rzeczy objective.. ale to nie tylko to).

Kolejną akcją, która zawsze mi pomagała, jest to, że zawsze samodzielnie buduję dołączoną bibliotekę statyczną.. następnie buduję aplikację..

Prawdopodobnie musisz mieć kategorię w nagłówku "public" biblioteki statycznej: # import " MyStaticLib.h "