Android Studio медленная инкрементная сборка

Question

Я прошел много шагов, чтобы усовершенствовать нашу систему сборки ( те и другие). Позже я прочитал этот официальный пост, в котором утверждается, что время сборки улучшено в 5-10 раз с добавочными сборками в Gradle 3.4. Действительно, наши инкрементные сборки не работали, потому что мы использовали annotationProcessors. Начиная с Gradle 4.7, процессоры аннотирования могут быть совместимы с инкрементными сборками. Я прошел через множество обновлений зависимостей, чтобы активировать инкрементные сборки с помощью annotationProcessors, которые его поддерживают.

Благодаря различным конфигурациям и улучшениям мне удалось сократить время сборки (предварительно скомпилированное) с ~30 до ~19 с. На основании поста построчной сборки я предполагал, что смогу еще больше сократить время сборки до ~5 с.

К сожалению, в случае инкрементных сборок он снизился до ~15 с. С помощью --profile а также --info Я пытался дополнительно диагностировать проблему. Только вынимая задание compileDevDebugJavaWithJavac это показывает, что шаг компиляции прошел от ~16 с до ~12 с.

Инкрементная компиляция 476 классов завершена за 12,51 с.

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

Я также попытался включить экспериментальную функцию

android.enableSeparateAnnotationProcessing=true

который работает и разбивает мою сборку на два этапа компиляции

compileDevDebugJavaWithJavac 6.777s

processDevDebugAnnotationsWithJavac 6.104s

Я надеялся, что в сочетании с

org.gradle.parallel=true

Обе задачи могут выполняться параллельно и почти вдвое быстрее. Но, видимо, параллельная обработка здесь не работает или нет?

Что еще можно сделать, чтобы увеличить время сборки очень небольших изменений?

Редактировать: я обнаружил, что основная проблема в том, что у нас слишком много зависимостей классов, и это всегда запускает компиляцию 476 классов (см. Этот вопрос). Поскольку я не ожидаю разрешения достаточного количества зависимостей классов в нашем устаревшем коде: мой вопрос остается в силе. Может проект может enableSeparateAnnotationProcessing распараллелить или есть какая-то другая конфигурация?

Answer 1

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

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