ブラウザーにドキュメントがある場合、同じオリジン サーバーから 1 つ以上のフレームが読み込まれます。
それらのフレームは、メイン ウィンドウと同じスレッドによって実行されますか?
または、プロセスが重いフレームがあり、他のフレームがフリーズしない可能性はありますか?
その仕様は見つかりませんでした。存在する場合、誰かがどこにあるか知っていますか?
ブラウザーにドキュメントがある場合、同じオリジン サーバーから 1 つ以上のフレームが読み込まれます。
それらのフレームは、メイン ウィンドウと同じスレッドによって実行されますか?
または、プロセスが重いフレームがあり、他のフレームがフリーズしない可能性はありますか?
その仕様は見つかりませんでした。存在する場合、誰かがどこにあるか知っていますか?
私は「ブラウザのしくみ」の専門家ではありませんが、私が予測しているのは次のとおりです。
確信が持てません。それはエンジンのタイプ(私たちが話します)、ブラウザ、そしてそのバージョンに依存します...
レイアウトレンダリングエンジン(通常はシングルスレッド)について話している場合。すべてが単一スレッドの線形フロー内で実行されます。従来、これは「ブラウザ」のメインスレッドでしたが、IE7では各ブラウザの「ウィンドウ」に独自のスレッドがありました。しかし、それは時間とともに変化し続け、今では「タブ」ごとにほとんどが単一のスレッドになっています。
タブ内; javascriptの実行中、レンダリングエンジンはjavascriptが終了するのを待ちます。その理由は、Javascriptエンジンが伝統的に同じシングルスレッドを共有しているためです(必ずしもそうとは限りません)。非同期イベントでも、適切な実行時間のキューに入れられます。
一方、ネットワーク操作。複数の並列スレッドで処理されます。しかし、繰り返します。これらの操作のコールバックは、メインスレッドのブラウザのイベントループに挿入されます。(そのため、これらの呼び出しの数は一般的に制限されています)。
レンダリング用。内側/埋め込みフレーム(などiframe
)は、フレームコンストラクター(サイズ、パディング、マージン、位置などを持つすべての長方形のボックスを担当します)の対象となります。スクリプトの実行は、メインウィンドウの同じスレッドで処理されます。(ここでも、Operaでは「一般的に」bec。これはiframeの場合には当てはまらない場合があります。)
したがって、各ブラウザには、イベント/操作がキューに入れられて実行されるタイミングと方法に関する内部スケジューリング実装があります。例えば; 以下の画像は、Geckoブラウザでページリクエストがどのように処理されるかを示しています。
ブラウザは、リフローを延期するか、すぐに実行するかを決定する場合があります。一般的に、その理由は速度とペイントを最適化することですが、ほとんどの場合、即時のリフローが必要です。たとえば、DOM要素の高さを変更するなどのレイアウトを変更するJavaScriptコード。レンダリングエンジンが要素の境界を正確に計算してレイアウトプロセスを続行できるように、これは即時のリフローである必要があります。GeckoReflowVisualizationに関するこのビデオを参照してください。
非凍結の重いプロセスに関する2番目の質問に戻ります。
Operaでは、重いプロセスをiframeにロードしても、メインウィンドウをブロックしない場合があります。しかし、これも時間とともに変化する可能性があります。これを約束するAPIを手に入れることができない場合; ノンブロッキングとして信頼することはできません。開発者は、JavascriptとDOMの操作についてシングルスレッドで考える必要があります。
あなたができることは、HTML5仕様のWebワーカーをチェックすることです。それらはjavascriptを介してアクセスできます。ワーカーはメッセージを介して別のスレッドとしか通信できず、DOMに直接アクセスできないため、これによってjavascriptにマルチスレッドがもたらされるとは思いません。しかし、それでも、現在のスレッドを邪魔することなく、重い計算をワーカーに割り当てることができます。