摘要：如果你有新建一個項目的經歷，那么你將看到推薦的方案在的中使用來定義版本號全局變量。例如之前的版本號就可以使用如下方式實現因為使用的是語言，所以以上都是語法例如版本控制，上面代碼的意思就是將有個相關的版本依賴放到的變量中，同時放到了中。

上篇文章我們已經將Gradle基礎運用介紹了一遍，可以這么說，只要你一直看了我這個Gradle系列，那么你的Gradle也將過關了，應對正常的工作開發已經不成問題了。

這篇文章我要向你介紹的是關于如何使用Gradle來更加優雅的管理多個module之間的依賴關系。

相信你一定有這樣的經歷：主項目依賴于多個子項目，或者項目間互相依賴。不同子項目間的依賴的第三方庫版本又沒有進行統一，升級一個版本所有依賴的項目都要進行修改；甚至minSdkVersion與targetSdkVersion也不相同。

今天我們就來解決這個問題，讓Gradle版本管理更加優雅。

之前的文章Android Gradle系列-運用篇中的dependencies使用的是最基本的引用方式。如果你有新建一個kotlin項目的經歷，那么你將看到Google推薦的方案

buildscript {
    ext.kotlin_version = "1.1.51"
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath "com.android.tools.build:gradle:3.0.0"
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

在rootProject的build.gradle中使用ext來定義版本號全局變量。這樣我們就可以在module的build.gradle中直接引用這些定義的變量。引用方式如下：

dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation"org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
}

你可以將這些變量理解為java的靜態變量。通過這種方式能夠達到不同module中的配置統一，但局限性是，一但配置項過多，所有的配置都將寫到rootProject項目的build.gradle中，導致build.gradle臃腫。這不符合我們的所提倡的模塊開發，所以應該想辦法將ext的配置多帶帶分離出來。

這個時候我就要用到之前的文章Android Gradle系列-原理篇中所介紹的apply函數。之前的文章我們只使用了apply三種情況之一的plugin(應用一個插件，通過id或者class名)，只使用在子項目的build.gradle中。

apply plugin: "com.android.application"

這次我們需要使用它的from，它主要是的作用是應用一個腳本文件。作用接下來我們需要做的是將ext配置多帶帶放到一個gradle腳本文件中。

首先我們在rootProject目錄下創建一個gradle腳本文件，我這里取名為version.gradle。

然后我們在version.gradle文件中使用ext來定義變量。例如之前的kotlin版本號就可以使用如下方式實現

ext.deps = [:]
 
def versions = [:]
versions.support = "26.1.0"
versions.kotlin = "1.2.51"
versions.gradle = "3.2.1"
 
def support = [:]
support.app_compat = "com.android.support:appcompat-v7:$versions.support"
support.recyclerview = "com.android.support:recyclerview-v7:$versions.support"
deps.support = support
 
def kotlin = [:]
kotlin.kotlin_stdlib = "org.jetbrains.kotlin:kotlin-stdlib-jre7:$versions.kotlin"
kotlin.plugin = "org.jetbrains.kotlin:kotlin-gradle-plugin:$versions.kotlin"
deps.kotlin = kotlin
 
deps.gradle_plugin = "com.android.tools.build:gradle:$versions.gradle"
 
ext.deps = deps
 
def build_versions = [:]
build_versions.target_sdk = 26
build_versions.min_sdk = 16
build_versions.build_tools = "28.0.3"
ext.build_versions = build_versions
 
def addRepos(RepositoryHandler handler) {
    handler.google()
    handler.jcenter()
    handler.maven { url "https://oss.sonatype.org/content/repositories/snapshots" }
}
ext.addRepos = this.&addRepos

因為gradle使用的是groovy語言，所以以上都是groovy語法

例如kotlin版本控制，上面代碼的意思就是將有個kotlin相關的版本依賴放到deps的kotlin變量中，同時deps放到了ext中。其它的亦是如此。

既然定義好了，現在我們開始引入到項目中，為了讓所有的子項目都能夠訪問到，我們使用apply from將其引入到rootProject的build.gradle中

buildscript {
    apply from: "versions.gradle"
    addRepos(repositories)
    dependencies {
        classpath deps.gradle_plugin
        classpath deps.kotlin.plugin
    }
}

這時build.gradle中就默認有了ext所聲明的變量，使用方式就如dependencies中的引用一樣。

我們再看上面的addRepos方法，在關于Gradle原理的文章中已經分析了repositories會通過RepositoryHandler來執行，所以這里我們直接定義一個方法來統一調用RepositoryHandler。這樣我們在build.gradle中就無需使用如下方式，直接調用addRepos方法即可

    //之前調用
    repositories {
        google()
        jcenter()
    }
    //現在調用
    addRepos(repositories)

另一方面，如果有多個module，例如有module1，現在就可以直接在module1中的build.gradle中使用定義好的配置

dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    // support
    implementation deps.support.app_compat
    //kotlin
    implementation deps.kotlin.kotlin_stdlib
}

上面我們還定義了sdk與tools版本，所以也可以一起統一使用，效果如下

android {
    compileSdkVersion build_versions.target_sdk
    buildToolsVersion build_versions.build_tools
    defaultConfig {
        applicationId "com.idisfkj.androidapianalysis"
        minSdkVersion build_versions.min_sdk
        targetSdkVersion build_versions.target_sdk
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    ...
}

一旦實現了統一配置，那么之后我們要修改相關的版本就只需在我們定義的version.gradle中修改即可。無需再對所用的module進行逐一修改與統一配置。

如果你的項目使用了kotlin，那么buildSrc&Kotlin的統一管理方案將更適合你。

Gradle項目會默認識別buildSrc目錄，并且會將該目錄中的配置注入到build.gradle中，以至于讓build.gradle能夠直接引用buildSrc中的配置項。

有了這一特性，我們就可以直接將之前version.gradle中的配置放入到buildSrc中，下面我們開始實現。

首先在根目錄新建一個buildSrc目錄(與app同級)，然后在該目錄新建src/main/java目錄，該目錄是你之后配置項所在的目錄；同時再新建build.gradle.kts文件，并在該文件中添加kotlin-dsl

plugins {
    `kotlin-dsl`
}
 
repositories {
    jcenter()
}

之后再sync project，最終的目錄結構如下

搭建好了目錄，現在我們在src/main/java下使用kotlin新建Dependencies文件(文件名任意)，在該文件中將之前的配置項放進來，只是使用kotlin語法進行實現而已，轉化的代碼如下

object Versions {
    const val support = "26.1.0"
    const val kotlin = "1.3.31"
    const val gradle = "3.4.1"
    const val target_sdk = 26
    const val min_sdk = 16
    const val build_tools = "28.0.3"
}
 
object Dependencies {
    val app_compat = "com.android.support:appcompat-v7:${Versions.support}"
    val kotlin_stdlib = "org.jetbrains.kotlin:kotlin-stdlib-jdk7:${Versions.kotlin}"
    val kotlin_plugin = "org.jetbrains.kotlin:kotlin-gradle-plugin:${Versions.kotlin}"
    val gradle_plugin = "com.android.tools.build:gradle:${Versions.gradle}"
    val addRepos: (handler: RepositoryHandler) -> Unit = {
        it.google()
        it.jcenter()
        it.maven { url = URI("https://oss.sonatype.org/content/repositories/snapshots") }
    }
}

這時你就可以直接使用Dependencies與Versions在各個build.gradle中引用，例如app下的build.gradle

android {
    compileSdkVersion Versions.target_sdk
    buildToolsVersion Versions.build_tools
    defaultConfig {
        applicationId "com.idisfkj.androidapianalysis"
        minSdkVersion Versions.min_sdk
        targetSdkVersion Versions.target_sdk
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    ...
}
dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    // support
    implementation Dependencies.app_compat
    //kotlin
    implementation Dependencies.kotlin_stdlib
}

根目錄的build.gradle亦是如此

buildscript {
    Dependencies.addRepos.invoke(repositories)
    dependencies {
        classpath Dependencies.gradle_plugin
        classpath Dependencies.kotlin_plugin
    }
}
 
allprojects {
    Dependencies.addRepos.invoke(repositories)
}
 
task clean(type: Delete) {
    delete rootProject.buildDir
}

其實我們真正需要get到的是一種思想，將配置統一管理。至于到底使用哪一種，這就看個人喜好了，但如果你的項目使用了kotlin，我還是建議你使用buildSrc模式，因為對于Groovy語法而言，我相信你還是對Kotlin更加熟悉。

源碼地址: https://github.com/idisfkj/an...

如果想了解更多關于我的文章，可以掃描下方二維碼，關注我的公眾號~