# 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.
