Gradle的实用技巧有哪些(gradle,移动开发)

1.Gradle依赖树查询

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

gradlewapp:dependencies

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

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

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

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

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

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

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

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

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

dependencies{implementationfileTree(include:['*.jar'],dir:'libs')implementationrootProject.ext.dependencies["appcompat-v7"]implementationrootProject.ext.dependencies["cardview-v7"]implementationrootProject.ext.dependencies["design"]implementationrootProject.ext.dependencies["constraint-layout"]annotationProcessorrootProject.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中配置如下：

applyfromconfig.gradle...defimplementationDependencies=project.ext.dependenciesdefprocessors=project.ext.annotationProcessodefimplementationExcludes=project.ext.implementationExcludesdependencies{//处理所有的xxximplementation依赖implementationDependencies.each{k,v->implementationv}//处理annotationProcessor依赖processors.each{k,v->annotationProcessorv}//处理所有包含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

applyplugin:'org.greenrobot.greendao'//greenDao指定版本和路劲等greendao{//数据库的schema版本，也可以理解为数据库版本号schemaVersion1//设置DaoMaster、DaoSession、Dao包名，也就是要放置这些类的包的全路径。daoPackage'com.example.ausu.big_progect.dao'//设置DaoMaster、DaoSession、Dao目录targetGenDir'src/main/java'}

然后再在build.gradle中引入

applyfrom'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，这样就是减少了不少代码量

applyplugin:'com.android.library'applyplugin:'kotlin-android'applyplugin:'kotlin-android-extensions'applyplugin:'kotlin-kapt'android{//指定用于编译项目的API级别compileSdkVersionVersions.compileSDK//指定在生成项目时要使用的SDK工具的版本，AndroidStudio3.0后不需要手动配置。buildToolsVersionVersions.buildTools//指定Android插件适用于所有构建版本的版本属性的默认值defaultConfig{minSdkVersionVersions.minSDKtargetSdkVersionVersions.targetSDKversionCode1versionName"1.0"}//配置Java编译(编码格式、编译级别、生成字节码版本)compileOptions{encoding='utf-8'sourceCompatibilityJavaVersion.VERSION_1_8targetCompatibilityJavaVersion.VERSION_1_8}kotlinOptions{jvmTarget=JavaVersion.VERSION_1_8.toString()}lintOptions{//lint异常后继续执行abortOnErrorfalse}}dependencies{implementationfileTree(dir:'libs',include:['*.jar'])...}

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

applyfrom:"../basic.gradle"dependencies{apiDeps.constraintLayoutapiDeps.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=newFile("../retrofit-source")

3.替换aar为源码

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

allprojects{repositories{...}configurations.all{resolutionStrategy{dependencySubstitution{substitutemodule("com.squareup.retrofit2:retrofit")withproject(':retofit-source')}}}}

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

这样做的主要优点在于

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

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