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配置。
项目里的gradle.properties没啥问题,真相很有可能就在Windows里的gradle.properties,颤抖的手打开了配置文件:
该文件在在个人目录下。
终于发现了端倪,原来不知道怎么就打开了org.gradle.jvmargs的配置,该配置参数明显比较低,于是注释掉整行。
迫不及待地编译…
果不其然,罪魁祸首就是它,问题解决了。
Gradle下载依赖超时
网上关于这个问题解决方式很多,比如科学上网,比如使用国内镜像源,如果这些方式都还不行,那么同样可以查看Window下的gradle.properties文件里关于代理的设置。
比如查看此处的代理是否生效,或者把代理注释掉。
下篇开始进入TS的世界,将会逐一分析Promise、SetTimeout等运行机制,相信你很快就会掌握JS/TS的运行时序。