6.9 KiB
目录
- 简述
- Gradle 构建流程
- Gradle Plugin
- Gradle 构建优化
- App 构建流程
简述
Gradle 构建流程
Gradle 的执行分为三大阶段：Initialization -> Configuration -> Execution。Initialization 阶段主要目的是初始化构建，它分为两个子过程，一个执行 Init Script，另一个是执行 Setting Script。Init Script 会读取全局脚本初始化一些通用的属性，比如 Gradle User Home 目录、Gradle version 等，一般情况下我们不会动这个文件。Setting Script 更常见，它初始化了一次构建所参与的所有模块。
Configuration 阶段会加载项目中所有模块的 build.gradle 文件，根据脚本创建对应的 Task，然后根据 Task 的依赖关系生成有向无环图。在每执行完一个 Project 的 build.gradle 文件后，都会回调每个 build.gradle 文件中配置的 project.afterEvaluate{} 函数。生成任务图的过程也可以通过 gradle.taskGraph.whenReady 来进行 hook。
Execution 阶段才真正进行任务的执行。Gradle 会按照 task graph 中的依赖关系执行每一个任务，对于任务的执行前后也可以添加 hook 函数。项目中我也通过对 assembleRelease 进行 hook，在它执行完把生成的 release Apk 复制到指定目录。
可以在项目中，使用 build --scan 来进行性能分析，查看这三个阶段做了哪些事情以及耗费了多少时间。
Gradle Plugin
起初呢，是因为有一个需求就是，我们的 App 因为权限问题被警告了，组长就希望我能找出 app 模块及其依赖的第三方库里面的权限信息。首先我的思路就是先找出项目中的 Manifest 文件，在正则匹配出权限就行了。对于本地工程，这个很好做，可以直接通过 Variant 直接拿到 Manifest 文件，写个脚本在根目录的 subprojects 跑一遍就可以了。但是对于第三方库就没办法了。这时候我就想到，在 Apk 打包的时候有一个 MergeManifest 的过程，这个时候 Gradle 是肯定知道所有 Manifest 的，然后就去看一下 Gradle 源码是怎么做的。其实呢是在 ProcessApplicationManifest 这个 Task 来做的，Manifest 是放在 VariantData 的 ArtifactCollection 里面的。然后我就把它封装成一个 Task 命令行调用就可以拿到所有权限信息了。
考虑到后面可能还会有一些类似的需求，于是我就写了一个插件。我觉得这是一个非常好的开端，之所以当初组长找到我做这件事是因为我之前在组内分享了 Gradle 的相关知识，包括 Gradle 的构建流程、Gradle 的核心概念 Task 以及利用 Transform API 结合 AspectJ、ASM 进行自动化埋点等。这对我来说呢是一个正向激励，后面我也越来越会做更多的分享。
后面呢，我还在 Plugin 里面添加了自动 TinyPng 资源压缩，考虑到我们的 minApi 19，又做了全量的 png 转 webp 这一步的压缩是包含第三方库里面的图片的，使用的是 Google 开源的 cwebp 工具。通过 png 转 webp，减少了 5.7M，再来做包体积优化时，发现存在不少的重复资源，也就是遍历生成 MD5 值进行比较，减少了 133 kb；通过配置 resConfigs 只保留 zh、en 减少了 1.1M。
再之后，基于做了 MethodTracker，简单使用一个注解就可以查看方法耗时，还有基于 Choreographer 的 FPS 检测。这里当时是遇到一个问题的，我们知道插件里面的类，在外部模块是不能访问到的，然而我这里的注解以及 FPSDetector 都是需要在 app 模块使用的，这时候我就看了 JW 的 Hugo 的实现，它也是基于 AspectJ 做的方法耗时，因为它的注解也是可以在 app 模块使用的，看源码发现它不过是是把这个注解放到外部一个远程库的，然后在插件里面进行依赖的。Hugo 仅仅只有四个类，却有 7k 多的 Star，所以说有时候不能被表面吓着，以为会很麻烦其实很简单。
在我写 Plugin 的之后，滴滴开源了 Booster，然后我就按照它的架构方式，使用 SPI 去自动注册 Task，这就不需要每新增一个 Task 都要去 apply 方法进行注册了。当时是用 Java 写的，也都切成了 Kotlin，并且也用的 kts 构建。
Gradle 构建优化
首先在测试优化效果时，不包含 Configuration 阶段的时间，所以实际上优化程度更高。但是一般来说并不会频繁更新依赖，所以去掉了 Configuration 阶段。结果就是：
| 全量编译 | 代码增量 | 资源增量 | |
|---|---|---|---|
| 优化前 | 1m 59s | 27s | 8s |
| 优化后 | 1m 1s | 9s | 10s |
首先就是使用较高版本的 Gradle 和 Android Gradle Plugin，在项目中，我主导了 Gradle 从 4.10.1 到 6.5.1 的升级。前面说过，Gradle 的构建分为三个阶段，分别是 Initialzation、Configuration 和 Execution 阶段。下面我就从这三个阶段来着手优化。
在 Initialzation 阶段，可以在 gradle.properties 中开启构建缓存和并行构建，也可以适当增加内存分配；
在 Configuration 阶段，避免使用动态版本和快照版本，动态版本即 1.0.+ 这种方式，快照版本即 SNAPSHOT，这两种方式都会迫使 Gradle 链接到远程仓库检查是否有依赖更新，默认有效期是 24h。我在项目中就发现一个友盟的 analyze 库使用了动态版本，然后就改为固定版本号；然后就是调整 repo 顺序并过滤请求，也就是把内部的 maven 仓库放在最前面，因为 Gradle 在查找远程库时，是串行查询所有 repo 中的 maven 地址的，直到找到可用的依赖，所以应该把最快和最高命中率的仓库放在前面。同时，在 Gradle 5.1 开始，可以指定特定 repo 下载特定的包名的依赖，然后我就在我们内部的 maven 库过滤 com.ehi 的依赖。这一操作能有效的减少 Configuration 阶段的时间；然后就是减少不必要的 Plugin，可以通过 build-scan 扫描项目中用到了哪些 Plugin，我在项目中发现我们 app 模块使用了一个 Google 的 osdecetor 的插件，但是搞了好久也没发现是哪里引入的，我怀疑是无良第三方库里面的，但是可惜一直没解决这个问题。
在 Execution 阶段，可以通过 -x 跳过不需要的 Task。我是在自己的 AS 里面配置 -x test -x lint 过滤掉 Test 和 Lint 相关的 Task，并且配置了一个 -PdevBuild 参数，这样测试小伙伴在 Jenkins 打 Debug 时也能享受这种收益，除此之外，我还会根据这个参数来关闭 AAPT2 自带的 png 压缩和 png 的合法性检查、关闭多 abi 和多 density 的构建以及通过 resConfigs 来最小化使用资源文件。resConfigs 不仅可以减少包体积，在 debug 时可以选择只构建中文简体和 xxhdpi 的资源。
App 构建流程
