Gradle и система сборки Android

• Приветствие студентов и слушателей.  

• Объяснение темы лекции: Gradle и система сборки Android.  

• Структура лекции: три этапа.  

• Определение Gradle как системы автоматизации сборки.  

• Основные понятия: проект, задачи, плагины, сборка.  

• Структура Gradle проекта на примере Android-проекта.  

• Автоматизация сборки APK, AR, JAR, запуск тестов.  

• Подключение стороннего кода, генерация и трансформация кода.  

• Параллельное выполнение задач, кэширование информации о сборке.  

• Проект: сущность, содержащая задачи, плагины и зависимости.  

• Задача: кусок логики сборочной логики проекта.  

• Плагин: переиспользуемая логика для абстрагирования логики проекта.  

• Сборка: выполнение набора задач.  

• Фаза сборки: этап жизненного цикла проекта.  

• Дерево файлов типичного Android-проекта.  

• Роль Gradle properties файла в настройке сборки.  

• Local Properties файл для указания пути к Android SDK.  

• Settings.gradle файл для определения модулей и подпроектов.  

• Переход от Groovy к Kotlin для написания DSL.  

• Пример использования блока plugins для регистрации плагинов.  

• Функциональный тип и метод ID в Kotlin.  

• Создание собственного Gradle плагина.  

• Применение знаний на практике в командной разработке.  

• DSL-блоки в Gradle скрывают обычный Java-код.  

• Gradle загружает скрипты в класс-пасс и исполняет их сверху вниз.  

• Код компилируется в байт-код JVM перед исполнением.  

• Android-плагин собирает ресурсы и исходный код в APK-файл.  

• Стандартный блок в Android-проекте настраивает пакет, SDK, версию приложения.  

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

• Релизная сборка подписывается релизным ключом, дебажная — дебажным.  

• Можно конфигурировать код по-разному для разных билдтайпов.  

• Продукт-флейворы позволяют собирать код для разных вариантов распространения приложения.  

• Пример использования: отключение рекламы в зависимости от типа распространения.  

• Библиотеки можно подключать к проекту или сборке.  

• Gradle скачивает и распаковывает библиотеки, позволяя использовать их код в проекте.  

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

• Аннотации описывают библиотеку: группа, имя, версия.  

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

• Важно либо явно подключать все зависимости, либо использовать транзитивные зависимости через API.  

• Для подключения библиотеки к сборке нужно обернуть конфигурацию в блок `buildscript`.  

• В блоке `dependencies` указывается только класс-пасс библиотеки.  

• NoClassFoundError возникает, когда Gradle выбирает более новую версию библиотеки, даже если она содержит ошибки.  

• Дублирование классов возникает, когда две библиотеки используют одинаковые классы, но разные версии.  

• Firebase использует первую версию библиотеки, но метод удалён во второй версии.  

• Gradle выбирает вторую версию, вызывая ошибку.  

• Для решения проблемы можно настроить Gradle на выбор определённой версии через конфигурации и стратегии разрешения конфликтов.  

• При подключении Firebase и сторонней библиотеки Google API возникает конфликт классов.  

• Ошибка: класс Google.GoogleAPI найден в обеих библиотеках.  

• Механизм exclude позволяет исключить зависимость от определённой библиотеки при подключении другой.  

• При подключении библиотеки Guava транзитивно подключается библиотека Finebox, которая не нужна в продакшене.  

• Exclude позволяет исключить эту библиотеку, чтобы избежать лишнего веса APK-файла.  

• Важно тщательно изучить, какие библиотеки исключать, чтобы не потерять нужный функционал.  

• Многомодульность — это разделение кодовой базы на отдельные Gradle-модули.  

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

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

• В сеттинг-файле указываются модули, участвующие в сборке проекта.  

• Модули подключаются через ключевое слово Project для ссылки на подпроект.  

• App-модуль инициализирует все модули и собирает проект.  

• Параллельная сборка модулей может ускорить процесс.  

• Для включения параллельной сборки нужно настроить Gradle на параллельность, указав «parallel = true».  

• Зависимости между модулями могут замедлять сборку, так как модули ждут завершения сборки зависимых модулей.  

• Core-модуль собирается первым, затем фичи 1 и 2.  

• App-модуль собирается последним и должен дождаться сборки всех остальных модулей.  

• Рекомендуется минимизировать нагрузку на App-модуль, чтобы избежать затягивания сборки.  

• Зависимости между фичами могут ухудшать параллельность сборки, выстраивая её в цепочку.  

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

• Gradle анализирует файловую систему проекта и оптимизирует пересборку, не перестраивая неизменённые модули.  

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

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

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

• Многомодульность может привести к дублированию зависимостей и конфигурации.  

• Для решения проблемы дублирования зависимостей используйте вершинный каталог.  

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

• Вершинный каталог позволяет централизованно управлять версиями зависимостей.  

• Создайте файл с расширением .toml для описания зависимостей.  

• Зарегистрируйте вершинный каталог в настройках Gradle, указав путь к файлу.  

• В файле .toml декларируйте версии и библиотеки, используя группы, имена и версии.  

• В Gradle-файлах используйте псевдонимы для библиотек, указанных в вершинном каталоге.  

• Объединяйте библиотеки в бандлы для упрощения работы.  

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

• Создайте новую директорию для конвенционных плагинов и включите её в настройки Gradle.  

• В настройках Gradle подключите плагин Kotlin DSL и необходимые библиотеки.  

• Создайте файлы conventio-плагинов с именами, соответствующими их назначению.  

• Настройте параметры и зависимости в файлах conventio-плагинов.  

• Используйте сгенерированный код Gradle для удобства использования конвенционных плагинов.  

• Вынесение логики отправки файлов в Google в отдельный плагин.  

• Замена кода в build.gradle на подключение плагина.  

• Гибкость использования плагинов для повторного использования логики между модулями.  

• Призыв задавать вопросы во время перерыва.  

• Обещание ответить на вопросы после перерыва.  

• Kotlin предпочтительнее для написания скриптов из-за строгой типизации.  

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

• Ожидается, что в будущем предпочтение будет отдаваться Kotlin.  

• Важность централизации библиотек в проекте.  

• Использование BOM-файлов для управления версиями библиотек.  

• Необходимость проверки актуальности версий подключаемых библиотек.  

• Gradle Wrapper позволяет гибко использовать разные версии Gradle.  

• Скрипт Gradle Wrapper обрабатывает версию Gradle и скачивает её при необходимости.  

• Преимущества Gradle Wrapper: лёгкость использования, стандартизация сборки, удобство переключения версий.  

• Gradle Daemon ускоряет сборку проектов на 15–75%.  

• Кэширование информации о предыдущих сборках.  

• Анализ изменений в файловой системе проекта для оптимизации пересборки.  

• Запуск Gradle Daemon в фоновом режиме.  

• Gradle демон выполняет задачи сборки и тестирования.  

• Демон отправляет результаты клиенту через локальный сокет.  

• После завершения сборки клиент уничтожается, а демон остаётся в фоновом режиме.  

• Команда `gradle status` показывает запущенные демоны.  

• Можно запустить сборку с демоном или без него, указав соответствующий флаг.  

• Демон можно принудительно остановить командой `stop`.  

• Три этапа жизненного цикла: инициализация, конфигурация, выполнение.  

• Инициализация: анализ settings.gradle, определение включенных проектов, создание экземпляров класса Project.  

• Конфигурация: анализ build.gradle, построение графа выполнения задач.  

• Выполнение: планирование и выполнение задач по построенному графу.  

• Задачи описываются в скриптах и плагинах, между ними выстраиваются связи.  

• На основе зависимостей строится направленный циклический граф выполнения задач.  

• Циклы в графе могут привести к сбою сборки.  

• Регистрация задач для будущего исполнения.  

• Присвоение свойств зарегистрированным задачам.  

• Возможность ручной регистрации задач.  

• Задачи состоят из списка экшенов, выполняемых в определённой последовательности.  

• Экшены выполняются в блоках `doFirst` и `doLast`.  

• Логику задач рекомендуется выносить в отдельные классы.  

• Создание абстрактного класса, наследуемого от `DefaultTask`.  

• Аннотирование метода с `@TaskAction`.  

• Обработка входных данных с помощью `@Input`.  

• Lazy configuration позволяет отложенную инициализацию объектов.  

• Регистрация задач без создания объекта, объект создаётся при построении графа задач.  

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

• Примеры входных данных: `Property`, `File`, `List<File>`.  

• Примеры выходных данных: `File`, `List<File>`, `Directory`.  

• Вариации размещения задач в графе для правильного выполнения.  

• Задача «Билд» формирует APK-файл из исходников.  

• Задача «Публиш» принимает APK-файл и публикует его.  

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

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

• Пример: «publish dependsOn build».  

• Можно связать входные и выходные данные задач через свойства Input и Output.  

• Gradle плагин позволяет упаковывать сборочную логику в отдельную сущность.  

• Плагин может регистрировать задачи, связывать их и принимать параметры.  

• Плагины можно размещать в отдельном проекте или в директории Build Source.  

• Для написания плагина нужно унаследоваться от класса Plugin и реализовать метод apply.  

• Важно сделать плагин публичным, зарегистрировав его в Gradle-файле.  

• Регистрация плагина позволяет подключать его в других модулях.  

• В плагине можно работать с Android блоками, настраивая их как в скриптовом файле.  

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

• Extensions позволяют настраивать плагин снаружи, передавая параметры.  

• Создание отдельного модуля для написания Gradle плагина.  

• Настройка директории Build Logic и создание Gradle-файла.  

• Подключение зависимостей, включая Android Gradle плагин и Kotlin Gradle плагин.  

• Регистрация плагина с заданным ID и классом реализации.  

• Реализация интерфейса Plugin.  

• Разделение логики выгрузки для разных вариантов сборки.  

• Использование Project extensions для настройки логики выгрузки.  

• Получение типизированного extension для Android.  

• Обработка ошибок при отсутствии extension.  

• Регистрация задачи для разных вариантов сборки.  

• Определение имени задачи и варианта сборки.  

• Пример имени задачи: «оплот АПК Ford баг».  

• Создание абстрактного класса «оплот Task».  

• Метод задачи должен быть помечен аннотацией Task Action.  

• Приём APK файла в качестве входных данных.  

• Написание метода для выгрузки APK файла.  

• Необходимость токена робота и ID чата.  

• Использование Kotlin Coroutines для асинхронных операций.  

• Подключение необходимых библиотек для работы с сетью.  

• Синхронизация проекта и добавление логики сборки.  

• Получение пути к APK файлу в конкретном варианте сборки.  

• Обработка директории с APK файлами.  

• Фильтрация файлов по суффиксу для извлечения только APK файлов.  

• Создание POST-запроса с URL Telegram API.  

• Передача токена, ID чата и APK файла через Multipart Form Data.  

• Настройка HTTP заголовков для корректной передачи файла.  

• Проверка кода ответа и вывод логов.  

• Синхронизация проекта и подключение плагина.  

• Запуск задачи публикации APK файла.  

• Проблема с передачей свойства «пока директории».  

• Проверка сингал артефакта ПК и удаление явного указания типа.  

• Указание директории для решения проблемы.  

• Ошибка возникает в момент обращения к HTTP-клиенту.  

• Использование флага -s для отладки.  

• Демонстрация печати имени файла для подтверждения ошибки.  

• Конфликт версий корутин из-за зависимости проекта.  

• Проверка версии корутин через задачу build.  

• Решение проблемы путём явного подключения нужной версии корутин.  

• Подключение нужной версии корутин через build.gradle.  

• Успешная сборка и отправка файла в Telegram.  

• Пример изменения имени файла и повторной сборки.  

• Плагин для выгрузки файлов в Telegram при сборке проекта.  

• Удобство использования плагина для командной разработки.  

• Пример применения плагина студентами мобильной разработки.  

• Отсутствие автоматической конвертации в IntelliJ.  

• Основные принципы конвертации: изменение стиля кода, использование одинарных кавычек, изменение регистра переменных.  

• Рекомендации по проверке исходников и поиску ответов в интернете.  

• Официальная документация Gradle как лучший источник информации.  

• Важность понимания многообразия механизмов Gradle.  

• Рекомендация изучать документацию и блочные логи для понимания работы Gradle.  

• Зависимость скорости сборки от архитектуры процессора.  

• Параллельное выполнение задач в многомодульных проектах.  

• Влияние количества демонов на производительность сборки.  

• Подведение итогов лекции.  

• Благодарность за внимание.