Очень долгая сборка с Gradle (Android Studio)

Question

Сейчас мы имеем время сборки 2 минуты 30 секунд для очень простого изменения. Это (по сравнению с ANT) удивительно медленно и убивает производительность всей команды. Я использую Android Studio и использую "Использовать локальное распространение Gradle". Я попытался дать больше памяти для gradle:

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

Намного больше памяти. И это все еще время от времени дает ошибки на память.

Исключение в потоке "пул-1-нить-1" java.lang.OutOfMemoryError: Превышен лимит накладных расходов GC

Удивительно. Я использую параллельную опцию и демон:

org.gradle.parallel = верно

org.gradle.daemon= верно

Это не очень помогает.

Я поместил вышеупомянутые параметры в ~/.gradle/gradle.properties (и я даже сомневался, что Android-студия игнорирует это, поэтому я протестировал - не игнорирует его).

Еще из терминала я получаю 1:30 время сборки против 2:30 в Android Studio, так что не уверен, что там не так. 1:30 все еще сумасшедший по сравнению с муравьем. Если вы знаете, что делает Android Studio (или игнорируете, или переписываете как конфигурацию Gradle), я был бы рад узнать.

Так что просто CMD + B (простая компиляция) очень быстро после изменений, например, 7 секунд. Но когда дело доходит до запуска приложения, оно запускает задачу dexXxxDebug, которая нас просто убивает. Я пытался положить

dexOptions {
    preDexLibraries = false
}

Не помогает

Я понимаю, что Gradle, вероятно, все еще не готов к работе, но я начинаю сожалеть о нашем решении перейти так рано. У нас есть много модулей, что, вероятно, является частью проблемы, но это не было проблемой с Ant.

Любая помощь приветствуется, Дэн

Еще немного информации о времени выполнения:

Описание Продолжительность

Total Build Time    1m36.57s
Startup 0.544s
Settings and BuildSrc   0.026s
Loading Projects    0.027s
Configuring Projects    0.889s
Task Execution  1m36.70s

Пожиратель времени::app:dexDebug 1m16.46s

Answer 1

Я не совсем уверен, почему Android Studio работает медленнее, чем командная строка, но вы можете ускорить сборку, включив инкрементальную привязку. В файле сборки вашего модуля добавьте эту опцию android блок:

dexOptions {
    incremental true
}

В этом dexOptions В блоке также можно указать размер кучи для процесса dex, например:

dexOptions {
    incremental true
    javaMaxHeapSize "4g"
}

Эти параметры взяты из цепочки рассылки adt-dev ( https://groups.google.com/forum/), которая имеет немного больше контекста.

Answer 2

Наша команда столкнулась с той же проблемой. Наш проект превышает предел метода для dex(>65k). Итак, в нашем проекте библиотеки мы поместили следующие параметры в build.gradle:

dexOptions {
    jumboMode = true
    preDexLibraries = false
}

В нашем проекте build.gradle:

 dexOptions {
    jumboMode = true
//  incremental true
}

ранее у нас была инкрементная истина. после комментирования его запуск занимает около 20 секунд по сравнению с 2 минутами 30 секундами. Я не знаю, это может решить вашу проблему. но это может помочь другим.:)

Answer 3

Отказ от ответственности: это не решение - это утверждение, что не существует решения с соответствующими ссылочными источниками, чтобы доказать это.

Поскольку все ответы здесь не решают проблему, которая существует с 2014 года, я собираюсь опубликовать несколько ссылок, которые описывают очень схожую проблему и представляют специфичные для ОС твики, которые могут или не могут помочь, так как OP сделал кажется, не указывать это, и решения сильно различаются между ними.

Во-первых, это проблема отслеживания ошибок AOSP, связанная с распараллеливанием, с множеством важных вещей, которые все еще открыты, и многие люди жалуются на версию 2.2.1. Мне нравится парень, который отмечает проблему (в первую очередь, высокую), включая "666", который не является совпадением. То, как большинство людей описывают музыкальные программы и заикания мыши во время сборок, похоже на то, что они смотрят в зеркало...

Вы должны заметить, что люди сообщают о хороших вещах с помощью процесса lasso для Windows, хотя я не вижу, чтобы кто-то действительно сообщал о чем-то хорошем с renice'ing или cpu-limiting в * nix вариантах.

Этот парень (который утверждает, что он не использует gradle) на самом деле представляет некоторые очень интересные вещи в Ask Ubuntu, которые, к сожалению, не работают в моем случае.

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

Обратите внимание, что все это восходит к оригинальной "666", высокоприоритетной проблеме...

Лично я не смог протестировать многие решения, потому что я работаю на управляемой (без root привилегий) машине с Ubuntu и не могу apt-get / renice, но я могу сказать вам, что у меня i7-4770, 8 ГБ оперативной памяти и гибрид SSD, и у меня есть эта проблема, даже после того, как много лет памяти и настроек. Это мучительная проблема, и я не могу понять, как Google не выделил необходимые человеческие ресурсы для проекта, который занимался разработками, чтобы исправить то, что лежит в основе разработки для самой важной платформы, которую они создают.

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

Answer 4

При передаче значения вы можете добавить букву "k" для обозначения килобайт, "m" для обозначения мегабайт или "g" для обозначения гигабайт.

Answer 5

'-offline' решил мою проблему.