Gradle學習目錄總結

如果是你想干的事情，在別人看起來可能是很難的一件事，不過你自己很喜歡，你不會覺得很苦。我開始創業那會是28歲。對我來講，我創業的目的不是為了自己當老板，我希望有一個平台有一個環境，我可以控制一些資源，讓我去創造一個新的產品和服務； 
—— 周鴻禕

Gradle是一種依賴管理工具，基於Groovy語言，面向Java應用為主，它拋棄了基於XML的各種繁瑣配置，取而代之的是一種基於Groovy的領域特定（DSL）語言。

當然，我們現在最多都是在Android Studio的項目中，和我一樣沒有接觸過的就當看看我的學習筆記吧。

---

閱讀第一個gradle

隨便找到了一個Android Sdk中的一個Sample代碼，看了一下它的gradle腳本。如下所示：

apply plugin: 'com.android.application' android { compileSdkVersion 21 #build的sdk版本 buildToolsVersion "21.1.2" #build的工具版本 defaultConfig { #默認配置，versionname，versioncode等 applicationId "com.example.hello" minSdkVersion 15 targetSdkVersion 21 versionCode 1 versionName "1.0" } buildTypes { #編譯方式 release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } } dependencies { #第三方依賴庫 compile fileTree(include: ['*.jar'], dir: 'libs') compile 'com.android.support:appcompat-v7:21.0.3' }

我們從閱讀上看來是很簡單的，我們完全沒有學習過gradle也能夠看到它的腳本大概的意思。那么，我們該如何書寫此類腳本能？這類的腳本又能夠幫助我們做一些什么復雜的事情？

---

由於在網上也沒有找到一個比較全面的Android Gradle教程，所以，自己根據官方的入門文檔： 
http://tools.android.com/tech-docs/new-build-system/user-guide

翻譯文如下：

說明

簡單的構建文件，最簡單的 純Java項目的build.gradle如下所示：

apply plugin: 'java'

這里配置使用了Gradle內置的 Java 插件。該插件提供用於構建並測試 Java 應用程序所需要的東西。

最簡單的 Android 項目的 build.gradle 則是以下內容：

buildscript { repositories { mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:0.11.1' } } apply plugin: 'android' android { compileSdkVersion 19 buildToolsVersion "19.0.0" }

在這個 Android 構建文件中，有3個主要部分：

• buildscript： 配置了驅動構建的代碼。

• apply plugin： android插件，配置構建Android需要的東西。

• android：配置了用於 android 構建的所有參數。

Tips：你應該只配置使用這個android插件。如果同時配置使用了java插件也會導致構建錯誤。

---

工程結構

基本項目開始於兩個名為“source sets”的組件。即主源代碼和測試代碼。它們分別在：

• src/main/
• src/androidTest/

里面的每個文件夾中都存在對應的源代碼組件的文件夾。

對於 Java 和 Android 插件，Java 源代碼和 Java 資源的位置如下：

• java/
• resources/

對於Android 插件，Android所特有的額外的文件和文件夾是：

• AndroidManifest.xml
• res/
• assets/
• aidl/
• res/
• jni/

注： src/androidTest/AndroidManifest.xml是不需要的，因為它會被自動創建。

---

項目配置結構

當IDE環境沒有自動的生成構建的Gradle腳本，我們可以根據 Gradle 文檔，為一個Java 項目重新配置 sourceSets可以通過如下方法實現：

sourceSets { main { java { srcDir 'src/java' } resources { srcDir 'src/resources' } } }

注： srcDir實際上會將給定的文件夾添加到現有的源文件夾列表中 （這在Gradle 文檔中沒有提及，但這是實際的行為）。

如果要替換默認的源文件夾，您就要使用傳入一個路徑數組的srcDirs來代替。以下是使用涉及的對象的另一種不同的方法：

sourceSets { main.java.srcDirs = ['src/java'] main.resources.srcDirs = ['src/resources'] }

Android 插件使用類似的語法，但因為它使用它自己的sourceSets，所以在android對象里面來實現。

這里有一個例子，使用舊的項目結構的主源碼並重新映射androidTest sourceSet 到tests文件夾：

android {
    sourceSets { main { manifest.srcFile 'AndroidManifest.xml' java.srcDirs = ['src'] resources.srcDirs = ['src'] aidl.srcDirs = ['src'] renderscript.srcDirs = ['src'] res.srcDirs = ['res'] assets.srcDirs = ['assets'] } androidTest.setRoot('tests') } }

---

構建任務

常規任務

在構建文件中配置使用一個插件，將自動創建一系列要運行的構建任務。Java 插件和 Android 插件約定的任務如下：

• assemble ：組裝項目的輸出的任務
• check ：運行所有檢查的任務。
• build ：這個任務將執行assemble和check。
• clean ：這個任務將清理項目的輸出

assemble，check和build這些任務，實際上不做任何事情。他們是錨記任務，用於讓插件添加實際的任務去做這些事情。這允許您能夠調用同樣的任務，無論項目的類型是什么，或者是配置使用了什么插件。

例如，配置使用findbugs插件將創建一個新的任務和使check任務依賴於它，使得每當調用check任務時都會調用到它。

您可以從命令行中運行下面的命令來獲取更高級別的任務：

gradle tasks

下面的命令可以得到一個完整的任務列表，並且看到任務運行之間的依賴關系：

gradle tasks --all

Java項目任務

Java 插件主要創建兩個任務，它們是主要錨記任務的依賴任務：

• assemble 
  
  • jar 這個任務將創建輸出。
• check 
  
  • test 這個任務將運行測試。

jar任務本身會直接或間接地依賴其他任務： 例如，classes任務用於編譯 Java 代碼。

testClasses任務用於編譯測試，但它很少會被調用，因為test任務依賴於它 （以及classes任務）。

一般情況下，你將可能永遠只調用assemble或check，而無視其他任務。

Android 任務

Android 的插件使用相同的約定配置以兼容其他插件，並添加了另外的錨記任務：

• assemble ：組裝項目的輸出的任務
• check ：運行所有檢查的任務。
• connectedCheck： 運行需要一個已連接的設備或模擬器的檢查。它們將在所有已連接的設備上並行運行。
• deviceCheck： 使用 API連接到遠程設備運行檢查。這一個是在 CI 服務器上使用的。
• build ：這項任務將執行assemble 和 check
• clean ：這個任務將清理項目的輸出

新的錨記任務是有必要的，以便能夠運行定期的檢查而無需連接的設備。 
注意到，build任務不依賴於deviceCheck或connectedCheck。

Android 項目具有至少兩個輸出： debug版本的APK 和release版本的 APK。這里的每一個輸出都有自己的錨記任務，以便單獨構建它們：

• assemble 
  
  • assembleDebug
  • assembleRelease

它們兩個都依賴於執行構建一個 APK所需的多個步驟的其他任務。assemble任務取則依賴於這兩個任務，所以調用 assemble 將會構建出這兩個 APKs。

Tips：在命令行上，Gradle 支持任務名稱的駝峰命名法的簡寫。例如： gradle aR 相當於輸入 gradle 
assembleRelease 只要沒有其他任務匹配 “aR”

check錨記任務有它們自己的依賴項：

• check 
  
  • lint
• connectedCheck 
  
  • connectedAndroidTest
  • connectedUiAutomatorTest （暫未實現）
• deviceCheck

這個任務依賴於當其他插件實現了測試擴展點時創建的任務。 
最后，該插件為所有構建類型 （debug、release、test）創建了omstal/uninstall 任務，只要他們可以被安裝（需要簽名）。

---

Android基本的構建定制（這才是重點）

Android 插件提供了大量的 DSL，以通過構建系統直接地自定義大部分事情。通過 DSL 可以配置以下清單條目：

• minSdkVersion
• targetSdkVersion
• versionCode
• versionName
• applicationId 
  （有效的包名 —— 更多的信息請參閱ApplicationId packageName）
• PackageName 用於測試應用程序的包名
• Instrumentation test runner

示例：

android {
    compileSdkVersion 19 buildToolsVersion "19.0.0" defaultConfig { versionCode 12 versionName "2.0" minSdkVersion 16 targetSdkVersion 16 } }

在android元素的內部的defaultConfig元素是定義所有這些配置的地方。

以前版本的 Android 插件使用packageName來配置清單的“packageName”屬性。 從 0.11.0開始，你應該在 
build.gradle 中使用 applicationId 來配置清單中的“packageName”條目。 它消除了應用程序的包名（指它的 
ID）和java 包名之間的所引起的混亂。

在構建文件中描述它的強大之處是它可以是動態的。 
例如，可以從文件中的某處或使用一些自定義的邏輯讀取版本信息：

def computeVersionName() {
    ... } android { compileSdkVersion 19 buildToolsVersion "19.0.0" defaultConfig { versionCode 12 versionName computeVersionName() minSdkVersion 16 targetSdkVersion 16 } }

Tips： 不要使用在作用域內可能與已存在的getter函數有沖突的函數名稱。例如 defaultConfig { …} 實例調用 getVersionName() 時將自動使用 defaultConfig.getVersionName() 的 getter 方法，而不是自定義的方法。

如果一個屬性未通過 DSL 來設置，它將使用默認值。下表描述了對於未設置的屬性的處理方式。

屬性名稱	DSL 對象中的默認值	默認值
versionCode	-1	如果在清單中存在，則使用清單中的值
versionName	null	如果在清單中存在，則使用清單中的值
minSdkVersion	-1	如果在清單中存在，則使用清單中的值
targetSdkVersion	-1	如果在清單中存在，則使用清單中的值
applicationId	null	如果在清單中存在，則使用清單中的值
testApplicationId	null	applicationId + “.test”
testInstrumentationRunner	null
android.test.InstrumentationTestRunner
signingConfig	null	null
proguardFile	N/A (只設置)	N/A (只設置)
proguardFiles	N/A (只設置)	N/A (只設置)

第二列的值是很重要的，如果您在構建腳本中使用自定義邏輯查詢這些屬性的話。例如，您可以編寫：

if (android.defaultConfig.testInstrumentationRunner == null) { // assign a better default... }

如果值仍然為null，那么在構建的時候它將會被設為第三列中的實際默認值，但是由於 DSL 元素不包含此默認值，因此您無法查詢它。

這是為了防止解析應用程序的清單，除非真的很需要。

構建方式

默認情況下，Android 插件自動將項目設置為生成應用程序的的debug和release版本。 
這兩個版本的不同，大多是圍繞在調試一個安全的（非開發版的）設備的能力，以及 apk 怎么簽名。

調試版本使用自動創建的密鑰/證書簽名，並且密鑰/證書的用戶名/密碼是已知的（以防止構建過程中需要相關的信息）的。release版本在構建的時候不會進行簽名，需要在之后進行簽名。

這個配置是通過一個叫BuildType的對象來完成的。默認情況下，2 個實例會被創建，分別是debug版和release版。

Android 插件允許自定義這兩個實例，以及創建其他的構建類型。它通過buildTypes DSL 容器來實現：

android {
    buildTypes {
        debug { applicationIdSuffix ".debug" } jnidebug.initWith(buildTypes.debug) jnidebug { packageNameSuffix ".jnidebug" jniDebuggable true } } }

上面的代碼段可實現以下操作：

• 配置默認的Debug Build Type： 
  
  • 設置包名為.debug，以便能夠在相同的設備上安裝debug和release兩個版本的apk
• 創建一個叫jnidebug的新的BuildType對象 ，並將其配置為debug生成類型的一個副本。
• 通過啟用 JNI 組件的debug構建，並添加不同的包后綴，繼續配置jnidebug。

創建新的 Build Types 就是簡單地在buildTypes下添加一個新的元素，然后調用 initWith()或者是使用一個閉包來配置。

以下是可能用到的屬性和它們的默認值：

屬性名稱	debug的默認值	release/其他的默認值
debuggable	true	false
jniDebuggable	false	false
renderscriptDebuggable	false	false
renderscriptOptimLevel	3	3
applicationIdSuffix	null	null
versionNameSuffix	null	null
signingConfig	android.signingConfigs.debug	null
zipAlignEnabled	false	true
minifyEnabled	false	false
proguardFile	N/A (只設置)	N/A (只設置)
proguardFiles	N/A (只設置)	N/A (只設置)

除了這些屬性，Build Types還會影響到構建的代碼和資源。 
對每個Build Type都會創建一個自動匹配的sourceSet，默認位置為

src/<buildtypename>/

這意味着Build Type的名字不能為main或者是androidTest （這是插件所強制的），並且它們之間必須是唯一的。

與任何其他source set一樣，生成類型的source set的位置也是可以重新設置的：

android {
    sourceSets.jnidebug.setRoot('foo/jnidebug') }

此外，對於每個Build Type，會創建一個新的assemble任務。

已經提到過的assembleDebug和assembleRelease這兩個任務，這里也會講一下它們是怎么來的。當debug和releaseBuild Types被預創建的時候，他們的任務也會被自動創建。然后，

上面的build.gradle片段也會生成一個assembleJnidebug任務，並且assemble將會依賴於它，就像它依賴於assembleDebug和assembleRelease任務一樣。

Tips： 請記住您可以輸入gradle aJ來運行assembleJnidebug任務。

可能會用到的情況：

• release模式下不需要，但debug模式下需要的權限
• 自定義的debug實現
• 為debug模式使用不同的資源（例如某個資源的值與簽名證書相綁定時）。

BuildType的代碼和資源通過以下方式被使用：

• manifest將被合並到應用程序的manifest中
• 代碼只是作為另一個源文件夾來起作用
• 資源將覆蓋main里面的資源，並替換已經存在的值。

---

簽名配置

對應用程序進行簽名，要求如下：

• 一個 keystore
• 一個 keystore 的密碼
• 一個 key 的別名
• 一個 key 的密碼

存儲類型

簽名文件的位置，key的名稱，以及這兩個密碼和存儲類型，一起構成了一個簽名配置 （ SigningConfig類型）

默認情況下，有一個debug的配置，配置使用了一個debug keystore。這個keystore使用了一個已知的key和一個已知的密碼。

這個debug keystore 位於$HOME/.android/debug.keystore，並且會在不存在時被創建。debug Build Type被設置為自動使用此debug

簽名配置

你也可以創建其他配置，或者自定義某個默認的內置配置。通過signingConfigs DSL 容器來實現：

android {
    signingConfigs {
        debug {
            storeFile file("debug.keystore") } myConfig { storeFile file("other.keystore") storePassword "android" keyAlias "androiddebugkey" keyPassword "android" } } buildTypes { foo { debuggable true jniDebuggable true signingConfig signingConfigs.myConfig } } }

上面的代碼段把debug keystore的位置修改為在項目的根位置下。這會自動影響到任何設置為使用它的Build Types，在這里，影響到的是debug Build Type。

代碼的代碼還創建了一個新的Signing Config和使用新配置的新的Build Type 。

Tips：只有位於默認位置下的debug keystores才會被自動創建。如果debug 
keystore的位置被更改了，它將不會在需要時自動創建。創建一個使用一個不同的名稱SigningConfig，但使用了默認的debug

\

Tips： keystore的路徑通常使用項目根目錄的相對路徑，但也可以是使用絕對路徑，盡管這不推薦 （除了自動創建的debug keystore）。——–

---

運行ProGuard

ProGuard 是通過 Gradle plugin for ProGuard version 4.10來進行支持的。ProGuard 插件會被自動配置使用，並且如果Build Type通過minifyEnabled屬性配置為運行ProGuard，對應的任務將被自動創建。

android { buildTypes { release { minifyEnabled true proguardFile getDefaultProguardFile('proguard-android.txt') } } productFlavors { flavor1 { } flavor2 { proguardFile 'some-other-rules.txt' } } }

變種使用他們的構建類型中所聲明的規則文件，product flavors（定制版本）則使用flavor中聲明的規則文件。

這里有 2 個默認的規則文件

• proguard-android.txt
• proguard-android-optimize.txt

它們位於 SDK 中。使用getDefaultProguardFile()將返回的文件的完整路徑。它們除了是否啟用優化之外，其它都是相同的。

---

依賴、注入庫、多項目構建設置

Gradle 項目可以對其他組件具有依賴關系。這些組件可以是外部的二進制包，或其他的 Gradle 項目。

二進制包的依賴

本地包 
要配置一個外部庫 jar 包的依賴，您需要在compile配置中添加一個依賴關系。

dependencies {
    compile files('libs/foo.jar') } android { ... }

Tips：dependencies DSL 元素是標准的 Gradle API 的一部分，不屬於android 元素內。

compile配置用於編譯主應用程序。里面的所有內容都會被添加到編譯類路徑，並且打包到最終生成的 apk 當中。下面是添加依賴時其他可能用到的配置：

• compile: 主應用程序
• androidTestCompile: 測試的應用程序
• debugCompile: debug Build Type
• releaseCompile: release Build Type.

因為不可能構建一個沒有任何關聯的Build Type的 APK，apk 總是配置兩個（或以上）的配置：compile和Compile。 
創建一個新的Build Type會基於它的名字自動創建一個新的配置。

這可能會有用，比如debug版本需要使用一個自定義庫（例如報告崩潰的信息），而release版本則不需要，或者是他們依賴於同一個庫的不同版本的情況下。

遠程工程

Gradle 支持從 Maven 和 Ivy 倉庫中拉取文件。

首先，這個倉庫必須添加到列表當中，然后必須用Maven 或 Ivy 聲明文件的方式聲明這個

repositories {
    mavenCentral()
}


dependencies {
    compile 'com.google.guava:guava:11.0.2' } android { ... }

mavenCentral()是指定maven中央倉庫的URL的快捷方法。Gradle支持遠程和本地倉庫。

Tips：Gradle 將遵循所有依賴關系的傳遞性。這意味着，如果一個依賴有它自己的依賴關系，這些依賴也會被拉取。

有關設置依賴關系的更多信息，請參閱 Gradle 用戶指南（這里），和DSL文檔（這里）。

---

多工程設置

Gradle 項目也可以通過使用多項目設置依賴於其他的 Gradle 項目。

一個多項目設置通常是通過讓所有的項目作為給定根項目的子文件夾來實現。

例如，給定以下項目結構：

MyProject/
 + app/
 + libraries/
    + lib1/
    + lib2/

我們可以識別出3個項目。Gradle 將通過以下名稱引用它們：

:app
:libraries:lib1 :libraries:lib2

每一個項目都有其自己的build.gradle文件，定義自己如何構建。 
此外，在根路徑下還將有一個叫settings.gradle的文件用於聲明所有的項目。 
這些文件的結構如下：

MyProject/
 | settings.gradle + app/ | build.gradle + libraries/ + lib1/ | build.gradle + lib2/ | build.gradle

settings.gradle的內容很簡單：

include ':app', ':libraries:lib1', ':libraries:lib2'

它定義了哪個文件夾實際上是一個 Gradle 項目。

該:app項目可能依賴於libraries，這是通過聲明如下的依賴關系來配置的：

dependencies {
    compile project(':libraries:lib1') }

---

庫項目

在上面的多項目的設置中，:libraries:lib1和:libraries:lib2可以是Java項目，而:app Android項目將會使用到它們的jar包輸出。

但是，如果你想共享訪問了 Andr​​oid API或使用了 Android-style的資源的代碼，這些庫項目就不能是普通的Java項目，而應該是 Andr​​oid Library 項目。 
創建庫項目 
Library項目與普通的 Android 項目非常相似，只有一些不同。

由於構建庫項目與構建應用程序有些不同不同，所以使用的是不同的插件。這兩個插件內部共享了大部分的相同的代碼，並且它們都由同樣的com.android.tools.build.gradle jar 包提供。

buildscript { repositories { mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:0.5.6' } } apply plugin: 'android-library' android { compileSdkVersion 15 }

上面的例子中創建了一個使用API​​ 15編譯的庫項目。SourceSets和依賴關系與它們在應用程序項目中的處理方式一樣，並且支持同樣方式的自定義。

普通項目和Library 項目之間的區別

一個 Library 項目主要輸出的是一個.aar包（它代表Android的歸檔文件）。它組合了編譯代碼（如一個jar文件或原生的.so文件）和資源（manifest，res，assets）。 
一個庫項目還可以生成測試apk，獨立於應用程序測試這個庫。

庫項目用着同樣的錨任務（assembleDebug， assembleRelease），所以構建這樣一個項目的命令也沒有任何區別。

對於其他的內容，庫項目和應用程序項目的行為是一樣的。。他們都有構建類型（build types）和產品定制（product flavors），並且都可以生成多個版本的aar。 
需要注意的是，Build Type的大部分配置都不適用庫項目。但是，您可以根據一個庫項目是否被其他項目使用還是被測試，使用自定義 sourceSet 來更改庫項目的內容。

引用一個庫項目

引用一個庫庫和引用其他任何項目的方法是一樣的：

dependencies {
    compile project(':libraries:lib1') compile project(':libraries:lib2') }

Tips： 如果您有多個庫，那么排序將非常重要。這類似於舊的生成系統中， project.properties 文件的依賴項的順序的重要性。

---

庫項目發布

默認情況下，一個庫項目只發布它的release 變種程序。這變種程序將被所有引用該庫的項目使用，無論那些項目構建的是哪種variant。這是由於 Gradle 限制而有的一個臨時限制，我們正在努力消除這個問題。

您可以控制要發布哪一個如下所示：

android {
    defaultPublishConfig "debug" }

Tips，這個發布的配置名稱引用的是完整的 變種程序 
名稱。release和debug，只在沒有定義flavor時適用。如果你想在使用flavors時更改默認的發布

你可以這樣寫：

android {
    defaultPublishConfig "flavor1Debug" }

發布一個庫項目的所有變種程序也是可以做到的。我們正計划在正常的項目對項目（project-to-project）的依賴（如上面的例子）時也可以這樣做，但現在因為 Gradle 的限制（我們也在努力修復這些問題)，還無法做到。

默認情況下沒有啟用發布所有變種程序。要啟用它們

android {
    publishNonDefault true }

變種程序意味着發布多個aar文件，而不是發布一個包含多個變種程序的aar文件，能意識到這一點是非常重要的。每一個 aar 包都是包含一個單一的變種程序。

發布一個變種程序，意識着讓這個可用的 aar 作為 Gradle 項目的輸出文件。這個文件將會在發布到一個maven倉庫中，或者另一個項目創建對這個項目依賴時用到。

Gradle 有一個默認文件的概念。它就是在編寫下面的代碼時用到的：

compile project(':libraries:lib2')

若要創建對一個項目的另一個已發布的文件的依賴，您需要指定使用哪一個：

dependencies {
    flavor1Compile project(path: ':lib1', configuration: 'flavor1Release') flavor2Compile project(path: ':lib1', configuration: 'flavor2Release') }