イベントループを踏まえて気をつけるべきことの抜粋
前回の記事(下記)は仔細に入りすぎ感があったので、自分用に要点を抽出してみた。
(イベントループの仕様は実行系に左右されるけど、今回の話はすべてブラウザに限定されます)
イベントループの復習
ブラウザのいろいろな仕事の分類のされ方
タスク
- イベントへの反応
- HTMLパーサによるパース
- コールバックの実行
- リソースの使用(??)
- DOM 操作への反応
タスクの何たるかはwhatwgがここで定義している
マイクロタスク
- MutationObserverで登録しておいたコールバック関数
- Promiseの解決時に呼び出されるコールバック関数
- queueMicrotask()で登録されたコールバック関数
アニメーションコールバック
- rAF()で登録したコールバック関数
各種仕事の行われ方
最強の動画
この動画をこのタイミングで再生すると、各仕事のキューの処理のされ方が分かる。
タスクは1つずつ、マイクロタスクはある限り消費し続ける、アニメーションコールバックは今ある分を消費しきったら一旦終わる。
コード
while (true) {
queue = getNextQueue();
task = queue.pop();
execute(task);
while (micortaskQueue.hasTasks()) {
doMicrotask();
}
if(isReapintTime()) {
animationTasks = animationQueue.copyTasks();
for(task in animationTasks) {
doAnimationTask(task);
while (micortaskQueue.hasTasks()) {
doMicrotask();
}
}
repaint();
}
}
体感してみる
- ①通常の関数呼び出し、②setTimeout()で積まれたタスク、③Promiseで積まれたMicrotaskが①→③→②の順に消化されていくことがわかる: 実際にJavaScript Visualizer 9000で試してみる
- Promise起因のコールバック呼び出しはPromiseがresolvedになったタイミングで呼ばれる: 実際にJavaScript Visualizer 9000で試してみる
- thenによるチェーンは、最初の処理が実行されるとそこから一気に実行される: 実際にJavaScript Visualizer 9000で試してみる
- fetch()などの非同期処理を実現するAPIは、要するにその内部でPromiseの状態をsettled(fulfilledかrejected)にしていると思われる。ちなみにJavaScript Visualizer 9000でもfetch()を動かせるのでやってみると、こんな感じになる: 実際にJavaScript Visualizer 9000で試してみる
おもしろい示唆
Promiseの順序保証
PromiseがMicrotaskであるおかげで、非同期処理まわりの処理順序を確定できる。下記のような関数を実行した時、処理Bがどれだけ時間を必要としても/どれだけ一瞬で終わろうとも、Aは処理Bのあとに行われることが約束されている(もちろんマシンスペックにもよらない)
const res = fetch('aaaaa')
res.then(処理A)
//処理B
return
※本当にどうでもいいけど、ES自体はPromiseについて「あとから実行される」としか定義しておらず、そのタイミングは指定していない。処理系に任せている。Microtaskとかいう概念もESには現れない
タスク、マイクロタスク、アニメーションコールバックが頻発・連鎖したときのブラウザの振る舞い、と注意
タスクとマイクロタスクとアニメーションコールバックは処理の優先順位(?)タイミング(?)が違うので、無限ループさせたときにブラウザの挙動が異なってくる
結論
タスクもアニメーションタスクもどれだけ頻発・連鎖させてもハングしない
マイクロタスクは最悪、ハングする
見て確かめる
示唆
- 重い処理をタスクに分割することでハングを防げる
- ただしその処理は非同期的になるので注意
- マイクロタスクについては下記のことがいえる
- マイクロタスクがマイクロタスクを作り続ければ、ブラウザは完全にハングする
- マイクロタスクが頻発すれば(=ブラウザのアニメーションコールバック実行の速度や、タスクの実行の速度を上回るくらいで頻発すれば)、ブラウザは段々と重くなり、いずれはハングする
await使用上の注意
awaitのイメージ
awaitは、『そのasync関数の残り全ての部分を、「awaitされるPromise」がresolvedになった時点でMicrotaskとしてキューに入れる仕組み』である
function resolveAfter2Seconds() {
return new Promise(resolve => {
setTimeout(() => {
resolve('resolved');
}, 2000);
});
}
async function asyncCall() {
console.log('calling');
const result = await resolveAfter2Seconds();
// ここから下がresolveAfter2Seconds()にthenでつながれたものとみなされる
console.log(result);
console.log("hi")
}
asyncCall();
// calling
// resolved
// hi
// これと同じ
async function asyncCallrewrited() {
console.log('calling');
resolveAfter2Seconds().then((result) => {
console.log(result);
console.log("hi")
})
}
// これは違う
async function asyncCall2() {
console.log('calling');
resolveAfter2Seconds().then((result) => {
console.log(result);
})
console.log("hi")
}
asyncCall2()
// calling
// hi
// resolved
注意
このように考えると、あるPromiseに対してawaitするときは、そのPromiseの結果とは無関係に実行できる処理を巻き込まないように注意しないといけない！！
You'll probably use async functions a lot where you might otherwise use promise chains, and they make working with promises much more intuitive.
Keep in mind that just like a promise chain, await forces asynchronous operations to be completed in series. This is necessary if the result of the next operation depends on the result of the last one, but if that's not the case then something like Promise.all() will be more performant.
https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Promises
例えばこういうこと
// 例えば同時に実行できるfetchを待たせてしまう
async function badFetch() {
const fetch1 = await fetch('1')
const fetch2 = await fetch('2')
const fetch3 = await fetch('3')
console.log(fetch1, fetch2, fetch3)
}
// こんなふうに同時実行したほうが良い
function goodFetch() {
const fetch1 = fetch('1')
const fetch2 = fetch('2')
const fetch3 = fetch('3')
Promise.all(fetch1, fetch2, fetch3).then(console.log(fetch1, fetch2, fetch3))
}
// より一般的に、全然関係ない処理を待たせてしまうという問題を考える
async function badAwait1() {
const fetch1 = await fetch('1')
const notRelatedResult = notRelatedCalc()
// ↑notRelatedCalc()はfetch1の結果に左右されない関数
return calc(fetch1, notRelatedResult)
}
// 下記も、notRelatedCalcが終わってからじゃないとfetchが走らないのでもったいない
async function badAwait2() {
const notRelatedResult = notRelatedCalc()
const fetch1 = await fetch('1')
return calc(fetch1, notRelatedResult)
}
// async使うなら、こういうのがよさそう
async function goodAwait1() {
const fetch1 = fetch('1')
const notRelatedResult = notRelatedCalc()
const result = await fetch1
reutrn calc(fetch1, notRelatedResult)
}
// asyncなしだとこう書ける
function goodAwait2() {
const fetch1 = fetch('1')
const notRelatedResult = notRelatedCalc()
const result = fetch1.then((resolve)=> calc(fetch1, notRelatedResult))
return result
}
fetchを先に済ませておこうという発想はprefetchという言葉で色々なフレームワーク、ライブラリに実際に取り入れられていると思う。
めちゃ細かいルール
MutationObserverの挙動
- MutationObserverによりセットされたコールバックは、1つのJSスクリプトコンテクストにつき1回しか呼ばれない(=特定のコールバックが紐付けられた特定のDOM操作を、1つのJSスクリプトコンテクスト内でどれだけ繰り返し行っても、紐付けられたコールバックは一度しかキューに登録されない)
-
whatwgさんの仕様にもある
To queue a mutation observer microtask, run these steps:
- If the surrounding agent’s mutation observer microtask queued is true, then return.
- Set the surrounding agent’s mutation observer microtask queued to true.
- Queue a microtask to notify mutation observers.
-
- この独特の仕様は、mutationObserverを90年代に導入するときに課題になっていた「(ルートドキュメントに対する)1スクリプト内での大量のイベント発生」を念頭においていそう(だし、それは実際そうすべきだろう)
- 下記リンク先の3つ目の例をみると実際に体感できる
- でもmutationObserverへのレコード登録は毎回される。下記リンク先のjsbinをためすといい
- なので、MutationObserverでループさせるとハングする。呼び出しもされずに静かに死んでいく。これはMicrotaskの連鎖で死ぬのとはまた毛色が違うはず
イベントコールバックの同期性
- スクリプト内でイベントを発生させる(e.g. click())と、イベントを発生させたJSスクリプトコンテクストが継続して、そのコンテクストの中でイベントによって呼ばれたコールバックが処理される＝同期的に行われる
- 下記リンク先の3つ目の例をみるといい
- addEventListener()で登録して発動したコールバックはMicrotaskではない！タスク！
- 補足: addEventListenerの登録は同期的に行われる
バブリングの同期性
- 「イベントに反応してコールバックをタスクに入れる」という1つのタスクの中で、バブリングも一気に処理される(=バブリングは他タスクによって中断されず、ひとまとまりで行われる)
- このルールはあくまでも下記リンクの実験結果から推察されることなので、仕様を見つけたわけではないです
Discussion