JS異步編程有哪些方案?為什么會(huì)出現(xiàn)這些方案?
關(guān)于 JS 單線程、EventLoop 以及異步 I/O 這些底層的特性,我們之前做過了詳細(xì)的拆解,不在贅述。在探究了底層機(jī)制之后,我們還需要對(duì)代碼的組織方式有所理解,這是離我們最日常開發(fā)最接近的部分,異步代碼的組織方式直接決定了開發(fā)和維護(hù)的效率,其重要性也不可小覷。盡管底層機(jī)制沒變,但異步代碼的組織方式卻隨著 ES 標(biāo)準(zhǔn)的發(fā)展,一步步發(fā)生了巨大的變革。接著讓我們來一探究竟吧!
回調(diào)函數(shù)時(shí)代
相信很多 nodejs 的初學(xué)者都或多或少踩過這樣的坑,node 中很多原生的 api 就是諸如這樣的:
- fs.readFile('xxx', (err, data) => {
- });
典型的高階函數(shù),將回調(diào)函數(shù)作為函數(shù)參數(shù)傳給了readFile。但久而久之,就會(huì)發(fā)現(xiàn),這種傳入回調(diào)的方式也存在大坑, 比如下面這樣:
- fs.readFile('1.json', (err, data) => {
- fs.readFile('2.json', (err, data) => {
- fs.readFile('3.json', (err, data) => {
- fs.readFile('4.json', (err, data) => {
- });
- });
- });
- });
回調(diào)當(dāng)中嵌套回調(diào),也稱回調(diào)地獄。這種代碼的可讀性和可維護(hù)性都是非常差的,因?yàn)榍短椎膶蛹?jí)太多。而且還有一個(gè)嚴(yán)重的問題,就是每次任務(wù)可能會(huì)失敗,需要在回調(diào)里面對(duì)每個(gè)任務(wù)的失敗情況進(jìn)行處理,增加了代碼的混亂程度。
Promise 時(shí)代
ES6 中新增的 Promise 就很好了解決了回調(diào)地獄的問題,同時(shí)了合并了錯(cuò)誤處理。寫出來的代碼類似于下面這樣:
- readFilePromise('1.json').then(data => {
- return readFilePromise('2.json')
- }).then(data => {
- return readFilePromise('3.json')
- }).then(data => {
- return readFilePromise('4.json')
- });
以鏈?zhǔn)秸{(diào)用的方式避免了大量的嵌套,也符合人的線性思維方式,大大方便了異步編程。
co + Generator 方式
利用協(xié)程完成 Generator 函數(shù),用 co 庫讓代碼依次執(zhí)行完,同時(shí)以同步的方式書寫,也讓異步操作按順序執(zhí)行。
- co(function* () {
- const r1 = yield readFilePromise('1.json');
- const r2 = yield readFilePromise('2.json');
- const r3 = yield readFilePromise('3.json');
- const r4 = yield readFilePromise('4.json');
- })
async + await方式
這是 ES7 中新增的關(guān)鍵字,凡是加上 async 的函數(shù)都默認(rèn)返回一個(gè) Promise 對(duì)象,而更重要的是 async + await 也能讓異步代碼以同步的方式來書寫,而不需要借助第三方庫的支持。
- const readFileAsync = async function () {
- const f1 = await readFilePromise('1.json')
- const f2 = await readFilePromise('2.json')
- const f3 = await readFilePromise('3.json')
- const f4 = await readFilePromise('4.json')
- }
這四種經(jīng)典的異步編程方式就簡(jiǎn)單回顧完了,由于是鳥瞰大局,我覺得知道是什么比了解細(xì)節(jié)要重要, 因此也沒有展開。不過沒關(guān)系,接下來,讓我們針對(duì)這些具體的解決方案,一步步深入異步編程,理解其中的本質(zhì)。