相信現在已經很少有公司android開發還用著Eclipse了吧，絕大部分都已經跟上潮流換上了Android Studio，AS預設使用Gradle作為專案構建工具。Gradle非常強大，可以方便我們做很多事情，例如：
（1）方便我們複用程式碼和資源
（2）方便我們使用相同的程式碼和資源構建出不同的應用
（3）方便我們配置專案構建流程，甚至是加入自定義邏輯
預設情況下build.gradle是這個樣子的：

apply plugin: 'com.android.application'

buildscript {
    repositories { 
        jcenter()
    }
 


    dependencies {
        classpath 'com.android.tools.build:gradle:1.3.1'
    }
}

android {
    compileSdkVersion 23
    buildToolsVersion "23.1.0"
}

apply plugin

apply plugin宣告外掛，其實可以理解為gradle構建的專案型別。android常用的有：

• com.android.application：表示構建android應用，即最終build輸出apk
• com.android.library：表示構建一個android庫，最終輸出aar格式檔案

當專案業務越來越多，越來越繁雜時後，為了提高開發效率，通常會對project按業務拆分，單獨業務拆分為一個子庫，或者底層通用框架和工具拆分為單獨的子庫，最終利用一個空專案作為殼，將其他子庫直接或者間接依賴進來打包成apk。這裡，殼的build.gradle就得宣告為’com.android.application’，而其他子庫均以aar形式依賴進來，也就是說其他子庫的build.gradle都是apply plugin: ‘com.android.library’。如果想要生成可安裝的apk檔案，必須得執行殼gradle的build task才行。

buildscript

buildscript中主要宣告gradle工具build時自身需要的配置，而不是程式碼編譯的配置，通常包括依賴倉庫repositories以及具體的依賴dependencies。repositories既可以是遠端倉庫，也可以配置本地的倉庫。

allprojects、subprojects

不同於buildscript，allprojects是對當前工程及其子工程進行配置，subproject是對當前工程所有子工程進行配置，通常配置專案依賴的所在倉庫，可以為多個。

dependencies

配置專案具體的依賴，可以是倉庫中的第三方庫也可以是本地android library原始碼，還可以是本地jar包等。例如：

dependencies {
    compile "com.android.support:recyclerview-v7:23.0.0"
    debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'
    releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'
    compile fileTree(dir: 'libs', include: '*.jar')
    compile project(':libraries:lib2')
}

另外，在配置dependencies時也可以根據build type、product flavor或者build variant對具體的build型別進行依賴配置。例如上面程式碼中的releaseCompile和debugCompile分別只對release和debug型別build有效。

android

顧名思義，android{}是用來配置android編譯階段引數的，其中compileSdkVersion和buildtoolsVersion是必須配置的，其他常用的還有以下配置：

• defaultConfig

應用的預設配置，包括應用的唯一標識，可安裝應用的系統最小版本以及目標（最佳）版本，應用版本號等資訊。

defaultConfig {
    applicationId 'com.sky.v1'
    minSdkVersion 15
    targetSdkVersion 23
    multiDexEnabled true  // 開啟multidex
    versionCode 985
    versionName 9.8.5
    buildConfigField "boolean", "IS_FREE", "true"  //自定義配置欄位
}

需要注意的是，applicationId會覆蓋manifest裡設定的packagename成為應用的唯一標識。另外，使用buildConfigField也可以自定義配置欄位，gradle build完成後會生成BuildConfig class，自定義欄位會被新增到其中。根據自定義配置欄位值，我們在程式碼中就可以作不同邏輯處理。BuildConfig預設提供了一些配置欄位，如下所示：

public final class BuildConfig {
  public static final boolean DEBUG = Boolean.parseBoolean("true");
  public static final String APPLICATION_ID = "com.sky.v1";
  public static final String BUILD_TYPE = "debug";
  public static final String FLAVOR = "";
  public static final int VERSION_CODE = -1;
  public static final String VERSION_NAME = "";

  public static final boolean IS_FREE = true;
}

• buildTypes

buildTypes宣告gradle build的型別。預設情況下，包含release和debug兩種配置，即可以build出應用的release版本和debug版本。針對release和debug版本，我們可以進行不同的配置，從而達到想要的效果。例如，proguard混淆，通常release版本才需要程式碼混淆，debug版本為了方便除錯關閉混淆。當然，我們也可以自定義build型別。

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
    }

    debug {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
    }
}

• productFlavors

和buildTypes有點類似，productFlavors也可以實現build出不同型別的apk。當專案需要打包不同版本（渠道）的apk，但是每個apk之間差別很小的時候，可以通過productFlavors來配置，gradle會對每一個配置的flavor分別打包，這樣就不需要我們手動修改程式碼或者資源重新build。例如，針對不同應用市場釋出android版本，可能使用不同的資源、sdk等，這時就可以使用productFlavors來解決問題。每個flavor可配置欄位和defaultConfig一致。

productFlavors {
    common {
    }
    qihoo {
    }
    yingyongbao {
    }
    meizu {
    }
}

Build Variant

gradle在build時是根據buildTypes和productFlavors的配置共同決定的，我們可以這麼理解：build variant ＝ (flavor, build type)。也就是說，按照上面的例子，總共有2*4，即8種build variant，commonRelease，commonDebug，qihooRelease等。理解build variant很重要，我們可以看到gradle tasks中有很多task名字都包含build variant。

Tasks

gradle所有的工作都是由一個個task組成的，根據上面的截圖可以看出主要包括assemble、check、build、clean等task。

• assemble 編譯並打包程式碼和資源輸出apk或者aar
• check 檢查測試程式碼，比如lint檢查，UT等。
• build 組合了check和assemble操作
• clean 清理之前的輸出以及生成的檔案，比如build目錄

gradle為不同的product flavor，build type以及build variant都建立了對應的一些task，例如assembleCommon、assembleRelease、assembleCommonRelease等。各個task之間存在依賴關係，例如assembleCommon依賴assembleCommonRelease和assembleCommonDebug等。