今天在github上下载了一个开源项目,然后AndroidStudio打开,报了以下错误:
Failed to open zip file. Gradle's dependency cache may be corrupt (this sometimes occurs after a network connection timeout.)
Re-download dependencies and sync project (requires network)
Re-download dependencies and sync project (requires network)
虽然系统给出了解决方案,但是点击它重新下载依然没有什么用处,百度搜了搜,发现几篇博客千篇一律给出的都不是本质上的解决方案。所以就有了这篇东西。
我知道有些人只想解决问题而不想管原因,所以先上解决方案:
解决方案
首先看一下你报错工程的gradlewrapper设置:
然后windows资源管理器打开
C:\Users\Administrator\.gradle\wrapper\dists
这个目录,直接删掉跟上面版本一致的文件夹,然后再次build工程,它会重新下载gradle,这个可能会耗时比较长,下载完毕后,问题就解决了。
为什么?
这里要扯到一个概念:gradlewrapper。
gradle作为一个构建工具,它本身的版本也是在不断迭代更新的,这就可能出现一种情况:一个团队合作的项目,每个人的电脑上gradle版本不一定相同,如果这样,由于升级带来的接口或实现不一致问题就会很严重(接口的破坏性升级会导致无法编译,实现不同则有可能带来隐患)。
为了避免出现这种情况,gradle采用了一种策略,就是gradlewrapper。每个工程下都有gradlewrapper配置文件,上面记录了这个工程使用的gradle版本,当有新成员下载了这个工程时,并不需要在电脑上手动安装gradle,而是在编译时由gradle-wrapper.jar根据gradle-wrapper.properties中的配置到gradle本地仓库去检索对应版本的gradle作为本工程的构建工具,如果本地仓库没有对应版本的gradle,则通过网络到远程仓库(gradle官方)去下载。
说到这里,大家肯定都明白了,上面提到的C:\Users\Administrator\.gradle\wrapper\dists
这个就是gradle本地仓库。而为什么会出现本文提到的错误?那是因为,本地仓库中对应版本的gradle文件压缩包出现了问题,可能是这个压缩包本身损坏了,也可能是这个压缩包是很早期的版本,过后被替换过,但又没换名字(后面这种是我自己猜测的,官方应该不至于干这种不专业的事吧。。。)。
为了验证我的猜测,我首先到本地仓库中找到对应版本的文件夹(本工程是4.6版本gradle),文件夹里面只有一个乱七八糟字符的文件夹(应该是某种规则的唯一编码),点进去,发现了以下两个文件:
然后我再回到本地仓库,对比一下完全没问题的4.4版本,发现内容是这样:
观察一下就能发现,4.4目录里那个文件夹就是把压缩包给解压了,那为什么4.6没有解压?我回到4.6的文件夹里用压缩工具手动解压那个安装包,在解压的最后,解压工具报了几个错误,不过还是解压出了一些文件。我们知道,gradle是用groovy来解压zip文件,如果这个过程中报错了,它会遵守事务,把残缺的解压结果删掉,所以就有了本文描述的错误。
ok。我把有问题的4.6改个名字,重新编译,这样跟删除是一个效果,目的是看看新下载的文件跟老的有什么区别。
看到区别了么?新的比老的大一些,至于是不是老的在传输过程中受损那就不得而知了。
最后,我用解压工具解压这个新压缩包,也并不会报任何错误。
这才是真正解决了问题。