我們在做很多學習或者遊戲類的小程序的時候，經常會有一個場景，在正式進入學習之前，把所有需要的音頻圖片等資源下載好，這樣在學習過程中，會有一種近乎離線學習的體驗。這是學習產品中很重要的一個環節。這裏總結一下，如何實現一個相對完善的資源加載環節。
我們假定會有100個左右的圖片音頻下載。
1.下載併發限制
如果我們一次性發100個下載請求，小程序毫無疑問會崩掉。按照官方文檔小程序一次性下載的最大數量爲10個。我們把下載請求統一控制，使用一個封裝後的下載接口。在這個接口內部維護一個下載隊列和等待隊列，來保證同時在進行的請求不超過某個數量。這樣只需要簡單的替換接口，業務邏輯不需要做任何處理，也不需要再關心併發問題。
2.失敗處理
對於100個左右的請求數量，在c端用戶複雜的網絡和設備條件下，某幾個請求失敗，是一個大概率事件。需要對這種情況有所準備，給予用戶友好的提示或者退出到上一頁。
3.緩存策略
如果我們下載失敗了，重新進入環節，重新拉取新的數據，重新去下載這100個請求，會有很大的問題：一個是下載量沒有減少，一個是下載失敗的概率也沒有減少，一個是用戶等待的下載時間沒有減少。使用緩存可以解決這幾個問題，在全局的下載請求接口中，按需給所有可能的下載請求加上緩存。這樣如果一個資源下載失敗或者重新進入學習，重新進來下載時，之前已經下載好的文件，不用再次下載，直接拿到之前已經下載好的臨時地址，可以保證是從上次下載到的地方去接着下載。 要注意的是，如果在某些業務場景下，接口每一次拿到的資源地址後面的參數不一樣，但其實資源是一樣的，可以以請求url問號之前的部分來當做緩存的key。這樣即使後面的參數不一樣，也可以被識別爲同一個資源。
4.setData節流
在加入緩存之後，用戶再一次進入一個環節的時候，因爲所有的資源都已經下載好，導致進度條更新過快，一秒鐘之內進度條可能更新上百次，不斷的setData，會引起新的性能問題。所以進度條的更新需要加節流操作。
5.超時與重試
小程序的下載接口其實並不是很穩定，有可能同一個資源這一秒下載不好，隔一秒鐘再去下載，它就可以順利下載下來。在下載失敗之後，隔一秒鐘之後重試下載，可以很大程度上提高下載的成功率。同時要縮短一下超時時間，從後臺日誌記錄中，分析用戶的下載用時，將下載超時相對縮短一點，並且增加重試機制。可以大大的提高下載的成功率。
6.允許下載失敗，使用原始地址
使用下載好的臨時地址的目的，是爲了保證用戶學習中的流暢性。但也不能爲了流暢性而犧牲可用性。當我們多次重試依然沒有下載成功的時候，可以考慮使用原始地址。對要下載的資源做分類，像某些提示音，背景圖之類的資源，不是那麼重要，下載不成功就使用原始地址。學習中的關鍵資源，則需要儘可能地保證下載好。
end
做了上面6點，資源下載這一塊的用戶反饋就可以降到很低。我們隨機回訪了一些後臺監控到下載異常比較多的用戶，他們在使用過程中幾乎是沒有感受到有下載失敗。整個優化的效果很明顯。
github地址：學習類產品100+資源加載體驗優化