Библиотека? Статическая? Динамический? Или Рамки? Проект внутри другого проекта

У меня есть приложение для iOS, и я хочу добавить большой кусок кода, который я разрабатывал, как еще один проект, просто для удобства тестирования. Новый блок в основном связан с сохранением изображения в различных службах обмена и т.д. Поскольку этот код совместного использования требует большого тестирования и последующего обновления, мне было интересно, как лучше всего внедрить этот фрагмент кода в мое существующее приложение.

Я не знаю, должна ли это быть статическая библиотека, динамическая библиотека или фреймворк, и, честно говоря, я не совсем уверен, в чем разница, или как мне это сделать и настроить в Xcode.

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

Ответ 1

Во-первых, некоторые общие определения (специфичные для iOS):

Статическая библиотека - единица кода, связанная во время компиляции, которая не изменяется.

Однако в статических библиотеках iOS не разрешено содержать изображения/активы (только код). Вы можете обойти эту проблему, используя медиа-пакет.

Лучшее, более формальное определение можно найти в Википедии здесь.

Динамическая библиотека - единица кода и/или активов, связанных во время выполнения, которые могут измениться.

Однако, только Apple разрешено создавать динамические библиотеки для iOS. Вы не можете создавать их, так как это отклонит ваше приложение. (См. этот другое сообщение SO для подтверждения и аргументации на таких).

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

Подробнее см. Wiki в Software Framework.

Следовательно, на iOS ваш единственный вариант - это в основном использовать статическую библиотеку или статическую фреймворк (основное отличие состоит в том, что статическая структура распределяется как скомпилированный файл .a чаще всего, тогда как статическая библиотека может просто включаться как подпроект - вы можете увидеть весь код, который сначала скомпилирован, и полученный в результате файл .a, используемый в качестве проекта проектом).

Теперь, когда мы ясно (er) на этих условиях, настройка статической библиотеки и поддержка медиа-пакета для iOS не слишком сложна, и есть много руководств о том, как это сделать. Я лично рекомендовал бы это:

https://github.com/jverkoey/iOS-Framework

Это довольно прямолинейное руководство и не имеет недостатка в работе с "поддельными статическими библиотеками"... проверьте его для получения дополнительной информации...

После создания вашей статической библиотеки это так же просто, как включение в него подмодуля внутри Git для использования в разных проектах.

Удачи.

ИЗМЕНИТЬ

Что касается подпроекта внутри проекта, насколько мне известно, чтобы это правильно работало/компилировалось, вам, по сути, нужно настроить цепочку компиляции, в которой сначала скомпилирован подпроект, который создает файл статической структуры .a который используется в качестве зависимости от проекта.

Вот еще один полезный учебник, в котором говорится об этом:

http://www.cocoanetics.com/2011/12/sub-projects-in-xcode/

РЕДАКТИРОВАТЬ 2

Начиная с iOS 8, Apple теперь позволяет разработчикам создавать динамические фреймворки! (Примечание: ваше приложение должно иметь минимальную цель для iOS 8, чтобы включить динамическую структуру... back porting не разрешен.)

Это было добавлено как новый шаблон проекта. В Xcode 6.1 это можно найти по адресу:

New Project -> iOS -> Framework & Library -> Cocoa Touch Framework

Ответ 2

Библиотеки и рамки

Мартин Фаулер в InversionOfControl

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

Framework воплощает в себе некоторый абстрактный дизайн, с большим количеством встроенного поведения. Чтобы использовать его, вам нужно вставить свое поведение в различные места фреймворка либо путем создания подклассов, либо путем подключения ваших собственных классов. Код платформы затем вызывает ваш код в этих точках. Основной элемент управления программы перевернут, отодвинут от вас в рамки. (Инверсия контроля)

Формат файла Mach-O (.o)

Для создания программ разработчики конвертируют исходный код в объектные файлы. Объектные файлы затем упаковываются в исполняемый код или статические библиотеки.

Когда вы компилируете исходные файлы, вы в основном создаете объектные файлы, используя формат файла Mach-O (Mach Object)^[About] Эти файлы являются основными строительными блоками ваших приложений, сред и библиотек. (динамический и статический).

Библиотеки и фреймворки на iOS

Library - это набор ресурсов и сам код, скомпилированный для одной или нескольких архитектур. Он состоит из Mach-O объектных файлов^{[check static or dynamic]}

Static library - .a (он же static archive library, static linked shared library^doc) - при связывании такой библиотеки с приложением static linker во время времени компиляции будет собирать объектные файлы из библиотеки и упакуйте их вместе с кодом объекта приложения в один исполняемый файл.

Начиная с Xcode 9.0, поддерживается статическая библиотека Swift.

Dynamic library - .dylib (он же dynamic shared library, shared object, dynamically linked library^doc) динамически связаны с исполняемым файлом приложения при загрузке или время выполнения, но не копируется в него.

Все системные библиотеки iOS и macOS - dynamic. Следовательно, наши приложения выиграют от будущих улучшений, которые Apple внесет в стандартные библиотечные фреймворки без создания и доставки новых сборок.

text-based stub library - .tbd, которые предоставляют гораздо более компактную версию заглушки dynamic library для использования в SDK и помогают значительно уменьшить размер ее загрузки.

Bundle - это файловый каталог с подкаталогами внутри. В iOS bundles служат для удобной отправки связанных файлов в одном пакете - например, изображений, перьев или скомпилированного кода. Система обрабатывает его как один файл, и вы можете получить доступ к ресурсам пакета, не зная его внутренней структуры.

Framework - .framework - это bundle или пакет, содержащий static or dynamic library^{[static vs dynamic framework]}, заголовочные файлы и ресурсы. Фреймворки - очень удобный способ сгруппировать связанные ресурсы, предоставить исполняемый файл вместе с общедоступными заголовками в одном пакете, который легко установить.

Static framework содержит static library, упакованный с его ресурсами.

Dynamic framework содержит dynamic library с его ресурсами. В дополнение к этому, dynamic framework может удобно включать разные версии одного и того же dynamic library в одну и ту же структуру!

Embedded framework является Dynamic framework и помещается в изолированную программную среду приложений и доступна только для этого приложения. Этот тип был создан в первую очередь для расширения для совместного использования общего кода и ресурсов. Он доступен, когда целью развертывания является iOS 8+.

Umbrella framework^{[Aggregate target]} - это пакет фреймворков, который содержит другие фреймворки (он же Nested Framework). Хотя создание зонтичных сред возможно, но для большинства разработчиков это не нужно и не рекомендуется. ^{[Official doc]}

Fake Framework - Фальшивый фреймворк - это обычная техника "преобразования" пакета в фреймворк, но на самом деле это bundle. Например, когда вы создаете свой собственный фреймворк и используете внутри него стороннюю библиотеку, вы можете отправить свой код и стороннюю библиотеку вместе (как один фреймворк). Одна из реализаций поддельных рамок.

Universal Library or Framework (он же Fat)^[lipo] ^{[Aggregate target]} ^{[Could not find module for architecture]} - содержит несколько архитектур. Текущие настройки вы можете проверить в Build Active Architecture Only^{[ONLY_ACTIVE_ARCH]}

Симулятор - x86_64, i386
Устройство - armv7, armv7s, arm64

Этот подход используется, когда вы используете общий двоичный файл. В результате потребитель должен иметь возможность работать с вашим фреймворком на реальном устройстве и симуляторе. Например, CocoaPods^[About] создайте его для модуля с закрытым исходным кодом

Зависимость^[About]

Зависимости - это просто предпосылки для построения цели. Целевое управление зависимостями - один из более сложных аспектов в XCode. Понимание набора инструментов Xcodes и конфигурации среды сборки помогает сделать зависимости более управляемыми.

Как создать и использовать статическую библиотеку:

[Swift customer → Swift статическая библиотека]
[Swift customer → статическая библиотека Objective-C]
[Потребитель Objective-C → Swift статическая библиотека]
[Потребитель Objective C → статическая библиотека Objective C]

Как создать и использовать динамический каркас^{[change to static]}

[Swift customer → Swift динамические рамки]
[Быстрый потребитель → Динамическая структура Objective-C]
[Потребитель Objective-C → Swift динамическая структура]
[Потребитель Objective C → Динамическая структура Objective C]

[Система сборки XCode]
[Компоненты XCode]

Ссылки

Подробнее здесь, здесь, здесь, здесь, здесь, здесь, здесь

Ответ 3

Вы также можете создать файл .podspec для CocoaPods (http://guides.cocoapods.org/making/private-cocoapods.html#1.-create-a-private-spec-repo) и использовать его, как и любой другой модуль, с той лишь разницей, что это ваш я не уверен, что произойдет, если ваш модуль должен создать модель CoreData, но это не так, как я понимаю).