Scoutファーストステップガイドを参照してください。Scoutは、Flashコンテンツを最適化するための、非常に強力なツールです。Playerの舞台裏の状況を確認できるようになるためです。Playerが実行しているかを把握する場合です。その場合のみ、Scoutで問題の解決方法を効率的に見つけ出すことができます。Playerによって実行されるアクティビティの基本知識を提供し、Scoutに表示される情報にそれらのアクティビティを関連付けることです。この記事は、Scoutで使用される用語のリファレンスガイドでもあります。Playerによって実行される様々なアクティビティの意味を調べることができます。Scoutを使用していて、「xの実行に時間がかかりすぎているのは分かるが、このxがどういう意味であるかが分からない」と思っている場合、この記事は役立ちます。Scoutのユーザーインターフェイスのガイドではないことに注意してください。Scoutの使用方法、様々なパネルの機能が分からない場合は、まず、ファーストステップガイドを参照してください。Playerは、あなたに代わって面倒な処理の手配をし、あなたと実世界の間の仲立ちをする点で、あなたの個人秘書のようなものです。Playerはそれ自体では、あなたに役立つことは何も行うことはできません。何をするかはあなたが指示する必要があります。そのためには2つの方法があります。Professionalで作成します。これらはフレーム単位のアニメーションです。一連のタグとして表現されます。タグは、各フレームで何をするか(画面中をオブジェクトが動き回るようにするなど)を記述したシンプルな指示です。Professionalで視覚的に行ったすべての操作(例えば、フレームへのオブジェクトの追加やトゥイーンの設定など)は、SWFファイルでタグとしてエンコードされます。純粋なActionScriptで記述します。Playerによって特定のタイミングで実行されます。SWFが読み込まれたとき、タイマーが開始されたとき、マウスクリックが発生したときなどです。Professionalで、スクリプトを個々のフレームにアタッチすることもできます。Playerには実行するべき様々なアクティビティが発生します。それらのアクティビティは大まかに次の4つのカテゴリに分類できます。即時実行のアクティビティ。Playerがすぐに実行します。処理が完了するまで、コンテンツの実行は続行されません。新しいビットマップの作成やHTTP要求の開始などです。継続実行のアクティビティ。Playerがバックグラウンドで実行し続けます。サウンドの再生やファイルのダウンロードなどです。遅延実行のアクティビティ。Playerがしばらくしてから実行する大きな処理としてスケジュールします。表示オブジェクトの位置を変更すると、そのオブジェクトは「dirty(ダーティ)」としてマークされます。Playerがしばらくしてからそのオブジェクトを再レンダリングする必要があることを意味します。暗黙実行のアクティビティ。Playerが実行する組み込みの処理です。ガベージコレクションや、オペレーティングシステムからのマウスおよびキーボードイベントの受信などです。上記の点は、この記事を読み進むにあたって重要ですので、覚えておいてください。PlayerはActionScriptのみを実行しているわけではありません。他の多くのアクティビティも実行しています。Playerを考えるなら、ActionScriptの実行中は会議で離席中に例えられます。Playerは会議後に、あなたが指示したすべての事務処理を実行する必要があります。凝ったアニメーションのレンダリングには時間がかかり、実際の処理のほとんどがActionScriptの外部で発生するのです。Playerが上記のような様々なアクティビティの実行をどのように管理するか、疑問に思うかもしれません。Playerは通常、オペレーティングシステムの個別のプロセスで実行されます。1つのプロセスのみが、そのブラウザー内で実行されるすべてのSWF(関連するあらゆるワーカースレッドも含む)に使用されます。PlayerによってこれらのSWFの実行が管理されるため、各SWFがそれぞれ独立して実行されているように見えます。実行されている各SWFは、プレーヤーインスタンスとして知られており、Scoutでのセッションに対応します。ワーカースレッドもプレーヤーインスタンスです。AIRコンテンツの場合、メインのプレーヤーインスタンスが1つと、そのインスタンスが使用するワーカーがあるだけです。Playerが実行されると、様々なアクティビティ間で切り替わります。小さいスクリプトを実行してから、ビデオを再生し、その後、グラフィックをレンダリングします。アクティビティの正確な組み合わせは、どのようなイベントが発生するか、どのような継続実行のアクティビティが進行中であるか、どのようなアクティビティがSWFのスクリプトおよびタイムラインによって要求されたかによって決まります。Playerは実行状況を記録し、CPU時間、CPUメモリ、GPUメモリなど、消費されているリソースを測定します。これらの測定値はScoutに送信されるため、何が起こっているかをScoutで確認できるようになります。Playerは、時間やメモリを大量に消費するアクティビティのみを測定してレポートします。Playerはどのタイミングでも次の2つのモードのいずれかになります。有効な何らかの処理を実行しています。ActionScriptの実行から、レンダリング、マウスイベントに至るまで、あらゆる種類の処理が考えられます。一時停止中です(ティーブレイクに例えることができます。Playerにお茶を出す必要はありません)。何らかの外部条件(GPUなど)でブロックされている可能性があります。実行する処理がないだけという可能性もあります。Timeline(フレームタイムライン)で灰色のバーで示されます。Playerが様々な種類のアクティビティにかける時間の割合をより簡単に視覚化するために、Scoutでは、アクティブ時間を次の4つのトップレベルカテゴリに分類します。API内でActionScriptコードの実行にかかった時間。DisplayListの処理(ラスタライズ、画面への描画など)の実行にかかった時間。APIを使用するStage3Dレンダリングは含まれていないことに注意してください。ビデオのネットワーク経由のダウンロード、ストリーミング、デコードにかかった時間。ガベージコレクション、イベントの処理、SWFの解析など、その他のすべての処理の実行にかかった時間。ここで理解しておくべき重要なことは、Scoutで表示されるのが経過時間であり、CPU時間ではないということです。Playerがストップウォッチを持って、各アクティビティのタイムを測っていると考えてください。Playerが測定する経過時間はより長くなります。正確なデータを得るには、Scoutでプロファイリングを行っている間、他のアプリケーションを閉じる必要があります。Playerのハートビート多くのFlashアプリケーション、特にゲームは、大量のグラフィックアニメーションを処理します。アニメーションの処理の基本原理は、一定の周期で(例えば1秒当たり60回)画面を再描画することです。それにより、スムーズなアニメーションに見えます。Playerの中核のコンセプトにあるのがフレームです。Playerの心臓部には、一定の周期でハートビートを刻むタイマーがあります。この周期がフレームレートと呼ばれます。これらのハートビート間の時間がフレームと呼ばれます。コンテンツを実行するフレームレートは指定できます。その指定にはSWFのプロパティを使用します。このプロパティはSWFの実行中にActionScriptから動的に変更できます。そのための一般的なプログラミング方法は、イベントハンドラーをEvent.ENTER_FRAMEに登録することです。このイベントは、ハートビートと新しいフレームの開始に対応します。ゲームを作成している場合は、このイベントハンドラーを使用して、ゲームの継続に必要な定期的な処理をすべて実行できます。ユーザーからの入力を処理し、物理エンジンを使用してゲームの状態を更新し、最後に、更新されたシーンをレンダリングできます。Playerが各フレームの実行にかけた時間が表示されます。fps)のフレームレートを達成するゲームを考えてみましょう。Playerは要求されたフレームレートで実行できていないことになり、コンテンツは遅く、ぎくしゃくして見えることがあります。Timeline(フレームタイムライン)では、赤い水平ラインはバジェットを示します。灰色のバーは、1フレーム当たりにかかった合計時間を示します。Playerは様々なアクティビティを実行します。実行するアクティビティの1つが、Event.ENTER_FRAMEイベントを送出して、登録済みのイベントハンドラーをコールすることです。Doリスト」に追加される可能性があります。これらのアクティビティは、このフレーム中にしばらくしてから実行する必要があります。マウス、キーボード、その他のイベントが、このフレーム中に発生する可能性もあり、これらのイベントも処理する必要があります。Playerはそのフレーム中の処理をすべて完了し、実行するべき処理を残しません。その後、次のハートビートを待機して受信すると、新しいフレームに対してまた初めから処理を開始します。Scoutで主に注意するべきなのは、赤いラインを超えている色付きのバーです。Playerが実行するべき処理をすべて完了するために、フレーム全体のバジェットよりも長くかかっていることを意味します。Playerが割り当てられた時間内に処理するべき処理が多すぎるということです。すべてのフレームが一貫してバジェットを超える場合は通常、コンテンツは遅くなります(図1参照)。不規則なスパイクがある場合、コンテンツはぎくしゃくして見えるようになります。Playerは常に、次のフレームを開始する前に待機することに注意してください。コンテンツがデバイスのすべてのリソースを占有していないということです。その結果、消費電力は削減され、CPU時間は他の処理の実行に割り当てられます。コンテンツに猶予時間が組み込まれているということです。その結果、コンテンツはより遅いデバイス上でも目的のフレームレートで実行できます。灰色のバーが赤いラインの上下で推移するのはまったく正常です(図2参照)。フレームについて次の細かい点に注意してください。fpsよりも高いフレームレートを設定しても、コンテンツがこのレートよりも速くなることはありません。fpsを超えるフレームレートをサポートしないことを忘れないでください。これよりも速く画面を更新しようとすることは絶対に避けてください。Playerはオペレーティングシステムと適切に連携しようとします。Webを閲覧するときに実行中のプレーヤーインスタンスが多数ある場合、それらのフレームレートはすべて異なることがあります。Playerはランダムなタイミングでウェイクアップして、コンピューターを遅くするのではなく、プレーヤーインスタンス間でウェイクアップタイミングを同期しようとします。大まかに言うと、1/60秒ごとにウェイクアップし、準備ができているプレーヤーインスタンスで新しいフレームを開始します。fpsに設定した場合、灰色のバーが赤いラインの上下を推移することが分かります(図3参照)。これは正常であり、問題ではありません。平均で目的のフレームレートを満たしている必要はあります(Scoutでフレームを範囲選択すると、平均のフレームレートを表示できます)。Scoutで、灰色のバーが一貫して赤いラインの上にある場合、色付きのバー(アクティブ時を示す)が常に赤いラインの下にあっても、おそらくコンピューター上で動作中の他のアプリケーションがCPUリソースを使い果たしています。他のアプリケーションとブラウザーウィンドウをシャットダウンしてみてください。Playerの基本構造をより深く理解できたところで、次は、Scoutに表示されるデータをさらに掘り下げてみましょう。Playerによる処理について詳細な内訳を得られることが分かります。これらのパネルでは、説明はできる限り自明であるように設計されていますが、場合によっては問題の根本原因にたどり着くために、もう少し詳しい情報が必要になることがあります。Playerの様々なアクティビティを機能領域にグループ化し(図4参照)、それらの意味をより詳しく説明します。Scoutの使用時にリファレンスガイドとしてこのセクションを参照して、現在の問題に該当する部分だけを読むことができます。Playerの様々な部分の仕組みについて理解を深めることもできます。Playerに何をするかを指示できます。Playerが理解できるようになります。Machine(AVM)によって実行されます。Playerの橋渡し役を果たします。Playerを操作できます。したAPIのコールは通常の関数のコールのように見えますが、内部では多くの場合、ネイティブCコードをコールすることで、高度な処理が実行されています。Scoutでは、これらのAPIは、ActionScriptパネルで通常の関数のコールとして表示されるため、内部の詳細を心配する必要はありません。APIのコールに時間がかかりすぎる場合は、コールの頻度を低くするか、処理負荷を減らします(引数のサイズを小さくしたり、引数を単純化したりする)。Playerに指示する必要があります。ほとんどの場合、そのためにはイベントハンドラーを使用します。イベントハンドラーは、特定のイベントが発生したときにコールされるように登録する関数です。カスタムイベントを作成し、EventDispatcher.dispatch()を使用して、イベントハンドラーを手動でコールできます。多くの場合、マウスの動きやキーの押下などの外部イベントを待機させたいと考えます。Scoutでは、この処理に関連する多数のアクティビティがあります。Playerがオペレーティングシステムからの外部イベントを常に待機して受信しています。イベントを受信すると、まず、該当する処理を実行し、どのイベントハンドラーを呼び出すかを割り出す必要があります(例えば、キーボードイベントの場合、呼び出すハンドラーは、どのオブジェクトにキーボードフォーカスがあるかによって決まります)。Scoutでは、次のいくつかの外部イベントが表示されます。キーボードイベント:keyDown、keyPress、keyUp。マウスイベント:mouseDown、rightMouseDown、mouseMove、mouseUp、mouseWheel。タッチおよびジェスチャーイベント:touch、gesture。ウィンドウイベント:resize、mouseLeave、foreground、background、fullScreen、fullScreenInteractiveAccepted、visible。これはイベント<name>の実際のActionScriptイベントハンドラーです。これが表示されるのは、イベントハンドラーを作成して登録している場合のみです(このことは上記のイベントだけでなく、どのイベントにも適用されます)。ここで役立つヒントがあります。Activities(上位アクティビティ)パネルでイベントをクリックすると、ActionScriptパネルがフィルターされて、この特定のイベントハンドラー内で実行されたコードのみが表示されるようになります。タイマーは外部イベントとほとんど同じように処理されますが、自分で設定する必要があります。TimerEvent.TIMERイベントをあらゆる登録済みのハンドラーに送出しています。次のように、コードの実行およびActionScriptの言語機能のサポートに関連する多数のAVMアクティビティがあります。明示的なメモリ管理を必要とするCやその他の言語とは異なり、ActionScriptはメモリの割り当てと解放を自動的に処理します。Playerは定期的にガベージコレクターを実行して、参照されなくなった(参照しているものが何もない)あらゆるオブジェクトをスキャンし、そうしたオブジェクトによって使用されているメモリを解放します。コンテンツのガベージコレクションの実行に長時間かかっている場合は、作成しているオブジェクトが多すぎるということです。可能であれば、オブジェクトのキャッシュまたはプールにより、新しいインスタンスを常に作成することを避けてみてください。ActionScriptのtrace()ステートメントの出力です。Log(トレースログ)パネルでこのデータを表示することもできます。ActionScriptの実行中に発生するあらゆる例外のスタックトレースです。これは、例外がキャッチされて処理された場合でも表示されるため、Scoutでこの例外が表示されても、必ずしもコードに問題があるわけではありません。UncaughtErrorEvent.UNCAUGHT_ERRORをあらゆる登録済みのハンドラーに送出しています。3コードを呼び出す場合に表示されるいくつかのアクティビティがあります。3コードへのコールです。3コードへのコールです。ActionScriptワーカーコンテンツ内にActionScriptワーカーを使用している場合、それらのワーカーはScoutで個別のセッションとして表示されます。内部では、個別のプレーヤーインスタンスにすぎず、APIを使用して相互にデータを共有します。Scoutでのワーカーのサポートは現在のところ、ベータ版の機能です。このサポートを有効にするには、次の操作を実行する必要があります。ワーカーのセッションを開始)」を選択します。サンプラー)」が有効になっていることを確認します。コンテンツで高度なTelemetryが有効になっていることも確認します(その方法が分からない場合は、ファーストステップガイドを参照)。ActionScriptワーカーを使用しているコンテンツについて、Scoutで次のアクティビティが表示される場合があります。ワーカーを起動して、その内部でActionScriptを継続的に実行する場合(イベント駆動の関数ではなく、1つの長時間実行される関数をワーカーが実行する場合)、Scoutでこのアクティビティが表示されます。ワーカーのトップレベルのエントリポイントに制御がまだあり、どのイベントにも対応していないということです。–Condition.wait()のコールがブロックされています。MessageChannel.receive()のコールがブロックされています。–MessageChannel.send()のコールがブロックされています。Mutex.lock()のコールがブロックされています。–Mutex.trylock()のコールがブロックされています。APIを使用してカスタムデータをScoutに送信できます。2つのメインのコールは次のとおりです。名前と値のペアをScoutにレポートします。Sequence(アクティビティシーケンス)パネルに表示されます。アクティビティをオプションの値と共にScoutにレポートします。開始時刻を記録するには、Telemetry.spanMarkerで調べて、Telemetry.sendSpanMetricに測定期間の終了時に渡します。Sequence(アクティビティシーケンス)の両方のパネルに表示されます。APIのドキュメントを参照してください。Playerの中核にあるのが、フレームティッカーです。このハートビートは新しいフレームの開始時ごとに送信されます。3イベントを送出します。次のようなフレームティッカーのアクティビティがあります。Playerはフレームに関連付けられたSWFタグを実行しています。Professionalでの処理に相当します。フレームにアタッチしたオブジェクトを作成して、トゥイーンに従って動き回るようにすることなどです。ProfessionalのAction(アクション)パネルを使用して、タイムライン上のフレームにアタッチするスクリプトです。Playerが実行します。Playerが実行しています。2のMovieClip.onEnterFrameイベントハンドラーです。PlayerはEvent.ENTER_FRAMEの登録済みのハンドラーを検索し、呼び出します。新しいフレームの入力時、そのフレーム内のFrameLabelオブジェクトにEvent.FRAME_LABELの登録済みハンドラーがある場合、そのハンドラーを呼び出します。PlayerはEvent.EXIT_FRAMEの登録済みのハンドラーを検索し、呼び出します。Playerで従来から使用されているレンダリング手法です。基本的に、ステージと呼ばれる空白のキャンバスに、表示オブジェクトと呼ばれるグラフィカルなエンティティをアタッチして配置することで描画します。ベクトルアート、ビットマップ、テキストなど、様々な種類の表示オブジェクトがあり、それらを階層的にネストして、複雑なシーンを作成できます。Proでそれらを配置してトゥイーンを設定しても、表示オブジェクトが実際にレンダリングされる方法について心配する必要はありません。Playerがあなたに代わって難しい処理を実行し、画面上に表示される実際のピクセルにDisplayListを変換する方法を割り出します。ActionScriptを使用してDisplayListを操作する場合、変更を加えるためにコールできるAPIがいくつかあることに気付くでしょう。した変更は即時実行のアクティビティとして考えることができます。APIをコールすると、そのAPIはDisplayListの内部状態を変更します。実行しないことは、画面上の表示の即時の変更です。Playerは変更された表示オブジェクトをdirty(ダーティ)としてマークして、再描画が必要であることを示します。Playerがレンダリングパスを実行します。Playerはすべての変更をまとめて収集するため、画面は一度更新するだけで済みます。ストップモーションアニメーションのように考えることができます。Playerがそのフレームのシーンを撮影するようなものです。ここでは、レンダリングパスがScoutでどのように表示されるかを説明します(図5参照)。DisplayListをスキャンし、dirty(ダーティ)とマークされた(例えば位置が変更された)あらゆるオブジェクトを検索することで、レンダリングサイクルを開始しています。その後、すべてのdirty(ダーティ)オブジェクトを含む最大3つの長方形を生成します。これらは再描画する必要がある画面の領域です。レンダリング)パネルで、赤い領域として表示されます。Playerは、新しいピクセルをどうするかを割り出す必要があります。そのために、内部バッファー(表示バッファー)にシーンを作成します。このプロセスに関連するいくつかの手順があります。PlayerはDisplayListを再びスキャンして、ダーティ領域に重なる表示オブジェクトを検索しています。見つかった各表示オブジェクトを一連のエッジと塗りに分割します(これらは場合によって、単色かグラデーション、またはエッジ間のスペースの色を定義するビットマップです)。表示オブジェクトに他の表示オブジェクトが含まれている場合、この同じプロセスがその他の表示オブジェクトにも再帰的に適用されます。Playerは階層的なシーンを様々な塗りの領域に平坦化します。Playerはこの段階で、エッジと色を実際のピクセルに変換する必要があります。ダーティ領域を水平ライン(スキャンライン)に分割します。それぞれが各垂直ピクセルに対応します。スキャンラインはマシン上のコア間で共有されます。Playerは、各スキャンラインをたどって、エッジ間の領域の塗りに基づいて、各ピクセルをどの色で塗るかを割り出します。この処理にかかる時間は、ピクセル数と、各ピクセルの描画コストによって異なります。単色は最小コストで描画できます。回転や拡大/縮小されたビットマップで、アルファブレンドの複数のレイヤーで構成されているものは、コストがかなり高くなることがあります。グローやドロップシャドウなどのフィルターを設定した場合、フィルターはこの段階で、ラスタライズされた画像に適用されています。表示オブジェクトの子にフィルターを設定した場合は、そのフィルターを適用した後に、親オブジェクトをラスタライズする必要があります。レンダリング)パネルで青で表示)、フィルターをそのサーフェスに適用します。その結果、新しいビットマップは、親の表示オブジェクトのエッジを作成するときに、アトミックな塗りとして扱われます。Playerはその表示バッファーから画面にデータをコピーしています。この処理はプレゼンテーションとも呼ばれます。この処理にかかる時間は、コピーする必要のあるピクセルの数によってほとんど決まります。オペレーティングシステムからのロックの取得時に遅延が生じることがあります。ハードウェアアクセラレーションを使用している場合、表示バッファーがグラフィックカード上に既にあります。Playerはグラフィックカードにそのバッファー内のデータを表示させるだけで済みます。待機)」に表示されます(詳しくは、GPU関連のパフォーマンスの問題についての諸注意を参照)。Playerの最新バージョン(11.5以降)を使用していることを確認してください。多数のエッジがあり様々なフィルターが適用された複雑なシェイプを描画する場合、レンダリングコストが高くなることがあります。できるだけDisplayListを変更しないようにして、各フレームで再描画する必要があるダーティ領域の数とサイズを減らしてみてください。ほとんど変更することのない(ただし位置を変更することは除く)複雑にネストされたオブジェクトを描画する場合、レンダリングパフォーマンスを向上させるために、そのオブジェクトをキャッシュできます。これにより、表示オブジェクトはキャッシュされたサーフェスにラスタライズされ、変更された場合のみ再作成するだけで済みます。表示オブジェクトの変換のみを行っていた場合は、cacheAsBitmapプロパティを設定します。mobileによってのみサポート)を使用してください。レンダリング)パネルにオレンジ色で表示)。Playerはそのキャッシュを使用しています。そのエッジを作成してラスタライズしていません。キャッシュされた表示オブジェクトまたはその子を変更する場合、キャッシュは無効になるため、作成し直す必要があります。Playerによるキャッシュされたサーフェスの更新に時間がかかりすぎる場合、キャッシュの使用に誤りがあるということです。キャッシュは、ほとんど変更されない表示オブジェクトにのみ使用するべきです。それ以外の場合は、キャッシュしないほうが、更新は速くなります。Scoutでは、各レンダリングパスの一部として、特定の種類の表示オブジェクトに対して実行されたアクティビティについて、追加情報が表示されます。次のアクティビティはテキストのレンダリングに関係します。テキスト表示オブジェクトが変更され(例えば、TextElementまたはTextFieldオブジェクトのtextプロパティが変更され)、再レイアウトが必要です。これにより、表示オブジェクトはdirty(ダーティ)としてマークされ、次のレンダリングパスで再描画も必要になります。TextFieldクラスを使用してテキストをレンダリングしています。Engineクラスを使用してテキストをレンダリングしています。次のアクティビティはBitmapオブジェクトに関係しており、それらのオブジェクトに関連付けられたビットマップデータ(Bitmap.bitmapData)を操作しています。BitmapDataオブジェクトのコンストラクターです。レンダリング)パネルにのみ表示されます。Playerでは表示できません。Playerで非同期デコードを使用するように設定します。それにより、画像は読み込み時にバックグラウンドスレッドを使用して解凍されるようになり、UIがブロックされることはなくなります。BitmapData.copyPixels()のコールです。BitmapData.draw()のコールです。その他にも、DisplayListのレンダリングに関連して、Scoutで表示される可能性のある処理があります。PlayerがDisplayListをラスタライズする表示バッファーを作成しています。この処理は通常、プレーヤーインスタンスの作成時に一度実行するだけで済みます。表示バッファーのサイズを調整しています。通常はステージのサイズ変更に応じて調整します。レンダリングパスが開始されようとしています。updateAfterEvent()をコールしたためです。fpsなど)を設定した場合、この関数をコールする必要はまったくありません。Playerが既にフレームごとに少なくとも1つのレンダリングパスを実行しているためです。明示的にstage.invalidate()をコールする場合、Event.RENDERイベントが、あらゆる登録済みのハンドラーに送出され、その直後にレンダリングパスが開始されます。クロスプラットフォームのハードウェアアクセラレーションによるレンダリングが可能になります。その仕組みは従来のDisplayListモデルとはまったく異なります。Stage3Dの上で動作するStarlingフレームワークには、2DコンテンツのDisplayList用に類似したAPIが用意されています。Stage3Dコンテンツは、画面上ではDisplayListの下の独自の表示バッファーにレンダリングされます。Stage3Dレンダリングサイクルの基本構造では、まず、GPUの状態(使用するテクスチャ、メッシュ、シェーダーをアップロード中)を設定してから、多数の描画コールをGPUに発行して、一連の三角形を目的のバッファーにレンダリングさせます。シーンを作成できたら、Context3D.present()をコールして、実際にそのシーンを画面に表示します。実際の処理は次の2つの場所で実行されます。flash.display3Dパッケージを使用したコールです。Sampler(ActionScriptサンプラー)をScoutで有効にします。APIにかかっている時間を確認できます。ActionScriptパネルでは、最も遅いコールを調査できます。最終的に、ほとんどの処理(実際のレンダリングなど)を実行しているのは、グラフィックカードです。Scoutでは現在のところ、GPUの処理時間に関する情報は表示されませんが、SummaryパネルでGPUのメモリ使用率を確認できます。ボトルネックがGPUだと考える場合は、この後のGPU関連のパフォーマンスの問題についての諸注意を参照してください。Playerが新しいプレーヤーインスタンスを起動するときは、まず、メインのSWFファイルをダウンロードし、解析して、メモリに読み込んでから、その実行を開始できるようになります。Playerのネットワークコンポーネントのものと多数重複していることに注意)。Playerが読み込もうとしているメインのSWFのURLです。Playerのスタンドアロンバージョンを実行しているときに表示されます。指定したURLにあるファイルをダウンロードしています。Loader.load()を使用して読み込むリソースのデータをネットワーク経由で受信しています。データが受信されるたびに、ProgressEvent.PROGRESSイベントが登録済みのハンドラーに送出されます。SWFファイルの一部であるデータを受信しています。JPEG、PNG、GIFなどの画像の一部であるデータを受信しています。SWFデータを解析し、必要に応じて解凍しています。Loaderによって使用されていたネットワーク接続を閉じています。これは、読み込みの完了、エラーの発生、Loader.close()のコールにより発生している可能性があります。ActionScriptバイトコードをデコードして、実行可能な形式に変換しています。あらゆる関数やクラス定義の外で定義された変数を初期化しています。2のMovieClipLoader.onLoadInitイベントハンドラーです。Playerでサポートされるネットワーク処理には主に3種類あります。ローカル接続、TCP/HTTP接続、ストリーミングメディアです。いずれを使用する場合も通常は、ネットワーク接続の設定か要求の開始から始めます。ネットワーク処理には時間がかかるため、同期的には実行されません。Playerがバックグラウンドでネットワーク処理を実行します。処理が終了したかを調べて、最新のステータスを取得できます。そのためには、該当するイベントのイベントハンドラーを登録します。同じマシン上で2つのプレーヤーインスタンスがやり取りをできるようにするには(例えば、ヘルパーSWFを読み込んだ場合)、LocalConnectionオブジェクトを設定して、関数間での呼び出しを可能にできます。Scoutでは、ローカル接続に関連する次のアクティビティが表示されます。arguments)のコールの結果として使用しています。LocalConnectionオブジェクトのデータの送受信など、ローカル接続の一般的な処理を実行しています。コンテンツ(画像やその他のSWFなど)をダウンロードするときは通常、HTTPを使用するLoaderまたはURLLoaderオブジェクトを利用します。NetConnectionを使用してサーバーからデータを送受信することもできます。Scoutでは、この処理に関連する次のアクティビティが表示されます。Playerによってキューに入れられます。定期的に、これらのキュー内の要求はネットワーク経由で送信されます。URL要求が送信された時刻です。Playerが要求しているURLです。URL要求の一意の識別子です。Responderオブジェクトのコンストラクターに渡されたいずれかの関数のコールです。NetConnection.call()の成功またはエラー返却に対応します。一般的なネットワークのオーバーヘッドです。バッファー内を調べて、あらゆるデータが到着したかどうかを確認しています。Playerは、サーバーからのストリーミングメディア(オーディオやビデオのデータなど)用の多数のプロトコルもサポートしています。プロトコルを指定したNetConnectionを使用して、NetStreamを作成できます。Protocol(RTMFP)はUDP上で機能します。Scoutでは、ストリーミングに関連する次のアクティビティが表示されます。サーバーから一連のオーディオまたはビデオデータを受信しています。Playerで再生できるようにしています。テーマなど)を受信しています。メタデータの受信時に呼び出すイベントハンドラーを登録できます。そのためには、onMetaDataプロパティ(NetStream.clientオブジェクトのプロパティ)を設定します。サーバーからのコマンドメッセージを処理しています。Playerに、以前に要求されたコマンドの状態を通知しています。これは、ストリームの終了、エラーの発生、NetStream.close()のコールにより発生している可能性があります。3オブジェクトのデータを受信しています(複数のクライアント間で共有)。これはSharedObject.connect()のコールの結果である可能性があります。Playerはサウンドを効率的に再生します。サウンドの処理の実行にかかった時間は、SoundオブジェクトやSoundChannelオブジェクトなどでのflash.mediaパッケージの関数のコールとして、ScoutのActionScriptパネルで表示されます。次のアクティビティが表示される場合もあります。2ではSound.onSoundCompleteハンドラーです。3ではSoundChannelオブジェクトのEvent.SOUND_COMPLETEハンドラーです。Playerでのビデオ再生は基本的には、実行時間の長いネットワーク処理です。Playerで再生するビデオを指定すると、継続実行のアクティビティがバックグラウンドで開始されます。データは定期的に、ネットワーク経由で到着し、解凍されてから、画面上に表示されます。必要なCPU時間は、プラットフォーム、コーデック、その他のビデオの設定によって、大きく異なることがあります。Scoutでは現在のところ、ビデオパフォーマンスについてそれほど多くの情報は表示されませんが、次のアクティビティが表示される場合があります。StageVideoオブジェクトを設定しています。Playerアクティビティがいくつかあります。2コードを実行しています。2を記述していない場合でも表示される場合があります。2コードを自動的に生成して、特定の初期化関数やハウスキーピング関数を実行するためです。AIRアプリケーションの起動時にActionScriptコードを実行しています。Professionalで作成したボタンオブジェクトなど)を処理できるように特殊なコードが用意されています。PlayerはこれらのボタンのいずれかのDisplayListを検索します。DisplayListに多数のオブジェクトがある場合、この処理のコストは高くなることがあります。既知の問題として、旧式のボタンオブジェクトを使用しない場合でも、この処理が発生します。アドビはこの問題の解決に取り組んでいます。その他のあらゆるアクティビティにかかる時間に対応します。Playerは通常、長時間かかるアクティビティのみを測定します。そのため、実行するその他の細かいアクティビティは、このカテゴリにまとめて分類されます。したアクティビティにかかるわずかな時間は無視してもかまわず、心配する必要はありません。Playerが何らかの処理の発生を待機しているとき、それは非アクティブ時間としてScoutに表示されます。原因として考えられるのは、何かにブロックされているか、実行する処理がないことです。ScoutのSummary(概要)パネルで「Inactive(非アクティブ)」カテゴリを展開すると、次の全部または一部のサブカテゴリが表示されます。現在のフレームで実行するべき処理は残っていません。そのため、プレーヤーインスタンスは、次のフレームの処理が発生するか、何らかの外部イベント(マウスイベント、ネットワークイベントなど)が発生するまで、スリープ状態になります。Playerはグラフィックカードによる何らかの処理の実行を待機しています。詳しくは、GPU関連のパフォーマンスの問題についての諸注意を参照してください。ワーカースレッドがCondition.wait()、MessageChannel.send()、またはMessageChannel.receive()コールでブロックされています。Playerは使用されるメモリも追跡します。ScoutのSummary(概要)パネルで、ちょうどCPU時間のように、メモリをカテゴリ別に確認できます。Playerは、明示的に割り当てるメモリのみを追跡します。一部のメモリはオペレーティングシステムが割り当てます。Playerの実行可能ファイルを格納するためになどです。したメモリはScoutには表示されません。Scoutでセッションのメモリ使用率を確認するとき、知っておくべき重要なことは、メモリ合計が、動作中のすべてのプレーヤーインスタンスによって使用されているメモリだということです。Players(別のプレイヤー)」の「Other(その他)」カテゴリに表示されます。「Uncategorized(未分類)」のメモリの一部も、他のプレーヤーインスタンスによって使用されている可能性があります。Player内で共有されるため、そのデータ構造がどのプレーヤーインスタンスに属するかを把握することは難しくなります。ブラウザーでコンテンツのプロファイリングを行うとき、可能であればSWFのみを実行することをお勧めします。Playerは、メモリを大量に使用する主要なデータ構造をできる限り追跡しようとしますが、領域によって追跡の程度は異なります。現在のところ、オーディオおよびビデオバッファーによって使用されるメモリ、JITコンパイルされたActionScriptコードによって使用されるメモリは測定されません。したメモリは、追跡対象外の他の内部データ構造と共に、「Uncategorized(未分類)」に表示されます。GPU関連のパフォーマンスの問題についての諸注意GPUはグラフィックカード上の特化したプロセッサーであり、ハードウェアアクセラレーションによるレンダリングを行うことができます。GPUは大量の三角形の配置や色付けなど、大規模な並列計算が得意です。この点はCPUとは対照的です。CPUははるかに複雑な処理を実行できますが、得意なのは一度に1つの処理を実行することです。APIが用意されています。作業をより楽にするには、高レベルのフレームワークを使用します。2DコンテンツにはStarling、3DコンテンツにはAway3Dを使用します。これらのフレームワークでは、GPUを舞台裏で使用していることを忘れないでください。Stage3Dの使用時に覚えておくべきことは、GPUがCPUと並列に実行されることです。コンテンツの速度が最も遅いコンポーネントによって制限されるということです。ActionScriptが高速であっても(その結果CPUに過負荷がかからなくても)、GPUに割り当てる処理が多すぎた場合、目的のフレームレートを達成することはできません。GPU使用時の最も一般的なパフォーマンスの問題は次の2つです。GPUへの処理負荷が高すぎる。その最も一般的な原因は、GPUへの描画コールが多すぎること、GPUの状態の変更が頻繁すぎること、使用するメッシュとテクスチャが大きすぎることです。コンテンツを最適化する方法は多数あります。圧縮されたテクスチャを使用すること、Starlingのテクスチャアトラスを使用すること、もちろん、レンダリングしようとしているオブジェクトを単純化することです。現在のところScoutでは、GPUによる処理は表示されません。レンダリング)パネルを使用すると、実行しているStage3Dコマンドを確認したり、最適化する方法を見つけ出したりできます。GPUの処理能力を超えた速度で画面を更新しようとしている。グラフィックカードは、ダブルバッファリングと呼ばれる手法を使用して動作します。一方のバッファーは、現在画面に表示されているデータの格納に使用され、他方のバッファー(バックバッファー)は、表示する次の画像の作成に使用されます。Context3D.present()をコールするとき、描画していたものをGPUに表示するように指示します。GPUはこれらの2つのバッファーを切り替える必要があります。GPUは1/60秒ごとにしかバッファーを切り替えることはできません。これはVSyncとして知られており、モニターによる画像の更新速度に関係します。待機)」として表示されます。これは通常は問題になりませんが、GPUがVSync速度に追いつくことができず、何度も更新期限に遅れた場合、GPUによる次のVSyncの更新を待機することがあります。この場合は、パフォーマンスを向上させるために、フレームレートを下げて、待機時間が増えないようにできます。ここで大きなヒントがあります。Playerでハードウェアアクセラレーションを一時的に無効にしてみてください(右クリックして「Settings(設定)」を選択)。Playerがソフトウェアレンダリングに切り替わり、待機時間がなくなったら、問題がGPUに関係していることを確認できます。Playerの仕組みについてより詳しく理解できました。Scoutを使用してコンテンツをより効果的に最適化できるようになります。Scoutの使用中に、表示されるアクティビティの意味を忘れてしまった場合は、参考としてこの記事を使用できることを覚えておいてください。Scoutをプロファイリングに大いにお役立てください。地域を選択してください地域を選択すると、アドビサイトで使用する言語と内容が変わります。