Is async await truly non-blocking in the browser?

问题:

I have been playing around with the feature in an SPA using TypeScript and native Promises, and I notice that even if I refactor a long-running function into an async function returning a promise, the UI is still unresponsive.

So my questions are:

• How exactly does the new async/await feature help avoid blocking the UI in the browser? Are there any special extra steps one needs to take when using async/await to actually get a responsive UI?

• Can someone create a fiddle to demonstrate the how async/await helps to make the UI responsive?

• How does async/await relate to prior async features such as setTimeout and XmlHttpRequest?

回答1:

await p schedules execution of the rest of your function when promise p resolves. That's all.

async lets you use await. That's (almost) all it does (It also wraps your result in a promise).

Together they make non-blocking code read like simpler blocking code. They don't unblock code.

For a responsive UI, offload CPU-intensive work to a worker thread, and pass messages to it:

async function brutePrime(n) {
  function work({data}) {
    while (true) {
      let d = 2;
      for (; d < data; d++) {
        if (data % d == 0) break;
      }
      if (d == data) return self.postMessage(data);
      data++;
    }
  }

  let b = new Blob(["onmessage =" + work.toString()], {type: "text/javascript"});
  let worker = new Worker(URL.createObjectURL(b));
  worker.postMessage(n); 
  return await new Promise(resolve => worker.onmessage = e => resolve(e.data));
}

(async () => {
  let n = 700000000;
  for (let i = 0; i < 10; i++) {
    console.log(n = await brutePrime(n + 1));
  }
})().catch(e => console.log(e));

回答2:

async is a more elegant way to structure asynchronous code. It doesn't allow any new capabilities; it's just a better syntax than callbacks or promises.

So, async can't be used to "make something asynchronous". If you have code that has to do lots of CPU-based processing, async isn't going to magically make the UI responsive. What you'd need to do is use something like web workers, which are the proper tool to push CPU-bound work to a background thread in order to make the UI responsive.

回答3:

JavaScript is single-threaded and runs in the same thread as the UI. So all JavaScript code will block the UI. As mentioned by others web workers can be used to run code in other threads, but they have limitations.

The difference between async functions and regular ones is that they return a promise. Using a callback you can then defer the execution of code, that handles the result of a function invocation and thereby allowing the UI to do some work. The following three examples have the same effect:

async function foo() {
  console.log("hi");
  return 1; 
}
foo().then(result => console.log(result))
console.log("lo");

function foo() {
  console.log("hi");
  return 1; 
}
Promise.resolve(foo()).then(result => console.log(result))
console.log("lo");

function foo() {
  console.log("hi");
  return 1; 
}
const result = foo();
setTimeout(() => console.log(result));
console.log("lo");

In all three cases the console logs hi, lo, 1. Before 1 is printed the UI can handle user input or draw updates. The reason 1 that is printed last in the first two cases is that callbacks for promises are not executed immediately.

await allows you to do that without callbacks:

async function foo() {
  console.log("hi");
  return 1; 
}

async function bar() {
  const result = await foo();
  console.log(result);
}

bar();
console.log("lo"); 

That will also print hi, lo, 1. Much like a callback for a promise, the code after await is never executed immediately.