Мне действительно нужно создать статическую библиотеку iOS для внутреннего кода?

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

Я нашел несколько полезных ответов о том, что такое статическая библиотека и как ее создать.

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

Я также нашел ответы на вопрос о том, как использовать ресурсы в библиотеке:

Библиотека iOS с ресурсами

Мой вопрос:

Мне действительно нужно создать статическую библиотеку, или я должен просто создать класс для внутреннего кода?

условия:

  1. У меня есть три проекта, для которых требуется специальный механизм кодирования и декодирования.
  2. Функции двигателя включают криптографию, передачу IP-пакетов и аппаратное двоичное кодирование.
  3. Менее 20 функций.
  4. Мы никогда не выпустим этот движок стороннему разработчику или с открытым исходным кодом.

Еще один способ спросить:

В каких обстоятельствах я должен создавать статическую библиотеку?

2 Solutions collect form web for “Мне действительно нужно создать статическую библиотеку iOS для внутреннего кода?”

На мой взгляд, создание статической библиотеки имеет следующие преимущества:

  1. Распространение кода. Это самая большая причина (возможно, единственная причина) разработчиков создать статическую библиотеку. Он запутывает фактический код и предоставляет методы API. Но поскольку вы прямо упомянули, что этот «пакет библиотеки» никогда не будет распространен среди сторонних разработчиков, эта причина может не применяться.
  2. Повторное использование кода. Это другая причина, о которой я могу думать. Но тогда можно добиться повторного использования кода, просто используя классы в файлах ( .m ), имея определения методов в файле заголовка и импортируя файл заголовка (файлы .h ). Так что это не большая причина для создания статической библиотеки.

Я не знаю о каких-либо преимуществах производительности из-за статически связанного кода. Кроме того, создание статической библиотеки имеет свои собственные накладные расходы на обслуживание. Это было бы не так просто, как создание одной сборки. Вы должны иметь в виду ссылку на статическую библиотеку, поддержку совместимости и т. Д.

Поэтому в вашем случае создание статической библиотеки может не иметь особого смысла.

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

Как упоминает Шрикар Аппал , выгоды от создания статической библиотеки: 1) Распределение кода , 2) Повторное использование кода , и я также хотел бы добавить: 3) Версии , 4) Проверка ( квеста к комментариям BergQuester ниже) и 5 ) Документация .

Давайте посмотрим на них более внимательно:

1) Распределение кода

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

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

В качестве альтернативы вместо этого вы можете включить проект статической библиотеки в качестве подпроекта для различных основных проектов, что делает его зависимым от основного проекта … см. https://github.com/jverkoey/iOS-Framework для того, как это можно настроить ,

2) Повторное использование кода

Даже в самых разных приложениях вы часто обнаружите, что выполняете ту же задачу, для которой вы ранее написали код. Если вы эффективный разработчик, вам не захочется снова писать тот же код … вместо этого вы хотите просто добавить свой ранее написанный, отполированный код.

Вы можете сказать, But I can just include the classes directly .

Что делать, если ваш код не обязательно polished ? Или, как это обычно бывает, рамки, которые он использует, меняются со временем?

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

Также не стоит беспокоиться о том, что на него накладывались другие разработчики, зависящие от конкретного проекта, – основной проект не может (или в случае статической библиотеки, включенной в качестве подпроекта, не должен ) изменять набор кодов статической библиотеки.

Это имеет дополнительное преимущество: если кому-то нужно изменить набор статических библиотек, он должен внести изменения таким образом, чтобы все проекты, опираясь на него, все равно могли бы использовать его (без хакеров для конкретных проектов).

3) Управление версиями

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

Что делать, если один проект исправляет некоторые ошибки, а другой проект исправляет другие ошибки в этом наборе классов? Возможно, вы не знаете, как объединить эти изменения (что, если две команды работают отдельно даже на них)? Или каждый проект может исправить одни и те же ошибки!

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

4) Испытание

Поскольку iOS продолжает развиваться как платформа, модульная проверка вашего кода становится все более распространенной. Apple даже продолжает строить и расширять рамки тестирования (XCTest), чтобы упростить и ускорить работу разработчиков iOS для модульных тестов.

Хотя вы могли (и, IMHO, должны ) записывать модульные тесты для вашего кода на уровне приложений, создание и инкапсуляция кода с помощью статических библиотек IN обычно делает эти тесты более удобными и удобными в обслуживании .

Тесты лучше, потому что хорошо спроектированные статические библиотеки инкапсулируют целенаправленную функциональность (то есть хорошо спроектированная библиотека выполняет определенную задачу, например, сетевые задачи), что упрощает «единицу» тестирования кода.

То есть хорошо спроектированная статическая библиотека намеревается выполнить предопределенную «цель», поэтому, по существу, она создает границы тестирования естественным образом (например, создание сетей и представление извлеченных данных, вероятно, будут по меньшей мере двумя отдельными библиотеками).

Тесты легче поддерживать, поскольку они будут находиться в одном хранилище (например, Git repo) в качестве статического библиотечного кода (и тем самым обновляться и обновляться вместе с этим кодом). Точно так же, как вы не хотите копировать и вставлять код из проекта в проект, вы также не хотите копировать и вставлять тесты.

5) Документация

Как и модульное тестирование, онлайн-документация продолжает становиться более важной в iOS.

В то время как вы можете (и снова IMHO, должен ) документировать код на уровне приложения, его лучше и проще поддерживать, если он находится на уровне статической библиотеки (по тем же соображениям, что и тестирование модулей выше).


Поэтому, чтобы ответить на ваш вопрос,

Мне действительно нужно создать статическую библиотеку, или я должен просто создать класс для внутреннего кода?

Вы можете спросить себя следующее:

  1. Будет ли этот код использоваться в нескольких приложениях?
  2. Будет ли в этом коде более одного класса?
  3. Будут ли несколько разработчиков работать или использовать этот код одновременно (возможно, в разных приложениях)?
  4. Будет ли этот код проверен модулем?
  5. Будет ли этот код документирован?

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

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

  • Получение проблемы при использовании .framework, в которой есть статическая библиотека .a
  • BUILT_PRODUCTS_DIR имеет путь для iphoneos вместо iphonesimulator
  • Я хотел бы использовать программу командной строки UNIX (Berkeleys SPICE) в приложении iOS. Каков процесс его компиляции в полезную библиотеку?
  • Ошибки компиляции с статической библиотекой C ++ включают в проект Swift
  • Живые библиотеки разделяются при создании для выпуска в Xcode
  • Почему размер финальной бинарной таблицы будет намного меньше размера статической библиотеки?
  • Каковы наилучшие методы для уменьшения размера статических библиотек в объекте-c?
  • Сокращение изображения в iOS
  • Проблема создания ссылки на проект для Xcode 4
  • Преобразование проекта xcode в статическую библиотеку
  • Xcode - заставить force_load работать с относительными путями
  • Interesting Posts

    JS: Как работает свойство event.touches?

    Как включить вертикальное разделение в Xcode IDE?

    ?? оператора в Свифте

    Понижение уровня приложения на уровне приложения возвращает ошибку

    Как создать зонтичную структуру в SDK для iOS?

    Требуется ли моему Mac-приложению применить ключ доступа к серверу?

    Встроенные dylibs / framework поддерживаются только на iOS 8.0 и более поздних версиях для архитектуры armv7

    CGRect для выбранной настройки UITextRange для многострочного текста?

    Swift: Я хочу знать, какова строка указательного пути кнопки, которую я нажал?

    С UIPresentationFormSheet, почему мой взгляд не перемещается над клавиатурой, когда она вверх?

    Добавление и удаление наблюдателя очереди транзакций – правильный путь?

    Пожарная авария. xcode 9. Нет googleservice

    Как изменить оповещение при возникновении ошибки после регистрации в Parse?

    Невозможно вызвать определенный метод класса Objective-C в Swift

    MBProgressHUD не работает с ARC

    PhoneC: Разработка iOS проста с помощью XCode, Swift3, UITableView, cocatouch, давайте создадим приложения для iPhone, iPad и Macbook.