Gradle for Android學習筆記（一）

每一個build.gradle文件代表一個project，一個project會有多個tasks

如Android工程：包含Android tasks,build tasks,build setup tasks,help tasks,install tasks,other tasks.

---

gradlew命令

gradlew -help—->查看命令

gradlew tasks—->查看root project有多少個task

gradlew tasks –all—->查看詳細的tasks

gradlew -v/gradlew.bat -v—->查看Gradle版本及其他信息

gradlew assembleDebug—->創建一個debug版本的app，在app/build/outputs/apk目錄下,也可以執行簡稱：gradlew assDeb或gradlew aD

gradlew :app:assembleDebug—->指定module名稱執行assemble任務創建debug版本apk文件。

---

Android Tasks簡述

Base tasks:定義了tasks，但沒有實現

assemble clean check build

Android tasks：實現了base tasks的行為
- assemble：對每一個build type創建一個apk

assemble tasks默認依賴assembleDebug和assembleRelease

clean：移除所有的編譯產生的文件 check：執行Lint檢查，如果Lint檢測到問題，可以中斷編譯 build：在assemble和check都運行

---

Project中build.gradle文件，對多個Module統一管理

如果你的工程有多個Android項目，可以把共同的設置寫在allprojects中，如

allprojects{
    apply plugin:'com.android.application'

    android{
        compileSdkVersion 24
        buildToolsVersion "24.0.0"
    }
}

這樣要求你的module都是Android app，當然有更好的一個寫法,可以在project中的build文件中定義一個ext{}，如：

ext{
    compileSdkVersion = 24
    buildToolsVersion = "24.0.0"
}

在Module中的build文件中的android{}中使用，如：

android{
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion

}

---

自定義task

在build.gradle中自定義tasks任務,如:

ext{
    local="hello local"
}

task print<<{
    println local
    println ok  //task可以執行gradle.properties文件中的配置
}

在gradle.properties文件中

ok='hello property'

---

Native Library：

android默認支持native library，當然你需要 在Module中創建一個jniLib目錄，如：

android{
    ...

    sourceSets.main{
        jniLibs.srcDir 'src/main/libs'
    }
}

使用.aar文件

repositories{
    flatDir{
        dirs 'aars'
    }
}

dependencies{
    compile(name:'libraryname',ext:'aar')
}

Dependency的概念：

compile：默認，大多數應用都全部依賴於它 apk：僅僅添加包，不參與編譯。僅僅作為Jar依賴，添加代lib庫中可能導致error provided：這個依賴不會被打包。僅僅作為Jar依賴，添加代lib庫中可能導致error testCompile:添加測試的依賴 androidTestCompile:添加測試的依賴。 debugCompile：debug版本的依賴。 releaseProvided：release版本不打包。

---

自定義buildTypes{}

在module項目中會自動生成一個release版本的build type，同時也有一個默認的debug版本（只不過隱藏了，可以對它的屬性值進行重寫，當然也可以自定義，如：

android{
    ...
    buildTypes{

        release{
            ...
        }

        debug{
            ...
        }

        my.initWith(buildTypes.debug)   //復制debug的所有屬性
        my{
            applicationIdSuffix ".my"   //applicationId的變體
            versionNameSuffix "-my"
            buildConfigFiled "boolean" "LOG_DEBUG" "true"
            ...
        }
    }
}

my.initWith(buildTypes.debug) —-表示my類型復制debug所有屬性

applicationIdSuffix “.my” —-表示應用id後面接上一個.my,如：

debug類型的applicationId:com.example

my類型的applicationId:com.example.my

應為applicationId不同，所以可以在同一個設備同時安裝這2個apk。一般用於區分free版，price版。

buildConfigFiled—-設置編譯配置

buildConfigFiled "boolean" "LOG_DEBUG" "true"
意思是：給這個類型設置設置一個boolean類型的變量LOG_DEBUG，默認為true。

同樣還可以這樣設置：
buildConfigField "String", "API_URL", "http://staging.example.com/api" 
意思是：配置文件從網絡請求。

在項目中的使用：

if(BuildConfig.LOG_DEBUG){
    log.e("","")
}

封裝成一個工具類，可以根據debug版本和release版本的不同進行log的統一開閉管理。

---

SourceSets

當你創建一個名稱為staging的build類型時，你需要使用自定義的source code和resource時，需要手動創建一個名稱和build type名稱相同的目錄。如圖：

我們在staging目錄下可以創建自己的resource，可以覆蓋和main目錄中的resource。

如：

你的main中string.xml文件中

    Application
    hello
    ...

你的staging目錄中string.xml文件

    Application Staging

那麼在合並的時候，string.xml是這樣的

    Application Staging
    hello
    ...

如果你的staging目錄沒有，或沒有資源時，直接使用的main中的。

---

Multiflavtor variants(多渠道打包)

比如我們的app需要打包到多個應用市場，如xiaomi，360等。

android{
    productFlavors{
        xiaomi{
            applicationId "com.example.application"
            ...
        }

        360{
            applicationId "com.example.application"
            ...
        }
    }
}

這樣打包的時候就可以打出2個應用市場的release-apk。

如果現在需求變更，需要一個free版本，一個price版本，如何打包呢？

我們可以這樣打包，如下:

android{
    ...

    flavorDimensions 'price','store'
    productFlavors{
        xiaomi{
            flavorDimension "store"
        }

        360{
            flavorDimension "store"
        }

        free{
            flavorDimension "price"
        }

        price{
            flavorDimension "price"
        }
    }
}

flavorDimensions—-是一個數組，store和price代表的2個維度，每個flavor分配到指定的維度中。

上面的例子中將 Product Flavor 分為兩組（即兩個維度），分別為price維度 [free, paid]和store維度[xiaomi,360] ，再加上默認的 BuildType 有 [debug, release] ，這將會組合生成以下的 Build Variant：

xiaomi-free-debug和xiaomi-free-release 360-free-debug和360-free-release xiaomi-price-debug和xiaomi-price-release 360-price-debug和360-price-release

---

Variant filters(過濾變體)

這段代碼可放在android{…}中，也可以放在android{}外。

android.variantFilter { variant ->
        if (!variant.buildType.name.equals('debug')) {
            variant.getFlavors().each() {
                flavor ->
                    if (!flavor.name.equals('xiaomi')) {
                        variant.setIgnore(true);
                    }
            }
        }
    }

代碼用來過濾一些Variant。結果可以查看這裡

---

Signing configurations(簽名配置)

默認情況下大概是這樣：一般只需要設置一個release的就好。

android{
    signingConfigs{
        release{
            storeFile file("release.keystore")
            storePassword "storepassword"
            keyAilas "keyAlias"
            keyPassword "keyPassword"
        }
    }
}

在buildTypes{}中使用

android{
    buildTypes{
        release{
            signingConfig  signingConfig.release
        }
    }
}

這樣release版本的在打包的時候，就會帶上簽名文件。

如果所有的都需要帶上簽名文件，可以在defaultConfigs{}中使用：

defaultConfigs{
    signingConfig  signingConfig.release
}

如果針對某個store平台加上簽名文件。可以：

android{
    productFlavors{
        xiaomi{//以小米為例
            signingConfig  signingConfig.release
        }
    }
}

如果我們需要對每一個平台使用不同的簽名打包，我們可以：

android{
    signingConfigs{
        release{
            ...//簽名配置，參考上面
        }

        xiaomi{
            ...
        }

        baidu{
            ...
        }
    }
}

對release版本打包簽名處理：

android{
    buildTypes{
        release{
            productFlavors.xiaomi.signingConfig signConfigs.xiaomi  //針對小米release版本進行簽名處理（使用小米特用的簽名文件）

             productFlavors.baidu.signingConfig signConfigs.baidu   //針對百度elease版本進行簽名處理（使用百度特用的簽名文件）
        }
    }
}