Gradle For Android—從Gradle和Android Studio開始

Android Studio

Android Studio在2013年5月份被Google揭曉和發佈（作爲早期的訪問預覽），同時並肩支持Gradle。Android Studio是基於JetBrains公司的IntelliJ IDEA，但是是被專門設計用來做Android開發的。對於Linux、Mac OS X和Windows都是免費可得的。

較之Eclipse，AS具有更好的用戶交互設計，更好的內存監控，更好的字符串翻譯編輯器，Android特有的問題警告和大量針對Android開發者的特性。除了規則的項目視圖和包視圖之外，它也具有特殊的項目結構視圖。特殊的視圖對Gradle腳本、drawables和其他資源以一種簡便的方式進行了劃分。AS的穩定版本1.0一發布，Google就棄用了Android Developer Tools（ADT）並且提醒所有開發者切換到AS.這意味着Google不會再爲Eclipse提供任何新的特性，而且所有與IDE相關的工具開發都集中到了AS上。如果你還在使用Eclipse，是時候去改變了如果你不想落伍。

截圖展現了對於一個簡單的Android app AS看起來的樣子：

保持最新

AS有四種更新通道：
- 金絲雀提供最新技術更新，但是可能包含bug；
- Dev通道每月或多或少更新；
- Beta是使用功能完整的更新，但仍可能包含bug；
- 穩定通道，系統默認，功能屬性全部都測試過，應該不包含bug；

默認情況下，AS每次啓動都會檢測更新，如果有更新的話，會通知你。

當你第一次啓動AS,它會啓動一個嚮導程序安裝環境並確保你有最新的Android SDK和必要的Google倉庫。也會讓你選擇創建AVD(Android Virtual Device)，所以你可以在模擬器上運行app。

理解Gradle基礎

爲了Android項目能使用Gradle構建，你需要安裝build腳本。約定成俗，腳本總是叫做build.gradle。你會注意到，當我們學習基礎的時候，Gradle支持“慣例優先原則”並且一般會爲設置和屬性提供默認值。這使得它更易啓動而沒有Ant或Maven的過多配置，後者已經成爲Android項目的實際構建工具很長時間了。你不需要完全遵守這些約定，因爲如果需要的話，可能會重寫他們。

Gradle build腳本不是使用傳統的xml編寫，而是使用基於Groovy的領域專用語言（DSL:Domain Specific Language）所寫。Groovy是針對JVM(Java Virtual Machine)的動態語言。Gradle身後的團隊相信使用基於動態語言的聲明式的、DSL式的方式要比使用更程序化的、Ant靈活格式的，或許多其他構建系統使用的基於xml的方式有更大的好處。

這並不意味着你需要先了解Groovy才能開始構建腳本的學習，它很容易約定，而且如果你學過java的話，學習不會如你所想困難。如果你想要創建你自己的tasks和plugin（我們會在接下來的章節中討論），對Groovy深入的瞭解也會帶來很大便利。然而，因爲Groovy是基於JVM的，你的自定義plugins可能會以java或其他基於JVM的語言編寫代碼。

projects和tasks

在Gradle中兩個最重要的概念就是projects和tasks。每一個build至少包含一個project，每一個project包含一個或多個tasks。每一個build.gradle文件代表着一個project。tasks是在build腳本內部被簡單地定義。當初始化build進程的時候，Gradle基於build文件集合project和task對象。一個task對象包含一系列需按序執行的action對象。一個action對象是一個被執行的代碼快，類似於java中的方法。

build生命週期

執行一個Gradle build就是以其最簡單的形式，僅僅執行依賴於其他task的task中的action。爲了簡化build過程，build工具創建了一個動態的流程模型叫做有向非循環圖（Directed Acyclic Graph：DAG）.這意味着所有的task都會被依次執行而不會陷入循環。task一旦被執行，就不會重複調用。沒有依賴的task總是會先於其他task執行。依賴圖是在build的配置階段生成的。一個Gradle build有三個階段：

-初始化：此階段project實例被創建。如果有多個module，每一個都會有build.gradle產生，多project將會被創建；
-配置：在此階段，build腳本會被執行，爲每一個project對象創建和配置所有的task；
-執行：這是gradle決定哪個task應該被執行的階段。哪個task應該被執行依賴於傳進來的用於啓動build的參數和當前的目錄。

build配置文件

爲了使得gradle構建一個project，總需要一個build.gradle文件。對Android來說，一個build文件有以下幾個元素：

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:1.2.3'
    }
}

這裏也是build實際被配置的地方。在repositories 模塊中，JCenter庫是被配製成build腳本的dependencies的源。JCenter是一個預配置的Maven庫並且不需要額外安裝；Gradle已經完成了。有好幾種庫都是可從gradle直接可得並且很容易添加到你自己的本地或遠程中。

build腳本塊也定義了一個基於Android構建工具的依賴(dependencies)爲作爲類路徑Maven工件。這也是Android plugin的來源。Android plusin提供構建和測試應用的所有東西。每一個Android project都需要使用這行代碼應用Android plugin：

apply plugin: 'com.android.application'

plugin是被用作擴展gradle構建腳本的能力的。應用plugin項目上使得build腳本定義屬性和使用被定義在plugin中的task成爲可能。

如果你在build一個library，你需要應用‘com.android.library’替代。不能在同一module中同時使用‘com.android.library’和‘com.android.application’，因爲這樣會導致build錯誤。一個module也不能同時既是Android application又是Android library

當使用Android plugin，Android特定慣例會被配置而且僅僅適用於Android的task會被生成。下面碎片中的Android塊是被plugin定義而且可以被配置到每一個project中：

android {
compileSdkVersion 22
buildToolsVersion "22.0.1"
}

這就是build中Android特有部分被配置的地方。Android plugin提供DSL定製的Android需求。唯一要求的屬性是compilation target和build tool。compilation target，被compileSdkVersion指定，是將要編譯app的SDK版本，使用最新的Android API版本作爲compilation target是很好的體驗。

在build.gradle文件中有很多自定義的屬性。我們將會在第二章討論最重要的屬性。

創建新項目

較之老的 Eclipse項目(Studio）新的Android項目文件結構也發生了很大改變。正如之前提到的，Graldle支持“慣例先於配置”並且這也應用到了新的文件結構上。

對一個簡單的app來說，gradle期待的文件目錄結構如下：

MyApp
├── build.gradle
├── settings.gradle
└── app
      ├── build.gradle
      ├── build
      ├── libs
      └── src
              └── main
                      ├── java
                      │     └── com.package.myapp
                      └── res
                            ├── drawable
                            ├── layout
                            └── etc.

Gradle項目通常實際上都有一個額外層。這使得更容易在最後的位置添加新的module。app所有的源碼都被封裝到app文件夾。這個目錄名默認也是module的名稱而且不需要命名。如果你使用AS創建一個包含一個手機app和一個Android 穿戴手錶app的project，這個module會被默認叫做application和wearable。

gradle利用一個被稱作source set的概念。官方gradle文檔介紹一個source set就是一組一起被編譯和執行的資源文件。對於一個Android project來說，對於默認的app版本，main就是保護了所有資源代碼和資源的source set。當你開始爲Android app寫測試時，你將會把測試用的源碼放到一個獨立的被稱之爲androidTest的source set，它僅僅包含測試

Directory	Content
/src/main/java	The source code for the app
/src/mian/res	These are app-related resources(drawables,layouts,strings and so on)
/libs	These are external libraries(.jar or .aar)
/build	The out put of the build process

Gradle包裝器

gradle是一個處於不斷發展中的工具，而且新版本具有向後兼容的能力。使用gradle wrapper是避免問題和確認build是可再生的一種好的方式。

gradle wrapper爲windows提供一批文件、爲其他操作系統提供一個shell腳本。當你運行腳本，需要的gradle版本就會被下載並自動運用到構建當中。這背後的思想就是每一個需要構建app的開發者或自動化系統都能僅僅運行wrapper，然後剩下的工具有wrapper完成。按照這種方式，並不需要在開發者機器或構建服務手動安裝正確的gradle版本。因此，也建議把wrapper文件添加到你的版本控制系統中（Version Control System:VCS）

運行gradler wrapper與直接運行gradle並無不同。只需要運行在Linux和Mac OS X運行‘gradlew’，在windows上運行gradlew.bat，代替規範的gradlw命令。

獲取Gradle包裝器

爲了你的方便，每一個新創建的Android項目都包含了gradle wrapper，所以當你創建一個新項目時，無需做任何事情便能獲取必要的文件。當然，手動安裝gradle到你的電腦上並使用到你的項目上也是可能的，但是gradle wrapper可以做相同的事並且可以保證正確使用正確的gradle版本。沒有理由不使用wrapper當在AS外使用gradle的時候。

你也能通過導向到項目文件下並在終端運行./gradlew -v或在命令提示符中運行gradlew.bat -v檢查gradle wrapper是否在你的項目中。運行該命令展示了gradlew版本和安裝的其他信息。如果你是轉換一個eclipse項目，wrapper默認不會出現在項目中。這種情況下，可以使用gradlew生成，但是你首先需要安裝gradle獲得wrapper。

下載、安裝gradle並添加到PATH後，創建一個包含這三行的build.gradle文件：

task wrapper(type: Wrapper) {
gradleVersion = '2.4'
}

然後運行gradle wrapper生成wrapper文件。

在最近的gradle版本中，也可不用修改build.gradle文件直接運行wrapper task，因爲它是默認被添作爲一個task。這種情況下，你可以使用–gradle-version參數指定版本，像這樣：

$ gradle wrapper --gradle-version 2.4

如果你不指定一個版本號，wrapper會被使用執行task的gradle版本配置。

這是被wrapper task生成的所有文件：

myapp/
├── gradlew
├── gradlew.bat
└── gradle/wrapper/
        ├── gradle-wrapper.jar
        └── gradle-wrapper.properties

你會看到gradle wrapper包含三個部分：

-一個運行在windows上的批處理文件和一個運行在Linux和Mac OS X的shell 腳本；
-被批處理文件和shell腳本使用的jar文件；
-一個屬性文件

gradle-wrapper.properties文件包含了配置並決定gradle使用的版本：

#Sat May 30 17:41:49 CEST 2015
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
Getting Started with Gradle and Android Studio
[ 12 ]
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/
gradle-2.4-all.zip

如果你想使用一個自定義的gradle distribution，可以改變distribution Url。這也意味着你使用的任何app或library都可以有一個不同的gradle URL，所以確定檢測你是否可以信任這些屬性在運行wrapper之前。

當被使用的gradle版本不是最新的，AS會友好的展現一個通知並建議自動爲你更新。基本上，AS改變gradle-wrapper.properties文件中的配置並觸發一個build，以便可以下載最新版本。

AS使用properties中的信息決定使用哪個版本的gradle，並在項目裏從gradle wrapper運行wrapper。然而，並沒有利用shell或bash腳本，所以你不應該自定義這些。

運行基礎build tasks

在終端或命令提示符中，導向到項目路徑並使用tasks命令運行gradle wrapper：

$ gradlew tasks

將會打印一列所有可得的task，如果添加–all參數，將會獲得更詳細每一個task的依賴的概述

在windows中，你需要運行gradlew.bat，在Linux和Mac OS X上，完整的命令是./gradlew。爲了簡潔，本書中我們僅會書寫gradlew

當你開發的時候爲了構建項目，運行聚合的task使用debug配置：

$ gradlew assembleDebug

這個task將會使用app的debug版本創建一個APK文件。默認下，gradle的Android plugin保存apk文件在MyApp/app/build/outputs/apk目錄下。

縮寫task名稱
爲了避免終端的大量輸入，gradle也提供縮寫駝峯式命名task。例如，你可以在命令行接口中執行assembleDebug通過運行gradlew assDeb或gradlew aD。但是這也有個條件，只有當駝峯式書寫是唯一的時候纔會奏效。一旦其他task有相同的縮寫，這個技巧對這些task就不會再奏效。

除了assemble之外，這裏還有三個基本的task：

-check：運行所有的檢查，通常意味着在已連接的色設備或模擬器上運行測試；
-build：觸發assemble和check；
-clean：清除project的輸出

我們將會在第二章討論這些task

章節總結

我們通過着眼於gradle的優點以及爲什麼它現在比其他構建系統更多地被使用開啓了這一章節。我們簡略地瞭解AS以及它如何幫助我們生成build文件。

介紹之後，我們又瞭解了Gradle Wrapper，其使得維護和分享project更容易。我們在AS中創建了創建一個新的project，而且你現在也知道了如何手動和自動地把eclipse項目移植到AS和gradle中。你也能夠在AS中使用gradle或直接的使用命令行接口build項目。

在接下來的幾章裏，我們將會瞭解到自定義build，所以你可以更深入地自動化build進程和更容易地維護。我們將會通過檢測所有標準的gradle文件，探索基礎的build task，並自定義build部分開啓接下來的章節。

歡迎轉載，轉載請註明！