EDITORIAL言葉、最近の研究のGradleシステムは、もともとのGradleの導入についての記事を書きたかったです。
しかし、私はすでに述べた非常に良い、Gradleのこの導入を見つけた公式サイトでは、私が直接翻訳になります。
オリジナル住所https://docs.gradle.org/current/userguide/what_is_gradle.html
何Gradleのこと？
Gradleのビルド自動化ツールは、オープンソース、ほぼすべてのソフトウェアを構築するのに十分な柔軟性を持つように設計されていますされています。
これは、次の重要な利点があります。
高性能
のみの入力と出力を実行するGradleのタスクは無効な作業を避けるために、変更されています。さらに、再利用の前にタスクスイッチのバッファ出力もできます（他のマシン上のキャッシュも可能です）。
Gradleのは、他の最適化の数を実装して、開発チームは絶えずのGradleのパフォーマンスが向上します。
JVMに基づいて、
GradleのはJDK上で実行され、JDKを実行するためにインストールする必要があります。それは、Javaを使用するユーザーのための追加ボーナスでJDK上で実行されているので、それがJDKに基づいているため、このようなカスタムタスクやプラグインとして、Java APIの標準ビルドスクリプトを使用することができ、加えて、それは良いクロスすることができプラットフォーム。
Gradleのは、JVMを構築プロジェクトに限定されるものではなく、さらにはプロジェクトの建設のためのネイティブサポートが付属しています。
約束
Gradleではでは、構築しやすい（例えばJavaプロジェクトなど）の項目の一般的なタイプの契約を実装することにより、Maveanアプローチを学びます。簡単に多くのプロジェクトのためのビルド・スクリプトを生成することができ、適切なプラグインを使用してください。
規則および制限はありません、あなたはあなたの建物モデルを実現するためにカスタムタスクを追加し、元の契約を上書きすることができます。
拡張性
Gradleではあなたは、自分の使命を定義し、既存のタスクの種類を上書きしたり、独自のビルドモデルを定義するために追加することができ、優れた拡張性を備えています。Androidのは、風味を高め、良い例であるとbuildTypeは、元の基礎で合意されたプラグインをサポートしています。
IDEのサポート
いくつかの一般的な主流のIDEサポートインポートGradleのプロジェクト、そしてあなたは、そのようなので、上のAndroidスタジオ、Eclipseの、のIntelliJ IDEA、NetBeansととして、と対話することができます。Gradleではまた、プロジェクトファイルは、Visual Studioのソリューションにロードされます。
洞察
スキャンが実行して構築するための豊富な情報を提供してビルドするには、建物の問題を見つけるためにそれを使用することができます。それはあなたが建物のパフォーマンスの問題を見つけることができます。為替の問題は非常に便利であるときように、あなたはまた、他の人にそれを共有することができます。
スキャンのより詳細な構成は、この文書を表示することができますhttps://scans.gradle.com/?_ga=2.3508848.1142716506.1563790305-874993899.1553652374
Gradleの五の重要な概念
Gradleのはそれだけで大変な使いやすい柔軟かつ強力なツールです。いくつかの基本原則の後、次のGradleは、あなたがより良いのGradleを使用するのに役立ちます非常によく理解し、感じることが理解します。
Gradleでは、一般的な構築ツールであります
建物はGradleのは、何も想像構築するために行うか、どのようにする必要はありませんので、あなたは、ほとんどのGradleタスクのソフトウェアを構築することができますので。
最大の制限は、Mavenの依存関係の管理とlvyコンパイルされたライブラリやファイルをサポートしていることです。
この制限にもかかわらず、しかし、トラブルとの時間に、一般的なタイプのプロジェクトを容易に構築されていない-などのJavaコンパイラライブラリ、層の規則、および事前に構築された機能として、プラグインを追加することによって、あなたは規則や関数を所有することができますプラグインとしてパッケージ化され、もちろん、このプラグインをリリースします。
Gradleのは、コアタスクに基づいています
Gradleは、モデリングタスク（要素作業）を構築することが非環式グラフを対象とします。これは、実際にタスクのセットを構築するために、およびそれらの依存関係に応じて有向非巡回グラフを作成するように構成されたことを意味します。マップが作成されると、Gradleのはどのような順序で実行するタスクを決定し、それらを実行します。
図以下は、1がシンプルで、矢印で示した非常に詳細な、タスクの依存関係がある二つのタスクです。
几乎所有的构建过程都可以建模为任务图，这也是Gradle如此灵活的原因之一。任务图可以通过插件和你自己的脚本定义，关于任务依赖性 可以看 文档 https://docs.gradle.org/current/userguide/tutorial_using_tasks.html#sec:task_dependencies
任务由三部分构成
- 操作 ——做一些工作，例如复制文件或者编译源码
- 输入 ——值，行为能够操作的值，文件或者目录。
- 输出 ——行为修改或产生的值，文件或目录
实际上根据现实情况以上都是可选的，例如在Gradle 的生命周期里任务就有的什么也没做，只是将多个任务组合起来。
另外 Gradle 的增量编译是很强大可靠的，为了快速编译除非真的需要执行 clean 任务之外没必要执行clean操作。
你可以选择运行哪些任务。通过指定执行所需任务来节省时间，但也仅此而已。如果你想运行单元测试，就应该执行 test任务。如果您想打包应用程序，大多数构建都有相应的组装任务。
最后一件事:Gradle的增量构建支持是健壮和可靠的，所以除非您真的想执行一个clean任务，否则通过避免 clean 任务来保持构建的快速运行
Gradle有几个固定的构建阶段
理解Gradle在三个阶段评估和执行构建脚本是很重要的：
- 初始化
创建构建环境并确定哪些项目参与构建 - 配置
为构建构造和配置任务图，根据用户想要运行的任务确定以何种顺序执行哪些任务。 - 执行
运行配置阶段结束时选择的任务。
这些阶段就构成了 Gradle 的生命周期。
与Apache Maven术语的比较：
Gradle的构建阶段不像Maven的阶段。Maven的构建阶段将构建分为多个阶段。它们的作用类似于 Gradle 的任务图，尽管不那么灵活。
Maven的构建生命周期概念与Gradle的生命周期任务大致相似。
好的设计构建脚本主要由声明式配置而非命令逻辑组成。在配置阶段可以理解地评估该配置。即便如此，许多此类构建还具有任务操作 - 例如通过doLast {}和doFirst {}块 - 在执行阶段进行评估。这很重要，因为在配置阶段评估的代码不会看到在执行阶段发生的更改。
配置阶段另一个重要的方面是每次构建都会对其中涉及的所有内容做评估。这也是为什么应该在配置阶段避免多余的工作。构建扫描可以帮助你识别这样的事情。
Gradle 的扩展方式
如果Gradle 附带的构建逻辑无法满足我们的构建需求，而往往通常是这样。大部分的构建都有特定的需求，需要我们添加自己的构建逻辑。
Gradle 提供了以下几个主要方式去扩展它。
自定义任务类型
当 Gradle 本身的任务无法满足你的时候，你可以编写自己的任务类型。最好将编写的任务源文件放在 buildSrc 目录或者打包一个插件，然后你就可以像使用其他的Gradle 任务那样使用了。
参考 https://docs.gradle.org/current/userguide/custom_tasks.html自定义任务操作
你可以将自己的构建逻辑附加在任务的 开始之前 Task.doFirst() 和 结束之后 Task.doLast() 的方法里。
项目和任务的额外属性
Gradle 允许你为项目或者任务添加自己的属性，你可以在自定义行为或者其他构建逻辑中使用。额外的属性甚至可以应用于你没有显式创建的任务，比如由Gradle的核心插件创建的任务。
自定义约定
ユーザーがより簡単に理解し、その使用できるように、条約は、簡素化建設のための強力な方法です。これは、ビルド（例えばJavaのビルドなど）標準のプロジェクト構造と命名規則を使用することで見ることができます。
あなたは合意を提供するために、独自のプラグインを書くことができます-彼らは唯一のビルドの関連側面のデフォルト値を設定する必要があります。カスタムモデル
Gradleではでは、あなたが仕事に加えて導入することができ、ファイルや設定を超えて概念を依存関係します。あなたはこれを見ることができ、彼らはプラグインを構築するために、ほとんどの言語に設定されたソースの概念に追加されます。非常に使いやすさと施工の効率を向上させることができ、適切なモデリングプロセスを構築します。
スクリプトAPIの操作
ビルドスクリプトは、実際に実行可能なコードです。グッドスクリプトではなく、これらのステップがどのように動作するかをより、ソフトウェアを構築するために必要な手順を説明します。これは、カスタムタスクやプラグインを行う必要がありました。
それは本当に、スクリプトのコードではありませんので、よくある誤解は、そのGradleのは強力で柔軟性があります。これは、基礎となるモデルとAPIを提供する能力です。私たちは、あなたがスクリプトであまりにも多くの不可欠のロジックを置くべきではありません実際に示唆したように。APIにマッピングされた文法のGradleスクリプトを構築する方法を理解するために：しかし、一つの側面として見ビルドスクリプトの実行可能コードが便利です。GroovyのDSL APIのJavadoc組成およびメソッドとプロパティが参照する文書が表示され、参照や閉鎖操作されています。これは、ビルドスクリプトのコンテキストで何を意味するのか？ビューエントリスクリプトGroovyのは、ビルドするこの質問への答えを理解し、効果的にAPIドキュメントを使用することができるようにするために。https://docs.gradle.org/current/userguide/groovy_build_script_primer.html#groovy_build_script_primer
GradleのはJVM上で実行するため、スクリプトは、標準のJava APIを使用することができ、GroovyのスクリプトはGroovyのAPIを使用することができますので、KotlinスクリプトはKotlinのAPIを使用することができます。