Что такое gradle java
Перейти к содержимому

Что такое gradle java

  • автор:

Gradle

Gradle — система автоматической сборки, построенная на принципах Apache Ant и Apache Maven. В Eclipse использовалась система Ant, но большинство разработчиков даже не замечало её работы. В основном возможности системы использовались в конторах для автоматизации различных задач. В Android Studio такой номер не пройдёт. Gradle сопровождает вас во время разработки постоянно. Поначалу, если вы перешли с Eclipse, Gradle сильно раздражает своими действиями. Но позже вы оцените её удобство и может даже полюбите её.

Gradle не является изобретением для Android Studio, система была разработана раньше и использовалась в приложениях для Java, Scala и других языках.

Система сборки Gradle очень мощная и сложная, чтобы о ней рассказать в двух словах. Есть целые книги о ней. Сами команды в Gradle представляют собой обычный текст с использованием синтаксиса Groove для конфигурации. Но нам не нужно знать всё. Познакомимся поближе с системой и научимся пользоваться ей.

Создайте новый проект или откройте любой существующий проект из Android Studio и посмотрите на структуру проекта.

В последних версиях студии файлы Gradle выделили в отдельную папку Gradle Script. Раскройте её. В основном вас должен интересовать файл build.gradle, который относится к модулю. Рядом с этим файлом в скобках будет написано Module: app. Двойным щелчком откройте его, вы увидите, что файл является текстовым.

Также есть файл build.gradle, который относится к проекту. Но с ним работают реже. Так находятся настройки для репозиториев и самого Gradle.

Вернёмся к файлу модуля, вы увидите много интересной информации. Например, вы там можете увидеть настройки, которые раньше вы могли видеть в манифесте — номера версий, номера SDK и так далее. Забегая вперёд, скажу, что здесь можно добавить всего одну волшебную строчку и нужная библиотека сама скачается из интернета и установится в проекте. Красота!

Однако вернёмся в корневую папку. Кроме файлов build.gradle мы можем заметить файлы gradle.properties, settings.gradle и другие. Трогать их не нужно.

В корневой папке также есть файлы gradlew и gradlew.bat для работы с Gradle Wrapper. В принципе вам не нужно знать о них ничего. Но для параноиков есть информация — если вы часто импортируете проекты из неизвестных источников, то они содержат файл gradle/wrapper/gradle-wrapper.properties. Откройте его текстовым редактором и посмотрите на адрес у distributionUrl. Путь должен вести на официальный сай //services.gradle.org или на внутренний корпоративный сервер. Другие адреса должны вызвать тревогу.

Вы могли заметить, что по сравнению с Eclipse изменилась структура файлов. В папке app находится папка src, а ней папка main, в которых папки java, res и файл манифеста. Новая структура лучше отвечает требованиям Gradle для управления файлами.

Вы, например, можете создавать альтернативные папки с ресурсами и с помощью build.gradle подключить их к проекту.

 android < compileSdkVersion 20 buildToolsVersion "20.0.0" defaultConfig < applicationId "ru.alexanderklimov.hellokitty" minSdkVersion 16 targetSdkVersion 20 versionCode 1 versionName "1.0" >sourceSets < main < res < srcDirs = [ 'src/main/res', 'src/main/presentations/animations', 'src/main/presentations/layouts'] >> > > 

В этом примере мы указали, что существуют новая папка presentations в папке /src/main/ наряду с существующими папками java и res. Внутри созданной папки есть ещё две папки layout и animations, которые содержат файлы ресурсов.

Только помните, что вам нужно избегать конфликта имён при слиянии всех файлов при сборке.

Значение sourceSets указывает Gradle, какие папки следует использовать. Этим приёмом пользуются продвинутые программисты. Мы пока не будем использовать такую технику.

Другая полезная возможность — создавать разные версии приложений, например, демо-версию и платную версию. Немного об этом рассказано здесь.

Номер версии приложения и требования к версии Android прописаны в секции defaultConfig. Если у вас сохранились старые версии приложений, то в манифесте можете удалить данные записи. По-моему, там даже выводится соответствующая подсказка. Даже если вы эти данные в манифесте не удалите, то значения из gradle.build имеют больший приоритет и перепишут значения в манифесте при не совпадении.

 defaultConfig

Подключение библиотеки происходит одной строчкой. Например, нужно добавить библиотеку Picasso:

 dependencies

В Android Studio 3.0 используется новая версия Gradle, в которой compile считается устаревшей. Вместо него следует использовать новое слово implementation.

 implementation 'com.android.support:recyclerview-v7:27.0.0' 

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

 debugCompile 'junit:junit:4.12' // старый вариант testImplementation 'junit:junit:4.12' // новый вариант для Android Studio 3.0 

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

 repositories

Можно указать другой репозиторий, например, Maven Central.

 repositories

Для поиска через Maven-репозиторий используйте The Central Repository Search Engine.

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

 dependencies < compile files("libs/library1.jar", "libs/library2.jar") >

Сам файл нужно скопировать в папку /libs.

При любом изменении файла недостаточно его сохранить. Нужно также произвести синхронизацию. Наверху обычно появляется жёлтая полоска с ссылкой Sync Now.

Задаём имя APK при компиляции

Можно задать собственное имя при компиляции проекта. Например, так.

 defaultConfig

Получим имя MyName-1.0.12-release.apk

Оптимизатор кода R8

Оптимизатор кода R8 имеет следующие возможности: урезание байт-кода, сжатие, обфускация, оптимизация, удаление «синтаксического сахара», преобразование в DEX. Оптимизатор может производить все операции за один шаг, что даёт сильное улучшение производительности. R8 был введён в Android Gradle plugin 3.3.0. Вам нужно только включить его.

 android < buildTypes < release < minifyEnabled true > > > 

R8 разработан для работы с существующими ProGuard-правилами, хотя возможны ситуации, когда нужно переработать правила.

 #отключение R8 только для Android Library модулей android.enableR8.libraries = false

#отключение R8 для всех модулей android.enableR8 = false

Сжимаем итоговый APK

В Gradle 1.4 появилась возможность сжать итоговый файл, убрав неиспользуемые ресурсы, в том числе из библиотек, например, Google Play Services.

 buildTypes

Во время сборки приложения вы можете увидеть строку:

 :android:shrinkDebugResources Removed unused resources: Binary resource data reduced from 2570KB to 1711KB: Removed 33% . 

Другой способ убрать неиспользуемые ресурсы конфигурации. Например, вам не нужные локализованные ресурсы для всех языков, которые входят в библиотеку Google Play Services или Android Support Library и др. Оставим только нужные языки. Возможно, вы также не хотите поддерживать mdpi или tvdpi-разрешения в своём приложении. Мы можем установить языки и разрешения, которые используются в приложении, остальные будут исключены, что позволит уменьшить вес приложения.

 // build.gradle android < defaultConfig < resConfigs "en", "ru" resConfigs "nodpi", "hdpi", "xhdpi", "xxhdpi", "xxxhdpi" >> 

Можно перенести ключи из манифеста.

Чтобы их не светить, например, если выкладывать код на Гитхабе, то сделаем так.

 defaultConfig

И в манифесте переделаем код.

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

 defaultConfig

В манифесте пишем.

Класс BuildConfig

В статье LogCat упоминался способ быстрого отключения журналирования.

Суть в следующем. Когда вы создаёте новые переменные в блоках defaultConfig или buildTypes (ветки debug и release), то Gradle создаёт специальный класс BuildConfig, и вы можете получить доступ к этим переменным.

Например, добавим переменную в defaultConfig

 defaultConfig

На языке Java это равносильно String YOUR_TOKEN = «ABRAKADABRA»;

Теперь мы можем обратиться к созданной строке.

 String token = BuildConfig.YOUR_TOKEN; // Что-то делаем со своей строкой 

С секцией buildType ситуация интереснее. У секции есть два блока debug и release. Можно создать переменные с разными значениями, которые будут использоваться в зависимости от ситуации. Например, у вас есть собственное API для сервера. Для тестирования вы используете один адрес, а для финальной версии — другой адрес. Тогда вы просто указываете разные адреса в разных ветках. Переменные могут быть не только строковыми.

 buildTypes < debug < buildConfigField "String", "API_URL", '"http://developer.alexanderklimov.ru/api/debug/"' buildConfigField "boolean", "REPORT_CRASHES", "true" >release < . тут какие-то другие записи buildConfigField "String", "API_URL", '"http://developer.alexanderklimov.ru/api/release/"' buildConfigField "boolean", "REPORT_CRASHES", "false" >> 

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

 Uri addressUri = Uri.parse(BuildConfig.API_URL); Intent openLinkIntent = new Intent(Intent.ACTION_VIEW, addressUri); startActivity(openLinkIntent); 

Теперь вам не нужно переписывать каждый раз код. Загружаться будет страница по нужному адресу автоматически.

Разделяем отладочную и финальную версию

По такому же принципу можно организовать запуск новой версии программы, не затрагивая программу, которую вы установили с Google Play. Допустим вы на своём телефоне установили своё собственное приложение через Google Play. Теперь вам нужно написать новую версию и проверить на своём телефоне. Из-за конфликта имён новое тестируемое приложение перепишет финальную версию или вообще не установится. Поможет следующий трюк.

 buildTypes < debug < applicationIdSuffix ".debug" versionNameSuffix "-debug" resValue "string", "app_name", "AboutCat (debug)" >release < minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' resValue "string", "app_name", "AboutCat" >> 

В специальных переменных applicationIdSuffix и versionNameSuffix мы задаём суффиксы, чтобы избежать конфликта. А в переменной resValue указываем название программы для отладочной и финальных версий, чтобы на устройстве можно было их найти. Не забудьте при этом удалить строковый ресурс app_name в res/values/strings.xml, иначе получите ошибку при компиляции. Теперь можете спокойно запускать приложение с новым кодом, не боясь повредить своё любимое приложение.

Прячем секретную информацию

Следующий совет больше подходит для компаний. Когда подписывается приложение, то нужно указывать пароль, хранилище и т.д. Чтобы их не светить в студии, можно прописать их в переменных и поместить в секцию signingConfigs. Сервер сам найдёт нужные ключи и воспользуется ими в своих сценариях.

 signingConfigs < release < storeFile "$" keyAlias "$" storePassword "$" keyPassword "$" > > 

Автогенерация версии кода

Нашёл совет, сам не применял. Не обязательно вручную менять версию приложения в атрибутах versionCode и versionName, можно сделать через переменные, а они сами подставятся в нужное место. На любителя.

 def versionMajor = 1 def versionMinor = 0 def versionPatch = 0 android < defaultConfig < versionCode versionMajor * 10000 + versionMinor * 100 + versionPatch versionName "$.$.$" > > 

settings.gradle

Файл settings.gradle обычно состоит из одной строчки.

 include ':app' 

Это означает, что у вас используется один проект для работы. Если вы будете подключать другие проекты, то здесь появятся новые строки.

gradle.properties (Project Properties)

Несколько советов по настройке файла gradle.properties.

Режим параллельного выполнения

В этом файле можно найти закомментированную строку # org.gradle.parallel=true. Если модули вашего проекта не используют друг друга как зависимости, создавая перекрёстные ссылки, можно включать режим параллельного выполнения, что ускорит скорость сборки до ~30%.

 org.gradle.parallel=true # включаем режим параллельного выполнения 

Gradle-демон

Включение на компьютере демона Gradle даст значительный прирост в скорости сборки.

 org.gradle.daemon=true # включаем демон 

Режим конфигурации при необходимости

Если в проекте используется много модулей, то можно включить режим конфигурации при необходимости. Ускорение будет заметно при большом количестве используемых модулей:

 org.gradle.configureondemand=true 

Меняем номер версии библиотек в одном месте

Очень часто в проекте используются взаимосвязанные библиотеки с одинаковыми номерами.

 dependencies < compile 'com.android.support:appcompat-v7:23.4.0' compile 'com.android.support:design:23.4.0' compile 'com.android.support:percent:23.4.0' compile 'com.android.support:cardview-v7:23.4.0' compile 'com.android.support:gridlayout-v7:23.4.0' //play services compile 'com.google.android.gms:play-services-location:9.2.1' compile 'com.google.android.gms:play-services-gcm:9.2.1' >

Можно быстро поменять у всех номера через переменную. Для этого используется секция ext, в которой указывается переменная и номер версии. Затем в секции dependencies номер версии заменяется на имя переменной

 ext < supportLibraryVersion = '24.0.0'; playServicesVersion = '9.2.1' >dependencies < compile "com.android.support:appcompat-v7:$supportLibraryVersion" compile "com.android.support:design:$supportLibraryVersion" compile "com.android.support:percent:$supportLibraryVersion" compile "com.android.support:cardview-v7:$supportLibraryVersion" compile "com.android.support:gridlayout-v7:$supportLibraryVersion" //play services compile "com.google.android.gms:play-services-location:$playServicesVersion" compile "com.google.android.gms:play-services-gcm:$playServicesVersion" >

Обратите внимание, что одинарные кавычки заменяются на двойные, а символ $ указывает на строковый тип.

Расширенная версия с разными переменными в другом виде.

 ext.compileSdkProjectVersion= 24 ext.buildToolsProjectVersion= '24.0.0' ext.supportLibraryVersion = '24.0.0' ext.googlePlayVersion = '8.4.0’ android < compileSdkVersion compileSdkProjectVersion buildToolsVersion buildToolsProjectVersion //… >dependencies

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

Настройки в Android Studio

Рассмотрим настройки, доступные в Android Studio. Закройте текущий проект, чтобы увидеть стартовое окно студии. В правой части нажмите на пункт Configure. В следующем окне выберите пункт Settings, чтобы оказаться в окне настроек студии. В левой части найдите пункт Build, Execution, Deployment, затем подпункт Build Tools, далее подпункт Gradle. По умолчанию, там всё чисто, только указан путь у Service directory path. Это были общие настройки.

Теперь рассмотрим настройки, относящиеся к проекту. Запустите любой проект в Android Studio. Выберите меню File | Settings. . Снова пройдитесь по пунктам Build, Execution, Deployment | Build Tools | Gradle. Вы увидите практически такое же окно с небольшими изменениями. Теперь поле Linked Gradle Projects не будет пустым, а также появятся дополнительные настройки. По умолчанию рекомендуют использовать Use default gradle wrapper.

Gradle Task

На правой стороне Android Studio имеется вертикальная вкладка Gradle, которую можно развернуть. Она содержит список задач (task), которая выполняет Gradle при работе с текущим проектом. Вы можете выделить любую из этих задач и запустить её двойным щелчком. Можно выделить несколько задач.

Узнать debug.keystore: MD5 и SHA1

Иногда требуется узнать значения debug.keystore: MD5 и SHA1. Обычно их получают через командную строку. Но это долго и неудобно, так как нужно помнить все аргументы. Есть способ проще. Открываем вкладку Gradle, нажимаем на кнопку со стрелками Refresh all Gradle Projects. Затем последовательно открываем элементы Tasks | android и запускаем команду signingReport. В нижнем окне Run увидите нужную информацию.

 Variant: debug Config: debug Store: C:\Users\klimo_000\.android\debug.keystore Alias: AndroidDebugKey MD5: BA:6F:23:49:2D:9A:9C:0C:44:75:E0:94:59:07:E0:22 SHA1: 9D:51:F4:B8:4B:15:57:4B:EC:79:67:DC:F4:7C:5B:FB:02:C6:A2:F7 Valid until: Thursday, 1 December 2044 

Gradle Console

Когда выполняется какая-то задача Gradle, то ход её выполнения можно увидеть в окне Gradle Console. Открыть её можно через вкладку Gradle Console в нижней правой части студии.

Terminal

Запускать задачи Gradle можно и в окне Terminal.

На панели инструментов имеется значок Sync Project with Gradle Files, которую следует использовать при редактировании файлов Gradle. Как правило, студия также выводит предупреждающее сообщение с ссылкой при изменении файла, которая делает ту же работу.

Добавление зависимостей через интерфейс студии

В статье описывался способ включения библиотеки в проект через редактирование файла build.gradle. Существует альтернативный вариант через настройки студии. Щёлкните правой кнопкой мыши на имени модуля (app) и выберите пункт Open Module Settings (быстрая клавиша F4). В правой части окна находятся вкладки, которые оказывают влияние на файл build.gradle. Например, вкладка Dependencies содержит подключаемые библиотеки.

Чтобы добавить новую зависимость, нажмите на значок с плюсом и выберите нужный вариант, например, Library dependency. Откроется список доступных библиотек из репозитория Maven.

Конфигурация в Android Studio Flamingo

Иногда студия начинает дурить, ругается на несовместимость каких версий библиотек, компиляторов и прочее. Вот и в версии Flamingo проект перестал собираться после какого-то обновления.

Мои настройки, после которого студия собрала проект.

 // Project plugins < id 'com.android.application' version '8.0.1' apply false id 'com.android.library' version '8.0.1' apply false id 'org.jetbrains.kotlin.android' version '1.8.0' apply false >// Module compileOptions < sourceCompatibility JavaVersion.VERSION_17 targetCompatibility JavaVersion.VERSION_17 >kotlinOptions

Дополнительное чтение

В примере работы с PDF-файлами в папке assets использована операция запрета на сжатие файлов, которое происходит по умолчанию.

Задачи Gradle — теория для общего развития.

Инициализация Gradle-проекта — Java: Настройка окружения

Ручная компиляции кода довольно утомительный процесс даже во время обучения. В реальных приложениях такой подход просто не применим, слишком много действий придется делать руками. Для компиляции используются специальные системы сборки, такие как Maven или Gradle. Последний стал стандартом де-факто для новых приложений, поэтому рассмотрим работу именно с ним. Принцип у всех таких систем один и тот же, поэтому зная один, несложно разобраться и в других.

Gradle — это не просто автоматизатор компиляции. Это навороченная система сборки, где компиляция это всего лишь один из этапов. Сборка проекта – довольно широкое понятие. Она включает в себя компиляцию исходного кода, упаковку в jar, запуск тестов и другие шаги, необходимые для создания рабочего приложения. Ключевые возможности Gradle:

  1. Автоматическая сборка проекта. Gradle сам знает какие файлы и как надо собирать. Сам компилирует, сам упаковывает в JAR
  2. Быстрая инкрементальная сборка. Компилируется только то, что изменилось
  3. Управление зависимостями. Gradle сам качает и подключает библиотеки. И заодно умеет их обновлять

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

В повседневной работе Java-программист пользуется Gradle через редактор, но во время обучения нужно потратить немного времени на то, чтобы разобраться с тем как он работает. Иначе потом будет сложно, когда что-то пойдет не так и возникнет ошибка. Поэтому здесь мы проделаем все операции через консоль, а дальше подключим редактор.

Начнем с установки. Если Gradle у вас не установлен, то посмотрите инструкцию . Проверить установку можно так:

-v ------------------------------------------------------------ Gradle 8.4 ------------------------------------------------------------ 

Теперь инициализируем новый Gradle-проект:

# Создаем директорию для проекта mkdir hexlet-gradle-project cd hexlet-gradle-project # Запускаем инициализацию gradle init 

Дальше Gradle задаст несколько вопросов, на базе которых сформируется правильная структура. Если во время создания вы ошиблись и выбрали не тот вариант, то ничего страшного. Просто дойдите до конца и пересоздайте директорию с проектом. Потом запустите все заново. Разбираем вопросы:

type of project to generate: 1: basic 2: application 3: library 4: Gradle plugin Enter selection (default: basic) [1..4] 

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

(default: Kotlin) [1..2] 

Выбираем язык для описания Gradle файлов. Kotlin DSL является выбором по умолчанию. Мы тоже будем использовать Kotlin

(default: hexlet-gradle-project): 

Просто жмем Enter. Текущее имя директории и есть имя проекта.

(some features may change in the next minor release)? (default: no) [yes, no] 

Выбираем yes. После этого появляется радостная надпись:

in 8m 46s 

Посмотрим на получившуюся структуру:

-a . . ├── .gitattributes ├── .gitignore ├── build.gradle.kts ├── gradle │ └── wrapper │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradle.properties ├── gradlew ├── gradlew.bat └── settings.gradle.kts 2 directories, 9 files 

Много всего, начнем по порядку.

Gradle сразу подготавливает проект к использованию через git добавив два файла .gitignore и .gitattributes. Игнорируются файлы сборки, которые попадут в директорию build и .gradle, это служебные файлы Gradle, которые он сам себе сгенерирует во время работы.

Файлы gradlew и gradlew.bat нужны для установки самого Gradle. Концепция здесь такая, Gradle во время создания проекта делает так, чтобы проект не использовал глобально установленный Gradle. Он скачивает сам себя в директорию gradle. Все команды будут запускаться через ./gradlew (в Windows ./gradlew.bat). Зачем так сделано? Так Gradle фиксирует версию. Если поменяется глобально установленная версия, то проект продолжит работать с той, с которой он работал. Меньше шансов что-то сломать, но сложнее в обновлении.

Файл settings.gradle.kts содержит различные настройки, например, там задается имя проекта. Остальное добавляется по мере развития и требований со стороны кода.

Файл build.gradle.kts – это основной файл Gradle, в котором на языке Kotlin описано то, как будет работать система сборки. Пока этот файл пустой, чуть позже мы его наполним

Далее нужно создать место, в котором будет располагаться исходный код нашего проекта. Внутри директории проекта создайте следующую файловую структуру: src/main/java/io/hexlet/example. Назначение директорий здесь следующее. Директория src (source) – место, в котором лежит весь исходный код проекта. Директория main отвечает за код проекта и дополнительные ресурсы (например, картинки). Внутри находится java, то есть тут лежит Java-код. Но подразумевается, что бывает и по-другому. И вот только внутри java начинается структура, соответствующая пакету проекта.

В директории example создайте новый Java-класс с именем App.java и добавьте туда код:

// Имя пакета // Соответствует структуре директорий внутри директории java package io.hexlet.example; public class App  public static void main(String[] args)  System.out.println("Hello, world!"); > > 

Само приложение готово. Теперь перейдем к настройке системы сборки. Откройте файл build.gradle.kts. Именно с этим файлом придется работать больше всего, настраивая Gradle для подключения новых библиотек и их конфигурации. Добавьте туда следующий код:

plugins  // Поддержка запуска из командной строки application > repositories  // Подключаем автоматическая работа с репозиторием Maven Central mavenCentral() > // Для плагина application указываем главный класс приложения application  // Входная точка mainClass.set("io.hexlet.example.App") > 

Теперь все готово. Попробуем запустить проект, а в следующем уроке поговорим о том, как конкретно работать с Gradle:

> Task :run Hello, world! # Вот он вывод нашей программы 

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

  • 130 курсов, 2000+ часов теории
  • 1000 практических заданий в браузере
  • 360 000 студентов

Наши выпускники работают в компаниях:

Что такое Gradle

Обновлено

Обновлено: 02.01.2024 Опубликовано: 22.07.2021

система сборки пакетов для программных продуктов, разработанных, преимущественно, на Java, Groovy и Scala.

По назначению и принципу работы похож на Maven, но с более простым конфигурационным файлом (более лаконичный код Groovy или Kotlin против большого и неудобного XML). На официальном сайте в разделе Gradle vs Maven Comparison представлено сравнение данных продуктов.

Также на официальном сайте представлена документация, которая позволит получить информацию о программном продукте и начать с ним работать. На соответствующей странице мы можем загрузить бинарник или исходный код Gradle, а также нестабильные бета-версии. Установка заключается в распаковке данного бинарника и прописыванию системной переменной GRADLE_HOME. Для проверки установки можно просто посмотреть версию системы сборки командой:

Как говорилось выше, данная система сборки предназначена для работы с приложениями Java, однако, поддерживаются и другие языки программирования.

Подробнее о Gradle на Википедии.

Встречается в статьях

Мини-инструкции:

  1. Как с помощью Gradle и плагина ospackage собрать пакеты RPM и Deb
  2. Пример сборки проекта, написанного на Java, с помощью системы сборки Maven

Введение в Gradle

Работая с Kotlin Multiplatform Mobile для iOS разработчика главным испытанием становится не изучение Kotlin, а изучение билд системы Gradle, которая собирает мультиплатформенную библиотеку. В данном разделе разобрано что есть Gradle с перспективы iOS разработчиков.

Gradle​

Gradle это система сборки, имеющая гибкую систему конфигурации через плагины и позволяющая описывать конфигурацию сборки в виде groovy / kotlin файлов.

Задача Gradle, как и любой системы сборки, скомпилировать исходный код в исполняемое приложение, либо подключаемую библиотеку. Благодаря ему разработчику не требуется писать команды вызова компилятора kotlin и передавать ему список исполняемых файлов, подключенных библиотек и прочее.

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

Gradle написан на java и является JVM (Java Virtual Machine) приложением, то есть для его использования требуется установленная на исполняемой машине JDK (Java Development Kit). Наиболее стабильная версия JDK — Oracle JDK (рекомендуется к скачиванию Oracle JDK 11 для работы с KMM).

Gradle имеет обширную, подробную документацию, доступную тут.

Gradle Daemon​

Это долгоживущий фоновый процесс, который запускается на выбранной JVM при первой сборке. Он помогает избежать затратного процесса начальной загрузки JVM, при этом кешируя данные о ваших предыдущих билдах в память, что заметно ускоряет скорость сборки проекта.

Подробнее о Gradle Daemon и как его подключать к проекту вы можете прочитать тут и тут.

Контекст для понимания дальнейших разделов​

  1. Gradle при каждом запуске проходит по нескольким фазам — инициализация, конфигурация, выполнение.
  2. Файлы gradle могут быть написаны как на groovy (тогда расширение просто .gradle , так и на Kotlin Script .gradle.kts ). При использовании Kotlin Script IDE предоставляет полноценный анализ с подсказками, поэтому мы используем только Kotlin Script вариант.

Составляющие конфигурации проекта​

Проект, использующий Gradle в качестве системы сборки, содержит:

  1. settings.gradle / settings.gradle.kts — настройки проекта, например подключение модулей проекта;
  2. build.gradle / build.gradle.kts — конфигурация конкретного gradle модуля;
  3. gradle.properties — файл содержащий набор ключ+значение передаваемыми в gradle.

settings.gradle​

Файл с настройками всего проекта (данные настройки влияют на все модули).
Может быть написан на groovy (тогда имя settings.gradle ) либо на kotlin — settings.gradle.kts .
Подробная информация в документации .
Код в данном файле выполняется в момент инициализации проекта (при каждом запуске градл происходит по стадиям инициализация, конфигурация, выполнение).

Пример содержимого с пояснениями:

// блок pluginManagement позволяет настроить работу с плагинами билдсистемы pluginManagement  // определяем список maven репозиториев, в которых нужно искать подключаемые плагины.  // Если данный блок не объявлять то будет использоваться gradlePluginPortal - https://plugins.gradle.org/  repositories  mavenCentral()  google()  > > // данный блок позволяет настроить для всех модулей проекта работу с зависимостями dependencyResolutionManagement  // определяем список maven репозиториев, в которых нужно искать подключаемые библиотеки.  repositories  mavenCentral()  google()  > > // подключение composite build - является темой для продвинутого погружения, обычно на проектах это не встретить // если кратко - это подключение другого самостоятельного gradle проекта к сборке нашего проекта, с возможностью подключать модули подключенного проекта как внешние зависимости в нашем проекте // https://docs.gradle.org/current/userguide/composite_builds.html includeBuild("network-generator") // подключение модулей проекта, каждый из них будет определяться как gradle модуль и будет читаться его build.gradle файл // двоеточие в пути обозначает уровень иерархии в файловой структуре. include(":network") include(":sample:mpp-library") 

Является упрощенным вариантом с moko-network.

(!) Основной сценарий когда iOS разработчику нужно работать с файлом settings.gradle — разработчик сам создает новый gradle модуль и нужно подключить его к билдсистеме. То есть добавляет include(«:mymodule») .

build.gradle​

Файл с конфигурацией модуля gradle проекта. Определяет всю логику сборки данного модуля (что собираем, как собираем).
Может быть написан на groovy (тогда имя build.gradle ) либо на kotlin — build.gradle.kts .
Подробная информация в документации.

Пример содержимого с пояснениями:

// подключение плагинов, которые и содержат всю основую логику сборки plugins  // плагин для сборки android библиотек. Требуется у нас в проектах так как мы собираем из мультиплатформы android код, помимо ios  // подробнее - https://developer.android.com/studio/build/index.html  id("com.android.library")  // плагин мультиплатформы. дает возможность собирать kotlin код разными компиляторами - Kotlin/JVM, Kotlin/JS, Kotlin/Native.  // подробнее - https://kotlinlang.org/docs/mpp-dsl-reference.html  id("org.jetbrains.kotlin.multiplatform")  // наш плагин мобильной мультиплатформы, упрощает настройку градл проектов для mobile использования (android, ios)  // подробнее - https://github.com/icerockdev/mobile-multiplatform-gradle-plugin  id("dev.icerock.mobile.multiplatform")  // плагин для генерации кода сериализации в момент компиляции, от библиотеки kotlinx.serialization  // подробнее - https://github.com/Kotlin/kotlinx.serialization  id("org.jetbrains.kotlin.plugin.serialization") > // объявление зависимостей данного модуля. Чем меньше зависимостей объявлено, тем быстрее будет производиться компиляция модуля. // зависимости ищутся в репозиториях, которые могут быть указаны как в самом build.gradle, так и в settings.gradle централизованно dependencies  // подключение зависимости к common коду, в виде реализации (implementation). Это означает что классы данной зависимости не будут видны вне данного модуля, без явного ее подключения.  commonMainImplementation(Deps.Libs.MultiPlatform.coroutines)  // подключение зависимости к common коду, транзитивно (api). Это означает что классы данной зависимости будут видны вне данного модуля при подключении нашего модуля.  commonMainApi(Deps.Libs.MultiPlatform.kotlinSerialization)  commonMainApi(Deps.Libs.MultiPlatform.ktorClient)  // подключение зависимости к андроид таргету, транзитивно. Классы данной зависимости видны только в androidMain сорссете.  androidMainApi(Deps.Libs.Android.ktorClientOkHttp)  // подключение зависимости к ios таргету, транзитивно. Классы данной зависимости видны только в iosMain сорссете.  iosMainApi(Deps.Libs.Ios.ktorClientIos)  // подключение другого модуля нашего проекта, в виде реализации  commonMainImplementation(project(":network"))  // подключение зависимостей к общему коду тестов, в виде реализации.  commonTestImplementation(Deps.Libs.MultiPlatform.ktorClientMock)  commonTestImplementation(Deps.Libs.MultiPlatform.Tests.kotlinTest)  commonTestImplementation(Deps.Libs.MultiPlatform.Tests.kotlinTestAnnotations)  // подключение зависимостей к андроид таргету тестов, в виде реализации.  androidTestImplementation(Deps.Libs.Android.Tests.kotlinTestJUnit) > 

Является упрощенным вариантом с moko-network.

Основные сценарий когда iOS разработчику нужно работать с файлом build.gradle :

  1. Подключение новой зависимости к модулю
  2. Подключение плагина с дополнительным функционалом ( например moko-resources / moko-network)

gradle.properties​

Файл с опциями выполнения gradle.
Подробнее в документации.

Пример содержимого с пояснениями:

# сколько максимум оперативной памяти gradle может использовать org.gradle.jvmargs=-Xmx4096m # выключение опции "конфигурация налету", так как многомодульные проекты с ней ломаются часто org.gradle.configureondemand=false # включение параллельной сборки - разные gradle модули могут выполнять свои задачи параллельно org.gradle.parallel=true # какой вариант кодстайла котлина используеся в проекте - используется IDE для включения верного кодстайла kotlin.code.style=official # специальные флаги для активации Commonizer чтобы в iosMain видно было методы ios, а не только в iosArm64 и iosX64 # подробнее тут - https://www.youtube.com/watch?v=Q99HvynwjtY # https://kotlinlang.org/docs/migrating-multiplatform-project-to-14.html#try-the-hierarchical-project-structure kotlin.native.enableDependencyPropagation=false kotlin.mpp.enableGranularSourceSetsMetadata=true kotlin.mpp.enableCompatibilityMetadataVariant=true # использование androidX библиотек для андроида, нужно android gradle plugin android.useAndroidX=true # отключение предупреждения о том что используется ios шорткат для настройки таргетов ios mobile.multiplatform.iosTargetWarning=false # путь до xcode проекта или воркспейса, используется Kotlin Multiplatform Mobile плагином для Android Studio чтобы запускать ios приложение с отладчиком # Подробнее https://plugins.jetbrains.com/plugin/14936-kotlin-multiplatform-mobile xcodeproj=./sample/ios-app 

Является упрощенным вариантом с moko-network.

Gradle Sync

Система сборки Gradle не связана напрямую с IDE и расчитана в первую очередь на работу без UI, через консоль. Но в IDEA и Android Studio реализована полная интеграция с Gradle, позволяющая запускать команды Gradle, видеть модули Gradle и прочее. Чтобы IDE могла считать конфигурацию проекта используется импорт проекта, называется действие Gradle Sync.

gradle sync in android studio

Кнопка для запуска Gradle Sync в Android Studio:

После успешного завершения импорта проекта, через Gradle Sync, мы получаем проиндексированный проект, в котором каждый gradle модуль обработан и считаны подключенные зависимости, настройки проекта (используется ли котлин, мультиплатформа и прочее):

project panel

Также после импорта проекта в IDE доступна панель работы с Gradle — в ней можно посмотреть все Gradle модули и все задачи, которые доступны в каждом модуле:

gradle tasks panel

Самая полезная, и часто используемая для iOS разработчиков задача — скомпилировать iOS фреймворк и перенести в директорию для Cocoapods.

Зовется она syncMultiPlatformLibraryDebugFrameworkIosX64 (добавляется плагином mobile-multiplatform). Где:

  • MultiPlatformLibrary — имя фреймворка, который будет получен на выходе
  • Debug — конфигурация сборки (для разработки собираем дебаг с отладочной инфой, Release делает CI)
  • IosX64 — таргет, который должен быть собран (то есть iOS для запуска в симуляторе на x64 машине)

Для разработки используем именно Debug + IosX64, так как этот вариант имеет оптимизацию на уровне Kotlin/Native компилятора с множеством кешей. Работает быстрее всех остальных вариантов сборки фреймворка.

gradle cocoapods task

Внесение изменений в конфигурацию

Какие блоки конфигурации можно использовать в конкретном build.gradle зависит от подключенных к данному проекту плагинов. Каждый плагин может добавлять свои блоки конфигурации и свои задачи.

Например, плагин org.jetbrains.kotlin.multiplatform добавляет блок kotlin и множество задач типа compileKotlinIosX64 (если в блоке kotlin включен таргет iosX64 ).

Детальная информация о том какие настройки доступны в блоке kotlin доступна на сайте документации.

Помимо документации узнать досутпный функционал предоставляемый плагином можно используя подсказки IDEA, когда используется Gradle Kotlin DSL, вместо Groovy. В таком случае, при успешно завершенной индексации (после клика на Gradle Sync) можно использовать автозавершение кода и переход к объявлению.

gradle kotlin dsl autocomplete

Использование автодополнения (либо подождать при наборе кода, либо нажать ctrl + space )

Использование перехода к объявлению типа ( Cmd + left click ):

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *