java Android Studio 在 i7 处理器上使用 100% CPU 进行项目重建

Android Studio using 100% CPU on an i7 processor for project Rebuild

提问by Lou Morda

My Windows 7 machine has a quad core i7 processor. When I Rebuild my project, it takes on average 25 seconds. And when I launch the app, it takes on average 36 seconds (before the app is uploaded to the device).

我的 Windows 7 机器有一个四核 i7 处理器。当我重建我的项目时，平均需要 25 秒。当我启动应用程序时，平均需要 36 秒（在应用程序上传到设备之前）。

I have 588 files in my project's /src folder, which includes all of my java and xml code. I've got two .so libs each 5MB and 7 jars in my /libs folder.

我的项目的 /src 文件夹中有 588 个文件，其中包括我所有的 java 和 xml 代码。我的 /libs 文件夹中有两个 .so 库，每个 5MB 和 7 个 jar。

See my attached screenshot. As you can see my CPU is maxed out at 100% the entire time. My iTunes music pauses, and I get a "Poor Performance" pop-up in the lower right hand corner of my windows taskbar. That's how bad it is.

请参阅我附加的屏幕截图。如您所见，我的 CPU 一直处于 100% 的最大值。我的 iTunes 音乐暂停，我在 Windows 任务栏的右下角看到一个“性能不佳”的弹出窗口。那是多么糟糕。

I'm using Android Studio 1.2.1.1

我使用的是 Android Studio 1.2.1.1

Most of the time is spent during the preDex and dex operations.

大部分时间都花在 preDex 和 dex 操作上。

Here's what I've tried so far (separately, I haven't tried them all together):

这是我迄今为止尝试过的（单独的，我还没有一起尝试过）：

1. adding gradle.properties -> "org.gradle.daemon=true"
2. Power Saving
3. Mode Invalidate Caches /
4. Restart Global Gradle Setings -> Offline
5. work Compiler -> Make project automatically

1. 添加 gradle.properties -> "org.gradle.daemon=true"
2. 省电
3. 模式使缓存无效 /
4. 重新启动全局 Gradle 设置 -> 离线
5. 工作编译器 -> 自动制作项目

Nothing has worked yet. I can't imagine that this is a common problem, am I right? Am I being too imaptient because this really is that much slower than Eclipse?

一切都还没有奏效。我无法想象这是一个普遍的问题，对吗？我是不是太不适应了，因为这真的比 Eclipse 慢得多？

I guess my questions are:

我想我的问题是：

1. Could this be due to the size of my jars or so files?
2. I tookover a project that had many nested views in XML files. Could this be causing a problem?

1. 这可能是由于我的 jars 或 so 文件的大小吗？
2. 我接管了一个在 XML 文件中有许多嵌套视图的项目。这会导致问题吗？

I'm really reaching for straws so if anyone has any information, esepecially why the dex operation is taking up so much CPU, that would be awesome.

我真的很想求助，所以如果有人有任何信息，特别是为什么 dex 操作占用了这么多 CPU，那就太棒了。

I guess it goes without saying that this is happening if I edit an XML file, do a rebuild, and then launch the app. If there's nothing to clean and rebuild... when I just do a Make Project... the average build time is 3 seconds.

我想不用说，如果我编辑 XML 文件，进行重建，然后启动应用程序，就会发生这种情况。如果没有要清理和重建的东西……当我只是做一个制作项目时……平均构建时间是 3 秒。

回答by Lou Morda

Here are the three improvements I was able to make:

以下是我能够做出的三项改进：

I was preDexing my JARs every time I built the project, so I found this solution:

每次构建项目时，我都会对 JAR 进行预Dexing，所以我找到了这个解决方案：

dexOptions {
    preDexLibraries = false
}

I was using the entire Google Play Services library:

我使用了整个 Google Play 服务库：

compile('com.google.android.gms:play-services:+') {
    exclude module: 'support-v4'
}

When all I needed was Google Cloud Messenger:

当我只需要 Google Cloud Messenger 时：

compile('com.google.android.gms:play-services-gcm:+') {
    exclude module: 'support-v4'
}

In Eclipse, I would always do a Rebuild and then launch app with the play button. In Android Studio, now I am just doing a Clean and then launch app with the play button. Also the Run button in Android Studio does NOT work every time right after the Clean. This was causing what seemed to be delays because nothing was happening. So now I leave the Gradle Console open to make sure that the run button is working, and when it doesn't I just hit it a second time.

在 Eclipse 中，我总是会进行重建，然后使用播放按钮启动应用程序。在 Android Studio 中，现在我只是在执行 Clean，然后使用播放按钮启动应用程序。此外，Android Studio 中的运行按钮并非每次都在 Clean 之后立即工作。这导致了似乎是延误，因为什么都没有发生。所以现在我让 Gradle 控制台保持打开状态以确保运行按钮正常工作，如果没有，我只是第二次点击它。

What I used to have:

我曾经拥有的：

Rebuild: 26 seconds
Launch:  36 seconds
Install: 15 seconds

and now:

现在：

Clean:    8 seconds
Launch:  22 seconds
Install: 15 seconds

which is a major improvement! Hopefully this helps someone else.

这是一个重大的改进！希望这对其他人有帮助。

回答by Joe

As stated on the tracker page for this issue, the team has identified this as the problem:

正如此问题的跟踪器页面所述，该团队已将其确定为问题：

--parallel-threads only applies to project parallelization.

For android tasks that are running in parallel, we always create as many threads as possible

--parallel-threads 仅适用于项目并行化。

对于并行运行的android任务，我们总是创建尽可能多的线程

From the page, it seems that they target release 1.3 to address this (see comment #13 there).

从页面上看，他们似乎以 1.3 版为目标来解决这个问题（请参阅那里的评论 #13）。

In the meantime, what has helped me to cope on Windows 7 is to set the CPU affinity for the Android Studio process (and its child processes) to spare at least one of the cores (as suggested by comment #9 on the page).

与此同时，帮助我处理 Windows 7 的是为 Android Studio 进程（及其子进程）设置 CPU 亲和性，以至少保留一个内核（如页面上的评论 #9 所建议的那样）。

There are many ways to do this, but you might want to try the top-voted answer on this superuser question(which suggested to use Process Lasso) that appears to work well enough for me.

有很多方法可以做到这一点，但您可能想尝试在这个超级用户问题（建议使用Process Lasso）上投票最高的答案，它似乎对我来说效果很好。

回答by Mark McClelland

In addition to optimizations specific to Gradle (see below), I recommend that you try disabling anti-virusprotection for your Gradle caches directory and your Android Studio project directory. For me, this reduces my build times by roughly 50%. Excluding those same directories from Windows Search indexing can also help.

除了特定于 Gradle 的优化（见下文），我建议您尝试禁用Gradle 缓存目录和 Android Studio 项目目录的防病毒保护。对我来说，这将我的构建时间减少了大约 50%。从 Windows 搜索索引中排除这些相同的目录也有帮助。

Gradle optimizations I use, in ~/.gradle/gradle.properties.

我使用的 Gradle 优化，在 ~/.gradle/gradle.properties 中。

org.gradle.daemon=true
org.gradle.jvmargs=-Xmx6144m <-- Tweak this based on available RAM
org.gradle.caching=true
org.gradle.parallel=true
kotlin.incremental=true

Note that enabling caching means you sometimes have to explicitly clear your caches when switching branches. I run this script when I run into puzzling build issues.

请注意，启用缓存意味着您有时必须在切换分支时明确清除缓存。当我遇到令人费解的构建问题时，我会运行此脚本。

#!/bin/bash

# Clean Android cache
./gradlew cleanBuildCache

# Clean Gradle cache, prompting for each directory
find ~/.gradle/caches -maxdepth 1 -name build-cache* -print -exec rm -rfI {} \;

# Clean Project
./gradlew clean

# Stop Gradle Daemon
./gradlew --stop

回答by itsben

To be honest, Android Studio is hands down better than Eclipse because of the UI designer. The downside is that it uses gradle instead of Ant. Gradle is also better but slower - especially on Windows. It runs much better on Linux. If you haven't used Linux before, fear not. Linux Mint is a stable OS that has a UI that is similar to Windows. You'll be right at home in no time. It consumes fewer resources so that leaves more processing power for the gradle build. Make the switch. You'll never go back.

老实说，由于 UI 设计器，Android Studio 比 Eclipse 更好。缺点是它使用 gradle 而不是 Ant。Gradle 也更好，但速度较慢——尤其是在 Windows 上。它在 Linux 上运行得更好。如果您以前没有使用过 Linux，请不要害怕。Linux Mint 是一个稳定的操作系统，其 UI 类似于 Windows。你很快就会在家。它消耗更少的资源，从而为 gradle 构建留下更多的处理能力。进行开关。你永远不会回去。