Сколько часов вы просидели перед Android Studio, просматривая сообщение «Gradle Build Running», просто ожидая сборки и развертывания приложения на вашем устройстве? Для больших приложений, совместно используемых десятками разработчиков, измерение этого числа важно для определения того, сколько времени может быть потрачено впустую. Ранее я писал о способах сокращения времени сборки, но очень важно получить исходные данные, чтобы понимать, как ваши улучшения ускоряют сборку по мере изменения ее настроек.
Время сборки любого крупного приложения будет в некоторой степени различаться даже для одного разработчика в зависимости от ряда факторов. Когда вы распространяете это на нескольких разработчиков, разбросанных по всему миру, каждый из которых имеет разные аппаратные и программные настройки, это число будет сильно различаться. В то время как ваша основная команда может иметь новейшее и самое лучшее оборудование, у вас может быть команда подрядчиков, использующих старые машины, над которыми у вас мало контроля. Важно понимать, насколько эти сроки сборки различаются для всех ваших разработчиков.
Как я упоминал в одной из своих предыдущих статей, я не являюсь экспертом по Gradle, но могу собрать что-то работающее. Обычно. Таким образом, могут быть улучшения, которые можно было бы внести в мой код, но обычно он выполняет свою работу.
Наша общая цель — измерить время выполнения процесса сборки каждого разработчика, а также собрать важную системную информацию. Я рекомендую не помещать весь ваш код в файл build.gradle. У нас есть отдельный файл Gradle, который мы называем buildTasks.gradle, который применяется в build.gradle для поддержания порядка.
Первый шаг — проверить каждую из задач сборки и определить, нужно ли ее измерять. Нас интересует любая задача, которая компилирует приложение и отправляет его на устройство. Это, как правило, задачи, начинающиеся со слова assemble. Такой шаг позволит пропустить такие задачи, как проверка линтера. Мы также можем пропустить задачи, связанные с тестами. Имена этих задач будут заканчиваться на test. Поэтому мы с радостью измерим задачу assembleDebug, но проигнорируем задачу assembleDebugAndroidTest.
Как организация, мы хотим измерять только время сборки в Android Studio. Мы намеренно игнорируем сборки из командной строки или через CI. Это полностью зависит от вас и вашей компании, поэтому следующий фрагмент полезен для моего проекта, но необязателен для всех остальных.
Если свойство версии IDEA не может быть найдено, сборка не выполняется в Android Studio (или какой-либо другой среде разработки IDEA), и мы немедленно завершаем задачу. В противном случае начинаем измерения и сбор данных:
startTimeSec устанавливается сразу при создании этой задачи. elapsedTimeSec определяется после фактического запуска задачи. На самом деле это число, которое нам нужно, но мы также хотим собрать дополнительные данные об оборудовании и программном обеспечении, на котором работает эта сборка. Таким образом, часть нашего скрипта определяет системную информацию о самой машине. Я расскажу об этом в следующей статье, а сейчас важной частью является определение операционной системы:
Каждое семейство аппаратных средств имеет свой собственный сценарий команд, специфичных для ОС, на котором запускается. Возвращается блок JSON с различными характеристиками машины (если все идет по плану), записанный в output, примерно так:
Обратите внимание на объект error, который мы передали в consumeProcessOutput. Если при выполнении этих внешних сценариев возникнет какая-либо проблема, в этот объект будет добавлено сообщение. Вместо того, чтобы пытаться исправить ошибку, мы просто немедленно возвращаемся и убиваем задачу, если это необходимо.
Если все работает успешно, мы используем JSON и преобразуем его в карту, которую сможем обновить позже. Я использую JsonSlurper, но подойдет любой парсер JSON:
Так мы можем превратить существующие спецификации во что-то более читабельное:
Или очистить значения по какой-либо причине:
Или добавить версии программного обеспечения:
Приложение для iOS также было настроено для измерения времени их сборки, поэтому мы жестко запрограммировали платформу на «Android» в нашем скрипте.
Наконец, мы добавляем фактическое время сборки. Мы включаем время как в секундах, так и в минутах, но вам решать, как вы хотите его представить:
Теперь, когда у вас есть желаемые характеристики оборудования и программного обеспечения, вы можете отобразить их или сохранить по своему усмотрению. В идеале вы со временем соберете эту информацию для каждого разработчика и объедините ее для последующего анализа. Вот где будет полезен облачный сервис ведения логов или аналитики. В следующей статье я расскажу о различных вариантах, а пока давайте просто выведем их в консоль:
Окончательный результат общей задачи будет выглядеть примерно так:
Наконец, включите все в файле build.gradle вашего приложения:
Вы можете посмотреть полный файл buildTasks.gradle здесь.
Как упоминалось в этой статье, не хватает нескольких деталей, которые я расскажу в следующей статье. В основном о том, как собрать информацию об оборудовании и куда отправить эти данные после того, как вы закончите. Но на данный момент вы должны иметь возможность успешно регистрировать эту информацию каждый раз, когда запускаете сборку локально. Надеюсь, этого достаточно, чтобы понять, сколько времени вы тратите впустую, просто ожидая завершения сборки.