Декларативные сборки Android, готовые к работе с агентами, с помощью Lightbuild

Здравствуйте!

Меня зовут Хуан Себастьян Овьедо.

Я менеджер по продуктам в команде Android для разработчиков.

Сегодня мы со Скоттом рады представить вам Lightbuild – новую экспериментальную среду сборки для приложений Android.

Я расскажу о контексте этого проекта, его философии и о том, почему мы считаем, что сейчас самое время переосмыслить настройку проектов для Android.

Я также расскажу, как этот новый подход закладывает основу для будущего разработки приложений для Android.

Для начала давайте посмотрим, как все работает сейчас.

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

Например, вы можете использовать логику, которая динамически вычисляет коды версий на основе истории Git, или определить пользовательскую задачу, которая преобразует объекты.

// build.gradle.kts
android {

  compileSdk = 37

  buildTypes {

    debug {

      // Custom logic in build script
      val commit = providers.exec {
        commandLine("git", "rev-parse",
                    "--short", "HEAD")
      }.standardOutput.asText.get()
       .trim()

      versionNameSuffix = "-$commit"

    }

  }

}

Наряду с Gradle существует AGP, или плагин Android Gradle, который берет универсальный движок Gradle и адаптирует его к набору инструментов Android.

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

Благодаря такой гибкости наши инструменты разработки работают в рамках определенного архитектурного жизненного цикла.

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

Поскольку файлы сборки написаны на императивном, полном по Тьюрингу языке, единственный общий способ для IDE узнать, какова конфигурация, – это запустить скрипты сборки.

Во время синхронизации IDE система сборки проходит этап настройки.

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

Это позволит синхронизировать представление проекта в Android Studio с его фактической конфигурацией.

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

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

В Google и в экосистеме в целом есть несколько инициатив, направленных на улучшение работы разработчиков в этой области.

Такие инициативы, как Declarative Gradle и тулчейн Kotlin, направлены на замену исполняемых скриптов сборки декларативной конфигурацией сборки.

В Android Studio есть помощник по обновлению AGP, который поможет вам перейти с одной версии AGP на другую.

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

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

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

Помимо этого, мы задались более широким вопросом.

Что если мы полностью переосмыслим способ настройки проектов?

Если мы посмотрим на то, как сегодня устроены современные приложения для Android, мы увидим серьезный сдвиг в сторону модульности.

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

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

На самом деле в файлах сборки не должно быть произвольного исполняемого кода.

Всё, что им нужно, – это чёткий способ указать свою структуру и зависимости.

Это наблюдение привело нас к созданию Lightbuild.

Lightbuild опирается на два столпа.

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

Во-вторых, он обеспечивает быструю синхронизацию IDE за счет упреждающего разрешения зависимостей.

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

Начнем с основы декларативной конфигурации сборки.

Посмотрите на файл в левой части экрана.

Это текущая конфигурация модуля.

// build.gradle.kts

plugins {
   alias(libs.plugins.android.library)
   alias(libs.plugins.kotlin.compose)
}

val gitCommit = providers.exec {
   commandLine("git", "rev-parse", "--short", "HEAD")
}.standardOutput.asText.get().trim()

android {
   namespace = "com.example.app"
   compileSdk = 37

   defaultConfig {
       minSdk = 24
       buildConfigField("String", "GIT_COMMIT",
                        "\"$gitCommit\"")
   }
   buildFeatures {
        compose = true
        buildConfig = true
   }
}

dependencies {
  implementation(platform(libs.androidx.compose.bom))
  implementation(libs.androidx.compose.ui)
  implementation(libs.androidx.compose.ui.graphics)
  ...

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

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

Теперь посмотрите на файл в правой части экрана.

Это конфигурация Lightbuild для похожего модуля.

# lightbuild.yaml

group: "com.example"
version: "1.0.0"

platform: android
type: library

android:
 namespace: "com.example.app"
 compileSdk:
   version:
     release:
       apiLevel: 37
 minSdk:
   version:
     release:
       apiLevel: 24
 dependencies:
   maven:
     - androidx.core:core-ktx:1.10.1
     - androidx.lifecycle:lifecycle-runtime-ktx:2.6.1
     - androidx.activity:activity-compose:1.8.0

Этот файл содержит только декларативные данные.

В нем нет определений локальных переменных, вызовов пользовательских вспомогательных функций, условных операторов и встроенных определений задач.

В нем четко указаны тип модуля, целевые SDK и зависимости.

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

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

Поскольку разработчики используют агентов в рамках своего рабочего процесса, этим агентам необходима возможность читать и изменять конфигурацию сборки.

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

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

В Lightbuild конфигурация проекта представляет собой детерминированный статический граф данных.

Это означает, что агенты могут проверять этот граф, понимать топологию модуля и изменять его, используя известную схему.

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

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

Ещё одна деталь, которую я хочу подчеркнуть, заключается в том, что Lightbuild – это не плагин для системы сборки, а интерфейс для механизма сборки.

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

Однако архитектурный подход, который мы использовали в Lightbuild, позволяет Android Studio (IDE) распознавать и обрабатывать проект как проект Lightbuild.

Теперь перейдем ко второму столпу, который касается продуктивности разработчиков и рабочего процесса: быстрой синхронизации IDE.

Даже если разработчики используют агентов в своих рабочих процессах, Android Studio остается важным инструментом для интерактивных задач, например для просмотра предварительных версий интерфейса Compose, пошаговой отладки кода при исследовании проблемы или анализа производительности с помощью профилировщика.

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

Открываете ли вы проект, редактируете файл сборки или переключаетесь между ветками, IDE быстро обрабатывает информацию и предоставляет доступ к нужным инструментам.

Одна из причин такой скорости и надежности – то, как Lightbuild обрабатывает зависимости.

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

В Lightbuild при изменении зависимостей инструмент автоматически вычисляет информацию о транзитивных зависимостях и записывает ее в файл resolved.deps в каталоге каждого модуля.

Это позволяет избежать повторного вычисления информации о транзитивных зависимостях при открытии или пересборке проекта.

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

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

Мы рады сообщить, что предварительная версия Lightbuild доступна в Android Studio Canary, а также в виде отдельных инструментов CLI.

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

Продолжайте использовать AGP и Gradle для рабочих приложений, а Lightbuild – для демо- и экспериментальных проектов.

Попробовать Lightbuild можно уже сегодня на сайте goo.gle/lightbuild. Мы будем рады вашим отзывам, которые помогут нам улучшить продукт.

А теперь я передаю слово Скотту, который покажет Lightbuild в действии.

Спасибо, Хуан.

Меня зовут Скотт Майерс.

Я инженер по связям с разработчиками Android. Мы уже некоторое время работаем над Lightbuild и рады показать вам, как вы можете получить доступ к этому инструменту и попробовать его в действии.

Итак, сначала перейдите по ссылке, которую упомянул Хуан, goo.gle/lightbuild, или просто выполните поиск по запросу Lightbuild.

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

Также вы можете установить интерфейс командной строки Lightbuild, чтобы получить все преимущества агентного подхода.

Итак, после того, как вы все настроите, как у меня здесь, на моем компьютере, у меня будет запущена последняя версия Android Studio Canary.

А сейчас я покажу, как создать демопроект Lightbuild. Вы сможете сделать это уже сегодня.

Сначала я перейду в мастер создания проектов.

Я выберу Empty Activity и нажму Next.

Теперь вы видите обычный экран сведений о проекте, но внизу есть новый вариант.

В разделе "Язык конфигурации сборки" выберите Lightbuild.

Прежде чем вы нажмете "Готово", вам напомнят, что это экспериментальная функция.

Вы увидите, что проект сразу синхронизируется с IDE и готов к работе.

Теперь давайте рассмотрим структуру типичного проекта Lightbuild.

Это стандартный шаблон Android, который вы получаете при создании нового приложения.

Оно просто говорит: "Привет, мир!"

Это простой способ начать.

На корневом уровне проекта есть файл project.lightbuild.yaml.

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

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

Итак, у нас есть два модуля: app и app-core.

Это связано с тем, что все проекты Lightbuild имеют как минимум два модуля.

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

И я скоро объясню, почему.

Сначала давайте посмотрим на этот модуль приложения.

Если развернуть его, то на корневом уровне модуля вы увидите файл lightbuild.yaml, который есть в каждом модуле.

Здесь есть некоторая базовая информация.

Мы работаем над платформой Android.

И этот модуль имеет тип приложения.

Вы можете перечислить целевые версии SDK, идентификатор приложения и т. д., а затем перечислить все модули, от которых зависит этот модуль приложения.

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

Поэтому в Lightbuild модули приложения не содержат исходного кода.

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

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

Теперь давайте рассмотрим модуль app-core, который является модулем библиотеки, от которого зависит этот модуль приложения.

Как видите, в этом модуле есть исходный код.

Здесь находится наша основная логика.

Оно просто говорит: "Привет, мир!"

Если я посмотрю на файл lightbuild.yaml в этом модуле, вы увидите, что он относится к типу библиотеки.

Здесь также задаются номера версий SDK, но перечисляются все внешние зависимости, которые у нас есть в этом модуле.

и объявляет модульные и инструментальные тесты.

Далее давайте посмотрим на другой файл, который вы могли заметить здесь, и Хуан немного говорил об этом, внутри каждого модуля есть файл resolved.deps.

Этот файл автоматически генерируется Lightbuild.

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

Таким образом, все ваши зависимости и транзитивные зависимости уже здесь.

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

Теперь давайте посмотрим, как Lightbuild улучшает работу разработчиков с синхронизацией проектов.

Итак, я вернулся в корневой каталог project.lightbuild.yaml, где перечислены все модули моего приложения.

Обычно при редактировании файлов конфигурации или конфигурации сборки вы заметите, что появляется кнопка синхронизации, обработка которой занимает некоторое время из-за процессов, которые описывал Хуан, когда ему приходится выполнять частичную сборку, выполняя все ваши скрипты сборки, а затем синхронизируя эту модель с IDE.

Давайте внесем довольно серьезное изменение в этот небольшой проект.

Мы просто удалим один из модулей.

И вы можете видеть, что этот модуль, прежде чем я нажму кнопку сохранения, он распознается IDE, потому что вы можете сказать, что он здесь выделен жирным шрифтом.

Он распознал каталог с исходными файлами и каталоги с тестами.

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

Если я отменю это изменение и нажму "Сохранить", то все вернется на свои места так же быстро.

Это пример быстрой синхронизации IDE, которую Lightbuild обеспечивает для ваших проектов.

Кроме того, вы можете использовать все привычные команды Android Studio.

Вы можете нажать кнопку запуска.

Приложение будет скомпилировано и запущено.

Это демонстрационное приложение не очень большое, но я увеличу масштаб, чтобы показать, что оно говорит "Привет, Android".

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

Для запуска этих тестов в фоновом режиме вызывается Lightbuild.

В общем, все работает так, как вы ожидаете.

Теперь я хочу показать, как использовать Lightbuild, если вы не работаете в Android Studio, а используете другой агентный процесс.

Для этого у нас есть командная строка.

Поэтому в CLI для Lightbuild я просто запущу базовую команду справки.

И да, все опечатки, которые вы видите в этом проекте сегодня, мои.

В Lightbuild есть несколько встроенных команд. Ой, извините, я запускаю это вне проекта.

Он постоянно мне это говорит.

Да, живая демонстрация.

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

Для этого я воспользуюсь android create, стандартным инструментом командной строки для создания шаблонов новых проектов.

Я буду использовать шаблон empty-activity-lightbuild, назову приложение Lightbuild Demo и помещу его в выходной каталог demo.

Теперь, если я перейду в этот каталог и введу lightbuild -h, я увижу все доступные команды Lightbuild.

У нас есть много ожидаемых вещей: сборка, очистка, тестирование.

Но есть и несколько новых.

Команда resolve проверяет зависимости проекта и генерирует файлы resolved.deps, о которых я говорил ранее.

А ещё есть команда запроса, которая позволяет вам и вашим агентам лучше понять структуру проекта.

Итак, сначала я покажу вам новую команду запроса.

Итак, если я просто посмотрю на структуру этого проекта с помощью командной строки, она будет такой же, как и в демо-версии Android Studio.

Но это не даёт мне много информации о том, как устроен мой проект.

Итак, если я выполню запрос Lightbuild и посмотрю, скажем, на этот модуль приложения, я буду использовать этот специальный синтаксис, чтобы сказать: "Покажи мне все, что находится под этим модулем приложения".

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

В нем есть APK-файлы и наборы App Bundle как для отладочных, так и для рабочих двоичных файлов.

Если я просто запущу цель приложения, будет собрано все.

Также можно указать вывод в формате JSON.

И таким образом, О, извините.

Опять же, все мои опечатки сегодня реальны.

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

Хм…

Да, должно работать.

Теперь

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

Но вместо этой таблицы вы также можете выводить команды Lightbuild в формате JSON, что проще для ваших агентов.

--format json…

А, формат.

Ой, извините.

Спасибо!

Это отзыв разработчика.

Спасибо!

Да, и ещё есть команда output, которую я тоже могу продемонстрировать, возможно, с вашей помощью.

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

Это просто способ для вас и ваших агентов изучить и лучше понять проект из командной строки с помощью Lightbuild.

Затем, очевидно, есть команда lightbuild resolve, о которой я упоминал ранее, которая сгенерирует все ваши файлы resolved.deps.

В нем также есть дополнительные функции.

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

Если есть какие-либо различия, он сообщит вам об этом и не выполнит сборку.

Таким образом, эти файлы разрешенных зависимостей могут действовать как файлы блокировки. Например, если вы создаете приложение в системе CI/CD для производства, вы захотите узнать, меняются ли какие-либо зависимости во время этой сборки.

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

И ещё кое-что.

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

Это доступно для вашего агента, поэтому это выходные данные для агента.

Теперь

Мы рассмотрели несколько простых проектов с Lightbuild. Теперь давайте перейдем к более амбициозному.

Команда Android создала пример приложения Now in Android, в котором можно посмотреть, как работают некоторые из последних функций Android, и узнать рекомендации по их использованию.

Это модульное приложение.

Он разбит, кажется, на 32 разных модуля.

Вот как это выглядит в GitHub.

Но я вернусь в Android Studio, где уже использовал агент.

Я использовал Gemini Argon, чтобы перевести проект для Android Now in Android на Lightbuild.

Это не официальная публикация, а просто мое личное исследование.

И вы можете видеть, что, хотя этот проект в моем project.lightbuild.yaml имеет все эти различные модули, он все равно открывается невероятно быстро и очень быстро синхронизируется с этой IDE.

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

Демо-версия будет использовать встроенные источники данных, а рабочая версия будет выходить в сеть и извлекать данные.

Чтобы сделать это с помощью Lightbuild, который обрабатывает такие вещи, как различные конфигурации сборки или версии продукта, вы переходите в модуль приложения и указываете, что этот модуль приложения является, например, демо-приложением.

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

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

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

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

Давайте посмотрим, успешно ли собирается приложение Now in Android со всеми 32 модулями.

Да, вот оно.

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

Например, приложение Now in Android использует плагин Hilt, а Lightbuild пока не поддерживает такие вещи.

Мой агент смог найти обходной путь и добавить поддержку Hilt, не меняя код проекта.

Весь код во всех этих модулях такой же, как и в исходном репозитории.

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

Поэтому Lightbuild пока доступен только в предварительной версии в Android Studio Canary.

А теперь я бы хотела вернуться к слайдам.

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

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

В ней есть первоклассная поддержка ИИ-агентов, командная строка и все те функции, которые вы помогли мне сегодня продемонстрировать.

Поэтому мы предлагаем вам попробовать его и использовать для демонстрационных и экспериментальных проектов.

Мы с Хуаном и некоторые инженеры из нашей команды будем у стенда агентного ИИ, чтобы ответить на ваши вопросы.

Вот и все.