Обучение мобильной разработке
Знай Gradle и Cocoapod бок о бок
Узнайте, как Gradle и Cocoapod обрабатывают зависимости.
Если вы занимаетесь мобильной разработкой, всегда полезно знать, как работают платформы iOS и Android одновременно.
Если вы хотите получить официальное обучение, ознакомьтесь с Документацией Gradle и Документацией Cocoapod.
Если вы просто хотите синхронизировать свои зависимости, ознакомьтесь с приведенными ниже
Если вы изучаете модульное построение своего приложения, вы можете проверить
Здесь я делюсь некоторыми сведениями о том, как работают Gradle (для Android) и Cocoapod (для iOS). Исходя из этого, мы можем оценить другую платформу, а также понять ее ограничения.
Проверить это…
Gradle является частью Android Studio; Cocoapod не является частью Xcode.
Android
В Android Studio мы можем легко нажать кнопку, чтобы легко синхронизировать все зависимости одним нажатием кнопки. По этой причине, когда мы изменяем файл Gradle и компилируем его, зависимости автоматически синхронизируются.
iOS
Для iOS Cocoapod официально не является частью Xcode, хотя это наиболее популярное средство управления зависимостями для разработчиков iOS. Следовательно, когда мы каждый раз меняем Podfile podspec, нужно переходить к терминалу, чтобы выполнить pod install или pod update.
Компиляция в Xcode не выполняется через Cocoapod. Если нужно скомпилировать проект Xcode на терминале, вместо него используется Fastlane.
Gradle настраивается в файлах .gradle; Cocoapod настроен на Podfile или Podpsec
Android
В Android, если у нас есть проект, зависимости Gradle в основном записываются в build.gradle файл (конечно, можно иметь другой файл и получить импорт (или apply).
Можно разбить
.gradleфайлы на разные файлы для разных целей, например для проверки тестового покрытия и т. д.
Это также относится к каждому модулю, где он имеет свой build.gradle.
Здесь основным проектом для Android обычно является модуль приложения. Но это может быть любой модуль.
Благодаря согласованному gradle файлу модуль библиотеки может зависеть от другого модуля библиотеки в Android, не полагаясь на корневой проект.
iOS
Вместо этого для iOS проект верхнего уровня содержит Podfile, а вместо этого библиотека содержит файл podspec.
Из-за этой разницы (Podfile против Podspec) модуль библиотеки не может зависеть от другого модуля библиотеки без участия корневого проекта. Всем необходимо провести канал через Podfile корневого проекта, чтобы связать их.
Gradle работает с JAR (или AAR); Cocoapod работает с кодами
Android
В Java (или Kotlin с использованием JVM) при компиляции в библиотеку он сохраняется как JAR (или AAR для библиотеки Android).
Поскольку они являются скомпилированными артефактами, JAR (или AAR) находятся в репозитории Maven, таком как Nexus.
Когда Gradle синхронизирует зависимости, им просто нужно загрузить соответствующие JAR-файлы.
Зная это, мы можем понять, что компиляция кода сосредоточена на модуле Android App.
Следовательно, в транзитивных зависимостях, даже если две библиотеки включают разные версии одной и той же библиотеки, как показано на диаграмме ниже, Gradle может разрешить разрешение зависимостей.
Однако есть риск, что если в BaseLib Jar v2 появятся критические изменения (по сравнению с BaseLib Jar v1), следовательно, во время выполнения он может дать сбой. Следовательно, способность разрешать такие зависимости имеет свою цену.
Чтобы лучше понять разрешение зависимостей Gradle, ознакомьтесь с приведенным ниже
iOS
В Cocoapod это не касается скомпилированных компонентов. Вместо этого он просто связывает зависимости через репозиторий исходного кода.
Это полагается на специальный репозиторий Git, служащий центром для всех библиотек.
Чтобы понять, как это работает, ниже расскажите, как можно создать личное репо, хранящее личную библиотеку.
Следовательно, когда мы выполняем pod install или pod update, мы фактически опускаем код зависимостей. Версия кода помечается с помощью tag кода, указанного в podspec.
Из-за этого мы не можем указать конкретную версию в библиотеке и ожидать, что она разрешится сама. Если есть конфликтующие транзитивные зависимости, он будет конфликтовать, и во время синхронизации Cocoapod он выйдет из строя.
Чтобы решить эту проблему, нужно использовать индикаторы оптимистичной версии, то есть ~>.
Gradle против кеширования Cocoapod
Android
Поскольку Gradle загружает файлы JAR (или AAR) большего размера, следовательно, время синхронизации Gradle намного больше.
Таким образом, Gradle кэширует загруженный артефакт вне модуля проекта. Он находится в папке ~/.gradle/cache.
Это также ускоряет совместное использование общих библиотек в проектах.
Если вы хотите вручную кэшировать свои зависимости Gradle, посмотрите ниже
iOS
Поскольку Cocoapods занимается только загрузкой кода, это намного быстрее. Он хранит их в папке project/Pods.
У Cocoapod также есть ~/.cocoadpod папка, но в основном она предназначена только для хранения репозитория podspecs. Вы можете увидеть все свои репозитории подов, набрав команду pod repo.
Работа с локальной библиотекой вместо внешней
Иногда мы разрабатываем библиотеку как отдельное репо, и основное приложение обращается к библиотеке как к внешней библиотеке. В целях отладки нам нравится связывать основное приложение с развивающейся библиотекой, а не с внешней библиотекой, как мы можем добиться этого в Gradle или Cocoapod?
Android
В Android у нас есть разные способы сделать это.
- Скопируйте всю кодовую базу модуля библиотеки, чтобы включить ее в проект Android в качестве другого модуля. Слишком много работы! Слишком много изменений в основной кодовой базе проекта Android.
- Скомпилируйте библиотеку в JAR (или AAR) и вручную скопируйте ее в папку проекта. Все еще довольно утомительно, так как нам нужно скопировать JAR и т. Д.
Более стандартный способ сделать это - загрузить библиотеку в mavenLocal() вместо фактического репозитория Nexus.
Все, что требуется в основном приложении для Android, - это иметь исходный репозиторий от mavenLocal(). И, возможно, какое-то изменение версии (например, SNAPSHOT), чтобы убедиться, что выбрана правильная версия.
Вы можете найти инструкцию в разделе Бонус: загрузка библиотеки в mavenLocal () в статье ниже
iOS
В iOS, поскольку он имеет дело с кодом, это на самом деле намного проще.
В подфиле вместо указания номера версии библиотеки, как показано ниже
pod 'SimpleSwiftLib', '0.3.0'
Можно перейти в папку
pod 'SimpleSwiftLib', :path => '../<the podspec folder>'
Создайте несколько внешних библиотек в одном репо
Иногда, если мы хотим создать несколько библиотек в одном репо, вместо того, чтобы иметь их по отдельности, как мы можем это сделать?
Android
В Android это относительно просто с папкой проекта по умолчанию.
Каждый модуль имеет свой собственный build.gradle и может независимо выполнять публикацию библиотеки.
Вы можете найти шаги публикации библиотек ниже
И вот пример проекта.
iOS
Для iOS мы не можем использовать папку проекта по умолчанию, как показано ниже, поскольку файл podspec должен находиться в корневой папке.
Вместо этого нам нужно переместить все podspec в корневую папку. Для более четкого разделения Образцов проектов, загружающих библиотеку, Образцы проектов можно вместо этого переместить в папку (и).
Вы можете увидеть образец такой организации проекта кода здесь.
Еще одно замечание: при тегировании проекта нам необходимо четко разделять теги для разных проектов.
В podspec вместо использования нижеприведенного
s.source = { :git => '<repo>', :tag => s.version.to_s }
мы можем изменить на
s.source = { :git => '<repo>', :tag => "libname-#{s.version}" }
Следовательно, когда мы помечаем имя библиотеки в репозитории git, это будет, например,
git tag libraryName-0.1.0Надеюсь, это даст вам кроссплатформенное обучение по каждой характеристике управления зависимостями. Ваше здоровье!
