1.build ios
2.build oppo，build结束之前，观察git，就会必现，目前看来build结束后好像就对了
可能修复的是其他姿势？我发现的姿势是
1.build ios
2.build oppo，build结束之前，观察git，就会必现，目前看来build结束后好像就对了
另外build oppo 也有一个必现bug，打出来的rpk会越来越大，因为没有清理logo和配置文件
第一个版本大概2个月不到 但是一直持续维护更新到了现在
谢谢反馈，“每次build oppo版本，包体会越来越大”问题，是勾选了md5 导致。目前 提供 rpk审核时，先删掉构建目录 quickgame 重新构建。后续版本会修复
mark.
为什么我还是卡在引导页了？？全屏都是透明黑的，没法操作了。。。
iphone 7
抱歉 修复版本还没全量发布
非常抱歉，这里是我们考虑用户的使用场景不够全面，我们确实有注意到同时写文件时会导致资源锁住，导致报错，但我们设想用户使用API清理缓存资源会是在场景启动之前，不会和writeCacheFile冲突，所以在清理缓存资源的地方，都直接使用了同步写文件的方式来提高效率，确实是存在这个问题，后续会进行完善。
另外，拜读你的修改之后发现：
1.
简单的修改这里会导致另一个问题，因为writeCacheFile是延迟一段时间写回文件中，所以有可能缓存已经被删除了，但文件还没写进去，如果这时小游戏因某种原因意外关闭，会导致缓存列表中存在，但实际缓存已经被删除的情况，请知悉
2.
这个地方使用exists又查询了一次，实际上这个做法也是2.0.9之前的做法，2.0.10之所以使用一个文件来保存缓存列表，目的就是为了减少微信API access的使用，提升效率，所以这里不建议再用exists检查一次哦。
这个地方之所以没有做等待，是因为写文件是以1s一次的速度写入的，而之前做过相关测试，即使在很慢很慢的Android机型（价值￥500）上，write一次的时间也不到40ms，所以没有做更多的检查，当然这里为保险起见，之后也会做互斥的检查
查找之后发现，相同请求的处理是在cc.loader.load中做的检查
如果有发现相同url的请求已经存在则复用，所以理论上应该没有这个情况发生，请问你那边能复现资源重复下载的情况么
3赞
mark
感谢细心回复
cleanCache是在内部某些情况下会调用到，例如registerFailHandler
确实，这里会导致问题，所以我才会去再次判断缓存资源是否实际存在 [quote=“EndEvil, post:28, topic:79251”]
这个地方使用exists又查询了一次，实际上这个做法也是2.0.9之前的做法，2.0.10之所以使用一个文件来保存缓存列表，目的就是为了减少微信API access的使用，提升效率，所以这里不建议再用exists检查一次哦。
[/quote]
而且这个写法也是为了保证那些已经出现问题的玩家 可以顺利的加载资源，包括其他开发者，可能也有部分用户的cacheFile文件已经出现了问题，我暂时没想到既保证效率又保证兼容的做法
这个是确实存在的，因为我实际测试中，发现了同一个url走到了download里面，原因我其实之前也说了，下载完成之前，再次请求，这个this._cache是不会存有这个url的，对于大一点资源，更容易复现
如果想最大化程度减少微信API access的次数，同时保证最强壮的稳定性，我建议可以参考看一下我附件里最新的代码【也merge了2.1.12的几行改动】，我直接在handle里先判断一次缓存是否存在，只有在极个别异常情况才会多走一次本地文件判断
因为安装2.0.10版本的代码，读取缓存资源之前，还是去读取了一次本地路径，确定本地路径没有后，如果发现缓存文件列表有这个文件，那么读取文件。
那么我新版本的代码，保持了一致的API access的次数，并且保证了使用cache文件的安全性，并且可以兼容已经出现问题的玩家
wx-downloader.js.zip (5.1 KB)
1赞
在下载完成之前，cache里面已经会有了的，在flowIn请求的时候，item就会被缓存着用来复用，这个问题可能是其他地方导致的，我尝试复现一下
嗯，看你的最新改动里面，access保持了一致，你可以这么改，等之后看机会再提升一下效率吧
这个是我的疏漏了，十分抱歉
更新2.0.10后，我们也有很多玩家反馈加载卡住的情况，辛苦各位大佬给出完整解决方案
下载网络图片，失败超过10次就不会再去下载东西了，所以玩家觉得卡住了
soga，有可能，我并没有去跟踪外部代码，但是内部调用时 确实有重复的url，我优化之前专门加了日志跟踪
没太懂10次是啥意思呢，下载不是业务逻辑自己控制的么 包括retry
我们已经更新了 麻烦试一下呢