1. 專案中Gradle檔案

對於一個gradle專案，最基礎的檔案配置如下：

一個專案有一個setting.gradle、一個頂層的 build.gradle檔案、以及每個Module中一個build.gradle檔案。

1.1 setting.gradle

檔案定義了哪些module應該被加入到編譯過程，對於單個module的專案可以不用需要這個檔案，但是對於multimodule的專案我們就需要這個檔案，否則gradle不知道要載入哪些專案。這個檔案的程式碼在初始化階段就會被執行。

1.2 頂層的build.gradle

頂層的build.gradle檔案的配置最終會被應用到所有專案中。它典型的配置如下：

• buildscript：定義了Android 編譯工具的類路徑。repositories中jCenter是一個著名的Maven倉庫。

• allprojects：定義的屬性會被應用到所有 moudle 中，但是為了保證每個專案的獨立性，我們一般不會在這裡面操作太多共有的東西。

1.3 每個模組單獨的build.gradle

針對每個moudle 的配置，如果這裡的定義的選項和頂層build.gradle定義的相同，後者會被覆蓋。典型配置如下：

• apply plugin：第一行程式碼應用了Android 程式的gradle外掛，作為Android 的應用程式，這一步是必須的，因為plugin中提供了Android 編譯、測試、打包等等的所有task。

• android：這是編譯檔案中最大的程式碼塊，關於android 的所有特殊配置都在這裡，這就是又我們前面的宣告的 plugin 提供的。

  defaultConfig：就是程式的預設配置
  注意，如果在AndroidMainfest.xml裡面定義了與這裡相同的屬性，會以這裡的為主。
  applicationId的選項：在AndroidManifest.xml中，那裡定義的包名有兩個用途：一個是作為程式的唯一識別ID，防止在同一手機裝兩個一樣的程式；另一個就是作為我們R資源類的包名。在以前我們修改這個ID會導致所有用引用R資源類的地方都要修改。但是現在我們如果修改applicationId只會修改當前程式的ID，而不會去修改原始碼中資原始檔的引用。

• buildTypes：定義了編譯型別，針對每個型別我們可以有不同的編譯配置，不同的編譯配置對應的有不同的編譯命令。預設的有debug、release 的型別。

• dependencies：是屬於gradle 的依賴配置。它定義了當前專案需要依賴的其他庫。

2. Gradle Wrapper

Gradle 不斷的在發展，新的版本難免會對以往的專案有一些向後相容性的問題，這個時候gradle wrapper就應運而生了。

gradlw wrapper包含一些指令碼檔案和針對不同系統下面的執行檔案。wrapper 有版本區分，但是並不需要你手動去下載，當你執行指令碼的時候，如果本地沒有會自動下載對應版本檔案。

在不同作業系統下面執行的指令碼不同，在 Mac 系統下執行./gradlew …，在windows 下執行gradle.bat進行編譯。

如果你是直接從eclipse 中的專案轉換過來的，程式並不會自動建立wrapper指令碼，我們需要手動建立。在命令列輸入以下命令即可：

gradle wrapper --gradle-version 2.4

它會建立如下目錄結構：

wrapper 就是我們使用命令列編譯的開始。下面我們看看 wrapper 有什麼樣的作用。

3. Gradle basics

Gradle 會根據build 檔案的配置生成不同的task，我們可以直接單獨執行每一個task。通過./gradlew tasks列出所有task。如果通過同時還想列出每個task 對應依賴的其他task，可以使用./gradlew tasks -all。

其實每當我們在Android Studio點選 build、rebuild、clean選單的時候，執行的就是一些gradle task。

3.1 Android tasks

有四個基本的 task, Android 繼承他們分別進行了自己的實現：

• assemble：對所有的buildType生成apk包。
• clean：移除所有的編譯輸出檔案，比如apk
• check:執行lint檢測編譯。
• build:同時執行assemble和check命令

這些都是基本的命令，在實際專案中會根據不同的配置，會對這些task設定不同的依賴。比如預設的 assmeble會依賴assembleDebug和assembleRelease，如果直接執行assmeble，最後會編譯debug和release的所有版本出來。如果我們只需要編譯debug版本，我們可以運assembleDebug。

除此之外還有一些常用的新增的其他命令，比如install命令，會將編譯後的apk安裝到連線的裝置。

我們執行的許多命令除了會輸出到命令列，還會在build資料夾下生產一份執行報告。比如check命令會生成lint-results.html.在build/outputs中。

4. BuildConfig

這個類相信大家都不會陌生，我們最常用的用法就是通過BuildConfig.DEBUG來判斷當前的版本是否是 debug版本，如果是就會輸出一些只有在debug環境下才會執行的操作。 這個類就是由gradle 根據 配置檔案生成的。為什麼gradle可以直接生成一個Java位元組碼類，這就得益於我們的gradle的編寫語言是Groovy，Groovy是一種 JVM 語言，JVM 語言的特徵就是：雖然編寫的語法不一樣，但是他們最終都會程式設計 JVM 位元組碼檔案。同是JVM 語言的還有Scala、Kotlin等等。

這個功能非常強大，我們可以通過在這裡設定一些key-value對，這些key-value 對在不同編譯型別的 apk 下的值不同，比如我們可以為debug 和release 兩種環境定義不同的伺服器。比如：

除此之外，我們還可以為不同的編譯型別的設定不同的資原始檔，比如：

5. Repositories

Repositories就是程式碼倉庫，我們平時的新增的一些dependency就是從這裡下載的，Gradle 支援三種類型的倉庫：Maven、Ivy和一些靜態檔案或者資料夾。在編譯的執行階段，gradle 將會從倉庫中取出對應需要的依賴檔案，當然，gradle 本地也會有自己的快取，不會每次都去取這些依賴。

gradle 支援多種Maven倉庫，一般我們就是用共有的jCenter就可以了。
有一些專案，可能是一些公司私有的倉庫中的，這時候我們需要手動加入倉庫連線：

如果倉庫有密碼，也可以同時傳入使用者名稱和密碼：

我們也可以使用相對路徑配置本地倉庫，我們可以通過配置專案中存在的靜態資料夾作為本地倉庫：

6. Dependencies

我們在引用庫的時候，每個庫名稱包含三個元素：

組名:庫名稱:版本號

如下：

如果我們要保證我們依賴的庫始終處於最新狀態，我們可以通過新增萬用字元的方式，比如：

但是我們一般不要這麼做，這樣做除了每次編譯都要去做網路請求檢視是否有新版本導致編譯過慢外，最大的弊病在於我們使用過的版本很很困難是測試版，效能得不到保證，所以，在我們引用庫的時候一定要指名依賴版本。

7. Local dependencies

• File dependencies
  通過files()方法可以新增檔案依賴，如果有很多jar檔案，我們也可以通過fileTree()方法新增一個資料夾，除此之外，我們還可以通過萬用字元的方式新增，如下：
  

• Native libraries
  配置本地 .so庫。在配置檔案中做如下配置，然後在對應位置建立資料夾，加入對應平臺的.so檔案。
  
  檔案結構如下：
  

• Library projects
  如果我們要寫一個library專案讓其他的專案引用，我們的bubild.gradle的plugin 就不能是andrid plugin了，需要引用如下plugin
apply plugin: 'com.android.library'
引用的時候在setting檔案中include即可。
  如果我們不方便直接引用專案，需要通過檔案的形式引用，我們也可以將專案打包成aar檔案，注意：這種情況下，我們在專案下面新建arrs資料夾，並在build.gradle 檔案中配置 倉庫：
  
  當需要引用裡面的某個專案時，通過如下方式引用：
  

8. Build Variants

在開發中我們可能會有這樣的需求：

• 我們需要在debug 和 release 兩種情況下配置不同的伺服器地址；
• 當打市場渠道包的時候，我們可能需要打免費版、收費版，或者內部版、外部版的程式。
• 渠道首發包通常需要要求在歡迎頁新增渠道的logo。等等
• 為了讓市場版和debug版同時存在與一個手機，我們需要編譯的時候自動給debug版本不一樣的包名。

這些需求都需要在編譯的時候動態根據當前的編譯型別輸出不同樣式的apk檔案。這時候就是我們的buildType大展身手的時候了。

8.1 Build Type

android 預設的帶有Debug和Release兩種編譯型別。比如我們現在有一個新的statging的編譯型別

8.2 Source sets

每當建立一個新的build type 的時候，gradle 預設都會建立一個新的source set。我們可以建立與main資料夾同級的資料夾，根據編譯型別的不同我們可以選擇對某些原始碼直接進行替換。

除了程式碼可以替換，我們的資原始檔也可以替換

除此之外，不同編譯型別的專案，我們的依賴都可以不同，比如，如果我需要在staging和debug兩個版本中使用不同的log框架，我們這樣配置：

9. Product flavors

前面我們都是針對同一份原始碼編譯同一個程式的不同型別，如果我們需要針對同一份原始碼編譯不同的程式（包名也不同），比如 免費版和收費版。我們就需要Product flavors。

注意：Product flavors和Build Type是不一樣的，而且他們的屬性也不一樣。所有的 product flavor 版本和defaultConfig 共享所有屬性！

像Build type 一樣，product flavor 也可以有自己的source set資料夾。除此之 外，product flavor 和 build type 可以結合，他們的資料夾裡面的檔案優先順序甚至高於單獨的built type 和product flavor 資料夾的優先順序。如果你想對於 blue型別的release 版本有不同的圖示，我們可以建立一個資料夾叫blueRelease。

注意：這個順序不能錯，一定是 flavor+buildType 的形式。

更復雜的情況下，我們可能需要多個product 的維度進行組合，比如我想要 color 和 price 兩個維度去構建程式。這時候我們就需要使用flavorDimensions：

根據我們的配置，再次檢視我們的task,發現多了這些task:

10. Resource merge priority

在Build Type中定義的資源優先順序最大，在Library 中定義的資源優先順序最低。

11. Signing configurations

如果我們打包市場版的時候，我們需要輸入我們的keystore資料。如果是debug 版本，系統預設會幫我們配置這些資訊。這些資訊在gradle 中都配置在signingConfigs中。

配置之後我們需要在build type中直接使用

12. Optimize

12.1 Speeding up multimodule builds

可以通過以下方式加快gradle 的編譯：

• 開啟並行編譯：在專案根目錄下面的 gradle.properties中設定
  org.gradle.parallel=true
• 開啟編譯守護程序：該程序在第一次啟動後回一直存在，當你進行二次編譯的時候，可以重用該程序。同樣是在gradle.properties中設定。
  org.gradle.daemon=true
• 加大可用編譯記憶體：
  org.gradle.jvmargs=-Xms256m -Xmx1024m

12.2Reducing apk file

在編譯的時候，我們可能會有很多資源並沒有用到，此時就可以通過shrinkResources來優化我們的資原始檔，除去那些不必要的資源。

如果我們需要檢視該命令幫我們減少了多少無用的資源，我們也可以通過執行shrinkReleaseResources命令來檢視log.

某些情況下，一些資源是需要通過動態載入的方式載入的，這時候我也需要像 Progard 一樣對我們的資源進行keep操作。方法就是在res/raw/下建立一個keep.xml檔案，通過如下方式 keep 資源：

12.3 Manual shrinking

對一些特殊的檔案或者資料夾，比如 國際化的資原始檔、螢幕適配資源，如果我們已經確定了某種型號，而不需要重新適配，我們可以直接去掉不可能會被適配的資源。這在為廠商適配機型定製app的時候是很用的。做法如下：
比如我們可能有非常多的國際化的資源，如果我們應用場景只用到了English,Danish,Dutch的資源，我們可以直接指定我們的resConfig:

對於尺寸檔案我們也可以這樣做