Чрезвычайно длинная сборка с Gradle (Android Studio)
прямо сейчас мы находимся в ситуации, когда время сборки 2 минуты 30 секунд для очень простых изменений. Это (по сравнению с ANT) удивительно медленное и убивает производительность всей команды.
Я использую Android Studio и использую "Использовать локальный дистрибутив gradle".
Я попытался предоставить больше памяти gradle:
org.gradle.jvmargs = -Xmx6096m -XX: MaxPermSize = 2048m -XX: + HeapDumpOnOutOfMemoryError -Dfile.encoding = UTF-8
Намного больше памяти. И ЭТО ЕЩЕ ЕЩЕ ЕЩЕ ОСТАЕТСЯ ОШИБОК ДЛЯ ПАМЯТИ.
Исключение в потоке "pool-1-thread-1" java.lang.OutOfMemoryError: превышен верхний предел GC
Удивительная. Я использую параллельную опцию и демон:
org.gradle.parallel = true
org.gradle.daemon = истина
Это действительно не помогает.
Я поставил вышеупомянутые параметры в ~/.gradle/ gradle.properties(и я даже сомневался, что студия Android игнорирует это, поэтому я тестировал - он не игнорирует его).
С терминала я получаю 1:30 время сборки против 2:30 в Android Studio, поэтому не уверен, что там не так. 1:30 - STILL CRAZY по сравнению с Ant. Если вы знаете, что делает Android Studio (или игнорируя или переписывая как gradle config), я был бы признателен за это.
Так просто CMD + B (простой компилятор) супер быстро после изменений, например 7 секунд.
Но когда дело доходит до запуска приложения, оно запускает задачу dexXxxDebug, которая просто убивает нас.
Я пробовал поставить
dexOptions {
preDexLibraries = false
}
Не помогает.
Я понимаю, что gradle, вероятно, еще не готов к производственным средам, но я начинаю сожалеть о нашем решении переехать так рано.
У нас есть много модулей, которые, вероятно, являются частью проблемы, но это не проблема с Ant.
Любая помощь ценится,
Dan
Дополнительная информация о времени выполнения:
Описание Продолжительность
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
Ответы
Ответ 1
Я не совсем уверен, почему Android Studio работает медленнее, чем в командной строке, но вы можете ускорить сборку, включив инкрементное дешинирование. В файле сборки модуля добавьте этот параметр в блок android
:
dexOptions {
incremental true
}
В этом блоке dexOptions
вы также можете указать размер кучи для процесса dex, например:
dexOptions {
incremental true
javaMaxHeapSize "4g"
}
Эти параметры берутся из потока в списке рассылки adt-dev (https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ), который имеет немного больше контекста.
Ответ 2
Наша команда столкнулась с той же проблемой.
Наш проект превышает предел метода для dex ( > 65k).
Итак, в проекте библиотеки ниже мы добавили опции в build.gradle:
dexOptions {
jumboMode = true
preDexLibraries = false
}
В нашем проекте build.gradle:
dexOptions {
jumboMode = true
// incremental true
}
ранее мы имели инкрементную истину. после того, как он прокомментировал это, он занимает около 20 секунд для запуска по сравнению с 2 миллионами 30 секунд.
Я не знаю, что это может решить вашу проблему. но это может помочь другим.:)
Ответ 3
Отказ от ответственности: это не решение - это утверждение о том, что нет никакого решения с соответствующими источниками ссылок для его подтверждения.
Так как все ответы здесь не решают проблему, которая задерживается с 2014 года, я собираюсь пойти и опубликовать пару ссылок, которые описывают очень симилярную проблему и представляют специфические для ОС настройки, которые могут или не помогут, так как ОП, похоже, не указывает его, и решения сильно различаются между собой.
Сначала актуальная проблема с ошибкой AOSP, относящаяся к распараллеливанию, с множеством релевантных материалов, все еще открытых и все еще с большим количеством людей, жалующихся как версия 2.2.1. Мне нравится парень, который отмечает проблему (высокий приоритет в этом), в том числе "666", не совпадение. То, как большинство людей описывают музыкальные программы и затягивание мышц во время сборки, похоже на просмотр зеркала...
Вы должны отметить, что люди сообщают о хороших вещах с помощью процесса lasso для Windows, хотя я вижу, что никто не сообщает ничего хорошего с renice'ing или cpu-limit в вариантах * nix.
Этот парень (который утверждает, что он не использует gradle) на самом деле представляет некоторые очень приятные вещи в Ask Ubuntu, которые, к сожалению, не работают в моем случае.
Вот еще одна альтернатива, которая ограничивает потоки выполнения gradle, но это действительно не улучшилось в моем сценарии, вероятно, из-за того, что кто-то говорит по другой ссылке о студия порождает несколько экземпляров gradle (в то время как параметр влияет только на один экземпляр parallelism).
Обратите внимание, что это все возвращается к исходному "666", высокоприоритетной проблеме...
Лично я не мог протестировать многие из решений, потому что я работаю на управляемой (без корневой системы) машине Ubuntu и не могу apt-get/renice, но могу сказать, что у меня есть i7-4770, 8 ГБ ОЗУ и гибридный SSD, и у меня есть эта проблема даже после большого количества памяти и gradle настроек за эти годы. Это мучительная проблема, и я не понимаю, как Google не предоставил необходимые ресурсы для проекта gradle, чтобы исправить то, что лежит в основе разработки для самой важной платформы, которую они создают.
Одно замечание в моей среде: я работаю в проекте с несколькими зависимостями, в котором около 10 подпроектов, все они строятся сами по себе и заполняют конвейер gradle.
Ответ 4
При передаче значения вы можете добавить букву "k", чтобы указать килобайты, "m", чтобы указать мегабайты, или "g", чтобы указать гигабайты.
Ответ 5
Для пользователей Linux это помогает: sudo renice -n 20 -p <pid of gradle daemon>
Вы можете найти pid, используя команду: pgrep -la java
И найдите ".gradle/daemon", выберите pid.
Ответ 6
'- offline' решил мою проблему.