# Gradle 是什么?
导航
[TOC]
## [](https://docs.gradle.org/current/userguide/what_is_gradle.html#gradle_overview)[概述](https://docs.gradle.org/current/userguide/what_is_gradle.html#gradle_overview)
Gradle 是个设计灵活、几乎可以构建如何类型软件的[自动构建](https://en.wikipedia.org/wiki/Build_automation)工具。以下是其一些最重要功能的高级概述：
**高性能**
Gradle 通过仅运行因更改了输入或输出而需运行的任务来避免复杂的工作。您还可以使用构建缓存来重用以前运行的任务输出，甚至可以重用来自其它机器（已开启构建缓存共享）的任务输出。
Gradle 还进行了许多其他优化，开发团队正不断努力提高 Gradle 的性能。
**JVM环境**
Gradle 在 JVM 上运行，您必须安装 Java 开发工具包 (JDK) 才能使用它。 这十分利于熟悉 Java 平台的用户，因为您可以在构建逻辑中使用标准 Java API，例如自定义任务类型和插件。 它还使得在不同平台上运行 Gradle 变得容易。
请注意，Gradle 不仅限于构建 JVM 项目，它甚至还包含对构建本机项目的支持。
**约定**
Gradle 借鉴了 Maven，通过实现约定使常见类型的项目（例如 Java 项目）构建更容易。 应用适当的插件，您就可以轻松地为许多项目提供精简的构建脚本。 但这些约定不会限制您：Gradle 允许您覆盖它们、添加自己的任务以及对基于约定的构建进行许多其他自定义。
**可扩展**
您可以轻松扩展 Gradle 以提供您自己的任务类型，甚至构建模型。 有关此示例，请参阅 Android 构建支持：它添加了许多新的构建概念，例如插件和构建类型。
**IDE 支持**
几个主要的 IDE 允许您导入 Gradle 构建并与之交互，如 Android Studio、IntelliJ IDEA、Eclipse 和 NetBeans。 Gradle 还支持生成将项目导入到 Visual Studio 所需的解决方案文件。
**智能扫描**
[构建扫描](https://scans.gradle.com/)提供有关构建运行的大量信息，您可以通过这些信息来解决构建问题。如果您需要寻求解决构建问题的建议，还可以与他人共享构建扫描。
## [](https://docs.gradle.org/current/userguide/what_is_gradle.html#five_things)[关于 Gradle 你需要知道的五点](https://docs.gradle.org/current/userguide/what_is_gradle.html#five_things)
Gradle 是一个灵活而强大的构建工具，当你第一次开始时很容易感到害怕。 但是，了解以下核心原则将使 Gradle 更加平易近人，并且您将在不知不觉中熟练使用该工具。
### [](https://docs.gradle.org/current/userguide/what_is_gradle.html#1_gradle_is_a_general_purpose_build_tool)[1\. Gradle 是个通用构建工具](https://docs.gradle.org/current/userguide/what_is_gradle.html#1_gradle_is_a_general_purpose_build_tool)
Gradle 可以构建任何软件，对你所尝试构建的内容或应该如何完成完全没有限制（除非仅兼容 Maven 和 Ivy 工具）。
这并意味着您可以轻松的创建构建。 Gradle 通过[*插件*](https://docs.gradle.org/current/userguide/plugins.html#plugins)添加规范和预构建的功能，让构建常见类型的项目（如 Java 项目）变得容易。 您甚至可以创建和发布自定义插件来封装您自己的约定和构建功能。
### [](https://docs.gradle.org/current/userguide/what_is_gradle.html#the_core_model_is_based_on_tasks)[2\. 基于任务（task）的核心模型](https://docs.gradle.org/current/userguide/what_is_gradle.html#the_core_model_is_based_on_tasks)
Gradle 将其构建为任务（工作单元）的有向无环图（DAG）模型。这意味构建实际配置了一组任务，并根据它们的依赖关系将它们连接起来创建 DAG。创建任务图后，Gradle 会根据任务所需要的顺序运行。
此图显示了两个示例任务图，一个抽象，一个具体，用箭头表示任务之间的依赖关系：
*图一：两个Gradle任务图的例子*
几乎任何构建过程都可以通过这种方式建模为任务图，这是 Gradle 如此灵活的原因之一。该任务图可以由插件和您自己的构建脚本定义，并通过[任务依赖机制](https://docs.gradle.org/current/userguide/tutorial_using_tasks.html#sec:task_dependencies)将任务链接在一起。
任务本身包括：
* 操作 — 操作的命令，比如复制文件或编译源代码；
* 参数 — 操作的配置、文件和目录；
* 结果 — 运行操作的生成和结果。
实际上，以上所有内容都是可以选择的，取决于任务所的需要。某些如标准生命周期任务甚至没有任何操作。这只是为了方便而将多个任务聚合在一起。
> 选择您要运行的任务，通过指定你需要的任务来节约时间。如果您只想进行单元测试，请选择执行该项目的测试任务。 如果你想打包应用程序，大多数构建都有打包任务。
最后一件事：Gradle [增量构建](https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:up_to_date_checks)强大且可靠，因此除非您确实想要执行清理，可避免`clean`从而使构建任务快速运行。
### [](https://docs.gradle.org/current/userguide/what_is_gradle.html#3_gradle_has_several_fixed_build_phases)[3\. Gradle has several fixed build phases](https://docs.gradle.org/current/userguide/what_is_gradle.html#3_gradle_has_several_fixed_build_phases)
It’s important to understand that Gradle evaluates and executes build scripts in three phases:
1. Initialization
Sets up the environment for the build and determine which projects will take part in it.
2. Configuration
Constructs and configures the task graph for the build and then determines which tasks need to run and in which order, based on the task the user wants to run.
3. Execution
Runs the tasks selected at the end of the configuration phase.
These phases form Gradle’s[Build Lifecycle](https://docs.gradle.org/current/userguide/build_lifecycle.html#build_lifecycle).
Comparison to Apache Maven terminologyGradle’s build phases are not like Maven’s phases. Maven uses its phases to divide the build execution into multiple stages. They serve a similar role to Gradle’s task graph, although less flexibly.Maven’s concept of a build lifecycle is loosely similar to Gradle’s lifecycle tasks.
Well-designed build scripts consist mostly of[declarative configuration rather than imperative logic](https://docs.gradle.org/current/userguide/authoring_maintainable_build_scripts.html#sec:avoid_imperative_logic_in_scripts). That configuration is understandably evaluated during the configuration phase. Even so, many such builds also have task actions — for example via`doLast {}`and`doFirst {}`blocks — which are evaluated during the execution phase. This is important because code evaluated during the configuration phase won’t see changes that happen during the execution phase.
Another important aspect of the configuration phase is that everything involved in it is evaluated*every time the build runs*. That is why it’s best practice to[avoid expensive work during the configuration phase](https://docs.gradle.org/current/userguide/authoring_maintainable_build_scripts.html#sec:minimize_logic_executed_configuration_phase).[Build scans](https://scans.gradle.com/)can help you identify such hotspots, among other things.
### [](https://docs.gradle.org/current/userguide/what_is_gradle.html#4_gradle_is_extensible_in_more_ways_than_one)[4\. Gradle is extensible in more ways than one](https://docs.gradle.org/current/userguide/what_is_gradle.html#4_gradle_is_extensible_in_more_ways_than_one)
It would be great if you could build your project using only the build logic bundled with Gradle, but that’s rarely possible. Most builds have some special requirements that mean you need to add custom build logic.
Gradle provides several mechanisms that allow you to extend it, such as:
* [Custom task types](https://docs.gradle.org/current/userguide/custom_tasks.html#custom_tasks).
When you want the build to do some work that an existing task can’t do, you can simply write your own task type. It’s typically best to put the source file for a custom task type in the[*buildSrc*](https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources)directory or in a packaged plugin. Then you can use the custom task type just like any of the Gradle-provided ones.
* Custom task actions.
You can attach custom build logic that executes before or after a task via the[Task.doFirst()](https://docs.gradle.org/current/dsl/org.gradle.api.Task.html#org.gradle.api.Task:doFirst(org.gradle.api.Action))and[Task.doLast()](https://docs.gradle.org/current/dsl/org.gradle.api.Task.html#org.gradle.api.Task:doLast(org.gradle.api.Action))methods.
* [Extra properties](https://docs.gradle.org/current/userguide/writing_build_scripts.html#sec:extra_properties)on projects and tasks.
These allows you to add your own properties to a project or task that you can then use from your own custom actions or any other build logic. Extra properties can even be applied to tasks that aren’t explicitly created by you, such as those created by Gradle’s core plugins.
* Custom conventions.
Conventions are a powerful way to simplify builds so that users can understand and use them more easily. This can be seen with builds that use standard project structures and naming conventions, such as[Java builds](https://docs.gradle.org/current/userguide/building_java_projects.html#building_java_projects). You can write your own plugins that provide conventions — they just need to configure default values for the relevant aspects of a build.
* [A custom model](https://docs.gradle.org/current/userguide/implementing_gradle_plugins.html#modeling_dsl_like_apis).
Gradle allows you to introduce new concepts into a build beyond tasks, files and dependency configurations. You can see this with most language plugins, which add the concept of[*source sets*](https://docs.gradle.org/current/userguide/building_java_projects.html#sec:java_source_sets)to a build. Appropriate modeling of a build process can greatly improve a build’s ease of use and its efficiency.
### [](https://docs.gradle.org/current/userguide/what_is_gradle.html#5_build_scripts_operate_against_an_api)[5\. Build scripts operate against an API](https://docs.gradle.org/current/userguide/what_is_gradle.html#5_build_scripts_operate_against_an_api)
It’s easy to view Gradle’s build scripts as executable code, because that’s what they are. But that’s an implementation detail: well-designed build scripts describe*what*steps are needed to build the software, not*how*those steps should do the work. That’s a job for custom task types and plugins.
There is a common misconception that Gradle’s power and flexibility come from the fact that its build scripts are code. This couldn’t be further from the truth. It’s the underlying model and API that provide the power. As we recommend in our best practices, you should avoid putting much, if any, imperative logic in your build scripts.
Yet there is one area in which it is useful to view a build script as executable code: in understanding how the syntax of the build script maps to Gradle’s API. The API documentation — formed of the[Groovy DSL Reference](https://docs.gradle.org/current/dsl/)and the[Javadocs](https://docs.gradle.org/current/javadoc/)— lists methods and properties, and refers to closures and actions. What do these mean within the context of a build script? Check out the[Groovy Build Script Primer](https://docs.gradle.org/current/userguide/groovy_build_script_primer.html#groovy_build_script_primer)to learn the answer to that question so that you can make effective use of the API documentation.
As Gradle runs on the JVM, build scripts can also use the standard Java API. Groovy build scripts can additionally use the Groovy APIs, while Kotlin build scripts can use the Kotlin ones.
