百度T6团队实力打造！Gradle-与-Android-构建入门-系统教程，我先收藏了

setting.gradle 中最关键的就是其提供的 include 方法，通过这个方法可以指定哪些工程需要参与编译，每一个参与编译的工程 Gradle 会为它创建一个 Project 对象

根目录 build.gradle

首先是 buildscript 代码块： gradle 默认是自顶向下执行，无论 buildscript 代码块在哪，它都会第一个执行

接下来是 repositories 和 dependencies： repositories 表示 dependencies 声明的依赖去哪些仓库找，google、jcenter、mavenCentral 都是第三方 Maven 仓库。同时，也可以通过 maven 方法添加自己的 Maven 仓库。需要注意的是，不应该假设组件一定会从特定仓库拉取，如果 Gradle 请求一个仓库超时，它会自动请求其他仓库。

dependencies：代表 Gradle 执行需要哪些依赖。比如需要 Android Gradle Plugin 插件为我们打包 apk 包，就需要添加: classpath ‘com.android.tools.build:gradle:3.4.0’

最后是 allprojects 和 repositories： 在 allprojects 中的配置会对所有工程生效而里面的 repositories 则表示工程声明的 dependencies 去哪些仓库查找

app build.gradle

首先可以看到 apply plugin: ‘com.android.application’，当应用这个插件后，它会为我们创建一系列 Task，比如 assembleDebug、assembleRelease，执行这些 Task，就会得到最终的 APK。

android 代码块是插件为我们提供的 API允许我们修改 Task 的行为。

dependencies 代码块的内容决定当前 Project 依赖哪些组件，而不同的依赖声明会有不同的结果，具体内容我们在下一节分析。

依赖管理

依赖配置

在 Android Gradle Plugin 3.0 时代，Google 使用 implementation 和 api 选项取代过去的 compile 选项。既然接口都变了，Google 索性将其他的配置项也进行了改名，方便大家理解其配置的含义。需要注意的是，老版本的接口没有被立刻删除，但是在下一个主要版本中会被删除。下面是各个配置项的官方中文解释：

举个例子： 假设 A 依赖 B，B 依赖 C。
如果 B 对 C 使用 implementation 依赖，则 A 无法调用 C 的代码
如果 B 对 C 使用 api 依赖，则 A 可以调用 C 的代码
如果 B 对 C 使用 compileOnly 依赖，则 A 无法调用 C 的代码，且 C 的代码不会被打包到 APK 中
如果 B 对 C 使用 runtimeOnly 依赖，则 A、B 无法调用 C 的代码，但 C 的代码会被打包到 APK 中

实际上每一个组件都有自己的 compileClasspath 和 runtimeClasspath
当一个组件参与编译时，Gradle 就会将其放在 compileClasspath 中
当一个组件参与打包时，Gradle 就会将其放在 runtimeClasspath 中

不同的依赖配置项，其实就是将声明的依赖放入不同组件的不同的 classpath 中，回到上面的例子 对于 implementation ，其实就是将 C 放入 B 的 compileClasspath 和 runtimeClasspath，放入 A 的 runtimeClasspath 中，从而实现 A 如果调用 C 的代码，在 A 的编译阶段 javac 报错，但最终 C 会被打包到 APK 包中

对于 api、compileOnly、runtimeOnly 原理相同

源码与二进制

当想要依赖一个源码工程时只需要这样写: implementation project(‘:demo:mylibrary’)

而且我们可以明确知道 mylibrary 中的依赖都会被正确打包到 APK 中

当我们依赖二进制需要这样写: implementation ‘androidx.appcompat:appcompat:1.0.2’

当执行依赖命令（只输出 release 包的 runtimeClasspath）:
./gradlew :app:dependencies --configuration releaseRuntimeClasspath > dependencies.txt

输出依赖关系图时会看到并不是仅仅依赖一个 appcompat 组件（只显示部分依赖），还包含该组件自己的依赖，以及依赖的依赖，直到组件自身没有依赖，这样的特性叫做依赖传递

releaseRuntimeClasspath - Resolved configuration for runtime for variant: release

— androidx.appcompat:appcompat:1.0.2

±-- androidx.annotation:annotation:1.0.0

±-- androidx.core:core:1.0.1

| ±-- androidx.annotation:annotation:1.0.0

| ±-- androidx.collection:collection:1.0.0

| | — androidx.annotation:annotation:1.0.0

| ±-- androidx.lifecycle:lifecycle-runtime:2.0.0

| | ±-- androidx.lifecycle:lifecycle-common:2.0.0

| | | — androidx.annotation:annotation:1.0.0

| | ±-- androidx.arch.core:core-common:2.0.0

| | | — androidx.annotation:annotation:1.0.0

| | — androidx.annotation:annotation:1.0.0

| — androidx.versionedparcelable:versionedparcelable:1.0.0

| ±-- androidx.annotation:annotation:1.0.0

| — androidx.collection:collection:1.0.0 (*)

±-- androidx.collection:collection:1.0.0 (*)

±-- androidx.cursoradapter:cursoradapter:1.0.0

那么 Gradle 是怎么确定这些依赖呢？当使用Maven 规范上传组件时，不单单会上传组件的二进制，还会上传一个 pom.xml 文件，依赖信息就在这个文件当中。

因为查看公共的 Maven 服务器有可能需要翻墙，下面给大家展示百度app自己搭建的服务器的后台，方便理解被上传的二进制在服务器是以怎样的结构存放的

这个是百度app自己搭建的 Maven 服务器后台，点击一项查看详情：

有上传的二进制 aar，也有 pom 文件，还有我们在上传时自定义的文件 readme

看完远端的 POM 文件，我们在看看当二进制被下载后在本地是如何存放的

下面是一个简单的 POM 文件:

可以看到有两个 dependency，需要注意的是 scope，也会分为 runtime 和 compile，runtime 不会参与编译，但会参与打包，compile 会参与编译和打包

两个实际例子： 一：假设 A 依赖 B，B 依赖 C

B 对 C 使用 implementation 依赖
B 中有类 Foo 继承于 C中的 Bar
在 A 中使用类 Foo 时会报错找不到类 Bar，解决办法只能让 A 再依赖 C，所以应该尽量避免使用继承
二：假设 A 依赖 B，B 依赖 C
BC 是二进制， B 的 POM 中对 C 的依赖是 runtime
在 Gradle 4.4 中，A 依然可以调用 C 的代码，这个问题在 Gradle 5.0 后被修复

依赖冲突

什么是依赖冲突：

假设 ABC 是源码，D 是二进制，A 声明依赖 B，A 声明依赖 C，B 声明依赖 D 1.0 版本，C 声明依赖 D 1.1版本，这时，D 有依赖冲突，需要确定是使用 1.0 还是 1.1 版本

如何解决依赖冲突：

1. 进行编译时，B 编译时依赖 D 的1.0版本，C 编译时依赖 D 的1.1版本，但最终打包到 apk 中 D 的版本是 1.1，因为版本号冲突默认选择最高版本
2. Gradle 为我们提供了一系列解决依赖冲突的规则如：不允许依赖传递，exclude 移除一个依赖，替换一个组件为另一个组件，这些方法就不一一介绍了，按需百度即可
3. 百度app在此基础上增加规则：如果最终应用的版本号高于在 version.properties 定义的版本号则报错

注意：

1. 假设 D 发布 1.2 版本，但 B、C 都没有基于 D 1.2 版本发布新版本，则最终打包还是 D 的 1.1 版本，所以所有组件最终被打包到 APK 包中的版本都为 version.properties 中定义的版本
2. 假设 D 的 MavenId 由 D 改成了 E，C 基于 E 发布二进制，B 还是老样子，在实际打包中会报类重复的错误，原因就是 B 的 POM 文件中依赖的还是 D，所以需要让 B 基于 D 改名后的 E重新发一个二进制

打包流程 有了前面这些铺垫，让我们实际看看在执行打包 Task 时，实际还执行了哪些 Task。环境配置如下：
Gradle 5.1.1
Android Gradle Plugin 3.1.2
org.gradle.parallel=true 开启并行编译
release 包 minifyEnabled true

执行命令可以得到如下图所示输出

–dry-run 表示不实际执行每个 Task

gradlew assembleRelease --dry-run

Task 很多，接下来为大家介绍几个重点的 Task，其余没介绍的感兴趣的同学可以找找对应的实现类，看看它的实现。

preBuild

描述：做一些编译前的检查
一个例子：有的人可能遇到下面的错误

"Android dependency "+ display+ “is set to compileOnly/provided which is not supported”

这个的原因就是由前面说过的 compileClasspath 和 runtimeClasspath 引起的。
当一个组件因为不同的依赖配置项导致它的 compileClasspath 比如为 1.1.1版本，但他的 runtimeClasspath 是 1.1.2版本，preBuild 就会检测出这个问题并报错我们处理

compileReleaseAidl

类：AidlCompile
描述：内部使用 AidlProcessor 调用 call 方法使用 build-tool 下的 aidl 执行编译。

各类 generate和 merge

这些 Task 允许我们在整个编译工程中动态的生成一些代码，生成好的资源需要和已有的资源进行合并，并且需要注意有可能覆盖已有资源，就不再详细介绍了，

过程

第一步：我们有 app 工程下的 Java 源文件，还有 AIDL、generate、R.java 等生成的 Java 源文件，还有本身依赖，源码子工程的 jar 包、远端 aar 解压的 jar 包等一系列二进制文件，源码文件是 javac 需要编译的内容，二进制文件 .jar/.class 则是当 javac 编译遇到一个类名等符号时，如果发现在现有的源文件找不到，该去哪找的集合，对应的 javac 参数就是 -classpath

而这个参数，其实就是 compileClasspath 的一个应用，如果你源文件引用了一个类，它的 jar 包不在 compileClasspath 中，那么在编译时 javac 就会报错找不到符号了

第二步：当源文件被编译成类文件后，Google 提供了 Transform 机制允许我们对二进制文件在打包前进行修改，比如前面图片中的 :app:transformClassesWithXXXForRelease SKIPPED 就是我们自定义的 Transform。通过 :app:transformClassesAndResourcesWithProguardForRelease SKIPPED 也可以看到 Proguard 也是通过 Transform 机制实现的，这里图片中一个 .class 文件，一个是 .jar/.class 文件，第一个显然是 javac 编译后的产物，第二个则是 runtimeClasspath，就是那些需要被打包的二进制。相信大家这样就理解了 compileClasspath 和 runtimeClasspath 是如何影响打包过程

第三步：当 Transform 处理好所有的 class 文件后，接下来就是将 .class 文件转换为 .dex 文件。值得注意的是，javac 只能发现源码的问题，不会发现那些未参与编译的二进制的问题。而在 dex 转换过程中则可以发现比如类重复问题或者一个类，名字不变，但是由 Class 变成了 Interface 这类严重的代码问题。

第四步：就是将前面的和资源进行打包。对应的类是 PackageApplication，得到这个 Task 后可以对打包的内容进行自定义

结语

虽然只对常见的一些配置提供一个大纲，没有详细介绍 Gradle 和 Android Gradle Plugin 相关内容，比如 Gradle 的生命周期，插件开发，Transform 机制等等，但是如果各位看了以后能对整个编译工具链有一个大体的了解，可以在需要的时候明白该从哪个方向去解决问题，就是本文的价值所在了。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

文末

那么对于想坚持程序员这行的真的就一点希望都没有吗？
其实不然，在互联网的大浪淘沙之下，留下的永远是最优秀的，我们考虑的不是哪个行业差哪个行业难，就逃避掉这些，无论哪个行业，都会有他的问题，但是无论哪个行业都会有站在最顶端的那群人。我们要做的就是努力提升自己，让自己站在最顶端，学历不够那就去读，知识不够那就去学。人之所以为人，不就是有解决问题的能力吗？挡住自己的由于只有自己。
Android希望=技能+面试

• 技能
  
• 面试技巧+面试题
  

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

ndroid希望=技能+面试**

• 技能
  [外链图片转存中…(img-q3DSsufd-1713688684515)]
• 面试技巧+面试题
  [外链图片转存中…(img-9XZhhmQy-1713688684516)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！