Ускорить время сборки проекта Android в IntelliJ IDEA
мне интересно, если есть какой-нибудь способ, как установить skip packaging and dexing
в IntelliJ идея, как в Eclipse и ADT. Есть Additional VM Options
поле в разделе компилятора Android DX в IntelliJ Preferences
, может быть, это может быть способ, как это сделать. Я также был бы признателен за другие советы,как ускорить сборку проекта IntelliJ Android.
4 ответов
в настройках Eclipse, полное название skip packaging and dexing
вы имеете в виду это Skip packaging and dexing until export or launch. (Speeds up automatic builds on file save)
, который является функцией, добавленной с ADT 12 в orde для решения проблемы инкрементной компиляции Eclipse (которая замедляет развитие Eclipse), проверьте Изменения 12.0.0 (Июль 2011) и этой ссылке для получения более подробной информации, обратите внимание, что упаковка и дэсин являются фундаментальным шагом при отладке/запуске проекта независимо от того, какой IDE (или не) вы использовать.
Как упоминал CrazyCoder в своих комментариях, IntelliJ не поддерживает Eclipse-как инкрементная компиляция и панель проблем по умолчанию, другими словами, он не автоматически компилирует ваш проект при изменении файла. Так что это действительно не проблема и не особенность IntelliJ.
ваше узкое место процесса сборки, вероятно, происходит из другого места. AFAIK в проекте среднего размера, больше всего времени процесс сборки тратит на компиляцию ресурсов (команда AAPT, проверьте процесс построения схемы). Некоторые умные люди из xdadevelopers нашли узкое место и создали исправленную версию AAPT:
http://forum.xda-developers.com/showthread.php?t=1907281
Я использую его сам, и я бы сказал, что ускорение скорости чувствительно в Eclipse, обратите внимание, что оно только увеличивает шаг AAPT, а не упаковку ad dexing. Если вы используете InteliJ, это, вероятно, не очень помогает, поскольку ему не нужно компилировать проект довольно часто.
Я использую IntelliJ 12. Я выиграл время развертывания и запуска приложений Android, позволяющих IntelliJ "автоматически создавать проект". Чтобы включить его, просто перейдите в предпочтения ->компилятор и проверьте "сделать проект автоматически". В этом же окне установите флажок "компилировать независимые модули параллельно".
включение "сделать проект автоматически " позволяет пропустить задачу" сделать " перед запуском приложения Android. Вы можете удалить его в " конфигурации запуска / отладки", выбор приложения для Android и удаление задачи" сделать "в разделе" перед запуском".
у меня нет решения, но у меня есть объяснение, почему существует огромная разница во времени компиляции между Eclipse и IntelliJ. Потому что есть. Всякий раз, когда вы зависите от внешних модулей или библиотек: IntellIJ всегда dex'ES зависимые модули. Eclipse, похоже, кэширует их.
Я тоже испытывал эту огромную разницу в одном из моих проектов. Я сделал несколько базовых тестов времени и обнаружил, что мой проект, который построил за 40 секунд в IntellIJ, занял только 20 Затмение. Много времени было потрачено на процесс, в котором IntelliJ имеет статус выполнение DEX, так вот как я нашел этот вопрос. Затем я попытался провести более тщательный и воспроизводимый эксперимент, и вот что я обнаружил.
настройки проекта
- проект Hello World от Новое Приложение Для Android шаблон в Eclipse.
- зависимость AndEngine Android С Открытым Исходным Кодом Проект игрового движка*.
- затмение: проект AndEngine определяется как"библиотека Android". Добавлена в качестве ссылки на вкладке Android и требуемый проект под Java Build Path / Projects-tab.
- IntelliJ: AndEngine определяется как"модуль". Установите в качестве зависимости для основного модуля HelloWorld флажок экспорт не проверено (не то, что я думаю, что это имеет значение).
*) Я мог бы использовать любой модуль, но вот это был хорошим примером, так как он a) довольно большой и b) является модулем Android, а это значит, что я должен связать его как проект Android, а не только как банку, как dbm предложить в сообщении выше.
Я добавил код входа в onCreate
метод MainActivity.java
(активность запуска HelloWorld), которая также вызвала метод в AndEngine, который также зарегистрировал строку. (Я изменил конструктор SoundManager
для вывода строки и вызова конструктора из MainActivity.java
). Это позволило мне увидеть, когда приложение было завершено развертывание и что оно также было развернуто правильно.
затем я сделал следующие изменения и приурочил каждый из них три раза в каждой IDE:
- A: изменена только строка ведения журнала в основном модуле
- A+B: изменена как строка ведения журнала в основном модуле, так и в модуле AndEngine.
Я сделал ручные тайминги со стандартным секундомером, а затем округлил вверх / вниз до ближайшей секунды. Я сделал три тайминги в каждом случае рассчитываются и по среднему арифметическому.
результаты:
Примечание: Я не включил отдельный столбец для " выполнения DEX "в Eclipse, потому что он просто выводит" make "или" refreshing workspace " во всем процессе сборки.
при запуске из Eclipse вы можете видеть из чисел, что я экономлю время, когда я только изменяю основной модуль - как и ожидалось. Но в IntelliJ время компиляции одинаково в обоих случаях!
вывод:
IntelliJ делает много ненужного DEX'ING. Если кто-нибудь знает, настраивается ли это, я думаю, мы решим, что Я believe является основной причиной проблемы.
иногда, когда я добавляю большие внешние банки в свой проект (Eclipse), кажется, что он значительно замедляет процесс сборки.
Я, однако, заметил, что вместо добавления банок, как обычно (Project -> Properties -> Java Build Path -> Libraries -> Add External JARs...
) вместо этого можно добавить пользовательскую библиотеку (Project -> Properties -> Java Build Path -> Libraries -> Add Library... -> User Library
) и вместо этого добавьте внешние банки в эту библиотеку.
это до сих пор всегда решало мои проблемы с большими банками-время сборки. Некоторые умные ребята также объяснили мне, почему это так, но, к сожалению, я не очень запомните объяснение. У меня нет опыта в IntelliJ - я не знаю, применимо ли это вообще в вашем случае, тем не менее, вы можете получить дальнейшие идеи отсюда...