Сборка Android-приложения. Задачка со звёздочкой

[rsashka]

Сборка проекта за 7-10 секунд, это действительно круто!
А сколько времени потом выполняется прогон тестов для «большого монолитного проекта»? Если тесты занимают несколько часов, то получается что-то вроде экономии на спичках.

[FlashLight13]

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

Скорость сборки есть смысл ускорять, потому что начиная с некоторой величины она прямо влияет на скорость разработки (одно дело отлаживать проект, у которого инкрементальная сборка занимает 30 секунд, другое, когда 3 минуты). Да и на CI как правило не один flavour собирается

[rsashka]

Я это понимаю (сам работал с проектами, у которых сборка происходила более часа), но в данном случае интересен порядок цифр. Но вы сами написали:

начиная с некоторой величины она прямо влияет на скорость разработки

А с какой величины начинает влиять? Разница между 10 и 30 секундами целых три раза, но на конечную продуктивность разработчика не будет влиять ни первая, ни вторая.

[FlashLight13]

Согласен, но разница в два раза между 20 минут и 10 становится более ощутимой.
На семпле AndroidStudio buck собирает чистый билд где-то в 1.5 раза шустрее Gradle.
Думаю, тут каждый сам должен эту грань провести и исследовать этот вопрос в контексте решаемой проблемы.

[mm3]

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

[screwer]

Линуксовое ядро (в андроид редакции) собирается начисто около 3 минут в 12 потоков на 8700к в WSL. Инкрементальная сборка после внесения изменений чуть больше 20 секунд. Из которых основное это линковка образа.

[sshikov]

>Ранние ревизии Maven собирались Ant, а сейчас они перешли на последний стабильный релиз.
Это тут про что написано?

[FlashLight13]

Про то, что когда-то давно для сборки Maven использовали Ant. Начиная с 3ей мажорной версии они перешли на сборку себя своим же предыдущим стабильным релизом

[sshikov]

Зачем это было называть «а сейчас», если тому уже пять лет? Минимум

[Stantin]

Интересно, а почему вы не включили в сравнение самый фундамент — ant?

[FlashLight13]

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

[sshikov]

Вообще что касается maven, то скорость сборки очень сильно зависит от нескольких вещей:
— SSD/HDD (как проект, так и локальный репозиторий)
— число потоков сборки (я тут этого параметра не увидел, поэтому удивлен)
— версии самого ядра и плагинов

У меня простое указание -T 10 ускоряет сборку в те же 10 раз (при условии что все плагины новые и поддерживают). Я заранее знаю, что мне тут повезло, но как минимум попробовать следовало бы

[FlashLight13]

Интересное замечание, спасибо! Все сборки производились на маке с SSD
Должен признать, что в

при условии что все плагины новые и поддерживают

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

[sshikov]

У меня тоже. В общем это видно по логам, должно быть. Я бы это просто проверил явно.

[advance]

Это критично для любой системы сборки. Ведь весь процесс сборки упирается в произвольное чтение\запись, ресурсы CPU и насколько составляющие системы доработаны и оптимизированы

[sshikov]

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

И еще когда-то были отдельные расширения (takari если мне не изменяет память), которые улучшали параллелизм при работе с локальным репозиторием, например. Не уверен, что это нужно в 3.5.*, но изучить вопрос тоже стоило бы — эффект был хороший.