7个你应该知道的Gradle实用技巧

前言

Gradle在Android开发中应用地十分广泛，但相信有很多同学并不很了解gradle

在屏山等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站设计、网站建设 网站设计制作按需策划,公司网站建设,企业网站建设,品牌网站建设,成都营销网站建设,成都外贸网站建设,屏山网站建设费用合理。

本文主要介绍了使用gradle的一些实用技巧，帮助读者增进对这个熟悉的陌生人的了解

主要包括以下内容

  1. Gradle依赖树查询
  2. 使用循环优化Gradle依赖管理
  3. 支持代码提示的Gradle依赖管理
  4. Gradle模块化
  5. Library模块Gradle代码复用
  6. 资源文件分包
  7. AAR依赖与源码依赖快速切换

1.Gradle依赖树查询

有时我们在分析依赖冲突时，需要查看依赖树，我们常用的查看依赖树的命令为

 
 
 
 
    
  
  
  
  
  1. gradlew app:dependencies 
    2.

不过这种命令行方式查看依赖树出来的信息太多，看的有些费劲

所以官方又推出了Scan工具来帮助我们更加方便地查看依赖树

在项目根目录位置下运行gradle build \--scan即可，然后会生成 HTML 格式的分析文件的分析文件

分析文件会直接上传到Scan官网，命令行最后会给出远程地址

第一次跑会让你在 Scan 官网注册一下，邮件确认后就能看了

scan 工具是按照依赖变体挨个分类的，debugCompileClassPath 就是 dedug 打包中的依赖包了

如上，使用这种方式分析依赖树更加方便简洁

2.使用循环优化Gradle依赖管理

如下所示，我们常常使用ext来管理依赖

 
 
 
 
    
  
  
  
  
  1. dependencies { 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. implementation fileTree(include: ['*.jar'], dir: 'libs') 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. implementation rootProject.ext.dependencies["appcompat-v7"] 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7. implementation rootProject.ext.dependencies["cardview-v7"] 
    8. 
  
  
  
  
  8.  
    9. 
  
  
  
  
  9. implementation rootProject.ext.dependencies["design"] 
    10. 
  
  
  
  
  10.  
    11. 
  
  
  
  
  11. implementation rootProject.ext.dependencies["constraint-layout"] 
    12. 
  
  
  
  
  12.  
    13. 
  
  
  
  
  13. annotationProcessor rootProject.ext.dependencies["glide_compiler"] 
    14. 
  
  
  
  
  14.  
    15. 
  
  
  
  
  15. ... 
    16. 
  
  
  
  
  16.  
    17. 
  
  
  
  
  17. } 
    18.

这样虽然实现了依赖的统一管理，但是随着项目越来越大，依赖也会越来越多，常常会有几十甚至上百行，导致build.gradle越来越长

有没有一种好的方式不在 build.gradle 中写这么多的依赖配置？

有，就是使用循环遍历依赖。

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

 
 
 
 
    
  
  
  
  
  1. ext{ 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. dependencies = [ 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. // base 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7. "appcompat-v7" : "com.android.support:appcompat-v7:${version["supportLibraryVersion"]}"， 
    8. 
  
  
  
  
  8.  
    9. 
  
  
  
  
  9. ... 
    10. 
  
  
  
  
  10.  
    11. 
  
  
  
  
  11. ] 
    12. 
  
  
  
  
  12.  
    13. 
  
  
  
  
  13.  
    14. 
  
  
  
  
  14.  
    15. 
  
  
  
  
  15. annotationProcessor = [ 
    16. 
  
  
  
  
  16.  
    17. 
  
  
  
  
  17. "glide_compiler" : "com.github.bumptech.glide:compiler:${version["glideVersion"]}", 
    18. 
  
  
  
  
  18.  
    19. 
  
  
  
  
  19. ... 
    20. 
  
  
  
  
  20.  
    21. 
  
  
  
  
  21. ] 
    22. 
  
  
  
  
  22.  
    23. 
  
  
  
  
  23.  
    24. 
  
  
  
  
  24.  
    25. 
  
  
  
  
  25. apiFileDependencies = [ 
    26. 
  
  
  
  
  26.  
    27. 
  
  
  
  
  27. "launchstarter" :"libs/launchstarter-release-1.0.0.aar" 
    28. 
  
  
  
  
  28.  
    29. 
  
  
  
  
  29. ] 
    30. 
  
  
  
  
  30.  
    31. 
  
  
  
  
  31.  
    32. 
  
  
  
  
  32.  
    33. 
  
  
  
  
  33. debugImplementationDependencies = [ 
    34. 
  
  
  
  
  34.  
    35. 
  
  
  
  
  35. "MethodTraceMan" : "com.github.zhengcx:MethodTraceMan:1.0.7" 
    36. 
  
  
  
  
  36.  
    37. 
  
  
  
  
  37. ] 
    38. 
  
  
  
  
  38.  
    39. 
  
  
  
  
  39.  
    40. 
  
  
  
  
  40.  
    41. 
  
  
  
  
  41. ... 
    42. 
  
  
  
  
  42.  
    43. 
  
  
  
  
  43.  
    44. 
  
  
  
  
  44.  
    45. 
  
  
  
  
  45. implementationExcludes = [ 
    46. 
  
  
  
  
  46.  
    47. 
  
  
  
  
  47. "com.android.support.test.espresso:espresso-idling-resource:3.0.2" : [ 
    48. 
  
  
  
  
  48.  
    49. 
  
  
  
  
  49. 'com.android.support' : 'support-annotations' 
    50. 
  
  
  
  
  50.  
    51. 
  
  
  
  
  51. ] 
    52. 
  
  
  
  
  52.  
    53. 
  
  
  
  
  53. ] 
    54. 
  
  
  
  
  54.  
    55. 
  
  
  
  
  55.  
    56. 
  
  
  
  
  56.  
    57. 
  
  
  
  
  57. ... 
    58. 
  
  
  
  
  58.  
    59. 
  
  
  
  
  59. } 
    60.

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

 
 
 
 
    
  
  
  
  
  1. apply from config.gradle 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. ... 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. def implementationDependencies = project.ext.dependencies 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7. def processors = project.ext.annotationProcesso 
    8. 
  
  
  
  
  8.  
    9. 
  
  
  
  
  9. def implementationExcludes = project.ext.implementationExcludes 
    10. 
  
  
  
  
  10.  
    11. 
  
  
  
  
  11. dependencies{ 
    12. 
  
  
  
  
  12.  
    13. 
  
  
  
  
  13. // 处理所有的 xxximplementation 依赖 
    14. 
  
  
  
  
  14.  
    15. 
  
  
  
  
  15. implementationDependencies.each { k, v -> implementation v } 
    16. 
  
  
  
  
  16.  
    17. 
  
  
  
  
  17. // 处理 annotationProcessor 依赖 
    18. 
  
  
  
  
  18.  
    19. 
  
  
  
  
  19. processors.each { k, v -> annotationProcessor v } 
    20. 
  
  
  
  
  20.  
    21. 
  
  
  
  
  21. // 处理所有包含 exclude 的依赖 
    22. 
  
  
  
  
  22.  
    23. 
  
  
  
  
  23. implementationExcludes.each { entry -> 
    24. 
  
  
  
  
  24.  
    25. 
  
  
  
  
  25. implementation(entry.key) { 
    26. 
  
  
  
  
  26.  
    27. 
  
  
  
  
  27. entry.value.each { childEntry -> 
    28. 
  
  
  
  
  28.  
    29. 
  
  
  
  
  29. exclude(group: childEntry) 
    30. 
  
  
  
  
  30.  
    31. 
  
  
  
  
  31. } 
    32. 
  
  
  
  
  32.  
    33. 
  
  
  
  
  33. } 
    34. 
  
  
  
  
  34.  
    35. 
  
  
  
  
  35. } 
    36. 
  
  
  
  
  36.  
    37. 
  
  
  
  
  37. ... 
    38. 
  
  
  
  
  38.  
    39. 
  
  
  
  
  39. } 
    40.

这样做的优点在于

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

 
 
 
 
    
  
  
  
  
  1. apply plugin: 'org.greenrobot.greendao' 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. //greenDao指定版本和路劲等 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. greendao { 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7. //数据库的schema版本，也可以理解为数据库版本号 
    8. 
  
  
  
  
  8.  
    9. 
  
  
  
  
  9. schemaVersion 1 
    10. 
  
  
  
  
  10.  
    11. 
  
  
  
  
  11. //设置DaoMaster、DaoSession、Dao包名，也就是要放置这些类的包的全路径。 
    12. 
  
  
  
  
  12.  
    13. 
  
  
  
  
  13. daoPackage 'com.example.ausu.big_progect.dao' 
    14. 
  
  
  
  
  14.  
    15. 
  
  
  
  
  15. //设置DaoMaster、DaoSession、Dao目录 
    16. 
  
  
  
  
  16.  
    17. 
  
  
  
  
  17. targetGenDir 'src/main/java' 
    18. 
  
  
  
  
  18.  
    19. 
  
  
  
  
  19. } 
    20.

然后再在build.gradle中引入

 
 
 
 
    
  
  
  
  
  1. apply from 'greendao-config.gradle' 
    2.

这样做主要有2个优点

1.单一职责原则，将greendao的相关配置封装在一个文件里，不与其他文件混淆

2.精简了build.gradle的代码，同时后续修改数据库相关时不需要修改build.gradle的代码

5.Library模块Gradle代码复用

随着我们项目的越来越大，Library Module也越建越多，每个Module都有自己的build.gradle

但其实每个build.gradle的内容都差不多，我们能不能将重复的部分封装起来复用？

我们可以做一个 basic 抽取，同样将共有参数/信息提取到 basic.gradle 中，每个 module apply，这样就是减少了不少代码量

 
 
 
 
    
  
  
  
  
  1. apply plugin: 'com.android.library' 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. apply plugin: 'kotlin-android' 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. apply plugin: 'kotlin-android-extensions' 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7. apply plugin: 'kotlin-kapt' 
    8. 
  
  
  
  
  8.  
    9. 
  
  
  
  
  9. android { 
    10. 
  
  
  
  
  10.  
    11. 
  
  
  
  
  11. // 指定用于编译项目的 API 级别 
    12. 
  
  
  
  
  12.  
    13. 
  
  
  
  
  13. compileSdkVersion Versions.compileSDK 
    14. 
  
  
  
  
  14.  
    15. 
  
  
  
  
  15. // 指定在生成项目时要使用的 SDK 工具的版本，Android Studio 3.0 后不需要手动配置。 
    16. 
  
  
  
  
  16.  
    17. 
  
  
  
  
  17. buildToolsVersion Versions.buildTools 
    18. 
  
  
  
  
  18.  
    19. 
  
  
  
  
  19. // 指定 Android 插件适用于所有构建版本的版本属性的默认值 
    20. 
  
  
  
  
  20.  
    21. 
  
  
  
  
  21. defaultConfig { 
    22. 
  
  
  
  
  22.  
    23. 
  
  
  
  
  23. minSdkVersion Versions.minSDK 
    24. 
  
  
  
  
  24.  
    25. 
  
  
  
  
  25. targetSdkVersion Versions.targetSDK 
    26. 
  
  
  
  
  26.  
    27. 
  
  
  
  
  27. versionCode 1 
    28. 
  
  
  
  
  28.  
    29. 
  
  
  
  
  29. versionName "1.0" 
    30. 
  
  
  
  
  30.  
    31. 
  
  
  
  
  31. } 
    32. 
  
  
  
  
  32.  
    33. 
  
  
  
  
  33. // 配置 Java 编译(编码格式、编译级别、生成字节码版本) 
    34. 
  
  
  
  
  34.  
    35. 
  
  
  
  
  35. compileOptions { 
    36. 
  
  
  
  
  36.  
    37. 
  
  
  
  
  37. encoding = 'utf-8' 
    38. 
  
  
  
  
  38.  
    39. 
  
  
  
  
  39. sourceCompatibility JavaVersion.VERSION_1_8 
    40. 
  
  
  
  
  40.  
    41. 
  
  
  
  
  41. targetCompatibility JavaVersion.VERSION_1_8 
    42. 
  
  
  
  
  42.  
    43. 
  
  
  
  
  43. } 
    44. 
  
  
  
  
  44.  
    45. 
  
  
  
  
  45. kotlinOptions { 
    46. 
  
  
  
  
  46.  
    47. 
  
  
  
  
  47. jvmTarget = JavaVersion.VERSION_1_8.toString() 
    48. 
  
  
  
  
  48.  
    49. 
  
  
  
  
  49. } 
    50. 
  
  
  
  
  50.  
    51. 
  
  
  
  
  51. lintOptions { 
    52. 
  
  
  
  
  52.  
    53. 
  
  
  
  
  53. // lint 异常后继续执行 
    54. 
  
  
  
  
  54.  
    55. 
  
  
  
  
  55. abortOnError false 
    56. 
  
  
  
  
  56.  
    57. 
  
  
  
  
  57. } 
    58. 
  
  
  
  
  58.  
    59. 
  
  
  
  
  59. } 
    60. 
  
  
  
  
  60.  
    61. 
  
  
  
  
  61. dependencies { 
    62. 
  
  
  
  
  62.  
    63. 
  
  
  
  
  63. implementation fileTree(dir: 'libs', include: ['*.jar']) 
    64. 
  
  
  
  
  64.  
    65. 
  
  
  
  
  65. ... 
    66. 
  
  
  
  
  66.  
    67. 
  
  
  
  
  67. } 
    68.

然后在相应的模块的build.gradle中引入即可

 
 
 
 
    
  
  
  
  
  1. apply from:"../basic.gradle" 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. dependencies { 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. api Deps.constraintLayout 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7. api Deps.retrofit 
    8. 
  
  
  
  
  8.  
    9. 
  
  
  
  
  9. } 
    10.

这样是不是简洁很多？读者可根据项目实际情况判断是否适合抽取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目录

 
 
 
 
    
  
  
  
  
  1. android { 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. //... 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. sourceSets { 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7. main { 
    8. 
  
  
  
  
  8.  
    9. 
  
  
  
  
  9. res.srcDirs( 
    10. 
  
  
  
  
  10.  
    11. 
  
  
  
  
  11. 'src/main/res', 
    12. 
  
  
  
  
  12.  
    13. 
  
  
  
  
  13. 'src/main/res_core', 
    14. 
  
  
  
  
  14.  
    15. 
  
  
  
  
  15. 'src/main/res_feed', 
    16. 
  
  
  
  
  16.  
    17. 
  
  
  
  
  17. ) 
    18. 
  
  
  
  
  18.  
    19. 
  
  
  
  
  19. } 
    20. 
  
  
  
  
  20.  
    21. 
  
  
  
  
  21. } 
    22. 
  
  
  
  
  22.  
    23. 
  
  
  
  
  23. } 
    24.

以上就完成了资源文件分包,这样做主要有几点好处

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

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

3.替换aar为源码

build.gradle(android) 脚本中添加替换策略

 
 
 
 
    
  
  
  
  
  1. allprojects { 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. repositories { 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. ... 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7. } 
    8. 
  
  
  
  
  8.  
    9. 
  
  
  
  
  9.  
    10. 
  
  
  
  
  10.  
    11. 
  
  
  
  
  11. configurations.all { 
    12. 
  
  
  
  
  12.  
    13. 
  
  
  
  
  13. resolutionStrategy { 
    14. 
  
  
  
  
  14.  
    15. 
  
  
  
  
  15. dependencySubstitution { 
    16. 
  
  
  
  
  16.  
    17. 
  
  
  
  
  17. substitute module( "com.squareup.retrofit2:retrofit") with project(':retofit-source') 
    18. 
  
  
  
  
  18.  
    19. 
  
  
  
  
  19. } 
    20. 
  
  
  
  
  20.  
    21. 
  
  
  
  
  21. } 
    22. 
  
  
  
  
  22.  
    23. 
  
  
  
  
  23. } 
    24. 
  
  
  
  
  24.  
    25. 
  
  
  
  
  25. } 
    26.

如上几步，就可以比较方便地实现aar依赖与源码依赖间的互换了

这样做的主要优点在于

1.不需要修改原有的依赖配置，而是通过全局的配置，利用本地的源码替换掉aar，侵入性低

2.如果有多个Module依赖于同一个aar，不需要重复修改，只需在根目录build.gradle中修改一处

总结

本文主要介绍了几个实用的Gradle技巧，如果觉得有所帮助，可以帮忙点赞

如果发现本文还有什么不足，欢迎在评论区指出~

当前名称：7个你应该知道的Gradle实用技巧
文章网址：http://www.36103.cn/qtweb/news5/15605.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

标签优化知识

行业网站建设

简阳网站建设　　 　培训网站方案　　 　升施印刷　　 　鸿艺文化　　 　混凝土搅拌罐车　　 　关键词排名　　 　都江堰做网站　　 　梓潼网站建设　　 　四川绵阳主机托管　　 　西信服务器托管　　 　自动门　　 　香港服务器空间　　 　成都企业网站定制　　 　广元双南建站　　 　温江网站建设　　 　成都模板网站　　 　网站报价方案　　 　贵阳联通机房　　 　绵阳网站建设公司　　 　平昌保洁