1.エンジニアリング構造分析
1.目次だけから、私たちのプロジェクトは複数のモジュールモジュールを持つプロジェクトです。
2.各モジュールの構成の観点から、各モジュールにはbuild.gradleファイルが含まれています。これは、各モジュールがプロジェクトでもあることを意味します。build.gradleファイルは、プロジェクトを判断するためのキーとシンボルです。
3.コマンドgradlewprojectを使用して出力を表示します。出力結果は、ルートプロジェクト（ルートプロジェクト）に複数のプロジェクトが含まれ、ルートプロジェクトがサブプロジェクトの管理に使用されることです。各サブプロジェクトは最終出力に対応します（たとえば、各サブプロジェクトはaar、jarを出力します）。
2.プロジェクトAPIの構成
gradleライフサイクルAPI、プロジェクト関連API、ファイル関連API、タスク関連API、属性関連API、その他のAPI
1.プロジェクト関連のAPI
は、子プロジェクトで実行されるParentProjectを取得します。それがすでにルートプロジェクトである場合、取得された値は空です。
親プロジェクトでサブプロジェクトの共通パラメーターを
構成します。aarのパッケージ化やmavenウェアハウスへのアップロード機能など、すべてのサブプロジェクトを個別に構成できます
。2。関連する属性API。
ソースコードを表示して、ここで定義されているプロジェクトによって定義された属性を確認できます。属性は多くありません。ただし、属性を拡張することで属性をカスタマイズできます。
最初のメソッド：
メソッドアップグレードの定義：
呼び出しメソッドは次のようになります。
compileSdkVersion this.rootProject.compileSdkVersion
implementation this.rootProject.libAndroidDesign
//当然调用方法也可以与第一种方法当中相同，这是为什么呢？
//因为所有的子project都继承于根project，所以父project里面定义的属性，
//当然能够在子project当中直接调用了
compileSdkVersion this.compileSdkVersion
implementation this.libAndroidDesign
メソッドを定義してからアップグレードします。
バージョン情報を保存するための専用の別のgradleファイルを作成
し、ルートプロジェクトにファイルをインポートするだけで済みます。
apply from: this.file('commonVersion.gradle')
compileSdkVersion rootProject.ext.android.compileSdkVersion
buildToolsVersion rootProject.ext.android.buildToolsVersion
2番目の定義方法：
gradle.propertiesで定義します。名前によると、これはgradleのプロパティであることがわかります。ただし、これはkey = valueの形式のみを定義でき、クロージャの形式は定義できません。
著者：
Cangshuipu魔女クラウドブログ：http：//blog.csdn.NET/amir_zt/
よりオリジナル、ソースを示してください、ありがとう。
https://blog.csdn.net/amir_zt/article/details/113877122