2022年8月9日,周一
最近由于项目的热更新逻辑需要修改,由于热更新逻辑之前测过将近1年都没去动它,所以又弄了一个测试工程发布win32进行测试,碰到了一个问题就是热更开始之后就卡住了,过了很久,提示错误
AssetsManagerEx : Fail to download version file, step skipped
看这个提示是下载version文件失败,通过浏览器访问没有问题,能访问到文件,于是我好一顿找,也没有找到原因,晚上回家在家里的电脑上把测试工程跑起来,发现热更新没有问题,第二天来公司换了一个web服务器,换成了nginx还是不行。弄到了中午还是不行,我就郁闷了,果断回家把家里的电脑拿过来完成了剩余的开发工作。热更新在demo中测试通过后,集成进项目测试,很是漫长的测试过程,就这样开发完测试完就到了2022年8月28号(周日)凌晨4点多了(居然弄了一个通宵)。
周一过来想着把这个问题解决掉,我在测试工程中添加了一个测试按钮,通过http去下载version.manifest,起初是在web上测试的,碰到了nginx的跨域问题,想着估计win32上下载失败可能是跨域问题,在处理nginx的跨域问题的时候,又碰到了几个问题
1.nginx都已经关闭了还是能够访问到内容
问题是启动了多个nginx进程
tasklist /fi "IMAGENAME eq nginx.exe"
,打印出当前的nginx进程
taskkill /f /pid 15372
,杀掉进程
2.nginx跨域设置修改后,发现没有生效,原因是由于浏览器缓存的事情,清除了浏览器缓存后,跨域修改生效了
#user nobody;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name 127.0.0.1;
add_header Access-Control-Allow-Origin *; # 允许跨域设置
location / {
root D:/htdoc;
}
}
}
解决了跨域问题之后,在win32上测试热更新,还是卡在下载version文件失败,我就郁闷了,不是这个事情,点了一下测试按钮通过http下载version文件
看到192.168.8.104:65368
这个ip和端口,这是个什么鬼,104不是我们的打包机吗,为什么请求会访问104这个ip,回想了一下,可能是之前设置的cmd代理,通过echo %http_proxy%
命令发现机器上确实存在这个环境变量配置
于是又是一顿查怎么去掉这个配置,后来发现是在环境变量里面
删除了这个环境变量配置,再测试发现ok了
前前后后,弄这个问题浪费了好长时间,最后解决了还是挺开心的
总结:
怀疑问题的方向不对,导致浪费了很多时间,起初我怀疑是xampp里面apache的问题,其实就是在win32里面http访问失败,如果早些单独测试win32里面的http访问可以直接定位问题直接找到请求被重定向到了192.168.8.104:65368,由于怀疑方向不对导致一直困扰在为啥热更新中下载version文件失败,从而怀疑web服务器的配置。
还是那句话确定问题->解决问题,中的确定问题很重要,如果没有确定问题,很有可能就会导致解决问题的方向上出现变差,导致会浪费很多没必要浪费的时间