Gradle的實用技巧有哪些

這篇文章主要講解了“Gradle的實用技巧有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Gradle的實用技巧有哪些”吧！

1.Gradle依賴樹查詢

有時我們在分析依賴沖突時，需要查看依賴樹，我們常用的查看依賴樹的命令為

gradlew app:dependencies

不過這種命令行方式查看依賴樹出來的信息太多，看的有些費勁

所以官方又推出了Scan工具來幫助我們更加方便地查看依賴樹

在項目根目錄位置下運行gradle build \--scan即可，然后會生成 HTML 格式的分析文件的分析文件

分析文件會直接上傳到Scan官網，命令行最后會給出遠程地址

第一次跑會讓你在 Scan 官網注冊一下，郵件確認后就能看了

scan 工具是按照依賴變體挨個分類的，debugCompileClassPath 就是 dedug 打包中的依賴包了

如上，使用這種方式分析依賴樹更加方便簡潔

2.使用循環優化Gradle依賴管理

如下所示，我們常常使用ext來管理依賴

dependencies {  implementation fileTree(include: ['*.jar'], dir: 'libs')  implementation rootProject.ext.dependencies["appcompat-v7"]  implementation rootProject.ext.dependencies["cardview-v7"]  implementation rootProject.ext.dependencies["design"]  implementation rootProject.ext.dependencies["constraint-layout"]  annotationProcessor rootProject.ext.dependencies["glide_compiler"]  ...  }

這樣雖然實現了依賴的統一管理，但是隨著項目越來越大，依賴也會越來越多，常常會有幾十甚至上百行，導致build.gradle越來越長

有沒有一種好的方式不在 build.gradle 中寫這么多的依賴配置？

有，就是使用循環遍歷依賴。

示例如下，首先添加config.gradle

ext{  dependencies = [  // base  "appcompat-v7" : "com.android.support:appcompat-v7:${version["supportLibraryVersion"]}"，  ...  ]    annotationProcessor = [  "glide_compiler" : "com.github.bumptech.glide:compiler:${version["glideVersion"]}",  ...  ]    apiFileDependencies = [  "launchstarter" :"libs/launchstarter-release-1.0.0.aar"  ]    debugImplementationDependencies = [  "MethodTraceMan" : "com.github.zhengcx:MethodTraceMan:1.0.7"  ]    ...    implementationExcludes = [  "com.android.support.test.espresso:espresso-idling-resource:3.0.2" : [  'com.android.support' : 'support-annotations'  ]  ]    ...  }

然后在build.gradle中配置如下：

apply from config.gradle  ...  def implementationDependencies = project.ext.dependencies  def processors = project.ext.annotationProcesso  def implementationExcludes = project.ext.implementationExcludes  dependencies{  // 處理所有的 xxximplementation 依賴  implementationDependencies.each { k, v -> implementation v }  // 處理 annotationProcessor 依賴  processors.each { k, v -> annotationProcessor v }  // 處理所有包含 exclude 的依賴  implementationExcludes.each { entry ->  implementation(entry.key) {  entry.value.each { childEntry ->  exclude(group: childEntry)  }  }  }  ...  }

這樣做的優點在于

1.后續添加依賴不需要改動build.gradle,直接在config.gradle中添加即可

2.精簡了build.gradle的長度

3.支持代碼提示的Gradle依賴管理

上面介紹了通過config.gradle管理依賴的方法

在我們添加Gradle依賴時，還有一些痛點

1.不支持代碼提示

2.不支持單擊跳轉

3.多模塊開發時，不同模塊相同的依賴需要復制粘貼

使用buildSrc+kotlin可以解決這個問題

效果如下：

由于buildSrc是對全局的所有module的配置,所以可以在所有module中直接使用

這里就不多介紹了，詳細開發及引入buildSrc的過程可見:

[譯]Kotlin + buildSrc：更好的管理Gadle依賴

buildSrc vs includeBuild

上面介紹的方法使用的是buildSrc,使用起來比較方便

不過它的缺點在于構建速度上會慢一些，使用includeBuild可以實現同樣的效果

兩者實現的最終效果是差不多的

詳細實現可見:【奇技淫巧】除了 buildSrc 還能這樣統一配置依賴版本？巧用 includeBuild

4.Gradle模塊化

我們在開發中，引入一些插件時，有時需要在build.gradle中引入一些配置，比如greendao,推送,tinker等

這些其實是可以封裝在相應gradle文件中，然后通過apply from引入

舉個例子，例如在我們使用greendao數據庫時，需要在build.gradle中指定版本

這種時候應該新建一個greendao-config.gradle

apply plugin: 'org.greenrobot.greendao'  //greenDao指定版本和路勁等  greendao {  //數據庫的schema版本，也可以理解為數據庫版本號  schemaVersion 1  //設置DaoMaster、DaoSession、Dao包名，也就是要放置這些類的包的全路徑。  daoPackage 'com.example.ausu.big_progect.dao'  //設置DaoMaster、DaoSession、Dao目錄  targetGenDir 'src/main/java'  }

然后再在build.gradle中引入

apply from 'greendao-config.gradle'

這樣做主要有2個優點

1.單一職責原則，將greendao的相關配置封裝在一個文件里，不與其他文件混淆

2.精簡了build.gradle的代碼，同時后續修改數據庫相關時不需要修改build.gradle的代碼

5.Library模塊Gradle代碼復用

隨著我們項目的越來越大，Library Module也越建越多，每個Module都有自己的build.gradle

但其實每個build.gradle的內容都差不多，我們能不能將重復的部分封裝起來復用？

我們可以做一個 basic 抽取，同樣將共有參數/信息提取到 basic.gradle 中，每個 module apply，這樣就是減少了不少代碼量

apply plugin: 'com.android.library'  apply plugin: 'kotlin-android'  apply plugin: 'kotlin-android-extensions'  apply plugin: 'kotlin-kapt'  android {  // 指定用于編譯項目的 API 級別  compileSdkVersion Versions.compileSDK  // 指定在生成項目時要使用的 SDK 工具的版本，Android Studio 3.0 后不需要手動配置。  buildToolsVersion Versions.buildTools  // 指定 Android 插件適用于所有構建版本的版本屬性的默認值  defaultConfig {  minSdkVersion Versions.minSDK  targetSdkVersion Versions.targetSDK  versionCode 1  versionName "1.0"  }  // 配置 Java 編譯(編碼格式、編譯級別、生成字節碼版本)  compileOptions {  encoding = 'utf-8'  sourceCompatibility JavaVersion.VERSION_1_8  targetCompatibility JavaVersion.VERSION_1_8  }  kotlinOptions {  jvmTarget = JavaVersion.VERSION_1_8.toString()  }  lintOptions {  // lint 異常后繼續執行  abortOnError false  }  }  dependencies {  implementation fileTree(dir: 'libs', include: ['*.jar'])  ...  }

然后在相應的模塊的build.gradle中引入即可

apply from:"../basic.gradle"  dependencies {  api Deps.constraintLayout  api Deps.retrofit  }

這樣是不是簡潔很多？讀者可根據項目實際情況判斷是否適合抽取basic.gradle使用

6.資源文件分包

隨著項目越來越大，項目中的資源文件也越來越大，比如layout與drawable文件夾下的文件數量常常可達幾百甚至上千個

我們能不能像代碼一樣，對資源文件進行分包呢？

答案是可以的，主要是利用gradle的sourceSets屬性

我們可以將資源文件像代碼一樣按業務分包,具體操作如下

1.新建res_xxx目錄

在 main 目錄下新建 res_core, res_feed（根據業務模塊命名）等目錄，在res_core中新建res目錄中相同的文件夾如：layout、drawable-xxhdpi、values等。

2.在gradle中配置res_xx目錄

android {  //...  sourceSets {  main {  res.srcDirs(  'src/main/res',  'src/main/res_core',  'src/main/res_feed',  )  }  }  }

以上就完成了資源文件分包,這樣做主要有幾點好處

1.按業務分包查找方便，結構清晰

2.strings.xml等key-value型文件多人修改可以減少沖突

3.當刪除模塊或做組件化改造時資源文件刪除或遷移方便，不必像以前一樣一個個去找

7.AAR依賴與源碼依賴快速切換

當我們的項目中Module越來越多，為了加快編譯速度，常常把Module發布成AAR，然后在項目中直接依賴AAR

但是我們有時候又需要修改AAR，就需要依賴于源碼

所以我們需要一個可以快速地切換依賴AAR與依賴源碼的方式

我們下面舉個例子，以retrofit為例

假如我們要修改retrofit的源碼，修改步驟如下：

1.首先下載retrofit，可以放到和項目同級的目錄,并修改目錄名為retrofit-source,以便區分

2.在settings.gradle文件中添加需要修改的aar庫的源碼project

include ':retrofit-source'  project(':retrofit-source').projectDir = new File("../retrofit-source")

3.替換aar為源碼

build.gradle(android) 腳本中添加替換策略

allprojects {  repositories {  ...  }    configurations.all {  resolutionStrategy {  dependencySubstitution {  substitute module( "com.squareup.retrofit2:retrofit") with project(':retofit-source')  }  }  }  }

如上幾步，就可以比較方便地實現aar依賴與源碼依賴間的互換了

這樣做的主要優點在于

1.不需要修改原有的依賴配置，而是通過全局的配置，利用本地的源碼替換掉aar，侵入性低

2.如果有多個Module依賴于同一個aar，不需要重復修改，只需在根目錄build.gradle中修改一處

感謝各位的閱讀，以上就是“Gradle的實用技巧有哪些”的內容了，經過本文的學習后，相信大家對Gradle的實用技巧有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！