Build board android что это

Уменьшаем время сборки ваших Android-проектов

Доброе утро! Начинаем понедельник с материала, перевод которого подготовлен специально для студентов курса «Android-разработчик. Продвинутый курс».

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

Посмотрите на показатели сканирования сборки до/после оптимизации

до оптимизации

после оптимизации ️️

Снизились с 5,5 минут до 17 секунд?? С ума сойти!

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

Прежде всего!

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

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

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

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

В разделе Performance есть вкладка Settings and suggestions, в которой приведены рекомендации по улучшению скорости сборки. Давайте посмотрим на них.

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

Шаг № 1: Обновите инструменты

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

Во время этого рефакторинга наш проект был на версии 3.2.1 плагина Gradle для Android Studio (на несколько версий старше, чем последний выпуск).

Вы можете перейти по этой ссылке, чтобы получить последнюю версию Gradle Plugin. На момент написания этого поста последней была версия 3.4.0.

Но здесь есть подвох, о котором мы должны помнить:

(Примечание: При использовании Gradle версии 5.0 или выше размер памяти демона Gradle по умолчанию уменьшается с 1 ГБ до 512 МБ. Это может привести к снижению производительности сборки. Чтобы переопределить этот параметр по умолчанию, укажите размер памяти для демона Gradle в файле gradle.properties вашего проекта.)

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

Откройте файл build.gradle верхнего уровня, который вы найдете в корне вашего проекта, и добавьте следующую строку в раздел зависимостей:

Вам также необходимо обновить distribution URL-адрес в файле свойств Gradle Wrapper, который находится по адресу gradle/wrapper/gradle-wrapper.properties . Обновите URL-адрес до следующего.

Вы столкнетесь с ошибкой при использовании Kotlin, если версия плагина Kotlin Gradle меньше 1.3.0. Если это так, воспользуйтесь подсказкой IDE, чтобы обновить Gradle плагин для Kotlin до последней версии (на момент написания этой статьи это версия 1.3.31).

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

Шаг № 2: Обновите конфигурации

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

Gradle может отключить инкрементную компиляцию, так как следующие процессоры аннотаций не являются инкрементными: butterknife-compiler-10.1.0.jar (com.jakewharton:butterknife-compiler:10.1.0), dagger-compiler-2.9.jar (com.google.dagger:dagger-compiler:2.9).

Рассмотрите возможность установки экспериментального флага android.enableSeparateAnnotationProcessing-true в файле gradle.properties для запуска обработки аннотаций в отдельной задаче и выполнения инкрементной компиляции.)

Инкрементная компиляция в основном предотвращает расточительную компиляцию всего набора исходных файлов и вместо этого компилирует только те файлы, которые были изменены. Из логов видно, что мы не пользуемся этой функцией. Он предлагает нам использовать android.enableSeparateAnnotationProcessing=true , но, в любом случае, мы не должны использовать конфигурацию «annotationProcessor» поскольку в нашем проекте используется Kotlin.

К счастью, в версии 1.3.30 Kotlin добавлена поддержка пошаговой обработки аннотаций.

(Инкрементная обработка аннотаций (с 1.3.30)

Начиная с версии 1.3.30, kapt поддерживает инкрементную обработку аннотаций в качестве экспериментальной функции. В настоящее время обработка аннотаций может выполняться инкрементально, только если все используемые процессоры аннотаций являются инкрементными.
Чтобы включить инкрементную обработку аннотаций, добавьте эту строку в файл gradle.properties :

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

1. 1. Измените конфигурацию annotationProcessor на kapt
2. 2. Включите экспериментальный флаг инкрементной обработки аннотации

Откройте файл build.gradle уровня вашего модуля и добавьте следующую строку в начало файла:

apply plugin: ‘kotlin-kapt’

Затем измените все конфигурации annotationProcessor в разделе зависимостей для использования kapt. Например:

//До
annotationProcessor ‘com.google.dagger:dagger-compiler:2.9’
//После
kapt ‘com.google.dagger:dagger-compiler:2.9’

Теперь откройте файл gradle.properties, расположенный в корне вашего проекта, и добавьте следующую строку:

Давайте снова запустим сборку.

Хорошо, похоже, мы еще немного продвинулись.

Шаг № 3: свойства Gradle

Мы на последнем этапе. Помните подвох, с которым мы столкнулись при обновлении версии плагина Gradle? Оказывается, более новые версии Gradle уменьшают размер используемой памяти до 512 МБ. Это сделано для того, чтобы слабые машины не расходовали слишком много памяти. У меня компьютер с 16 гигабайтами оперативной памяти, поэтому я могу позволить себе скормить около 2-3 гигов демону Gradle, но ваши цифры могут отличаться.

Откройте файл gradle.properties, расположенный в корне вашего проекта, и добавьте следующую строку. Не забудьте выбрать размер в соответствии с вашими требованиями и спецификацией компьютера.

org.gradle.jvmargs=-Xmx3072m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

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

Вот как выглядит мой окончательный вариант файла gradle.properties :

• org.gradle.parallel — этот флаг позволяет Gradle собирать модули внутри проекта параллельно, а не последовательно. Это полезно только для многомодульных проектов.
• org.gradle.configureondemand — этот флаг настраивает только те модули, которые необходимы для проекта, а не собирает их все.

Сделав это, давайте посмотрим, какие у нас теперь показатели скорости сборки:

Заключительные замечания

Это ни в коем случае не обширный охват всех способов оптимизации скорости сборки. Есть множество других вещей, которые я не рассмотрел в этом посте, таких как использование minSdk 21 при использовании MultiDex, предварительная индексация библиотек, отключение сжатия PNG и т. д., — это всего лишь некоторые из них.

Но большинство из этих конфигураций требуют более глубокого понимания системы сборки Android и опыта работы с крупными многомодульными проектами (где преимущества наиболее очевидны). Шаги, которые я упомянул выше, легко внедряются в проект даже джуниор разработчиками и имеют значительные выгоды. Я надеюсь, что это поможет вам увеличить скорость сборки!

Источник

Строим Android x86

Установка окружения для сборки

Для сборки Android потребуется 64 битная версия Linux. Еще один важный момент: обратите внимание на версию GCC, которая установлена на системе. Google поддерживает версию GCC 4.4 и выше. Так же на системе должна быть установлена реализация Java от Oracle.
Установка дополнительных зависимостей для Ubuntu 12.04:

Установите символьную ссылку для устранения конфликта имен:

Загрузка дерева исходных кодов

Установка Repo

Repo — утилита управления репозиториями, упрощающая работу с Git для Android. Более подробную информацию можно прочесть здесь (http://source.android.com/source/version-control.html)
Для установки, инициализации и настройки Repo выполните следующие шаги:
• Убедитесь, что у вас есть директория bin в вашем домашнем каталоге и она прописана в PATH:

• Загрузите Repo скрипт и выставите права на выполнение:

Инициализация Repo клиента

После установки Repo, настройте доступ к репозиториям исходных кодов Android:
• Создайте пустую директорию для исходных файлов и перейдите в нее. Например, это может выглядеть так:

• Запустите скрипт repo init, чтобы обновить версию самого Repo.

Эта команда подключит ветку master из дерева исходных кодов Android. Вы можете указать любую другую, используя ключ -b:

Для просмотра всех доступных веток введите команду:

Нас интересуют наиболее последние версии Android от Google:

• Jelly Bean: remotes/origin/android-4.1.1_r6
• Ice Cream Sandwich: remotes/origin/android-4.0.4_r2.1

Можно выбрать любую на ваш вкус, дальнейшие шаги не будут отличаться. Для демонстрации процесса сборки под VirtualBox возьмем версию Jelly Bean (JB).
В случае успешной инициализации вы увидите сообщение о том, что Repo инициализирован в вашей директории и в ней появится папка .repo

Загрузка файлов

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

Начальная синхронизация может занять больше часа времени.

Сборка ядра

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

Воспользуемся заранее подготовленной версией ядра от Intel:

Перейдем в директорию ядра:

Теперь у нас есть исходники ядра. Нужно модифицировать конфигурационный файл и пересобрать. Чтобы сократить время на полную настройку ядра, воспользуемся конфигурационным файлом, который подготовили для на разработчики. Важный момент — не забывайте указать архитектуру для которой происходит сборка ядра, в нашем случае это x86.

Через несколько секунд загрузится графическое меню настройки ядра. Стрелками «вверх», «вниз» вы можете передвигаться по пунктам меню, «Enter» чтобы зайти в подменю. Все точно так же как с обычным ядром Linux.

Чтобы включить поддержку мыши:
• Зайдите в «Device Drivers»
• Выберите «Input device Support»
• Отметьте «Mice»
Вы можете зайти в подменю «Mice» и посмотреть дополнительные настройки драйверов.
Затем выйдите из меню конфигурации ядра. Это можно сделать с помощью нескольких нажатий на «Esc». Не забудьте сохранить настройки, когда меню конфигурации предложит это сделать.
Сделав необходимые настройки ядра, соберем его. Это не займет много времени, особенно если вы используете многоядерную машину — можете указать опцию команды make: -j N, где N — число ядер (например, для написания статьи использовалась make -j 32).

При успешной компиляции вы увидите сообщение:

Путь до нового ядра указан в последней строке.

Подмена ядра

Путь к ядру, которое будет использовано в сборке для VirtualBox можно определить следующим образом:

Должно вывестись примерно следующее:

Скопируем bzImage по найденному пути:

Построение Android

Установим окружение для сборки:

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

После выполнения команды вы увидите информацию о предстоящей сборке:

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

Процесс сборки может занять значительное время, конкретные цифры зависят от мощности центрального процессора и объема оперативной памяти машины. На системе, которая использовалась для подготовки статьи это заняло около часа. Рекомендуемое число потоков для сборки можно определить из расчета 2GB оперативной памяти на поток.
При успешной компиляции, последняя строка вывода будет содержать путь и размер образа:

Далее необходимо собрать загрузочный образ для VirtualBox:

Если сборка прошла успешно, в консоли должна появиться запись:

Настройка VirtualBox

Эмулятор Jelly Bean

Сборка эмулятора мало чем отличается от сборки версии для VirtualBox. Если у вас уже есть исходные коды, то приступайте к сборке с шага инициализации окружения. Для чистоты эксперимента, будет процесс постройки эмулятора будет изложен с самого начала. Поэтому создадим отдельную директорию для Jelly Bean Emulator и повторим уже знакомые шаги.

Загрузка исходных кодов

Выбор сборки эмулятора

В случае успеха вы увидите:

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

Теперь сборка эмулятора завершена.
Самый простой способ запустить его:

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

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

Источник