Gradle Builds Everything —— 处理依赖（aar）

我们使用 gradle 的时候，会使用implementation, compile等方式加入一些依赖，比如，aar 是个最经典的例子。那么 aar 到底经过 gradle 怎样的处理使得它能轻松的应用这个产物呢？

认识 aar

首先，aar是一个zip文件，这句话应该不难理解，意思是，aar 是 zip 文件改了后缀名来的，它的二进制格式和 zip 没有啥两样，所以我们完全可以把后缀名改成 zip 再解压一下。我们以androidx.recyclerview:recyclerview:1.0.0这个 GAV 下过来的 aar 为例子。

我们看下解压了 aar 里面的文件是怎么样的

我们可以看到，资源部分是完好无损的保存下来的，我们打开里面的资源文件，是可以直接查看的。唯一有变化的是，多了 R.txt， classes.jar，一个是记录 aar 打包时候生成的 R.java里面的 id信息，另外一个就是从 java 源代码编译好的 jar 文件(字节码)啦。

通过 聊聊 APK —— 脱离 AS 手工创造 APK 文件 等系列文章我们可以了解到，apk 的打包过程中，其实是不存在 aar 这个文件实体的，那么看完了 aar 的文件目录结构，我们可以近似得出结论：aar 是一个有特定格式的 zip 文件，且必须解压后才能使用。

事实上后续的一些验证能证明这个结论。

引入和下载依赖

Gradle 引入依赖我们可能再熟悉不过了：在Dependencies这个节点中，加入implementation/api/compileOnly等指令即可。这些指令在 gradle 的世界中被称之为Configurations一开始我并不知道为什么要用这个名字来命名他们。直到我后来看了 gradle 相关的源码之后，才确定，一个指令真的是代表了一种配置 —— 你使用implementation和compileOnly 引入相同的依赖，他们的行为是不一致的，这就是这两者被定义成不同配置的原因。至于里面的区别，我们后续再讲。想提前了解的同学可以移步官网传送门：