扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
这篇文章主要讲解了“Gradle的实用技巧有哪些”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Gradle的实用技巧有哪些”吧!
10年的阜新网站建设经验,针对设计、前端、开发、售后、文案、推广等六对一服务,响应快,48小时及时工作处理。成都全网营销推广的优势是能够根据用户设备显示端的尺寸不同,自动调整阜新建站的显示方式,使网站能够适用不同显示终端,在浏览器中调整网站的宽度,无论在任何一种浏览器上浏览网站,都能展现优雅布局与设计,从而大程度地提升浏览体验。创新互联从事“阜新网站设计”,“阜新网站推广”以来,每个客户项目都认真落实执行。
有时我们在分析依赖冲突时,需要查看依赖树,我们常用的查看依赖树的命令为
gradlew app:dependencies
不过这种命令行方式查看依赖树出来的信息太多,看的有些费劲
所以官方又推出了Scan工具来帮助我们更加方便地查看依赖树
在项目根目录位置下运行gradle build \--scan即可,然后会生成 HTML 格式的分析文件的分析文件
分析文件会直接上传到Scan官网,命令行最后会给出远程地址
第一次跑会让你在 Scan 官网注册一下,邮件确认后就能看了
scan 工具是按照依赖变体挨个分类的,debugCompileClassPath 就是 dedug 打包中的依赖包了
如上,使用这种方式分析依赖树更加方便简洁
如下所示,我们常常使用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的长度
上面介绍了通过config.gradle管理依赖的方法
在我们添加Gradle依赖时,还有一些痛点
1.不支持代码提示
2.不支持单击跳转
3.多模块开发时,不同模块相同的依赖需要复制粘贴
使用buildSrc+kotlin可以解决这个问题
效果如下:
由于buildSrc是对全局的所有module的配置,所以可以在所有module中直接使用
这里就不多介绍了,详细开发及引入buildSrc的过程可见:
[译]Kotlin + buildSrc:更好的管理Gadle依赖
buildSrc vs includeBuild
上面介绍的方法使用的是buildSrc,使用起来比较方便
不过它的缺点在于构建速度上会慢一些,使用includeBuild可以实现同样的效果
两者实现的最终效果是差不多的
详细实现可见:【奇技淫巧】除了 buildSrc 还能这样统一配置依赖版本?巧用 includeBuild
我们在开发中,引入一些插件时,有时需要在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的代码
随着我们项目的越来越大,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使用
随着项目越来越大,项目中的资源文件也越来越大,比如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.当删除模块或做组件化改造时资源文件删除或迁移方便,不必像以前一样一个个去找
当我们的项目中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的实用技巧有哪些这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流