…
有没有一种好的方式不在 build.gradle 中写这么多的依赖配置？
有，就是 使用循环遍历依赖。答案似乎很简单，但是要想处理在依赖时遇到的所有情况，并不简单。下面，我直接给出相应的适配代码，大家可以直接使用。
首先，在 app 下的 build.gradle 的依赖配置如下所示：
// 处理所有的 aar 依赖
apiFileDependencies.each { k, v -> api files(v)}
// 处理所有的 xxximplementation 依赖
implementationDependencies.each { k, v -> implementation v }
debugImplementationDependencies.each { k, v -> debugImplementation v }
releaseImplementationDependencies.each { k, v -> releaseImplementation v }
androidTestImplementationDependencies.each { k, v -> androidTestImplementation v }
testImplementationDependencies.each { k, v -> testImplementation v }
debugApiDependencies.each { k, v -> debugApi v }
releaseApiDependencies.each { k, v -> releaseApi v }
compileOnlyDependencies.each { k, v -> compileOnly v }
// 处理 annotationProcessor 依赖
processors.each { k, v -> annotationProcessor v }
// 处理所有包含 exclude 的依赖
implementationExcludes.each { entry ->
implementation(entry.key) {
entry.value.each { childEntry ->
exclude(group: childEntry)
}
}
}
debugImplementationExcludes.each { entry ->
debugImplementation(entry.key) {
entry.value.each { childEntry ->
exclude(group: childEntry.key, module: childEntry.value)
}
}
}
releaseImplementationExcludes.each { entry ->
releaseImplementation(entry.key) {
entry.value.each { childEntry ->
exclude(group: childEntry.key, module: childEntry.value)
}
}
}
testImplementationExclude.each { entry ->
testImplementation(entry.key) {
entry.value.each { childEntry ->
exclude(group: childEntry.key, module: childEntry.value)
}
}
}
androidTestImplementationExcludes.each { entry ->
androidTestImplementation(entry.key) {
entry.value.each { childEntry ->
exclude(group: childEntry.key, module: childEntry.value)
}
}
}
然后，在 config.gradle 全局依赖管理文件中配置好对应名称的依赖数组即可。代码如下所示：
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-annot
ations’
]
]
…
三、Gradle 常用命令
1、Gradle 查询命令
1）、查看主要任务
./gradlew tasks
2）、查看所有任务，包括缓存任务等等
./gradlew tasks --all
2、Gradle 执行命令
1）、对某个module [moduleName] 的某个任务[TaskName] 运行
./gradlew :moduleName:taskName
3、Gradle 快速构建命令
Gradle 提供了一系列的快速构建命令来替代 IDE 的可视化构建操作，如我们最常用的 clean、build 等等。需要注意的是，build 命令会把 debug、release 环境的包都构建出来。
1）、查看构建版本
./gradlew -v
2）、清除 build 文件夹
./gradlew clean
3）、检查依赖并编译打包
./gradlew build
4）、编译并安装 debug 包
./gradlew installDebug
5）、编译并打印日志
./gradlew build --info
6）、编译并输出性能报告，性能报告一般在构建工程根目录 build/reports/profile 下
./gradlew build --profile
7）、调试模式构建并打印堆栈日志
./gradlew build --info --debug --stacktrace
8）、强制更新最新依赖，清除构建后再构建
./gradlew clean build --refresh-dependencies
9）、编译并打 Debug 包
./gradlew assembleDebug
简化版命令，取各个单词的首字母
./gradlew aD
10）、编译并打 Release 的包
./gradlew assembleRelease
简化版命令，取各个单词的首字母
./gradlew aR
4、Gradle 构建并安装命令
1）、Release 模式打包并安装
./gradlew installRelease
2）、卸载 Release 模式包
./gradlew uninstallRelease
3）、debug release 模式全部渠道打包
./gradlew assemble
5、Gradle 查看包依赖命令
1）、查看项目根目录下的依赖
./gradlew dependencies
2）、查看 app 模块下的依赖
./gradlew app:dependencies
3）、查看 app 模块下包含 implementation 关键字的依赖项目
./gradlew app:dependencies --configuration implementation
四、使用 Build Scan 诊断应用的构建过程
在了解 Build Scan 之前，我们需要先来一起学习下旧时代的 Gradle build 诊断工具 Profile report。
1、Profile report
通常情况下，我们一般会使用如下命令来生成一份本地的构建分析报告：
./gradlew assembleDebug --profile
这里，我们在 Awesome-WanAndroid App的根目录下运行这个命令，可以得到四块视图。下面，我们来了解下。
1）、Summary
Gradle 构建信息的概览界面，用于 查看 Total Build Time、初始化（包含 Startup、Settings and BuildSrc、Loading Projects 三部分）、配置、任务执行的时间。如下图所示：
2）、Configuaration
Gradle 配置各个工程所花费的时间，我们可以看到 All projects、app 模块以及其它模块单个的配置时间。如下图所示：
3）、Dependency Resolution
Gradle 在对各个 task 进行依赖关系解析时所花费的时间。如下图所示：
4）、Task Execution
Gradle 在执行各个 Gradle task 所花费的时间。如下图所示：
需要注意的是，Task Execution 的时间是所有 gradle task 执行时间的总和，实际上 多模块的任务是并行执行的。
2、Build Scan
Build Scan 是官方推出的用于诊断应用构建过程的性能检测工具，它能分析出导致应用构建速度慢的一些问题。在项目下使用如下命令即可开启 Build Scan 诊断：
./gradlew build --scan
如果你使用的是 Mac，使用上述命令时出现
zsh: permission denied: ./gradlew
可以加入下面的命给 gradlew 分配执行权限：
chmod +x gradlew
执行完 build --scan 命令之后，在命令的最后我们可以看到如下信息：
可以看到，在 Publishing build scan 点击下面的链接就可以跳转到 Build Scan 的诊断页面。
需要注意的是，如果你是第一次使用 Build Scan，首先需要使用自己的邮箱激活 Build Scan。如下图界面所示：
这里，我输入了我的邮箱 chao.qu521@gmail.com，点击 Go！之后，我们就可以登录我们的邮箱去确认授权即可。如下图所示：
直接点击 Discover your build 即可。
授权成功后，我们就可以看到 Build Scan 的诊断页面了。如下图所示：
可以看到，在界面的右边有一系列的功能 tab 可供我们选择查看，这里默认是 Summary 总览界面，我们的目的是要查看 应用的构建性能，所以点击右侧的 Performance tab 即可看到如下图所示的构建分析界面：
从上图可以看到，Performance 界面中除了 Build、Configuration、Dependency resolution、Task execution 这四项外，还有 Daemon、Network activity、Settings and suggestions。
在 Build 界面中，共有三个子项目，即 Total build time、Total garbage collection time、Peak heap memory usage，Total build time 里面的配置项前面我们已经分析过了，这里我们看看其余两项的含义，如下所示：
- Total garbage collection time：总的垃圾回收时间。
- Peak heap memory usage：最大堆内存使用。
对于 Peak heap memory usage 这一项来说，还有三个子项，其含义如下：
- 1）、PS Eden Space：Young Generation 的 Eden（伊甸园）物理内存区域。程序中生成的大部分新的对象都在 Eden 区中。
- 2）、PS Survivor Space：Young Generation 的 Eden 的 两个Survivor（幸存者）物理内存区域。当 Eden 区满时，还存活的对象将被复制到其中一个 Survivor 区，当此 Survivor 区满时，此区存活的对象又被复制到另一个 Survivor 区，当这个 Survivor 区也满时，会将其中存活的对象复制到年老代。
- 3）、PS Old Gen：Old Generation，一般情况下，年老代中的对象生命周期都比较长。
由于我们的目的是关注项目的 build 时间，所以，我们直接关注到 Task execution 这一项。如下图所示：
可以看到，Awesome-WanAndroid 项目中所有的 task 都是 Not cacheable 的。此时，我们往下滑动界面，可以看到所有 task 的构建时间。如下所示：
如果，我们想查看一个 tinyPicPluginSpeedRelease 这一个 task 的执行详细，可以点击 :app:tinyPicPluginSpeedRelease 这一项，然后，就会跳转到 Timeline 界面，显示出 tinyPicPluginSpeedRelease 相应的执行信息。如下图所示：
此外，这里我们点击弹出框右上方的第一个图标：Focus on task in timeline 即可看到该 task 在整个 Gradle build 时间线上的精确位置，如下图所示：
至此，我们可以看到 Build Scan 的功能要比 Profile report 强大不少，所以我强烈建议优先使用它进行 Gradle 构建时间的诊断与优化。
五、总结
Gradle 每次构建的运行时间会随着项目编译次数越来少，因此为了准确评估 Gradle 构建提速的优化效果，我们可以在优化前后分别执行以下命令进行对比分析，如下所示：
···
gradlew --profile --recompile-scripts --offline --rerun-tasks assembleDebug
···
ne 即可看到该 task 在整个 Gradle build 时间线上的精确位置，如下图所示：
[外链图片转存中…(img-kB5Q3dYd-1642937233830)]
至此，我们可以看到 Build Scan 的功能要比 Profile report 强大不少，所以我强烈建议优先使用它进行 Gradle 构建时间的诊断与优化。
五、总结
Gradle 每次构建的运行时间会随着项目编译次数越来少，因此为了准确评估 Gradle 构建提速的优化效果，我们可以在优化前后分别执行以下命令进行对比分析，如下所示：
···
gradlew --profile --recompile-scripts --offline --rerun-tasks assembleDebug
···