blocks|key|2946657|text|我不太确定为什么Android+Studio比命令行慢，但你可以通过打开增量dexing来加快构建速度。在模块的构建文件中，将此选项添加到android块：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2946658|dexOptions+{
++++incremental+true
}|code-block|syntax|javascript|2946659|在dexOptions块中，您还可以指定dex进程堆大小，例如：|2946660|dexOptions+{
++++incremental+true
++++javaMaxHeapSize+"4g"
}|2946661|这些选项取自adt-dev邮件列表(https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ)上的一个线程，它有更多的上下文。|2946662|entityMap|0|LINK|mutability|MUTABLE|url|https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ^0|1X|7|0|0|1|A|0|0|I|1N|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|11|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|M|3|N|5|H|7|15|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|16|8|@]|D|@$9|17|A|18|1|19]]|E|$]]|$1|Q|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|R|$S|$5|T|U|V|E|$W|X]]]]

I'm not quite sure why Android Studio is slower than the command line, but you can speed up your builds by turning on incremental dexing. In your module's build file, add this option to your <code>android</code> block:

<pre><code>dexOptions {
 incremental true
}
</code></pre>

In that <code>dexOptions</code> block you can also specify the heap size for the dex process, for example:

<pre><code>dexOptions {
 incremental true
 javaMaxHeapSize "4g"
}
</code></pre>

These options are taken from a thread on the adt-dev mailing list (<a href="https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ" rel="noreferrer">https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ</a>) which has a little more context.

blocks|key|152224|text|我们的团队也面临着同样的问题。我们的项目超过了dex的方法限制(>65k)。因此，在out库项目中，我们在build.gradle中添加了以下选项：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|152225|dexOptions+{
++++jumboMode+=+true
++++preDexLibraries+=+false
}|code-block|syntax|javascript|152226|在我们的项目build.gradle中：|152227|+dexOptions+{
++++jumboMode+=+true
//++incremental+true
}|152228|以前我们有增量真。在评论之后，它需要大约20秒才能运行，而不是2分30秒。我不知道这能解决你的问题。但它可以帮助其他人。:)|152229|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Our team was facing the same issue.
Our project exceeds the method limit for dex(>65k).
So, in out library project we put below options in build.gradle:

<pre><code>dexOptions {
 jumboMode = true
 preDexLibraries = false
}
</code></pre>

In our project build.gradle:

<pre><code> dexOptions {
 jumboMode = true
// incremental true
}
</code></pre>

previously we had incremental true. after commenting it its taking around 20s to run as compared to 2mins 30 seconds.
I don't know this may solve your problem. but it can help to others. :)

blocks|key|150774|text|“离线”解决了我的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|150775|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

blocks|key|153587|text|在传递一个值时，可以附加字母'k‘表示千字节，'m’表示兆字节，或'g‘表示千兆字节。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|153588|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

When passing a value, you can append the letter 'k' to indicate kilobytes, 'm' to indicate megabytes, or 'g' to indicate gigabytes.

blocks|key|153593|text|免责声明:这不是一种解决方案-它是一种声明，即没有使用相关链接源来证明it.的解决方案|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|153594|由于这里的所有答案都不能解决自2014年以来一直挥之不去的问题，我将继续发布几个链接，其中描述了一个非常相似的问题，并提供了特定于操作系统的调整，这些调整可能有帮助，也可能没有帮助，因为OP似乎没有指定它，并且解决方案在它们之间存在很大差异。|153595|首先是actual+AOSP+bug-tracker+issue+referring+to+parallelization，有很多相关的东西，仍然是开放的，仍然有很多人抱怨版本是2.2.1。我喜欢注意到这个问题的人(这是一个高优先级的问题)，包括"666“在内的id不是巧合。大多数人描述音乐程序和鼠标移动在构建过程中卡顿的方式就像是在照镜子……|153596|你应该注意到，人们报告了Windows的进程套索的好东西，而我看到没有人真正报告了*nix变体中的renice‘in或cpu限制的好东西。|153597|This+guy+(他说他不使用gradle)实际上在Ask+Ubuntu中提供了一些非常好的东西，不幸的是在我的例子中不起作用。|153598|Here+is+another+alternative限制了gradle执行的线程，但在我的场景中，这并没有真正改善，可能是因为有人在另一个链接上说过，studio会产生多个gradle实例(而该参数只影响一个实例的并行性)。|153599|请注意，这一切都回到了最初的"666"，高优先级问题……|153600|就我个人而言，我无法测试许多解决方案，因为我在一台托管的(无根权限)+Ubuntu机器上工作，无法执行apt-get/renice，但我可以告诉你，我有一个i7-4770，8+8GB内存和混合固态硬盘，即使经过多年来的大量内存和gradle调整，我也遇到了这个问题。这是一个诱人的问题，我不能理解谷歌为什么没有向gradle项目投入必要的人力资源，以修复他们构建的最重要平台的开发核心。|153601|在我的环境中需要注意的一件事是:我在一个多依赖工作室项目中工作，大约有10个子项目，所有这些项目都是自己构建的，并填满了gradle管道。|153602|entityMap|0|LINK|mutability|MUTABLE|url|https://code.google.com/p/android/issues/detail?id=66696|1|https://askubuntu.com/a/470256|2|https://stackoverflow.com/a/30507485/1103974^0|0|12|0|0|3|1M|0|0|0|0|8|1|0|0|R|2|0|0|36|27|0|0|1X|0^^$0|@$1|2|3|4|5|6|7|17|8|@$9|18|A|19|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1A|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|1B|8|@]|D|@$9|1C|A|1D|1|1E]]|E|$]]|$1|J|3|K|5|6|7|1F|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1G|8|@]|D|@$9|1H|A|1I|1|1J]]|E|$]]|$1|N|3|O|5|6|7|1K|8|@]|D|@$9|1L|A|1M|1|1N]]|E|$]]|$1|P|3|Q|5|6|7|1O|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|1P|8|@$9|1Q|A|1R|B|C]]|D|@]|E|$]]|$1|T|3|U|5|6|7|1S|8|@$9|1T|A|1U|B|C]]|D|@]|E|$]]|$1|V|3|-4|5|6|7|1V|8|@]|D|@]|E|$]]]|W|$X|$5|Y|Z|10|E|$11|12]]|13|$5|Y|Z|10|E|$11|14]]|15|$5|Y|Z|10|E|$11|16]]]]

Disclaimer: This isn't a solution - it's a statement that there is no solution with relevant link sources to prove it.

Since all answers here do not solve a problem that has been lingering since 2014, I'm gonna go ahead and post a couple of links which describe a very simillar problem and present OS-specific tweaks that might or might not help, since OP did not seem to specify it, and solutions vary a lot across them.

First is the <a href="https://code.google.com/p/android/issues/detail?id=66696" rel="nofollow noreferrer">actual AOSP bug-tracker issue referring to parallelization</a>, with a lot of relevant stuff, still open and still with a lot of people complaining as off version 2.2.1. I like the guy who notes the issue (a high-priotity one at that) id including "666" not being a coincidence. The way most people describe music programs and mouse movement stuttering during builds feels like looking into a mirror...

You should note people report good stuff with process lasso for Windows, while I see none really reporting anything good with renice'ing or cpu-limiting in *nix variants.

<a href="https://askubuntu.com/a/470256">This guy</a> (who states he doesn't use gradle) actually presents some very nice stuff in Ask Ubuntu, that unfortunately doesn't work in my case.

<a href="https://stackoverflow.com/a/30507485/1103974">Here is another alternative</a> that limits threads of gradle execution, but that didn't really improve in my scenario probably due to what somebody says on another link about studio spawning multiple gradle instances (while the parameter only affects one instance's parallelism). 

Note that this all goes back to the original "666", high-priority issue...

Personally I couldn't test many of the solutions because I work on a managed (no root privs) Ubuntu machine and can't apt-get/renice, but I can tell you I have an i7-4770, 8GB RAM and a hybrid SSD, and I have this problem even after a lot of memory and gradle tweaks over the years. It is a tantalizing issue, and I can't understand how Google hasn't committed the necessary human resources to the gradle project to fix something that is at the core of development for the most important platform they build.

One thing to note on my environment is: I work in a multi-dependency studio project, with about 10 subprojects, all of them building on their own and filling up the gradle pipeline.

right now we are in a situation of having build times 2 minutes 30 seconds for very simple change. This (compared to ANT) is amazingly slow and is killing the productivity of the whole team.
I am using Android Studio and using the "Use local gradle distribution".
I've tried to give more memory to gradle:

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

A lot more memory. AND IT IS STILL GIVING ERRORS FOR MEMORY from time to time. 

<blockquote>
 Exception in thread "pool-1-thread-1" java.lang.OutOfMemoryError: GC overhead limit exceeded
</blockquote>

Amazing. I am using the parallel option and daemon:

<blockquote>
 org.gradle.parallel=true 
 
 org.gradle.daemon=true
</blockquote>

It doesn't really help. 

I've put the aforementioned parameters in ~/.gradle/gradle.properties (and I even doubted that Android studio is ignoring that, so I tested - it is not ignoring it).

Still from terminal I get 1:30 build time vs 2:30 in Android Studio, so not sure what is wrong there. 1:30 is STILL CRAZY compared to Ant. If you know what Android Studio is doing (or ignoring, or rewriting as gradle config), I'd be grateful to know.

So just CMD + B (simple compile) is super fast after changes, like 7 seconds.
But when it comes to running the app, it starts the task dexXxxDebug, which is just killing us. 
I've tried putting 

<blockquote>
<pre><code>dexOptions {
 preDexLibraries = false
}
</code></pre>
</blockquote>

Doesn't help.

I understand that gradle is probably still not ready for production environments, but I'm starting to regret our decision to move so early to it.
We have lots of modules, which is probably part of the problem, but that was not an issue with Ant. 

Any help appreciated,
Dan

Some more information about execution times:

Description Duration

<pre><code>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
</code></pre>

The time eater:
:app:dexDebug 1m16.46s

Extremely long build with Gradle (Android Studio)

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

现在我们的情况是，对于非常简单的更改，构建时间为2分30秒。这(与ANT相比)慢得令人惊讶，而且正在扼杀整个团队的生产力。我使用的是Android Studio和“使用本地gradle发行版”。我试着给gradle更多的内存： org.gradle.jvmargs=-Xmx6096m -XX:MaxPermSize=2...

问使用Gradle构建超长版本(Android Studio)
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用Gradle构建超长版本(Android Studio)EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用Gradle构建超长版本(Android Studio)
EN