Hebikuzure's Tech Memo

2011年8月9日

IE10 における Web Workers のデバッグ

Filed under: IE Blog — hebikuzure @ 8:35 PM

Debugging Web Workers in IE10
http://blogs.msdn.com/b/ie/archive/2011/07/12/debugging-web-workers-in-ie10.aspx


今日は IE Blog の記事から IE10 で追加された Web Workers のサポートに伴う F12 開発者ツールの新機能についての記事を私訳しました。

以下の文章は IE Blog の 7/12 の記事 Debugging Web Workers in IE10 を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation および日本マイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


IE10 における Web Workers のデバッグ

2011年7月12日 午前11時34分

Web Workers を利用すると長時間動作する複雑なJavaScript アルゴリズムをバックグラウンドで動作させるオフロードにより、Web アプリケーションはより応答性が良くなります。IE10 には Web ページおよび Web worker の両方で実行される JavaScript に対する完全で動作予測のしやすいデバッギング エクスペリエンスが含まれています。

IE10 ではすべての Web worker で生成される新規のスクリプト コンテキストに対応できるよう F12 開発者ツールが拡張されています。デバッグを開始する (F12 ツール内で [デバッグ開始] ボタンをクリックする) と、Web ページのスクリプト コンテキストにアタッチされるのと同様、現在の (そして将来の) すべての worker のコンテキストにもアタッチされます。これが完全で動作予測のしやすいスクリプト デバッギングという事の意味です: 従来のシングル スレッドのスクリプト対する F12 ツールのすべてのデバッグとプロファイリングの機能は、workers に対しても同様に利用できます。

他の製品では、エミュレーションを通じた限定的なデバッグをサポートしています。現在、多くの開発者向けツールは Web Worker のデバッグにまったく対応していません。そうでなければ、iframe を使って workers をエミュレートするような、シミュレートされた環境でのサポートを提供しているだけです。残念ながら、シミュレーションは開発者をミスリードするでしょう。デバッガーが正しくないシナリオを許容してしまい (例えば DOM アクセスなど) 、デバッグしている間はスクリプトの動作継続のための通常の実行中に失敗してしまうからです。

実行時の挙動が一定しないデバッガーを使うと、混乱を招く “ハイゼンバグ” が生じがちです。これは特に既存のコードを workers を使うように移行している際に顕著です。さらに、UI のスレッド コンテキスト内で実行されるシミュレートされた環境では、アプリケーションがデバッグ中応答しなくなる危険性も存在します。これら両方の陥穽を考えると、Web Workers を利用しようとするアプリケーションに対する真のデバッグ機能のサポートは開発者にとって重要です。

既存の知識に基づいて

F12 開発者ツールは普通のスクリプトと同様の機能を Web Workers でもサポートしますから、皆さんはそのデバッグ方法の大半をすでにご存じという事になります。Workers の実行コード内でブレーク ポイントを設定する事や、すべてのローカル変数を確認する事、ウォッチ リストを構成する事、コンソールを経由して worker を操作する事、コードをステップ実行する事などが可能です。こうした機能によりスクリプト デバッグに通じている開発者であればすぐに Web Workers でも高い生産性が得られるでしょう。とは言え、worker のデバッグに関しては、ここでお知らせしておいた方が良い、注意すべき点もいつくかあります。(以下のすべてのスクリーンショットは、Web Worker Harness for test262 のデモ アプリを使用しています)

スクリプトで新しい Worker オブジェクトが生成され、worker のコンテキストが初期化されると、実行されているスクリプト ファイルがスクリプト リソースのリストに表示されます。ここからファイルを選択し、通常と同様にデバッグを開始できます。


F12
開発者ツールのスクリプト タブと利用可能なスクリプトのメニューのスクリーン ショット

Web Worker のスクリプト内のブレーク ポイントに達すると、その変数またはスコープを調査している場合、通常のスクリプトとは異なる重要な相違に気づくでしょう: スクリプトは通常の Window オブジェクトではなく、 WorkerGlobalScope 型のグローバル オブジェクトを持っています。これはWeb workers が (DOMのような) UI スレッドの共有メモリへのアクセスを制約する新しいオブジェクトであり、通常の実行中はそうしたアクセスは許可されていません。これは self へのウォッチを追加するだけで確認できます。


F12
開発者ツールのウォッチ タブのスクリーン ショット

複数のスクリプト コンテキストのデバッグ

F12 ツールは現在動作しているすべてのスクリプト コンテキストに対応しているため、ブレークポイントに留まっている間は、他のすべてのスクリプト エンジンに停止するよう要請できます。このため現在デバッグ中のスクリプト コンテキストが他のコンテキストから操作される事が防げるので、予期しやすいデバッギング エクスペリエンスが作り出されます。

さらに、一度に単一のスクリプト コンテキストをデバッグする事に限定されません。(worker 内であれ UI スレッド内であれ) ブレークポイントからの実行継続を行うと、すべてのスクリプト コンテキストが再開され、別のブレークポイントにヒットする (または debugger ステートメントまたは例外に遭遇する) まで実行されます。これにより worker のスクリプト コンテキストから UI スレッドのコンテキストへの “フォーカス” の切り替えが自動的に行われる事になり、これらの相互作用のデバッグが容易になります。

Worker を背後で利用しているアプリケーション内のブレークポイントに留まっている間、コール スタック ペインには (実際のコール スタックに加えて) どれだけの worker インスタンスが動作しているか表示されます。各 “Root” は個別の JavaScript 実行コンテキストを示しています。Root #0 はWeb ページの通常のスクリプトを動作させているメインの JavaScript の UI スレッドを示しています。Root #1 は現在動作中の worker (スクリプト ファイルで識別) を示しています。それ以外にも worker が実行されていれば、Root #2 や Root #3 などのようにリストに表示されるでしょう。


F12
開発者ツールのコール スタック タブのスクリーン ショット

Worker のアクティビティーとネットワーク リクエストをプロファイルする

デバッグに加えて、他のスクリプトと同様に、動作している worker のパフォーマンスを確認するためプロファイラーを使用する事もできます。F12 ツールでプロファイラー タブを選択し、プロファイリングの開始 をクリックしてからプロファイルしたいスクリプトを実行します。実行が終了したら、F12 ツールで プロファイリングの停止 をクリックします。以下は 現在のビュー ドロップダウンから 呼び出しツリー を選択した際の表示です。


F12
開発者ツールのプロファイラー タブのスクリーン ショット

URL カラムでは個々のアクティビティーがどのスクリプトによる物なのかを示しています。例えば、上の例では worker 内のテストの実行 (worker 内の execute 関数) に使用された時間は、UI スレッドでのテストの実行に使用された時間 (UI スレッド内の run 関数の消費時間) に比べて少ないという事が指摘できます。

Workers は全体としてのネットワーク アクティビティーにも関連しています。何故ならブラウザーは worker が実行するスクリプトを、ブラウザーが依存しているすべての子スクリプトと同様に (importScripts を経由して) ダウンロードする必要があるからです。必要なのは、ネットワーク タブを選択し、キャプチャの開始 ボタンをクリックするだけです。以下は worker に由来するスクリプトのリクエストを含む、キャプチャのスクリーンショットです。


F12
開発者ツールのネットワーク タブのスクリーン ショット

worker.js ファイルへのダウンロード リクエストが記録されていますが、さらに注目すべきは Initiator カラムでなぜそれがダウンロードされたかが記録されている事 (この場合は Web worker のため) です。さらに、15.2.js ファイルはworker によってインポートされていますが、同様に表示されており、importScripts メソッドの呼び出しによりインポートされたことが示されています。

皆さんのフィードバックを歓迎しています! IE10 での Web Workers の利用やそのツールの機能に関して何か問題を見つけられましたら、ぜひ Connect を通じてお知らせください。

—Jonathan Carter と Gaurav Seth, プログラム マネージャー, Browser Programmability & Tools

広告

コメントする »

まだコメントはありません。

RSS feed for comments on this post. TrackBack URI

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

WordPress.com Blog.

%d人のブロガーが「いいね」をつけました。