查看原文
其他

分享 7个 Gradle 实用小技巧

RicardoMJiang 鸿洋 2021-10-13

本文作者


作者:RicardoMJiang

链接:

https://juejin.cn/post/6947675376835362846

本文由作者授权发布。


前言


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


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


主要包括以下内容:


1.Gradle依赖树查询。


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


3.支持代码提示的Gradle依赖管理。


4.Gradle模块化。


5.Library模块Gradle代码复用。


6.资源文件分包。


7.AAR依赖与源码依赖快速切换。


1Gradle依赖树查询


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


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依赖

https://juejin.cn/post/6844903615346245646


buildSrc vs includeBuild


上面介绍的方法使用的是buildSrc,使用起来比较方便。


不过它的缺点在于构建速度上会慢一些,使用
includeBuild可以实现同样的效果。


两者实现的最终效果是差不多的。


详细实现可见:
【奇技淫巧】除了 buildSrc 还能这样统一配置依赖版本?巧用 includeBuild

https://juejin.cn/post/6844904169833234439


4Gradle模块化


我们在开发中,引入一些插件时,有时需要在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的代码。


5Library模块Gradle代码复用


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


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


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


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资源文件分包


随着项目越来越大,项目中的资源文件也越来越大,比如layoutdrawable文件夹下的文件数量常常可达几百甚至上千个。


我们能不能像代码一样,对资源文件进行分包呢?


答案是可以的,主要是利用gradlesourceSets属性。


我们可以将资源文件像代码一样按业务分包,具体操作如下:


1.新建res_xxx目录 。


main 目录下新建 res_core, res_feed(根据业务模块命名)等目录,在res_core中新建res目录中相同的文件夹如:layoutdrawable-xxhdpivalues等。


2.在gradle中配置res_xx目录。


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


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


1.按业务分包查找方便,结构清晰。


2.
strings.xmlkey-value型文件多人修改可以减少冲突。


3.当删除模块或做组件化改造时资源文件删除或迁移方便,不必像以前一样一个个去找。


7AAR依赖与源码依赖快速切换


当我们的项目中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 Scan使用介绍

https://juejin.cn/post/6895299152226615309

使用循环进行依赖优化

https://juejin.cn/post/6844904122492125198

Android 重构 | 持续优化统一管理 Gradle

https://juejin.cn/post/6872721978898743310

Android res 资源 分包

https://juejin.cn/post/6844903780547297288




最后推荐一下我做的网站,玩Android: wanandroid.com ,包含详尽的知识体系、好用的工具,还有本公众号文章合集,欢迎体验和收藏!


推荐阅读


Jetpack 这么讲就懂了,LiveData 完全掌握!
Span 有多强大?玩转各种文字特效
Android 代码混淆,到底做了什么?



扫一扫 关注我的公众号

如果你想要跟大家分享你的文章,欢迎投稿~


┏(^0^)┛明天见!

: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存