Разработка
Почему получение пакетов в Swift Package Manager занимает слишком много времени
Вы можете спросить — зачем? Почему бы не получить только релизную ветку или даже готовый релизный коммит?
Давайте перейдем непосредственно к делу, не объясняя историю создания Swift Package Manager или историю падения Римской империи.
Проблема
Когда вы добавляете зависимость в свой проект с помощью Swift Package Manager (spm), он получает весь репозиторий пакета, со всеми ветками и полной историей git, которая может состоять из многолетних снепшотов git.
Зачем?
Вы можете спросить — зачем? Почему бы не получить только релизную ветку или даже готовый релизный коммит?
Ответ кроется в этом комментарии инженера по инфраструктуре в GitHub, который отвечал на проблему в Cocoapods, когда он делал то же самое, что мы хотим, чтобы делал spm — shallow clone:
Как упоминалось в комментарии, неглубокое клонирование (shallow clone) по какой-то причине обходится гораздо дороже, чем клонирование всего репозитория. Поэтому GitHub ограничивает скорость получения таких репозиториев, что может привести к тому, что клонирование пакета займет много времени, даже если его размер относительно меньше размера всего репозитория. Хуже того, выборка может вообще завершиться неудачей из-за таймаута.
Именно поэтому Apple получает весь репозиторий целиком, и этот комментарий главного контриьбютора spm, который работает в Apple, подтверждает это утверждение.
Решение
Так каково же решение? Судя по всему, многие компании используют такой подход — создание отдельного репозитория, который включает в себя предварительно скомпилированный .xcframework пакета. Потребитель этого пакета теперь получает лишь часть объема оригинального репозитория, содержащего исходный код.
Примеры
Например, команда Airbnb/Lottie использовала этот подход и уменьшила размер своего репо с +300 МБ до менее чем 500 КБ:
- Оригинальный репо lottie-ios (+300 МБ)
- Оптимизированный репо lottie-spm (менее 500 КБ)
Signal также делает то же самое:
- Оригинальный OneSignal-iOS-SDK
- Оптимизированный OneSignal-XCFramework
Заключение
Если вы нашли эту статью полезной, не стесняйтесь поделиться ею, и если у вас есть отзывы, я буду рад их услышать.
-
Интегрированные среды разработки2 недели назад
Лучшая работа с Android Studio: 5 советов
-
Новости4 недели назад
Видео и подкасты о мобильной разработке 2024.43
-
Новости3 недели назад
Видео и подкасты о мобильной разработке 2024.44
-
Исследования2 недели назад
Поможет ли новая архитектура React Native отобрать лидерство у Flutter в кроссплатформенной разработке?