這篇文章主要介紹了淺談關於JS下大批量異步任務按順序執行解決方案一點思考，小編覺得挺不錯的，現在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧
前言
最近需要做一個瀏覽器的, 支持大體積文件上傳且要支持斷點續傳的上傳組件, 本來以爲很容易的事情, 結果碰到了一個有意思的問題:
循環執行連續的異步任務, 且後一個任務需要等待前一個任務的執行狀態
這麼說可能有點空泛, 以我做的組件舉例:
這個組件本意是爲了上傳大體積視頻, 和支持斷點續傳, 因爲動輒幾個G的視頻不可能直接把文件讀進內存, 只能分片發送(考慮到實際網絡狀態, 每次發送大小定在了4MB), 而且這麼做也符合斷點續傳的思路.
組件工作流程如下:
- 選定上傳文件後, 從H5原生upload組件裏取得文件的blob對象 (同步)
- 通過blob對象的slice方法把文件切片 (同步)
- 新建一個Filereader對象, 通過Filereader的readAsArrayBuffer方法讀取步驟2中生成的slice (異步)
- 如果步驟3的buffer讀取成功(通過監控Filereader的onload事件), 則ajax發送步驟3中的buffer (異步)
- 如果ajax發送成功, 且服務器儲存完成, 會向客戶端發回一個成功狀態碼, 如果ajax的response中存在這個狀態碼, 則進行下一次切片發送 (異步)
從組件工作流程可以發現, 3,4,5中的連續異步任務, 必須要按順序進行, 且每一步任務間存在相互依賴, 最後還要對這些步驟進行多次循環.
如果只是處理單次的連續異步任務, 通過promise鏈式調用即可, 但是要循環執行這樣的連續異步任務讓我想了很久.
後來google了很久也沒發現解決方案, 無奈下閉門造車了2天, 想出了3套方案, 權當拋磚引玉, 希望各位給出更好建議
3套方案的核心思想相同, 類似觀察者模式, 來控制循環的進行, 區別在於循環的實現不同, 實際上這3套方案也是我自我否定的過程, 不斷思考更好的方法, 整個組件代碼略長, 在此只挑出問題相關部分, 且省略錯誤處理部分
方案1
依然以上傳組件舉例
//循環狀態標記,0爲初始狀態,1爲正常,2爲出錯
let status = 0;
/* 新建Filereader,讀取文件切片,返回一個promise
* 把讀取成功的arraybuffer通過reslove傳出
*/
const createReader = ()=> {
return new Promise ((reslove, reject)=> {
let reader = new Filereader();
...
reader.onload = ()=> {
reslove(reader.result)
}
reader.onerror = ()=> reject()
})
}
// ajax發送createReader方法讀取到的Buff
const createXhr = ()=> {
const xhr= new XMLHttpRequest();
return new Promise ((reslove, reject)=> {
...
xhr.onreadystatechange= ()=> {
...
//如果readyState == 4,status == 200且服務器的狀態碼存在,更改全局標記爲1
status = 1;
reslove()
}
})
}
//每一輪循環開始前都檢查一次全局狀態標記
const checkStatus = ()=> {
...
if (status == 1) {
loop()
}
}
//循環過程的鏈式調用
const loop = ()=> {
createReader().then(()=> createXhr()).then(()=> checkStatus());
}
方案1是基於初見問題的'想當然'解決方法, 碰到異步任務就promise, 這樣的循環長鏈調用, 寫法不優雅, 且錯誤調試異常麻煩, 更爆炸的是因爲閉包問題, 在循環執行中這些內存難以回收, 內存消耗急劇增加, 只能等待循環執行完成
方案2
徹底引入觀察者模式, 構造一個簡單的EventEmitter, 通過event.on, event.emit的形式完成循環
//模仿node.js的EventEmitter
class EventEmitter {
constructor() {
this.handler = {};
}
on(eventName, callback) {
if (!this.handles){
this.handles = {};
}
if (!this.handles[eventName]) {
this.handles[eventName] = [];
}
this.handles[eventName].push(callback);
}
emit(eventName,...arg) {
if (this.handles[eventName]) {
for (var i=0;i<this.handles[eventName].length;i++) {
this.handles[eventName][i](...arg);
}
}
}
}
let ev= new EventEmitter();
...
//監聽createReader事件,如果讀取buffer成功就觸發toajax事件來上傳切片
ev.on('createReader', ()=> {
let reader = new Filereader();
...
reader.onload = ()=> {
ev.emit('toajax')
}
})
//監聽toajax事件,如果上傳成功,就觸發createReader事件開始讀取下一切片
ev.on('toajax', ()=> {
let xhr= new XMLHttpRequest();
...
xhr.onreadystatechange = ()=> {
//如果readyState == 4,status == 200且服務器的狀態碼存在
ev.emit('createReader')
}
})
方案2徹底貫徹'事件', 代碼語義更自然, 錯誤調試也比方案1更爲簡單, 但內存泄漏問題依然存在
方案3
方案3, 迴歸方案1的狀態管理方式, 但是通過setInterval方法來實現循環.
//全局狀態標記
let status = 0;
//讀取切片
const createReader = ()=> {
let reader = new Filereader();
...
reader.onload = ()=>status = 1
}
//上傳切片
const createXhr = ()=> {
let xhr= new XMLHttpRequest();
...
xhr.onreadystatechange = ()=> {
...
//如果readyState == 4,status == 200且服務器的狀態碼存在
status = 2
}
}
/* 設置一個間隔時間極短的計時器,根據status決定下一步的任務,
* 上傳完成後定時器自動清除自己
* 另外有判斷文件是否上傳完成的方法,這裏就不寫了
*/
let timer = setInterval(()=> {
if (status == 2) {
createReader();
} else if (status == 1) {
createXhr();
} else if (status == 3) {
clearInterval(timer);
}
},10)
不可否認, 方案3看上去很low, 如果追求極致的執行效率, 方案3無疑是最蠢的辦法, 但是方案三相當於把異步任務轉化爲了同步任務, 語義簡潔, 且沒有上面2種方法的內存泄漏問題.
方案3本質上是把while (true)改寫成了setInterval, 因爲while true會阻塞線程, 各種異步事件的回調也會被一同阻塞, 所以選擇了setInterval
總結
當時還嘗試過使用Object.defineProperty方法給status 綁一個set方法, 通過每次給status set新值的時候來判斷循環, 但是發現這樣做依然像是鏈式調用, 一樣存在內存泄漏問題, 這裏就不寫了.
說實話, 這3個方案感覺都有很大缺陷, 甚至可以說粗淺, 本人入坑前端2個月, 眼界有限無可避免, google無門後, 想到社區來求助, 希望老哥們提供更好的思路.
最後掛上文中提到的上傳插件, 因爲感覺還有缺陷就沒封裝, 只做了個demo(前端上傳插件用的方案2, 後端拼接文件切片用的方案3)
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持神馬文庫。