Различия

Показаны различия между двумя версиями страницы.

--- service:gradle [08.04.2024 12:41] – [Проблемы больших проектов] viacheslav
+++ service:gradle [30.07.2024 19:21] (текущий) – внешнее изменение 127.0.0.1
@@ Строка 2: / Строка 2: @@
 https://www.youtube.com/results?search_query=gradle+kotlin
+Gradle Tutorial - Crash Course: https://www.youtube.com/watch?v=gKPMKRnnbXU\\
+Understanding Gradle (playlist): https://www.youtube.com/playlist?list=PLWQK2ZdV4Yl2k2OmC_gsjDpdIBTN0qqkE\\
 Gradle и система сборки Android: https://www.youtube.com/watch?v=5SYaITerrjU
@@ Строка 379: / Строка 381: @@
 ==== Конфигурация сборки и доп. логика сборки начинает смешиваться, усложняя поддержку ====
+m( С 49-й минуты - идиотское программистское красноглазие - мегаудобство, нечего сказать. Файлик ссылается на файлик, а тот ещё на файлик, а тот ещё на файлик. Если это удобство, тогда какой же ужас без этого Гредла со сборкой ява-приложений?
 Например, когда в ''build.gradle'' прописывается выгрузка файла в Google и т. п. Если ''build.gradle'' разрастается на несколько сотен строк, это уже тяжело читать и поддерживать.
 <file java app/build.gradle.kts>
@@ Строка 392: / Строка 396: @@
 </file>
+Для решения этой проблемы изобрели Convention plugins.
+Создаётся каталог с любым именем (ну, т. е., ещё один плагин/подпроект), к примеру, ''build-logic''.\\
+Затем, в корневом ''settings.gradle.kts'' добавляется строка в раздел ''pluginManagement {}''.
+<code java>
+pluginManagement {
+  includeBuild("build-logic")
+}
+</code>
+В ''build-logic'' создаётся свой файл ''settings.gradle.kts''
+<file java build-logic/settings.gradle.kts>
+dependencyResolutionManagement {
+  versionCatalogs {
+    create("libs") {
+      from(files("../libs.toml"))
+    }
+  }
+  repositories {
+    google()
+    mavenCentral()
+  }
+}
+</file>
+Там же ''build.gradle.kts''
+<file java build-logic/build.gradle.kts>
+plugins {
+  // без этого не взлетит
+  "kotlin-dsl"
+}
+dependencies {
+    implementation(libs.agp)
+    implementation(libs.cotlin.gradle.plugin)
+    // Костыль для работы version plugins внутри Convention plugins, иначе не работает (система ниппель!)
+    implementation(files(libs.javaClass.superclass.protectionDomain.codeSource.location))
+}
+</file>
+После этого можно создавать сами файлы Convention-плагинов. Вид дерева каталогов:
+{{:service:pasted:20240408-134709.png}}
+Названия файлов важны, т. к. к ним потом нужно будет обращаться.
+<file java android-feature-convention.gradle.kts>
+plugins {
+  id("com.android.library")
+  id("org.jetbrains.kotlin.android")
+}
+android {
+  compileSdk = 33
+  defaultConfig {
+    minSdk = 24
+  }
+}
+dependencies {
+  implementation(libs.bundles.feature.deps)
+}
+</file>
+В файле выше не будет работать конструкция ''android {}'' и ''implementation(libs.)'', т. к. этот код не генерируется в Convention plugins.\\
+Поэтому надо найти плагин, где это не подсвечивается красным цветом, **перейти в исходники и скопировать исходники оттуда в код плагина вместо неработающих конструкций.** m(
+В файл ''publish-google-convention.gradle.kts'' выносится весь код закачки на Гугл, ранее бывший в ''app/build.gradle.kts''
+<file java publish-google-convention.gradle.kts>
+import java.io.File
+import java.net.URL
+tasks.register("publishToGoogle") {
+  doLast {
+    in uploadApkToGoogle(file(File(rootDir, "build/outputs/apk/release/release.apk")).readBytes())
+  }
+}
+tasks.findByName("publishToGoogle").dependsOn(tasks.findByName("assembleRelease"))
+</file>
+Теперь ''build.gradle.kts'' выглядят так:
+<file java feature1/build.gradle.kts>
+plugins {
+  id("android-feature-convention")
+}
+android {
+  namespace = "com.example.feature1"
+}
+</file>
+<file java app/build.gradle.kts>
+plugins {
+  id("publish-google-convention")
+}
+</file>
+===== Gradle wrapper =====
+Рекомендуемый способ от разработчика Gradle для работы с ним. Структура файлов:
+{{:service:pasted:20240409-062254.png?600}}
+Здесь команда ''gradle build'' не сработает, нужно запускать скрипт ''./gradlew build'' или в винде ''gradlew.bat''.
+Основной параметр в файле ''gradle-wrapper.properties'' - это
+<file java gradle-wrapper.properties>
+// Указывает, откуда враппер может скачать ту или иную версию Гредла, с которой он будет работать
+distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
+</file>
+Если Гредл уже скачан, то при вызове ''./gradlew build'' команда сборки сразу передаётся этой конкретной версии Гредла.
+Преимущества использования wrapper:
+  * Легко использовать Гредл без предварительной установки
+  * Стандартизация сборки. К примеру, при отправке на CI будет собираться именно с Гредлом, который указан в параметрах, а не с тем, который установлен на удалённой машине.
+  * Быстрое переключение версии Гредла для проекта.
+===== Gradle daemon =====
+Это фоновый JVM-процесс, помогающий сокращать время сборки и конфигурации проекта (до 75% при повторной сборке). Что он делает:
+  - Кэширует информацию о проектах между сборками
+  - Висит в фоне, поэтому при запуске сборки не тратится время на инициализацию JVM
+  - Следит за изменениями файлов проекта
+Схема работы: ''./gradlew build'' запускает Gradle client, а тот, в свою очередь, Gradle daemon. Если демона ещё нет, то он создаётся. Демон выполняет сборку и передаёт результат и логи клиенту, всё это отображается в терминале и клиент завершает работу вместе с запросом на сборку. Демон же продолжает висеть в фоне в статусе Idle и ждёт следующего обращения к нему.
+<code bash>
+# Статус запущенных демонов
+./gradlew --status
+# Запуск сборки с демоном из терминала
+./gradlew build --daemon
+# Запуск сборки без демона
+./gradlew build --no-daemon
+# Принудительно остановить все демоны (например, если не подхватываются переменные или ещё по каким-то причинам)
+./gradlew --stop
+</code>
+<file java gradle.properties>
+// Настройка Гредла для запуска сборки с демоном (false - без демона)
+org.gradle.daemon=true
+</file>
+===== Жизненный цикл сборки / Tasks =====
+  * Инициализация
+    * Анализ ''settings.gradle.kts'', определение, какие проекты включены (include) в сборку
+    * Создание экземпляра класса Project для каждого проекта/модуля
+  * Конфигурация
+    * Анализ сценария сборки из ''build.gradle.kts'' каждого проекта
+    * Создание направленного ациклического графа задач (DAG) для каждого проекта. Задачи выполняются в порядке их зависимости друг от друга.
+  * Выполнение
+    * Планирование и выполнение всех задач в соответствии с построенным графом
+Gradle task - кусок логики, который выполняется при сборке проекта. Задачи могут выполнять разные действия: сборка apk-файла, заупск тестов, установка приложения на устройство, выгрузка apk в Маркет и т. д. Задача состоит из действий (actions), выполняющихся последовательно.