转载请保留原文链接：/zzx023/article/details/89842503
微信小游戏的环境与正常web浏览器的环境相似，但很多细节上会有所不同，同时也存在很多限制。因此微信小游戏平台下的一些优化手段需要单独拿出来，一些方案的思路会借鉴H5游戏的方案。
这里首先分享一下wx-downloader的优化，如果对于目前游戏的加载速度以及首场景打开的速度不满意的话，这个优化应该会有一些帮助。
Cocos Creator通过wx-adapter与微信小游戏进行的适配。对于一些重度游戏来说，小游戏4M首包+4M分包，总共8M的空间很难完全放下所有的资源。因此会使用到远程加载资源。参考：小游戏环境的资源管理
小游戏远程加载资源这个功能本质上即是使用微信的下载api对资源进行下载并加载的过程。接口函数为wx-downloader.js中的downloadRemoteFile方法，这个函数中使用了wx.downloadFile以及wx.saveFile这两个API
坑爹的地方就来了，注意wx.saveFile这个API，这个API虽然是异步执行的，但是它的开销相当的大，不亚于一个同步执行的复杂函数。
我们可以看到在creator2.0.9之前的wx-downloader中这一块的代码。
在下载文件到临时目录后，通过wx.saveFile将文件保存到缓存中。这里有个问题，就是我们的download请求在微信小游戏平台上最大是10，也就是说当需要下载的文件数很多时，就有可能同时调用10次wx.saveFile。这就又进一步大大的加剧了这一部分的开销。导致首场景加载的速度变得很慢。
接下来我们再看Cocos Creator2.0.9版本中，wx-downloader里面对于这一块的处理：
这里改成不直接调用wx.saveFile，改为了一个cacheAsset的函数，再看一下cacheAsset方
法：
这里改为了下载成功后，将临时目录的路径存到一个数组中，通过setTimeout，每间隔一段时间调用一次wx.saveFile缓存文件。这样的话就可以避免在同一时间多次调用wx.saveFile，从而造成额外的开销以及卡顿。
因此，如果你用的是creator2.0.9一下的版本，如果项目在加载资源时耗时比较长的话，可以尝试升级到2.0.9版本，或者是使用2.0.9的wx-downloader
但实际项目使用的过程中，我们会发现，当需要远程加载的文件数量多，且其中有一些较大的文件时，2.0.9的这个优化效果并不是很显著。
所以关于wx-downloader.js的优化并没有结束。
我们还有进一步的，更极致的优化方法。
在看最终的优化方案前，我们先看一组测试数据：
可以看到android下使用image下载图片资源的速度是最快的，ios下使用download下载资源的速度是最快的。相比较之前download+saveFile的效率都会有极大的提升。
因此我们可以找到一个比较极致的优化方案，肉戏来了：
按照不同的平台我们进行不同的处理
在Android平台的微信小游戏下：
图片资源通过Image去下载，不使用wx提供的download接口，下载完成后直接使用。后续通过downloadFile异步下载一次，下载完成后通过异步进行saveFile非图片的资源通过download下载，然后异步缓存到目录
iOS平台的微信小游戏下：通过download下载下来后先试用，后续通过异步的方式去缓存文件。
需要注意的是，异步缓存图片不要像上面那样通过settimeout来做，可以通过回调的方式，缓存完一个文件后再去缓存下一个文件。 另外，文件的目录尽量不要太深，也不要太多。减少不必要的mkdir的浪费。
对于大型重度的微信小游戏来说，在实际项目中，首场景加载的速度从原来的20s，优化到了5s。提升非常的恐怖，同时也证明了我们这个优化思路没有任何问题。
如果觉得《Creator 2.0.x 微信小游戏加载优化（一）：定制wx-downloader》对你有帮助，请点赞、收藏，并留下你的观点哦！
