1. 前言
最近重拾了一个之前的Android项目，发现Gradle死活都无法编译成功。
明明前阵子都是好的，代码都没变，Android Studio配置都没变，咋就不行了呢，百思不得其解。
2. 分析
AS编译OOM
现象
如上图，gradle在进行mergeDexDebug时出现了OOM。
黎明前的黑暗
刚开始遇到这个问题的时候心情还是古井无波，毕竟作为一名老Android多少知道Gradle的一些莫名其妙的秉性，工程代码没改动，其他小伙伴同样的代码跑起来一帆风顺，于是乎怀疑是哪儿的配置错了，但不知道具体的地方，只能靠不厌其烦地尝试。
Clean大法好，重新Build，等待良久…
第一次尝试失败。
重启大法好，重启AS，等待良久…
第二次尝试失败。
切换JDK版本 11<==>17，引出了其它错误
第三次尝试失败。
祭出重磅武器：Invalidate Caches，重启AS，等待更久了…
第四次尝试失败。
开始怀疑无辜的Windows系统，重启之，机械地重复上述过程，等待…
第五次尝试失败。
此时对AS产生了嫌隙，下载最新版本AS，卸载旧版本，安装新版本，又是一顿操作…
第六次尝试失败。
看来AS没啥毛病，把矛头指向了Gradle本尊，删除了Gradle全部缓存，重新下载依赖，这可等得不是一般的久…
第七次尝试失败。
七次都能召唤神龙了，而问题的解决还遥遥无期。
在尝试的过程中也同步地进行其它分析：
查看AS进程的内存消耗，并没有达到OOM范围。
面向百度编程，面向Google编程，甚至和ChatGPT深入聊了好久，毫无成效。
网上一堆改动AS JavaHeap的配置，本项目里都有这些配置，不用做改动，
百思不得其解。
最终还是怀疑配置哪错了，但找不到只能想到回到盘古开天辟地的时代—重装系统，但此方法有违天和，于是退一步，用终极大法，不，它的前一步。
寻找系统还原点，可惜之前没给它设置还原点。。。
柳暗花明
天不亡我，正当准备痛下决心重装系统时，余光瞟见Build日志，发现了Gradle的提示：
项目里的gradle.properties没啥问题，真相很有可能就在Windows里的gradle.properties，颤抖的手打开了配置文件：
该文件在在个人目录下。
终于发现了端倪，原来不知道怎么就打开了org.gradle.jvmargs的配置，该配置参数明显比较低，于是注释掉整行。
迫不及待地编译…
果不其然，罪魁祸首就是它，问题解决了。
Gradle下载依赖超时
网上关于这个问题解决方式很多，比如科学上网，比如使用国内镜像源，如果这些方式都还不行，那么同样可以查看Window下的gradle.properties文件里关于代理的设置。
比如查看此处的代理是否生效，或者把代理注释掉。
下篇开始进入TS的世界，将会逐一分析Promise、SetTimeout等运行机制，相信你很快就会掌握JS/TS的运行时序。
