As members of the Android Developer Tools team, my teammates and I come to work each day to build tools intended to make Android the best mobile developer platform out there. Sometimes, this means building tools that help you write apps. At other times, this means building tools that help you get back to writing your app.

作为Android开发人员工具小组的成员，我和我的队友每天都在工作，以构建旨在使Android成为最好的移动开发者平台的工具。 有时，这意味着需要构建可帮助您编写应用程序的工具。 在其他时候，这意味着需要构建工具来帮助您重新编写应用程序。

We know that lengthy builds waste time, break up the flow of development, and ultimately generate lots of frustration. The average Android Studio user builds their project ~65 times a week, so even a 10 second slow down would cost around 9 hours of each developer’s time a year. Yet, as was noted in our earlier article, Improving build speed in Android Studio, ~60% of Android developers do not analyze their build. Paired with ever growing project complexity, this has resulted in consistently increasing build durations across all Android Studio projects and a ton of lost productivity.

我们知道，漫长的工作浪费时间，破坏了开发流程，最终产生了很多挫败感。 Android Studio用户平均每周要构建项目65次，因此，即使放慢10秒，每年每个开发人员的时间也要花费9个小时左右。 但是，正如我们之前的文章“ 提高Android Studio中的构建速度”所述 ，约60％的Android开发人员没有分析其构建。 再加上项目复杂性的不断提高，这导致所有Android Studio项目的构建时间持续增加，并导致大量生产力损失。

To address this, we created the Build Analyzer, a tool designed to help all developers understand what determines the duration of their build and how it can be minimized.

为了解决这个问题，我们创建了构建分析器，该工具旨在帮助所有开发人员了解决定其构建持续时间以及如何将其最小化的因素。

利用构建分析器 (Taking advantage of the Build Analyzer)

Each time you build your app, Android Studio generates a Build Analyzer report. To see the report, make sure you do the following:

每次您构建应用时，Android Studio都会生成一个构建分析器报告。 要查看报告，请确保您执行以下操作：

1. Upgrade Android Gradle Plugin such that its version is greater than or equal to 4.0.0升级Android Gradle插件，使其版本大于或等于4.0.0
2. Build or rebuild your project建立或重建您的专案
3. Navigate to the Build Analyzer by selecting View > Tool Windows > Build from the menu bar, and then clicking on the Build Analyzer tab通过从菜单栏中选择“视图”>“工具窗口”>“构建”，导航到“构建分析器”，然后单击“构建分析器”选项卡

For the sake of this article, we’re going to be walking through a Build Analyzer report generated when running a clean build of the Santa Tracker app, an open-source educational app developed by Google.

为了本文的目的，我们将遍历运行由Google开发的开源教育应用程序Santa Tracker应用程序的全新版本时生成的构建分析器报告。

Opening the Build Analyzer lands you on the Overview page. The Overview page provides some basic information and links to jump off into the details. At a glance, you can see that this build’s duration was primarily determined by task execution as opposed to configuration.

打开构建分析器将您带入“ 概述”页面。 概述页面提供了一些基本信息和链接，以跳入详细信息。 一目了然，您可以看到此构建的持续时间主要由任务执行而非配置决定。

To learn more, let’s dig into the two datasets provided by the Build Analyzer, Tasks and Warnings by either using the links under Common views into this build or the combobox in the top left corner which currently reads “Overview”.

要了解更多信息，我们可以使用此构建的“通用”视图下的链接或当前左上角的组合框(当前显示为“概述”)来深入了解构建分析器， 任务和警告提供的两个数据集。

Tasks

任务

These tasks, either due to input/output dependencies or parallelism constraints, determined the observed build duration. Excluded from this set are tasks that ran in parallel without impacting observed build duration. Looking at this allows me to tell where the heavy lifting is being done when I build my app.

这些任务，由于输入/输出依赖性或并行性约束，决定了观察到的构建持续时间。 从这组中排除的是并行运行的任务，而不会影响观察到的构建持续时间。 查看此内容可以让我知道在构建应用程序时繁重的工作在哪里完成。

When viewed in a flat list, tasks are color coded by their source. Tasks originating from Project Customizations are defined locally in your project, and are the easiest to modify. Tasks labeled as coming from Android/Java/Kotlin Plugins come from core plugins, and tasks which were added by Other Binary Plugins could come from a binary plugin that someone on your team has authored or from a third-party binary plugin.

在平面列表中查看时，任务按其来源进行颜色编码。 源于项目自定义的任务是在项目中本地定义的，并且最容易修改。 标为来自Android / Java / Kotlin插件的任务来自核心插件，而其他二进制插件添加的任务可能来自团队中某人编写的二进制插件，也可能来自第三方二进制插件。

Tasks are displayed in a flat list by default, but can be grouped by the plugin that added them with the Group by plugin control. Grouping adds a node for each plugin in your project and modifies the visualization to display plugins as opposed to individual tasks.

默认情况下，任务显示在平面列表中，但可以通过将其添加到分组按插件控件的插件进行分组。 分组为项目中的每个插件添加一个节点，并修改可视化以显示插件，而不是单独的任务。

Here, grouping allows me to observe that the majority of my build’s duration is due to the execution of tasks from core plugins, like the Kotlin and Android Gradle plugins. This is unsurprising, especially when executing a clean build of a project like Santa Tracker. Executing an incremental build often results in less time being spent on the execution of tasks from core plugins and can reveal the impact of other plugins.

在这里，分组使我观察到，构建的大部分时间是由于从核心插件(例如Kotlin和Android Gradle插件)执行任务而导致的。 这不足为奇，特别是当执行像Santa Tracker这样的项目的干净构建时。 执行增量构建通常会减少执行核心插件上的任务所花费的时间，并且可以揭示其他插件的影响。

This plugin view is especially useful when comparing your build times before and after adding or upgrading a plugin, which will allow you to weigh the benefits of any changes against their impact on build duration. Being mindful whenever making a change is one of the best ways to prevent constantly increasing build durations from eating into your productivity. It’s also worth noting that build durations vary due to incremental execution and other constraints, so it’s best to compare a few builds.

当比较添加或升级插件前后的构建时间时，此插件视图特别有用，这将使您可以权衡任何更改的好处及其对构建持续时间的影响。 随时进行更改时要谨记谨慎，这是防止持续增加构建时间而影响生产率的最好方法之一。 还值得注意的是，构建持续时间会因增量执行和其他约束而有所不同，因此最好比较几个构建。

Warnings

警告事项

Here you can see all warnings generated by this build. This includes warnings generated for tasks that did not determine this build’s duration.

在这里，您可以看到此构建生成的所有警告。 这包括对没有确定这个版本的工期任务产生的警告。

Each warning contains an explanation of why it was generated, a recommendation for how to resolve it, and, if applicable, the details of the task which generated it. In the case that the warning was not generated by someone on your team, you can use the Generate report feature to explain the issue to the original task or plugin author.

每个警告均包含其生成原因的说明，解决方法的建议，以及(如果适用)生成它的任务的详细信息。 如果警告不是由团队中的某人生成的，则可以使用“ 生成报告”功能向原始任务或插件作者解释该问题。

As shown in the image above, we generated a Task Setup warning when using the Build Analyzer on the Santa Tracker project discussed above. This issue looks to be due to conflicting output directories, so we can resolve this problem by changing the output directory of either the generateExtraResources or mergeDebugResources tasks. The mergeDebugResources task comes from the base android plugin and cannot be edited locally, while the generateExtraResources task is project customization authored by my team. As a result, i’m going to edit the generateExtraResources task.

如上图所示，当在上面讨论的Santa Tracker项目上使用构建分析器时，我们生成了一个任务设置警告。 该问题似乎是由于输出目录冲突造成的，因此我们可以通过更改generateExtraResources或mergeDebugResources任务的输出目录来解决此问题。 mergeDebugResources任务来自基本的android插件，无法在本地进行编辑，而generateExtraResources任务是由我的团队创作的项目自定义项 。 结果，我将编辑generateExtraResources任务。

Again, note that the above report was generated by a clean build. Reports generated by incremental builds will be less consistent but are likely a better representation of your usual development workflow, so make sure that you use the Build Analyzer with both clean and incremental builds. To learn even more about what you can do with the Build Analyzer, read Troubleshoot build performance.

同样，请注意，以上报告是由干净的构建生成的。 增量构建生成的报告的一致性较差，但可能会更好地表示您通常的开发工作流程，因此请确保同时使用干净构建和增量构建的Build Analyzer。 要了解有关使用构建分析器可以做什么的更多信息，请阅读对构建性能进行故障排除 。

构建分析器如何工作 (How the Build Analyzer works)

Each time you use Android Studio to build your project, the Build Analyzer uses both the Gradle Tooling API and the Android Gradle Plugin to locally gather data. The Tooling API is used to attach a ProgressListener, which provides information on project configuration, task execution, annotation processors, and more. The Android Gradle Plugin provides additional information on things such as task name to task class name mapping and task configuration.

每次使用Android Studio构建项目时，构建分析器都会使用Gradle Tooling API和Android Gradle插件在本地收集数据。 Tooling API用于附加ProgressListener ，它提供有关项目配置，任务执行，注释处理器等的信息。 Android Gradle插件提供了诸如任务名称到任务类名称的映射以及任务配置之类的更多信息。

When your build completes, the Build Analyzer runs this information through a suite of analyzers, each of which looks for and reports a specific problem. As an example, one analyzer checks for tasks that are configured to run on each and every build. These tasks prevent time from being saved during incremental builds and can seriously impact build speed.

构建完成后，构建分析器将通过一组分析器运行此信息，每个分析器都会查找并报告特定问题。 例如，一个分析器检查配置为在每个版本上运行的任务。 这些任务会阻止在增量构建过程中节省时间，并且会严重影响构建速度。

How does this analyzer find tasks that always run? A Gradle task is up-to-date when none of its inputs or outputs have changed since the last build. When a task is up-to-date, Gradle skips running the task and re-uses the task’s old outputs instead of wasting time recreating them. A task will never be up-to-date if it doesn’t have both a task input and output declared. This analyzer consumes the information on task outputs which is provided by the Gradle Tooling API and identifies all tasks that do not declare any outputs or that specifically override up-to-date to always be false. In doing so, it identifies all tasks that will never be up-to-date and that will always run. By doing this automatically, we hope to help you quickly address this problem and start taking full advantage of incremental builds.

该分析仪如何查找始终运行的任务？ 自上次构建以来，Gradle任务的输入或输出均未更改，则该任务是最新的 。 当任务是最新的时，Gradle会跳过运行任务并重新使用任务的旧输出，而不是浪费时间来重新创建它们。 如果没有同时声明任务输入和输出的任务将永远不会是最新的。 该分析器使用Gradle Tooling API提供的有关任务输出的信息，并标识所有未声明任何输出或明确覆盖最新状态始终为false的任务。 这样，它可以标识永远不会更新且始终运行的所有任务。 通过自动执行此操作，我们希望可以帮助您快速解决此问题并开始充分利用增量构建。

Alongside the analyzer which identifies tasks that always run, there are currently two additional analyzers. One identifies annotation processors that are not incremental and the other identifies tasks that overwrite each other’s outputs. In the future, we plan to continue releasing analyzers that help you quickly find common problems and learn about Gradle best practices.

除了可确定始终运行的任务的分析器外，当前还有两个附加的分析器。 一个标识非增量注释处理器，另一个标识覆盖彼此输出的任务。 将来，我们计划继续发布分析仪，以帮助您快速发现常见问题并了解Gradle最佳实践。

下一步 (Next Steps)

If the Build Analyzer reports a warning for a task that is part of a third-party plugin, then consider filing a bug against the original plugin author. These issues may not be addressed immediately but will result in improvements for the entire ecosystem. If you believe that there is an issue with the Build Analyzer itself, please let us know on our issue tracker.

如果“构建分析器”报告了第三方插件中某项任务的警告，请考虑针对原始插件作者提交错误。 这些问题可能不会立即得到解决，但会改善整个生态系统。 如果您认为构建分析器本身存在问题，请在问题跟踪器上告知我们。

If you are interested in investigating your build even further, try using Gradle Scan to obtain additional information. Using Gradle’s Build Cache may also reduce the duration of your build.

如果您有兴趣进一步调查构建，请尝试使用Gradle Scan获取其他信息。 使用Gradle的构建缓存还可以减少构建时间。

As this tool matures, we hope to expand our suite of analyzers to identify additional warnings. We are also excited to learn how people use the tool and will be making improvements to the navigation, visualizations, and other components accordingly. Please let us know if you have any feedback, especially concerning issues you identified in your own build that were not caught by our analyzers.

随着该工具的成熟，我们希望扩展我们的分析仪套件，以识别其他警告。 我们也很高兴学习人们如何使用该工具，并将相应地改进导航，可视化和其他组件。 如果您有任何反馈意见，特别是与您在自己的内部版本中发现的问题没有被我们的分析仪发现的问题，请告诉我们。