Різниця між фреймворком і статичною бібліотекою в xcode4 і способом їх виклику


133

Я абсолютно новачок у кодексі xcode та aim-c. Я хочу задати дуже основне питання.

Я бачив, що "прив'язуючи бінарне до бібліотек" в налаштуваннях проекту, існують відмінності щодо фреймворку та бібліотек, імпортованих з інших проектів у робочу область.

Перше запитання, чому існують рамки? І чому там бібліотека? Не може моя бібліотека бути основою?

І тоді, з .h файлу, як я можу викликати класи зі своєї імпортованої статичної бібліотеки?

Я думаю, має бути префікс, але я не міг його знайти. Ні "ProjName / Myclass.h" не працюють.

Будь ласка, будьте максимально конкретними.

Дякую


Не основне питання
Масіх

Відповіді:


140

Найбільшою перевагою, яку має рамка перед статичними бібліотеками, є те, що вони діють як акуратний спосіб упаковки складених бібліотечних бінарних файлів та будь-яких пов'язаних із ними заголовків. Вони можуть бути включені у ваш проект (як і вбудовані рамки SDK, такі як Foundation та UIKit), і вони повинні працювати (більшість часу).

Більшість фреймворків містять динамічні бібліотеки; рамки, створені в Xcode за допомогою шаблону Mac Framework, створять динамічну бібліотеку. IPhone не підтримує динамічні рамки, і тому стало загальним для того, щоб бібліотеки багаторазового використання коду iOS поширювались як статичні бібліотеки.

Статичні бібліотеки в порядку, але вони вимагають трохи додаткової роботи з боку користувача. Вам потрібно зв’язати свій проект з бібліотекою, і вам потрібно скопіювати файли заголовків у проект або посилати їх кудись, встановивши відповідні шляхи пошуку заголовків у налаштуваннях збірки.

Отже: підсумовуючи, моя думка полягає в тому, що найкращий спосіб розповсюдження вашої бібліотеки - це рамки. Щоб створити "статичний" фреймворк для iOS, ви, по суті, можете взяти звичайний фреймворк та замінити бінарний файл на зібрану статичну бібліотеку. Ось як я розповсюджую одну зі своїх бібліотек, Resty, і так я маю намір розповсюджувати свої бібліотеки в майбутньому.

Ви можете поглянути на доданий Rakefile у цьому проекті (якщо ви цього не знаєте, Rake є еквівалентом Ruby Make). У мене є кілька завдань щодо складання мого проекту (використання xcodebuild) та упаковки їх як статичної основи для iOS. Вам це повинно бути корисним.

Крім того, ви можете використовувати ці шаблони Xcode 4 для створення фреймворку iOS.

Оновлення 9 грудня 2013 року : це популярна відповідь, тому я подумав редагувати, щоб сказати, що мій перший вибір для розповсюдження бібліотеки змінився. Мій перший вибір для будь-якої сторонньої бібліотеки як споживача чи виробника - це CocoaPods. Я поширюю свої бібліотеки за допомогою CocoaPods і пропоную попередньо складену статичну бібліотеку з заголовками як варіант резервного копіювання.


1
Тож бібліотеки можуть бути або статичними, і динамічними, а рамки - це просто група бібліотек, яка також може бути або динамічною, або статичною, це правильне розуміння?
Тоні

Схоже, що рамкова ціль Xcode також дозволяє копіювати заголовки, але не зв'язувати ресурси. Чи можуть статичні бібліотеки також містити заголовки?
Тоні

Наступне запитання: чи не має значення, чи ви створили рамку за допомогою налагодження чи дистрибуції? Тому що в іншому випадку розподіл має менший слід.
Олдріч Ко

2
@GoRoS так, я роблю; насправді я просто провів деяку роботу для клієнта, зробивши його приватний SDK доступним за допомогою CocoaPods. Трюк полягає в тому, щоб мати публічне репо зі складеною статичною бібліотекою, заголовками та підспеками, що вказують на це, і приватне репо з вашим джерелом. В ідеалі у вас є якийсь CI / автоматизація, щоб перевірити ваше приватне репо, скомпілювати та оновити ваше загальнодоступне репо, підтримуючи це синхронізація. Використовуйте теги, щоб тегувати фактичні версії з версією у публічному репо-репортажі (і, ймовірно, і в приватному репо-репортажі, щоб ви знали, який джерело комісій був використаний для створення публічного випуску).
Люк Редпат

1
@LukeRedpath ваше рішення з CI звучить досить ідеально ... чи знаєте ви про якусь хорошу статтю / блог з підручником, як його налаштувати? В ідеалі з Дженкінсом
micromanc3r

19

в основному, фреймворки є АБО бібліотеками і забезпечують зручний механізм роботи з ними. Якщо ви заглянете "всередину" рамки, це просто каталог, що містить статичну бібліотеку та файли заголовків (у деяких структурах папок з метаданими).

Якщо ви хочете створити свій власний фреймворк, вам слід створити "статичну бібліотеку" і запакувати її певним чином. див. це питання

Взагалі, фреймворки на платформах використовуються для поведінки багаторазового використання, коли ви додаєте власний код "у існуючий фреймворк". якщо ви хочете мати якусь конкретну функціональність, ви можете скористатися бібліотекою (наприклад, три20) і запакувати її у розповсюджуваний додаток


1
Зауважте, що немає вимоги, що рамка повинна містити статичну бібліотеку. Насправді в Mac OS X більшість фреймів не містять статичних бібліотек - натомість містять динамічні бібліотеки.

дякую, це зрозуміло, але як я можу викликати клас у статичній бібліотеці з файлу .m? Чи достатньо викликати #import "MyClass.h", окрім додавання у "посилання бінарних файлів з бібліотеками"?
Леонардо

@Bavarious ти маєш рацію, я повинен був писати лише "бібліотеки" ^^; все-таки існує майже будь-який фреймворк без бібліотек - у більшості випадків ви посилаєтесь на рамки для компіляції, і бібліотека присутня в цільовій системі. це знову така поведінка та функціональність
Мартін Уллріх

@ Леонардо так, в основному це те, що ти повинен зробити. Просто переконайтесь, що .h-файли десь на вашому шляху. Якщо у вас є XCode-проект libaray, ви можете включити проект та його ціль як залежність, щоб ви отримали більше функцій налагодження та .h-файли на своєму шляху
Martin Ullrich

Я розгублений, я вважав, що ваша відповідь була правильною, але я побачив, що вона позначена як "-1"?!?!?! По-друге, бібліотека є частиною робочого простору і правильно пов'язана з основним проектом. Але я все одно отримую "клас не знайдено" у рядку "#import" MyClass.h "'під час створення програми. Я знаю, що є хитрість зробити так, щоб він працював.
Леонардо
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.