Gradle for Android應用

概述

我們都已經知道Gradle是基於JVM的一種構建工具。它是基於Groovy語言的聲明式構建，還支持java，C，C++等項目。我們在進行Android開發時，需要在Android Studio中對build.gradle文件進行配置。但是AS與Gradle並沒有直接的關係，這只是Google在AS中選擇了Gradle作爲項目的構建工具，爲了Gradle能在AS上應用，Google實現了AS上支持Gradle的插件，叫做Andorid Gradle Plugin。因爲AS應用了這個插件，所以能夠支持Gradle構建項目。我們可以在項目根目錄下的build.gradle文件中，看到：
classpath ‘com.android.tools.build:gradle:2.2.2’
這就是依賴gradle插件的代碼，後面的版本號代表的是android gradle plugin的版本，並不是Gradle的版本，與Gradle官方沒有關係。

Gradle 文件

一個項目中，會有一個setting.gradle，根目錄有build.gradle文件，每個Module都有自己的一個build.gradle文件。
setting.gradle：這個文件定義了哪些module應該被加入編譯過程，對於單個module的項目可以不用這個文件，但是對於multimodule的項目我們就需要這個文件，否則gradle不知道加載哪些項目，該文件的代碼在初始化階段就會被執行。
根目錄的build.gradle：根目錄的build.gradle文件配置最終會被應用到所有項目中。典型配置如下：

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

allprojects {
    repositories {
        jcenter()
    }
}

● buildscript ：定義了Android編譯工具的類路徑，repositories 中，jcenter是一個著名的Maven倉庫。
● allprojects：定義的屬性會被應用到所有moudle中，但是爲了保證每個項目的獨立性，我們一般不需要修改。
● 每個module中的build.gradle：針對每個moudle的配置。

下面針對module中build.gradle文件配置信息說明

apply plugin：聲明瞭項目的類型，這裏只Android。

android：設置編譯Andorid項目的參數，接下來，構建的android項目的所有配置都在這裏完成。
● defaultConfig：程序的默認配置，如果在AndroidMainfest.xml裏面定義了與這裏相同的屬性，會以這裏的爲主。
applicationId：我們曾經在AndroidMainfest.xml中，定義的包名有兩個用途：一個是作爲程序唯一識別的ID，防止在同一個手機裝兩個一樣的程序；另一個就是作爲R資源類的包名。以前修改這個包名，會導致所有引用R資源類的地方都要修改。但是現在我們修改applicationId屬性只會修改當前程序的ID，而不會修改源碼中資源的引用。
resConfig：針對app的本地化開發進行資源過濾，當工程依賴v7和Google服務時，非常有效。
resConfigs “zh”,”en” //定義包含的語言資源
resConfigs “mdpi”, “hdpi” //定義包含的尺寸資源

● lintOptions：配置lint檢查，一般設置：abortOnError false
● sourceSets：配置本地.so庫，如下：

    sourceSets {
        main {
            jniLibs.srcDirs = ['src/main/jniLibs']  //jniLibs 表示.so存放的目錄
        }
    }

● signingConfigs：配置簽名信息。
● buildTypes：定義了編譯類型，針對每個類型我們可以有不同的編譯配置，不同的配置對應有不同的編譯命令。默認有debug，release的類型。可以在不同類型中，設置各自的配置要求，如下。
applicationIdSuffix：與applicationId相關，給applicationId添加後綴，用來配置不同的程序 ID，使得在同一部設備中可以安裝多個相同的應用。

versionNameSuffix：與上同理，給versionName添加後綴，定義不同的版本名稱。獲得當 前渠道版本的的名稱，通過variant.getVersionName()。

buildConfigField：根據編譯版本的不同，動態的控制代碼的處理邏輯。設置後會在BuildConfig類中，動態生成對應的屬性值。如下：

buildTypes {
        debug {
            buildConfigField("String","UPDATE_URL","\"http://****/\"")
            ...
        }
        release {
            buildConfigField("String","UPDATE_URL","\"https://****/\"")
            ...
        }
        }

manifestPlaceholders：我們可以在AndroidManifest中定義一個變量，在build.gradle中動 態的替換掉。例如，動態替換友盟的appkey。
首先在AndroidManifest中定義一個變量：

<meta-data
                android:name="UMENG_APPKEY"
                android:value="${umeng_app_key}"/>

然後，在build.gradle文件中根據不同的環境，生成不同的appkey的apk。

buildTypes {
        debug {
         manifestPlaceholders = [umeng_app_key: "你替代的內容"]
        }
        release {
     　　manifestPlaceholders = [umeng_app_key: "你替代的內容"]
        }
        develop {
    　　 manifestPlaceholders = [umeng_app_key: "你替代的內容"]
        }
       }

替換多個變量的方法：
AndroidManifest中：

<meta-data
            android:name="UMENG_APPKEY"
            android:value="${umeng_app_key}"/>
<meta-data
            android:name="UMENG_SECRET"
            android:value="${umeng_app_secret}"/>

build.gradle文件中：

buildTypes {
        debug {
        manifestPlaceholders = [umeng_app_key: "XXX",umeng_app_secret:"XXX"]
        }
        ...
 }

● defaultPublishConfig： 通過它可以配置項目在構建時，編譯的版本類性，默認是“release”，當在module B 中build文件上配置defaultPublishConfig “debug”時，在發A的release版本時，b的版本仍爲debug版本，這點需要注意。
● publishNonDefault：相對於上面defaultPublishConfig，它可以根據編譯的版本類型來選擇編譯版本。如在module B中配置publishNonDefault true，表示b的版本根據module A的編譯類型來選擇打包版本。

dependencies：定義了項目的依賴庫，我們在引用庫的時候，每個庫名稱包含三個元素：組名:庫名稱:版本號，如下：

dependencies {
    compile 'com.android.support:appcompat-v7:23.4.0'
    compile 'com.jakewharton:butterknife:8.1.0'
}

還可以引用本地的jar包，如下：

dependencies {
    //單文件依賴
    compile files('libs/umeng-analytics-v6.0.1.jar')
    //某個文件夾下面全部依賴
    compile fileTree(include: ['*.jar'], dir: 'libs')
    //依賴某個項目
    compile project(path: ':pickerview')
    //依賴某個項目對應的版本
    releaseCompile project(path:':repository',configuration:'release')
    debugCompile project(path:':repository',configuration:'debug')
}

六種依賴類型：
Compile
compile是對所有的build type以及favlors都會參與編譯並且打包到最終的apk文件中。
Provided
Provided是對所有的build type 以及favlors只在編譯時使用，類似eclipse中的external-libs，只參與編譯，不打包到最終的apk。
APK
只會打包到apk文件中，而不參與編譯，所以不能在代碼中直接調用jar中的類或方法，否則在編譯時會報錯。
Test compile
Test compile 僅僅是針對單元測試代碼的編譯以及最終打包測試apk時有效，而對正常的debug或者release apk 包不起作用。
Debug compile
Debug complie 僅僅針對debug模式的編譯和最終的debug apk 打包
Release compile
Release compile 僅僅針對Release 模式的編譯和最終的Release apk打包。

Gradle Wrapper
Gradle不斷的在發展，新的版本難免會出現對以前的項目兼容性的問題，爲了避免安裝所有的版本gradle，於是推出了Gradle Wrapper。gradlw wrapper包含一些腳本文件和針對不同系統下面的運行文件。wrapper有版本區分，但是並不需要你手動下載，當你運行腳本的時候，如果本地沒有會自動下載對應版本文件。通過它每個項目你可以支持不同的Gradle版本來構建項目。我們可以在終端中測試版本好，首先切換到項目所在的目錄，然後輸入gradlew -v，就可以查看當前項目所用的gradle版本，如果是第一次執行該命令，會去下載對應的版本。
關於gradlew 的幾個命令：
● ./gradlew -v 版本號
● ./gradlew clean 清除所有的編譯輸出文件，比如apk。
● ./gradlew build 檢查依賴並編譯打包，這裏注意的是 ./gradlew build 命令把 debug、release 環境的包都打出來。
● ./gradlew assembleDebug 編譯並打Debug包
● ./gradlew assembleRelease 編譯並打Release的包
以上命令都是在終端裏執行，並且必須要切換到所在項目的根目錄下執行。

參考博客：http://www.flysnow.org/2015/03/30/manage-your-android-project-with-gradle.html