我们在做很多学习或者游戏类的小程序的时候，经常会有一个场景，在正式进入学习之前，把所有需要的音频图片等资源下载好，这样在学习过程中，会有一种近乎离线学习的体验。这是学习产品中很重要的一个环节。这里总结一下，如何实现一个相对完善的资源加载环节。
我们假定会有100个左右的图片音频下载。
1.下载并发限制
如果我们一次性发100个下载请求，小程序毫无疑问会崩掉。按照官方文档小程序一次性下载的最大数量为10个。我们把下载请求统一控制，使用一个封装后的下载接口。在这个接口内部维护一个下载队列和等待队列，来保证同时在进行的请求不超过某个数量。这样只需要简单的替换接口，业务逻辑不需要做任何处理，也不需要再关心并发问题。
2.失败处理
对于100个左右的请求数量，在c端用户复杂的网络和设备条件下，某几个请求失败，是一个大概率事件。需要对这种情况有所准备，给予用户友好的提示或者退出到上一页。
3.缓存策略
如果我们下载失败了，重新进入环节，重新拉取新的数据，重新去下载这100个请求，会有很大的问题：一个是下载量没有减少，一个是下载失败的概率也没有减少，一个是用户等待的下载时间没有减少。使用缓存可以解决这几个问题，在全局的下载请求接口中，按需给所有可能的下载请求加上缓存。这样如果一个资源下载失败或者重新进入学习，重新进来下载时，之前已经下载好的文件，不用再次下载，直接拿到之前已经下载好的临时地址，可以保证是从上次下载到的地方去接着下载。 要注意的是，如果在某些业务场景下，接口每一次拿到的资源地址后面的参数不一样，但其实资源是一样的，可以以请求url问号之前的部分来当做缓存的key。这样即使后面的参数不一样，也可以被识别为同一个资源。
4.setData节流
在加入缓存之后，用户再一次进入一个环节的时候，因为所有的资源都已经下载好，导致进度条更新过快，一秒钟之内进度条可能更新上百次，不断的setData，会引起新的性能问题。所以进度条的更新需要加节流操作。
5.超时与重试
小程序的下载接口其实并不是很稳定，有可能同一个资源这一秒下载不好，隔一秒钟再去下载，它就可以顺利下载下来。在下载失败之后，隔一秒钟之后重试下载，可以很大程度上提高下载的成功率。同时要缩短一下超时时间，从后台日志记录中，分析用户的下载用时，将下载超时相对缩短一点，并且增加重试机制。可以大大的提高下载的成功率。
6.允许下载失败，使用原始地址
使用下载好的临时地址的目的，是为了保证用户学习中的流畅性。但也不能为了流畅性而牺牲可用性。当我们多次重试依然没有下载成功的时候，可以考虑使用原始地址。对要下载的资源做分类，像某些提示音，背景图之类的资源，不是那么重要，下载不成功就使用原始地址。学习中的关键资源，则需要尽可能地保证下载好。
end
做了上面6点，资源下载这一块的用户反馈就可以降到很低。我们随机回访了一些后台监控到下载异常比较多的用户，他们在使用过程中几乎是没有感受到有下载失败。整个优化的效果很明显。
github地址：学习类产品100+资源加载体验优化