Категории Objective-C в статической библиотеке

Question

Можете ли вы рассказать мне, как правильно связать статическую библиотеку с проектом iPhone. Я использую статический проект библиотеки, добавленный в проект приложения в качестве прямой зависимости (цель -> общие -> прямые зависимости), и все работает нормально, но категории. Категория, определенная в статической библиотеке, не работает в приложении.

Итак, мой вопрос, как добавить статическую библиотеку с некоторыми категориями в другой проект?

И вообще, что лучше всего использовать в коде проекта приложения из других проектов?

Answer 1

Решение: Начиная с Xcode 4.2, вам нужно всего лишь перейти к приложению, которое связывается с библиотекой (не с самой библиотекой), и щелкнуть проект в Навигаторе проекта, щелкнуть цель вашего приложения, затем настроить параметры, а затем выполнить поиск "Другое". Флаги компоновщика ", нажмите кнопку + и добавьте '-ObjC'. "-all_load" и "-force_load" больше не нужны.

Детали: Я нашел ответы на различные форумы, блоги и документы Apple. Теперь я попытаюсь сделать краткое изложение моих поисков и экспериментов.

Проблема была вызвана (цитата из технических вопросов и ответов Apple QA1490 https://developer.apple.com/library/content/qa/qa1490/_index.html):

Objective-C не определяет символы компоновщика для каждой функции (или метода в Objective-C) - вместо этого символы компоновщика генерируются только для каждого класса. Если вы расширяете ранее существующий класс категориями, компоновщик не знает, как связать объектный код реализации базового класса и реализации категории. Это препятствует тому, чтобы объекты, созданные в получающемся приложении, отвечали на селектор, который определен в категории.

И их решение:

Чтобы решить эту проблему, статическая библиотека должна передать компоновщику опцию -ObjC. Этот флаг заставляет компоновщик загружать каждый объектный файл в библиотеке, который определяет класс или категорию Objective-C. Хотя этот параметр обычно приводит к увеличению размера исполняемого файла (из-за загрузки в приложение дополнительного объектного кода), он позволяет успешно создавать эффективные статические библиотеки Objective-C, которые содержат категории в существующих классах.

и есть также рекомендации в FAQ по разработке iPhone:

Как связать все классы Objective-C в статической библиотеке? Установите для параметра сборки других флагов компоновщика значение -ObjC.

и описания флагов:

-all_load Загружает всех членов статических архивных библиотек.

-ObjC Загружает все члены статических архивных библиотек, которые реализуют класс или категорию Objective-C.

-force_load (path_to_archive) Загружает всех членов указанной статической архивной библиотеки. Примечание: -all_load заставляет всех участников всех архивов быть загруженными. Эта опция позволяет вам ориентироваться на определенный архив.

* мы можем использовать force_load, чтобы уменьшить двоичный размер приложения и избежать конфликтов, которые all_load может вызвать в некоторых случаях.

Да, это работает с *.a файлами, добавленными в проект. Но у меня были проблемы с проектом lib, добавленным как прямая зависимость. Но позже я обнаружил, что это была моя вина - проект прямой зависимости, возможно, не был добавлен должным образом. Когда я удаляю это и добавляю снова с шагами:

1. Перетащите файл проекта lib в проект приложения (или добавьте его с помощью Project->Add to project…).
2. Нажмите стрелку на значке проекта lib - показано имя файла mylib.a, перетащите этот файл mylib.a и поместите его в группу Target -> Link Binary With Library.
3. Откройте информацию о цели на первой странице (Общие) и добавьте мою библиотеку в список зависимостей

после этого все работает ок. Флаг "-ObjC" был достаточно в моем случае.

Меня также заинтересовала идея из блога http://iphonedevelopmentexperiences.blogspot.com/2010/03/categories-in-static-library.html. Автор говорит, что он может использовать категорию из lib, не устанавливая флаг -all_load или -ObjC. Он просто добавляет в категорию h/m файлы пустой фиктивный интерфейс класса / реализации, чтобы заставить линкер использовать этот файл. И да, этот трюк делает свою работу.

Но автор также сказал, что он даже не создан экземпляр пустышки. Мм… Как я обнаружил, мы должны явно вызывать некоторый "настоящий" код из файла категории. Так что, по крайней мере, должна быть вызвана функция класса. И нам даже не нужен фиктивный класс. Одиночная функция c делает то же самое.

Так что, если мы напишем lib файлы как:

// mylib.h
void useMyLib();

@interface NSObject (Logger)
-(void)logSelf;
@end


// mylib.m
void useMyLib(){
    NSLog(@"do nothing, just for make mylib linked");
}


@implementation NSObject (Logger)
-(void)logSelf{
    NSLog(@"self is:%@", [self description]);
}
@end

и если мы вызываем useMyLib(); в любом месте проекта App, затем в любом классе мы можем использовать метод категории logSelf;

[self logSelf];

И еще блоги по теме:

http://t-machine.org/index.php/2009/10/13/how-to-make-an-iphone-static-library-part-1/

http://blog.costan.us/2009/12/fat-iphone-static-libraries-device-and.html

Answer 2

Ответ от Владимира на самом деле довольно хороший, однако я хотел бы дать здесь несколько дополнительных знаний. Может быть, однажды кто-нибудь найдет мой ответ и может найти его полезным.

Компилятор преобразует исходные файлы (.c, .cc, .cpp, .m) в объектные файлы (.o). В исходном файле есть один объектный файл. Объектные файлы содержат символы, код и данные. Объектные файлы не могут использоваться непосредственно операционной системой.

Теперь при создании динамической библиотеки (.dylib), инфраструктуры, загружаемого пакета (.bundle) или исполняемого двоичного файла эти объектные файлы связываются вместе компоновщиком для создания чего-то, что операционная система считает "пригодным для использования", например что-то, что может напрямую загружать на определенный адрес памяти.

Однако при создании статической библиотеки все эти объектные файлы просто добавляются в большой архивный файл, отсюда и расширение статических библиотек (.a для архива). Таким образом, файл.a - это не что иное, как архив объектных (.o) файлов. Подумайте об архиве TAR или ZIP-архиве без сжатия. Просто проще скопировать один файл.a вокруг, чем целую кучу файлов.o (аналогично Java, где вы упаковываете файлы.class в архив.jar для легкого распространения).

При связывании двоичного файла со статической библиотекой (= архив), компоновщик получит таблицу всех символов в архиве и проверит, на какие из этих символов ссылаются двоичные файлы. Только объектные файлы, содержащие ссылочные символы, фактически загружаются компоновщиком и учитываются процессом компоновки. Например, если в вашем архиве 50 объектных файлов, но только 20 содержат символы, используемые двоичным файлом, только те 20 загружаются компоновщиком, остальные 30 полностью игнорируются в процессе компоновки.

Это работает очень хорошо для кода на C и C++, поскольку эти языки пытаются сделать как можно больше во время компиляции (хотя C++ также имеет некоторые функции только для времени выполнения). Obj-C, однако, это другой тип языка. Obj-C в значительной степени зависит от функций времени выполнения, и многие функции Obj-C фактически являются функциями только времени выполнения. Классы Obj-C на самом деле имеют символы, сравнимые с функциями C или глобальными переменными C (по крайней мере, в текущей среде выполнения Obj-C). Компоновщик может видеть, есть ли ссылка на класс или нет, поэтому он может определить, используется ли класс или нет. Если вы используете класс из объектного файла в статической библиотеке, этот объектный файл будет загружен компоновщиком, поскольку компоновщик видит используемый символ. Категории являются функцией только времени выполнения, категории не являются символами, такими как классы или функции, и это также означает, что компоновщик не может определить, используется ли категория или нет.

Если компоновщик загружает объектный файл, содержащий код Obj-C, все его части Obj-C всегда являются частью этапа компоновки. Таким образом, если объектный файл, содержащий категории, загружен, поскольку любой символ из него считается "используемым" (будь то класс, будь то функция, будь то глобальная переменная), категории также загружаются и будут доступны во время выполнения., Тем не менее, если сам объектный файл не загружен, категории в нем не будут доступны во время выполнения. Объектный файл, содержащий только категории, никогда не загружается, поскольку он не содержит символов, которые компоновщик мог бы считать "используемыми". И это вся проблема здесь.

Было предложено несколько решений, и теперь, когда вы знаете, как все это работает вместе, давайте еще раз посмотрим на предлагаемое решение:

1. Одним из решений является добавление -all_load на вызов компоновщика. Что на самом деле будет делать этот флаг компоновщика? На самом деле он сообщает компоновщику следующее: " Загрузите все объектные файлы всех архивов, независимо от того, видите ли вы какой-либо используемый символ или нет ". Конечно, это будет работать, но он также может создавать довольно большие двоичные файлы.

2. Другое решение состоит в том, чтобы добавить -force_load на вызов компоновщика, включая путь к архиву. Этот флаг работает так же, как -all_load, но только для указанного архива. Конечно, это будет работать.

3. Самое популярное решение - добавить -ObjC на вызов компоновщика. Что на самом деле будет делать этот флаг компоновщика? Этот флаг сообщает компоновщику " Загружать все объектные файлы из всех архивов, если вы видите, что они содержат какой-либо код Obj-C ". И "любой код Obj-C" включает в себя категории. Это также будет работать и не заставит загружать объектные файлы, не содержащие кода Obj-C (они все еще загружаются только по требованию).

4. Другое решение - довольно новая настройка сборки XCode Perform Single-Object Prelink, Что будет делать этот параметр? Если этот параметр включен, все объектные файлы (помните, по одному на исходный файл) объединяются в один объектный файл (который не является реальной связью, отсюда и название PreLink) и этот единственный объектный файл (иногда также называемый "мастер-объектом"). файл ") затем добавляется в архив. Если теперь какой-либо символ главного объектного файла рассматривается как используемый, весь главный объектный файл считается используемым, и, следовательно, все его части Objective C всегда загружаются. А поскольку классы являются обычными символами, достаточно использовать один класс из такой статической библиотеки, чтобы также получить все категории.

5. Окончательное решение - трюк, который Владимир добавил в самом конце своего ответа. Поместите " поддельный символ " в любой исходный файл, объявляющий только категории. Если вы хотите использовать какую-либо из категорий во время выполнения, убедитесь, что вы каким-то образом ссылаетесь на фальшивый символ во время компиляции, так как это вызывает загрузку объектного файла компоновщиком и, следовательно, также весь код Obj-C в нем. Например, это может быть функция с пустым телом функции (которая ничего не будет делать при вызове) или глобальная переменная (например, глобальная переменная) int достаточно прочитать или написать один раз). В отличие от всех других решений, приведенных выше, это решение переносит контроль над тем, какие категории доступны во время выполнения для скомпилированного кода (если он хочет, чтобы они были связаны и доступны, он обращается к символу, в противном случае он не обращается к символу, и компоновщик будет игнорировать Это).

Это все, ребята.

Ой, подождите, есть еще одна вещь:
У компоновщика есть опция с именем -dead_strip, Что делает этот вариант? Если компоновщик решил загрузить объектный файл, все символы объектного файла становятся частью связанного двоичного файла, независимо от того, используются они или нет. Например, объектный файл содержит 100 функций, но только одна из них используется двоичным файлом, все 100 функций все еще добавляются в двоичный файл, поскольку объектные файлы либо добавляются целиком, либо не добавляются вообще. Частичное добавление объектного файла обычно не поддерживается компоновщиками.

Однако, если вы скажете компоновщику "мертвую полосу", компоновщик сначала добавит все объектные файлы в двоичный файл, разрешит все ссылки и, наконец, просканирует двоичный файл на наличие символов, которые не используются (или используются только другими символами, не находящимися в использования). Все символы, которые были найдены неиспользуемыми, затем удаляются как часть этапа оптимизации. В приведенном выше примере 99 неиспользуемых функций снова удаляются. Это очень полезно, если вы используете такие параметры, как -load_all, -force_load или же Perform Single-Object Prelink потому что в некоторых случаях эти параметры могут значительно увеличить размер двоичных файлов, а мертвое удаление снова удалит неиспользуемый код и данные.

Мертвое извлечение работает очень хорошо для кода C (например, неиспользуемые функции, переменные и константы удаляются, как и ожидалось), и это также работает довольно хорошо для C++ (например, удаляются неиспользуемые классы). Он не идеален, в некоторых случаях некоторые символы не удаляются, хотя было бы неплохо удалить их, но в большинстве случаев это работает довольно хорошо для этих языков.

Что насчет Obj-C? Забудь об этом! Там нет мертвых раздевания для Obj-C. Поскольку 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 до последнего вызова ссылки компоновщик выведет в журнал сборки, какой объектный файл из какой библиотеки он загружал из-за того, какой символ используется. Он будет печатать только первый символ, который считается используемым, но это не обязательно единственный символ, используемый в этом объектном файле.

Answer 3

Эта проблема была исправлена ​​в LLVM. Исправление поставляется как часть LLVM 2.9. Первая версия Xcode, в которой содержится исправление, - это поставка Xcode 4.2 с LLVM 3.0. Использование -all_load или же -force_load больше не требуется при работе с XCode 4.2 -ObjC все еще нужно

Answer 4

Вот что вам нужно сделать, чтобы полностью решить эту проблему при компиляции статической библиотеки:

Либо перейдите в Настройки сборки Xcode и установите Perform Single Object Prelink на YES, либо GENERATE_MASTER_OBJECT_FILE = YES в вашем файле конфигурации сборки.

По умолчанию компоновщик создает файл.o для каждого файла.m. Так что категории получают разные.o файлы. Когда компоновщик просматривает статическую библиотеку.o файлов, он не создает индекс всех символов на класс (время выполнения будет, неважно, что).

Эта директива попросит компоновщик упаковать все объекты вместе в один большой файл.o и тем самым вынудит компоновщик, который обрабатывает статическую библиотеку, получить индекс всех категорий классов.

Надеюсь, что это проясняет.

Answer 5

Один из факторов, который редко упоминается при обсуждении ссылок на статические библиотеки, заключается в том, что вы также должны включать сами категории в фазы сборки -> копировать файлы и компилировать источники самой статической библиотеки.

Apple также не подчеркивает этот факт в своих недавно опубликованных статьях Использование статических библиотек в iOS.

Я провел целый день, пробуя всевозможные варианты -objC, -all_load и т. Д., Но ничего из этого не вышло... этот вопрос привлек мое внимание к этой проблеме. (не поймите меня неправильно... вам все равно придется делать вещи -objC... но это больше, чем просто).

еще одно действие, которое всегда помогало мне, - это то, что я всегда сначала собираю включенную статическую библиотеку самостоятельно, а затем создаю прилагаемое приложение.

Answer 6

Возможно, вам нужно иметь категорию в заголовке вашей публичной статической библиотеки: #import "MyStaticLib.h"