JS本身是一门单线程的语言,所以在执行一些需要等待的任务(eg.等待服务器响应,等待用户输入等)时就会阻塞其他代码。如果在浏览器中JS线程阻塞了,浏览器可能会失去响应,从而造成不好的用户体验。幸运的是JS语言本身和其运行的环境(浏览器,Node)都提供了一些解决方案让JS可以“异步”起来,在此梳理一下相关的知识点,如果你读完之后有所收获,那更是极好的。
JS中每个函数都伴有一个自身的作用域(execution context),这个作用域包含函数的一些信息(eg.参数,局部变量等),在函数被调用时,函数的作用域对象被推入执行栈(execution context stack),执行完毕后出栈。当执行一些异步任务时,JS仅调用相应的api并不去等待任务结果而是继续执行后续代码,这些异步任务被浏览器或者Node交由其他线程执行(eg.定时器线程、http请求线程、dom事件线程等),完成之后这些异步任务的回调函数会被推入相应的队列中,直到执行栈为空时,这些回调函数才会被依次执行。
举个例子:
function main() {
console.log('A)
setTimeout(function display() {
console.log('B')
}, 0)
console.log('C')
}
main()
以上代码在Event Loop中的执行过程如下:
类似于setTimeout这样的任务还有:setInterval, setImmediate, 响应用户操作的事件(eg. click, input等), 响应网络请求(eg. ajax的onload,image的onload等),数据库操作等等。这些操作有一个统一的名字:task,所以上图中的message queue其实是task queue,因为还存在一些像:Promise,process.nextTick, MutationObserver之类的任务,这些任务叫做microtask,__microtask会在代码执行过程中被推入microtask queue而不是task queue__,microtask queue中的任务同样也需要等待执行栈为空时依次执行。
一个task中可能会产生microtask和新的task,其中产生的microtask会在本次task结束后,即执行栈为空时执行,而新的task则会在render之后执行。microtask中也有可能会产生新的microtask,会进入microtask queue尾部,并在本次render前执行。
这样的流程是有它存在原因的,这里仅仅谈下我个人的理解,如有错误,还请指出:
浏览器中除了JS引擎线程,还存在GUI渲染线程,用以解析html, css, 构建DOM树等工作,然而这两个线程是互斥的,只有在JS引擎线程空闲时,GUI渲染线程才有可能执行。在两个task之间,JS引擎空闲,此时如果GUI渲染队列不为空,浏览器就会切换至GUI渲染线程进行render工作。而microtask会在render之前执行,旨在以类似同步的方式(尽可能快地)执行异步任务,所以microtask执行时间过长就会阻塞页面的渲染。
上文提到setTimeout,setInterval都属于task,所以即便设置间隔为0:
setTimeout(function display() {
console.log('B')
}, 0)
回调也会异步执行。
setTimeout,setInterval常被用于编写JS动画,比如:
// setInterval
function draw() {
// ...some draw code
}
var intervalTimer = setInterval(draw, 500)
// setTimeout
var timeoutTimer = null
function move() {
// ...some move code
timeoutTimer = setTimeout(move, 500)
}
move()
这其实是存在一定的问题的:
在这种背景下,Mozilla提出了requestAnimationFrame,后被Webkit优化并采用,requestAnimationFrame为编写JS动画提供了原生API。
function draw() {
// ...some draw code
requestAnimationFrame(draw)
}
draw()
requestAnimationFrame为JS动画做了一些优化:
当然requestAnimationFrame存在一定的兼容性问题,具体可参考 can i use。
fs.readdir(source, function (err, files) {
if (err) {
console.log('Error finding files: ' + err)
} else {
files.forEach(function (filename, fileIndex) {
console.log(filename)
gm(source + filename).size(function (err, values) {
if (err) {
console.log('Error identifying file size: ' + err)
} else {
console.log(filename + ' : ' + values)
aspect = (values.width / values.height)
widths.forEach(function (width, widthIndex) {
height = Math.round(width / aspect)
console.log('resizing ' + filename + 'to ' + height + 'x' + height)
this.resize(width, height).write(dest + 'w' + width + '_' + filename, function(err) {
if (err) console.log('Error writing file: ' + err)
})
}.bind(this))
}
})
})
}
})
假设最初学JS时我看到的是上面的代码,我一定不会想写前端。这就是所谓的“callback hell”,而Promise把回调函数的嵌套逻辑替换成了符合正常人思维习惯的线性逻辑。
function fetchSomething() {
return new Promise(function(resolved) {
if (success) {
resolved(res);
}
});
}
fetchSomething().then(function(res) {
console.log(res);
return fetchSomething();
}).then(function(res) {
console.log('duplicate res');
return 'done';
}).then(function(tip) {
console.log(tip);
})
async await是ES2017引入的两个关键字,旨在让开发者更方便地编写异步代码,可是往往能看到类似这样的代码:
async function orderFood() {
const pizzaData = await getPizzaData() // async call
const drinkData = await getDrinkData() // async call
const chosenPizza = choosePizza() // sync call
const chosenDrink = chooseDrink() // sync call
await addPizzaToCart(chosenPizza) // async call
await addDrinkToCart(chosenDrink) // async call
orderItems() // async call
}
Promise的引入让我们脱离了“callback hell”,可是对async函数的错误用法又让我们陷入了“async hell”。
这里其实getPizzaData和getDrinkData是没有关联的,而await关键字使得必须在getPizzaData resolve之后才能执行getDrinkData的动作,这显然是冗余的,包括addPizzaToCart和addDrinkToCart也是一样,影响了系统的性能。所以在写async函数时,应该清楚哪些代码是相互依赖的,把这些代码单独抽成async函数,另外Promise在声明时就已经执行,提前执行这些抽出来的async函数,再await其结果就能避免“async hell”,或者也可以用Promise.all():
async function selectPizza() {
const pizzaData = await getPizzaData() // async call
const chosenPizza = choosePizza() // sync call
await addPizzaToCart(chosenPizza) // async call
}
async function selectDrink() {
const drinkData = await getDrinkData() // async call
const chosenDrink = chooseDrink() // sync call
await addDrinkToCart(chosenDrink) // async call
}
// return promise early
async function orderFood() {
const pizzaPromise = selectPizza()
const drinkPromise = selectDrink()
await pizzaPromise
await drinkPromise
orderItems() // async call
}
// or promise.all()
Promise.all([selectPizza(), selectDrink()]).then(orderItems) // async call
javascript中alert是Bom中的成员函数,alert对话框是模态的,具有阻塞性质的,不点击是不会执行后续代码的。js的阻塞是指在调用结果返回之前,当前线程会被挂起, 只有在得到结果之后才会继续执行。
如何优化async代码?更好的编写async函数:使用return Promise.reject()在async函数中抛出异常,让相互之间没有依赖关系的异步函数同时执行,不要在循环的回调中/for、while循环中使用await,用map来代替它
Javascript语言的执行环境是单线程,异步模式非常重要。在浏览器端,耗时很长的操作都应该异步执行,避免浏览器失去响应,最好的例子就是Ajax操作。
js异步加载又被称为非阻塞加载,浏览器在下载JS的同时,还会进行后续页面处理。那么如何实现js异步加载呢?下面整理了多种实现方案供大家参考。异步加载js方案:Script Dom Element、onload时的异步加载、$(document).ready()、async属性、defer属性、es6模块type=module属性
回调函数方式:将异步方法如readFile封装到一个自定义函数中,通过将异步方法得到的结果传给自定义方法的回调函数参数。事件驱动方式:使用node events模块,利用其EventEmitter对象
JavaScript引擎是基于单线程 (Single-threaded) 事件循环的概念构建的,同一时刻只允许一个代码块在执行,所以需要跟踪即将运行的代码,那些代码被放在一个任务队列 (job queue) 中
传统的异步解决方案采用回调函数和事件监听的方式,而这里主要记录两种异步编程的新方案:ES6的新语法Promise;ES2017引入的async函数;Generator函数(略)
请实现如下的函数,可以批量请求数据,所有的URL地址在urls参数中,同时可以通过max参数 控制请求的并发度。当所有的请求结束后,需要执行callback回调。发请求的函数可以直接使用fetch。
将setState()认为是一次请求而不是一次立即执行更新组件的命令。为了更为可观的性能,React可能会推迟它,稍后会一次性更新这些组件。React不会保证在setState之后,能够立刻拿到改变的结果。
上述,在Chrome 66和node v10中,正确输出是:执行async1函数,此函数中又调用了async2函数,输出async2 end。回到async1函数,遇到了await,让出线程。遇到setTimeout,扔到下一轮宏任务队列
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!