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