Gradle**
Gradle在android开发中应用地十分广泛，这里主要介绍了使用gradle的一些实用技巧，主要包括以下内容：

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

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

    1、Gradle依赖树查询

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

    1. gradlew app:dependencies

    不过这种命令行方式查看依赖树出来的信息太多，看的有些费劲
    所以官方又推出了Scan工具来帮助我们更加方便地查看依赖树
    在项目根目录位置下运行gradle build \--scan即可，然后会生成 HTML 格式的分析文件的分析文件
    分析文件会直接上传到Scan官网，命令行最后会给出远程地址
    第一次跑会让你在 Scan 官网注册一下，邮件确认后就能看了
    scan 工具是按照依赖变体挨个分类的，debugCompileClassPath 就是 dedug 打包中的依赖包了
    7 个Gradle 实用技巧 - 图1如上，使用这种方式分析依赖树更加方便简洁

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

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

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

    这样虽然实现了依赖的统一管理，但是随着项目越来越大，依赖也会越来越多，常常会有几十甚至上百行，导致build.gradle越来越长
    有没有一种好的方式不在 build.gradle 中写这么多的依赖配置？
    有，就是使用循环遍历依赖。
    示例如下，首先添加config.gradle

    1. ext{
    2.   dependencies = [
    3.       // base
    4.       "appcompat-v7"                      : "com.android.support:appcompat-v7:${version["supportLibraryVersion"]}"，
    5.       ...
    6.   ]
    8.   annotationProcessor = [
    9.       "glide_compiler"                    : "com.github.bumptech.glide:compiler:${version["glideVersion"]}",
    10.       ...
    11.   ]
    13.   apiFileDependencies = [
    14.       "launchstarter"                                   :"libs/launchstarter-release-1.0.0.aar"
    15.   ]
    17.   debugImplementationDependencies = [
    18.       "MethodTraceMan"                                  : "com.github.zhengcx:MethodTraceMan:1.0.7"
    19.   ]
    21.   ...
    23.       implementationExcludes = [
    24.           "com.android.support.test.espresso:espresso-idling-resource:3.0.2" : [
    25.               'com.android.support' : 'support-annotations'
    26.           ]
    27.       ]
    29.   ...
    30. }

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

    1. apply from config.gradle
    2. ...
    3. def implementationDependencies = project.ext.dependencies
    4. def processors = project.ext.annotationProcesso
    5. def implementationExcludes = project.ext.implementationExcludes
    6. dependencies{
    7.   // 处理所有的 xxximplementation 依赖
    8.   implementationDependencies.each { k, v -> implementation v }   
    9.   // 处理 annotationProcessor 依赖
    10.   processors.each { k, v -> annotationProcessor v }
    11.   // 处理所有包含 exclude 的依赖
    12.   implementationExcludes.each { entry ->
    13.       implementation(entry.key) {
    14.           entry.value.each { childEntry ->
    15.               exclude(group: childEntry)
    16.           }
    17.       }
    18.   }
    19.   ...
    20. }

    这样做的优点在于
    1.后续添加依赖不需要改动build.gradle,直接在config.gradle中添加即可
    2.精简了build.gradle的长度

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

    上面介绍了通过config.gradle管理依赖的方法
    在添加Gradle依赖时，还有一些痛点
    1.不支持代码提示
    2.不支持单击跳转
    3.多模块开发时，不同模块相同的依赖需要复制粘贴
    使用buildSrc+kotlin可以解决这个问题
    效果如下：
    7 个Gradle 实用技巧 - 图2
    由于buildSrc是对全局的所有module的配置,所以可以在所有module中直接使用。

    buildSrc vs 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. //greenDao指定版本和路劲等
    3. greendao {
    4.   //数据库的schema版本，也可以理解为数据库版本号
    5.   schemaVersion 1
    6.   //设置DaoMaster、DaoSession、Dao包名，也就是要放置这些类的包的全路径。
    7.   daoPackage 'com.example.ausu.big_progect.dao'
    8.   //设置DaoMaster、DaoSession、Dao目录
    9.   targetGenDir 'src/main/java'
    10. }

    然后再在build.gradle中引入

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

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

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

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

    这样是不是简洁很多？读者可根据项目实际情况判断是否适合抽取basic.gradle使用

    6、资源文件分包

    随着项目越来越大，项目中的资源文件也越来越大，比如layout与drawable文件夹下的文件数量常常可达几百甚至上千个
    能不能像代码一样，对资源文件进行分包呢？
    答案是可以的，主要是利用gradle的sourceSets属性
    可以将资源文件像代码一样按业务分包,具体操作如下
    1.新建res_xxx目录
    7 个Gradle 实用技巧 - 图3
    在 main 目录下新建 res_core, res_feed（根据业务模块命名）等目录，在res_core中新建res目录中相同的文件夹如：layout、drawable-xxhdpi、values等。
    2.在gradle中配置res_xx目录

    1. android {
    2.   //...
    3.   sourceSets {
    4.       main {
    5.           res.srcDirs(
    6.                   'src/main/res',
    7.                   'src/main/res_core',
    8.                   'src/main/res_feed',
    9.           )
    10.       }
    11.   }
    12. }

    以上就完成了资源文件分包,这样做主要有几点好处
    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. project(':retrofit-source').projectDir = new File("../retrofit-source")

    3.替换aar为源码
    build.gradle(android) 脚本中添加替换策略

    1. allprojects {
    2.   repositories {
    3. ...
    4.   }
    6.   configurations.all {
    7.       resolutionStrategy {
    8.           dependencySubstitution {
    9.               substitute module( "com.squareup.retrofit2:retrofit") with project(':retofit-source')
    10.           }
    11.       }
    12.   }
    13. }

    如上几步，就可以比较方便地实现aar依赖与源码依赖间的互换了
    这样做的主要优点在于
    1.不需要修改原有的依赖配置，而是通过全局的配置，利用本地的源码替换掉aar，侵入性低
    2.如果有多个Module依赖于同一个aar，不需要重复修改，只需在根目录build.gradle中修改一处