Ускорить время сборки проекта 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 (или не) вы использовать. enter image description here

Как упоминал 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.

Я сделал ручные тайминги со стандартным секундомером, а затем округлил вверх / вниз до ближайшей секунды. Я сделал три тайминги в каждом случае рассчитываются и по среднему арифметическому.

результаты:

Graphs of IntellIJ vs Eclipse compile and deploy time

Примечание: Я не включил отдельный столбец для " выполнения 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 - я не знаю, применимо ли это вообще в вашем случае, тем не менее, вы можете получить дальнейшие идеи отсюда...