本篇文章給大家?guī)淼膬热菔顷P于微信小程序的10個請求并發(fā)限制的優(yōu)化消息！！！有一定的參考價值，有需要的朋友可以參考一下，希望對你有所幫助。

這可能是一個冷消息，所以標題比較勁爆。

小程序并發(fā)限制由來已久，從剛發(fā)布時的 5 并發(fā)，到后來的 10 并發(fā)，同時發(fā)出的請求數(shù)若超出這個限制則將被殘忍拋棄，由此催生了很多開發(fā)者在自己的項目中造了「請求排隊」的輪子。然而事實上，早在一年半以前，app開發(fā)

該限制就被微信官方取消。

10 個請求的并發(fā)限制

關于并發(fā)限制，微信開發(fā)者文檔中是這么寫的：

這一限制的意思是在同一時刻， wx.request、wx.uploadFile、wx.downloadFile 加起來的并發(fā)總數(shù)不能超出 10 個。

至今，仍有很多開發(fā)者一直遵守著這個規(guī)則。

許多人在寫業(yè)務的時候小心翼翼地維護著請求數(shù)。為了將請求數(shù)控制好，特地將一些并行請求改為串行，或者引入請求隊列來維護小程序請求。

這部分資深開發(fā)者為了遵守這一規(guī)則所花的功夫，多少反映出了早年他們在面對數(shù)額超出后請求被殘忍拋棄時的無奈。

附小程序基礎庫版本 1.3.0 的控制臺報錯:

時至今日，仍有開發(fā)者在討論解決小程序并發(fā)限制的方法

被忽略的消息

實際上，微信在 2017 年 7 月的基礎庫 1.4.0 版本升級中就做了優(yōu)化，對超過并發(fā)限制的請求做了隊列處理，只是還有很多開發(fā)者并不知道這一消息。

從嚴格意義上來說，此次優(yōu)化并沒有完全解除原有的并發(fā)限制。目前同時處理請求的上限仍是 10 個，但在 10 個以外的請求會排隊，當前面有請求完成的時候，隊列中的請求按順序發(fā)送并處理，*不會像之前那樣直接將超出 10 個的請求丟棄。

附件小程序基礎庫 1.4.0 更新日志（部分）：

現(xiàn)在，我們終于可以忽略請求并發(fā)限制，愉快地發(fā)送請求了。畢竟請求都是可以都發(fā)送出去的，只不過在效率上會比無并發(fā)限制的情況慢一些。

發(fā)送請求的正確姿勢

如上文所說，微信小程序是在基礎庫 1.4.0 版本中加入對超過并發(fā)限制的請求做隊列處理優(yōu)化的，在 1.4.0 以下的版本中超出并發(fā)部分的請求會被丟棄。

據(jù)微信官方數(shù)據(jù)，截止到 2018 年 12 月，1.4.0 版本以下用戶占比大約是 0.04%，雖然目前小程序很少會兼容到這么低的版本，但是對一些有特殊需要的小程序也要注意基礎庫的差異。

另外要注意的是小程序并發(fā)請求的排隊機制。當同時調用的請求超過 10 個時，小程序會先發(fā)起 10 個并發(fā)請求，超過 10 個的部分按調用順序進行排隊，當前一個請求完成時，再發(fā)送隊列中的下一個請求。

附 20 個請求并發(fā)測試：

測試結果：

從圖中可以看到，前 10 個請求同時發(fā)出，而后面的請求的起始點，對應了前面某個請求的結束點，可以反映出請求的排隊行為。

這意味著，在并發(fā)請求很多的時候應該做好排隊策略，按請求的重要程度和響應時間調整調用順序，如果遇到請求的響應很慢的情況，可以考慮做 timeout 處理，以免大量等待，影響用戶體驗。

以上就是微信小程序的10個請求并發(fā)限制的優(yōu)化消息！！！的詳細內容，更多請關注沈陽網站建設其它相關文章！