必要条件

この記事に必要な予備知識

この記事を最大限に活用するには、まず、Getting started with Adobe Scoutファーストステップガイドを参照してください。

ユーザーレベル

中級

原文 作成日: 2013/3/20

Understanding Flash Player with Adobe Scoute

Adobe Scoutは、Flashコンテンツを最適化するための、非常に強力なツールです。Scoutを使用すると、Flash Playerの舞台裏の状況を確認できるようになるためです。こうした情報の取得が最も役立つのは、なぜどのような処理をFlash Playerが実行しているかを把握する場合です。その場合のみ、Scoutで問題の解決方法を効率的に見つけ出すことができます。

この記事の目的は、Flash Playerによって実行されるアクティビティの基本知識を提供し、Scoutに表示される情報にそれらのアクティビティを関連付けることです。この記事は、Scoutで使用される用語のリファレンスガイドでもあります。したがって、Flash Playerによって実行される様々なアクティビティの意味を調べることができます。Scoutを使用していて、「xの実行に時間がかかりすぎているのは分かるが、このxがどういう意味であるかが分からない」と思っている場合、この記事は役立ちます。

ただし、Scoutのユーザーインターフェイスのガイドではないことに注意してください。Scoutの使用方法、様々なパネルの機能が分からない場合は、まず、ファーストステップガイドを参照してください。

Flash Playerの概要

Flash Playerは、あなたに代わって面倒な処理の手配をし、あなたと実世界の間の仲立ちをする点で、あなたの個人秘書のようなものです。しかし、Flash Playerはそれ自体では、あなたに役立つことは何も行うことはできません。何をするかはあなたが指示する必要があります。そのためには2つの方法があります。

  • タイムライン。Flash Professionalで作成します。これらはフレーム単位のアニメーションです。一連のタグとして表現されます。タグは、各フレームで何をするか(画面中をオブジェクトが動き回るようにするなど)を記述したシンプルな指示です。Flash Professionalで視覚的に行ったすべての操作(例えば、フレームへのオブジェクトの追加やトゥイーンの設定など)は、SWFファイルでタグとしてエンコードされます。
  • スクリプト。純粋なActionScriptで記述します。スクリプトはFlash Playerによって特定のタイミングで実行されます。例えば、SWFが読み込まれたとき、タイマーが開始されたとき、マウスクリックが発生したときなどです。また、Flash Professionalで、スクリプトを個々のフレームにアタッチすることもできます。

Flash Playerがスクリプト、またはタイムライン内のタグを実行すると、Flash Playerには実行するべき様々なアクティビティが発生します。それらのアクティビティは大まかに次の4つのカテゴリに分類できます。

  • 即時実行のアクティビティ。これらの処理はFlash Playerがすぐに実行します。処理が完了するまで、コンテンツの実行は続行されません。例えば、新しいビットマップの作成やHTTP要求の開始などです。
  • 継続実行のアクティビティ。これらの処理は、開始されてから終了するか停止されるまで、Flash Playerがバックグラウンドで実行し続けます。例えば、サウンドの再生やファイルのダウンロードなどです。
  • 遅延実行のアクティビティ。これらの処理は、スクリプトまたはタグでは大きな処理には見えなくても、Flash Playerがしばらくしてから実行する大きな処理としてスケジュールします。例えば、表示オブジェクトの位置を変更すると、そのオブジェクトは「dirty(ダーティ)」としてマークされます。これは、Flash Playerがしばらくしてからそのオブジェクトを再レンダリングする必要があることを意味します。
  • 暗黙実行のアクティビティ。要求されなくてもFlash Playerが実行する組み込みの処理です。例えば、ガベージコレクションや、オペレーティングシステムからのマウスおよびキーボードイベントの受信などです。

上記の点は、この記事を読み進むにあたって重要ですので、覚えておいてください。Flash PlayerはActionScriptのみを実行しているわけではありません。他の多くのアクティビティも実行しています。あなたの個人秘書としてFlash Playerを考えるなら、ActionScriptの実行中は会議で離席中に例えられます。それほど長い会議でない場合でも、Flash Playerは会議後に、あなたが指示したすべての事務処理を実行する必要があります。凝ったアニメーションのレンダリングには時間がかかり、実際の処理のほとんどがActionScriptの外部で発生するのです。

プレーヤーインスタンスとセッション

Flash Playerが上記のような様々なアクティビティの実行をどのように管理するか、疑問に思うかもしれません。

WebブラウザーでFlashコンテンツを実行すると、Flash Playerは通常、オペレーティングシステムの個別のプロセスで実行されます。1つのプロセスのみが、そのブラウザー内で実行されるすべてのSWF(関連するあらゆるワーカースレッドも含む)に使用されます。Flash PlayerによってこれらのSWFの実行が管理されるため、各SWFがそれぞれ独立して実行されているように見えます。実行されている各SWFは、プレーヤーインスタンスとして知られており、Scoutでのセッションに対応します。ワーカースレッドもプレーヤーインスタンスです。AIRコンテンツの場合、メインのプレーヤーインスタンスが1つと、そのインスタンスが使用するワーカーがあるだけです。

プレーヤーインスタンスの実行

Flash Playerが実行されると、様々なアクティビティ間で切り替わります。例えば、小さいスクリプトを実行してから、ビデオを再生し、その後、グラフィックをレンダリングします。アクティビティの正確な組み合わせは、どのようなイベントが発生するか、どのような継続実行のアクティビティが進行中であるか、どのようなアクティビティがSWFのスクリプトおよびタイムラインによって要求されたかによって決まります。いずれのアクティビティの実行中でも、Flash Playerは実行状況を記録し、CPU時間、CPUメモリ、GPUメモリなど、消費されているリソースを測定します。これらの測定値はScoutに送信されるため、何が起こっているかをScoutで確認できるようになります。こうした測定のオーバーヘッドを最小限に抑えるために、Flash Playerは、時間やメモリを大量に消費するアクティビティのみを測定してレポートします。

最も基本的なレベルでは、Flash Playerはどのタイミングでも次の2つのモードのいずれかになります。

  • Active(アクティブ) - 有効な何らかの処理を実行しています。ActionScriptの実行から、レンダリング、マウスイベントに至るまで、あらゆる種類の処理が考えられます。
  • Inactive(非アクティブ) - 一時停止中です(ティーブレイクに例えることができます。ただし、Flash Playerにお茶を出す必要はありません)。何らかの外部条件(GPUなど)でブロックされている可能性があります。または、実行する処理がないだけという可能性もあります。

Scoutでは、合計時間(アクティブ時間と非アクティブ時間の合計)は、Frame Timeline(フレームタイムライン)で灰色のバーで示されます。Flash Playerが様々な種類のアクティビティにかける時間の割合をより簡単に視覚化するために、Scoutでは、アクティブ時間を次の4つのトップレベルカテゴリに分類します。

  • ActionScript(青) - ActionScript API内でActionScriptコードの実行にかかった時間。
  • DisplayList Rendering(DisplayList レンダリング)(緑) - DisplayListの処理(ラスタライズ、画面への描画など)の実行にかかった時間。別のActionScript APIを使用するStage3Dレンダリングは含まれていないことに注意してください。
  • Network and Video(ネットワークとビデオ)(黄色) - ビデオのネットワーク経由のダウンロード、ストリーミング、デコードにかかった時間。
  • Other(その他)(オレンジ) - ガベージコレクション、イベントの処理、SWFの解析など、その他のすべての処理の実行にかかった時間。

ここで理解しておくべき重要なことは、Scoutで表示されるのが経過時間であり、CPU時間ではないということです。ちょうどFlash Playerがストップウォッチを持って、各アクティビティのタイムを測っていると考えてください。オペレーティングシステムが、Flash Playerのアクティビティの実行中に割り込んで、しばらくの間、他のアプリケーションを実行した場合、Flash Playerが測定する経過時間はより長くなります。最も正確なデータを得るには、Scoutでプロファイリングを行っている間、他のアプリケーションを閉じる必要があります。

Flash Playerのハートビート

多くのFlashアプリケーション、特にゲームは、大量のグラフィックアニメーションを処理します。アニメーションの処理の基本原理は、一定の周期で(例えば1秒当たり60回)画面を再描画することです。それにより、スムーズなアニメーションに見えます。このプログラミング手法に役立つように、Flash Playerの中核のコンセプトにあるのがフレームです。Flash Playerの心臓部には、一定の周期でハートビートを刻むタイマーがあります。この周期がフレームレートと呼ばれます。これらのハートビート間の時間がフレームと呼ばれます。コンテンツを実行するフレームレートは指定できます。その指定にはSWFのプロパティを使用します。このプロパティはSWFの実行中にActionScriptから動的に変更できます。

そのための一般的なプログラミング方法は、イベントハンドラーをEvent.ENTER_FRAMEに登録することです。このイベントは、ハートビートと新しいフレームの開始に対応します。ゲームを作成している場合は、このイベントハンドラーを使用して、ゲームの継続に必要な定期的な処理をすべて実行できます。例えば、ユーザーからの入力を処理し、物理エンジンを使用してゲームの状態を更新し、最後に、更新されたシーンをレンダリングできます。

Scoutでプロファイリングを行うと、Frame Timeline(フレームタイムライン)には、Flash Playerが各フレームの実行にかけた時間が表示されます。1秒当たり60フレーム(60 fps)のフレームレートを達成するゲームを考えてみましょう。1秒は1,000ミリ秒(ms)ですので、バジェットは1フレーム当たり1,000/60 = 16.7 msです。1フレーム当たりに平均でこれより長くかかっている場合、Flash Playerは要求されたフレームレートで実行できていないことになり、コンテンツは遅く、ぎくしゃくして見えることがあります。ScoutのFrame Timeline(フレームタイムライン)では、赤い水平ラインはバジェットを示します。灰色のバーは、1フレーム当たりにかかった合計時間を示します。

1フレーム内で、Flash Playerは様々なアクティビティを実行します。まず実行するアクティビティの1つが、Event.ENTER_FRAMEイベントを送出して、登録済みのイベントハンドラーをコールすることです。ハンドラーがActionScriptコードを実行するとき、遅延実行または継続実行の新しいアクティビティ(画面の一部の再描画、新しいファイルのダウンロード開始など)が「To Doリスト」に追加される可能性があります。これらのアクティビティは、このフレーム中にしばらくしてから実行する必要があります。また、マウス、キーボード、その他のイベントが、このフレーム中に発生する可能性もあり、これらのイベントも処理する必要があります。最終的に、Flash Playerはそのフレーム中の処理をすべて完了し、実行するべき処理を残しません。その後、次のハートビートを待機して受信すると、新しいフレームに対してまた初めから処理を開始します。

Scoutで主に注意するべきなのは、赤いラインを超えている色付きのバーです。これは、Flash Playerが実行するべき処理をすべて完了するために、フレーム全体のバジェットよりも長くかかっていることを意味します。つまり、Flash Playerが割り当てられた時間内に処理するべき処理が多すぎるということです。すべてのフレームが一貫してバジェットを超える場合は通常、コンテンツは遅くなります(図1参照)。一方、不規則なスパイクがある場合、コンテンツはぎくしゃくして見えるようになります。

適切なタイミングでフレームを終了しても、Flash Playerは常に、次のフレームを開始する前に待機することに注意してください。これは正常です。コンテンツがデバイスのすべてのリソースを占有していないということです。その結果、消費電力は削減され、CPU時間は他の処理の実行に割り当てられます。また、コンテンツに猶予時間が組み込まれているということです。その結果、コンテンツはより遅いデバイス上でも目的のフレームレートで実行できます。灰色のバーが赤いラインの上下で推移するのはまったく正常です(図2参照)。

フレームについて次の細かい点に注意してください。

  • Flash Playerの最大フレームレートは60 fpsです。60 fpsよりも高いフレームレートを設定しても、コンテンツがこのレートよりも速くなることはありません。ほとんどのモニターは、60 fpsを超えるフレームレートをサポートしないことを忘れないでください。これよりも速く画面を更新しようとすることは絶対に避けてください。
  • Flash Playerはオペレーティングシステムと適切に連携しようとします。Webを閲覧するときに実行中のプレーヤーインスタンスが多数ある場合、それらのフレームレートはすべて異なることがあります。Flash Playerはランダムなタイミングでウェイクアップして、コンピューターを遅くするのではなく、プレーヤーインスタンス間でウェイクアップタイミングを同期しようとします。大まかに言うと、1/60秒ごとにウェイクアップし、準備ができているプレーヤーインスタンスで新しいフレームを開始します。つまり、60等分されないフレームレートを設定した場合、例えば24 fpsに設定した場合、灰色のバーが赤いラインの上下を推移することが分かります(図3参照)。これは正常であり、問題ではありません。ただし、平均で目的のフレームレートを満たしている必要はあります(Scoutでフレームを範囲選択すると、平均のフレームレートを表示できます)。
  • Scoutで、灰色のバーが一貫して赤いラインの上にある場合、色付きのバー(アクティブ時を示す)が常に赤いラインの下にあっても、おそらくコンピューター上で動作中の他のアプリケーションがCPUリソースを使い果たしています。他のアプリケーションとブラウザーウィンドウをシャットダウンしてみてください。

Flash Playerのコンポーネント

Flash Playerの基本構造をより深く理解できたところで、次は、Scoutに表示されるデータをさらに掘り下げてみましょう。Top Activities(上位アクティビティ)およびActivity Sequence(アクティビティシーケンス)パネルでは、Flash Playerによる処理について詳細な内訳を得られることが分かります。これらのパネルでは、説明はできる限り自明であるように設計されていますが、場合によっては問題の根本原因にたどり着くために、もう少し詳しい情報が必要になることがあります。このセクションでは、Flash Playerの様々なアクティビティを機能領域にグループ化し(図4参照)、それらの意味をより詳しく説明します。



Scoutの使用時にリファレンスガイドとしてこのセクションを参照して、現在の問題に該当する部分だけを読むことができます。または、セクション全体を読んで、Flash Playerの様々な部分の仕組みについて理解を深めることもできます。

ActionScript 3とイベント処理

ActionScriptはFlashの言語であり、Flash Playerに何をするかを指示できます。SWFのビルド時、ActionScriptコードは低レベル言語(ActionScriptバイトコード)にコンパイルされ、Flash Playerが理解できるようになります。このバイトコードはSWFの動作時にActionScript Virtual Machine(AVM)によって実行されます。AVMは、ActionScriptの特定のコア機能(ガベージコレクション、例外など)を実装し、コードとFlash Playerの橋渡し役を果たします。

ActionScriptからAPIを使用して、Flash Playerを操作できます。こうしたAPIのコールは通常の関数のコールのように見えますが、内部では多くの場合、ネイティブCコードをコールすることで、高度な処理が実行されています。Scoutでは、これらのAPIは、ActionScriptパネルで通常の関数のコールとして表示されるため、内部の詳細を心配する必要はありません。APIのコールに時間がかかりすぎる場合は、コールの頻度を低くするか、処理負荷を減らします(引数のサイズを小さくしたり、引数を単純化したりする)。

ActionScriptからFlash Playerを呼び出すだけでなく、コードを実行するタイミングをFlash Playerに指示する必要があります。ほとんどの場合、そのためにはイベントハンドラーを使用します。イベントハンドラーは、特定のイベントが発生したときにコールされるように登録する関数です。カスタムイベントを作成し、EventDispatcher.dispatch()を使用して、イベントハンドラーを手動でコールできます。しかし多くの場合、マウスの動きやキーの押下などの外部イベントを待機させたいと考えます。Scoutでは、この処理に関連する多数のアクティビティがあります。

  • Handling event "<name>"(イベント「<name>」の処理) - Flash Playerがオペレーティングシステムからの外部イベントを常に待機して受信しています。イベントを受信すると、まず、該当する処理を実行し、どのイベントハンドラーを呼び出すかを割り出す必要があります(例えば、キーボードイベントの場合、呼び出すハンドラーは、どのオブジェクトにキーボードフォーカスがあるかによって決まります)。Scoutでは、次のいくつかの外部イベントが表示されます。
    • キーボードイベント:keyDownkeyPresskeyUp
    • マウスイベント:mouseDownrightMouseDownmouseMovemouseUpmouseWheel
    • タッチおよびジェスチャーイベント:touchgesture
    • ウィンドウイベント:resizemouseLeaveforegroundbackgroundfullScreenfullScreenInteractiveAcceptedvisible
  • Event "<name>"(イベント「<name>」) - これはイベント<name>の実際のActionScriptイベントハンドラーです。これが表示されるのは、イベントハンドラーを作成して登録している場合のみです(このことは上記のイベントだけでなく、どのイベントにも適用されます)。ここで役立つヒントがあります。ScoutのActivity Sequence(アクティビティシーケンス)またはTop Activities(上位アクティビティ)パネルでイベントをクリックすると、ActionScriptパネルがフィルターされて、この特定のイベントハンドラー内で実行されたコードのみが表示されるようになります。

タイマーは外部イベントとほとんど同じように処理されますが、自分で設定する必要があります。

  • Handling event "timer"(イベント「timer」の処理)TimerEvent.TIMERイベントをあらゆる登録済みのハンドラーに送出しています。
  • Timer started(開始されたタイマー): <interval> – タイマーの開始が表示され、タイマーイベント間の遅延が<interval> msで示されます。

また次のように、コードの実行およびActionScriptの言語機能のサポートに関連する多数のAVMアクティビティがあります。

  • Garbage collection(ガベージコレクション) - 明示的なメモリ管理を必要とするCやその他の言語とは異なり、ActionScriptはメモリの割り当てと解放を自動的に処理します。Flash Playerは定期的にガベージコレクターを実行して、参照されなくなった(参照しているものが何もない)あらゆるオブジェクトをスキャンし、そうしたオブジェクトによって使用されているメモリを解放します。コンテンツのガベージコレクションの実行に長時間かかっている場合は、作成しているオブジェクトが多すぎるということです。可能であれば、オブジェクトのキャッシュまたはプールにより、新しいインスタンスを常に作成することを避けてみてください。
  • Trace: <output> – ActionScriptのtrace()ステートメントの出力です。Trace Log(トレースログ)パネルでこのデータを表示することもできます。
  • Exception(例外): <class> - ActionScriptの実行中に発生するあらゆる例外のスタックトレースです。これは、例外がキャッチされて処理された場合でも表示されるため、Scoutでこの例外が表示されても、必ずしもコードに問題があるわけではありません。
  • Handling uncaught error(不明なエラーの処理)UncaughtErrorEvent.UNCAUGHT_ERRORをあらゆる登録済みのハンドラーに送出しています。

最後に次のように、他の言語からActionScript 3コードを呼び出す場合に表示されるいくつかのアクティビティがあります。

  • AVM Bridge callback(AVM ブリッジコールバック) - ActionScript 2からActionScript 3コードへのコールです。
  • ExternalInterface callback(ExternalInterface コールバック) - JavaScriptコードからActionScript 3コードへのコールです。

ActionScriptワーカー

コンテンツ内にActionScriptワーカーを使用している場合、それらのワーカーはScoutで個別のセッションとして表示されます。内部では、個別のプレーヤーインスタンスにすぎず、APIを使用して相互にデータを共有します。Scoutでのワーカーのサポートは現在のところ、ベータ版の機能です。このサポートを有効にするには、次の操作を実行する必要があります。

  • Scoutで、「Preferences(環境設定)」>「Beta Features(ベータ版の機能)」に移動し、「Start Sessions For ActionScript Workers(ActionScript ワーカーのセッションを開始)」を選択します。
  • Scoutのサイドバー(表示されていない場合は「Window(ウィンドウ)」>「Sidebar(サイドバー)」を選択)で、「ActionScript Sample(ActionScript サンプラー)」が有効になっていることを確認します。
  • コンテンツで高度なTelemetryが有効になっていることも確認します(その方法が分からない場合は、ファーストステップガイドを参照)。

ActionScriptワーカーを使用しているコンテンツについて、Scoutで次のアクティビティが表示される場合があります。

  • Running Worker code(ワーカーコードの実行) - ワーカーを起動して、その内部でActionScriptを継続的に実行する場合(イベント駆動の関数ではなく、1つの長時間実行される関数をワーカーが実行する場合)、Scoutでこのアクティビティが表示されます。ワーカーのトップレベルのエントリポイントに制御がまだあり、どのイベントにも対応していないということです。
  • Waiting for Condition(条件の待機)Condition.wait()のコールがブロックされています。
  • MessageChannel.receiveMessageChannel.receive()のコールがブロックされています。
  • MessageChannel.sendMessageChannel.send()のコールがブロックされています。
  • Mutex.lockMutex.lock()のコールがブロックされています。
  • Mutex.trylockMutex.trylock()のコールがブロックされています。

ユーザーアクティビティ

Flash Playerが作成する組み込みの測定データに加えて、Telemetry APIを使用してカスタムデータをScoutに送信できます。2つのメインのコールは次のとおりです。

  • Telemetry.sendMetric(name, value) - 名前と値のペアをScoutにレポートします。それらのデータはActivity Sequence(アクティビティシーケンス)パネルに表示されます。例えば、Telemetry.sendMetric("UserID", 2)をコールする場合、コードが実行されると、Activity Sequence(アクティビティシーケンス)パネルに「UserID: 2」が表示されます。
  • Telemetry.sendSpanMetric(name, startTime, value) - アクティビティをオプションの値と共にScoutにレポートします。開始時刻を記録するには、Telemetry.spanMarkerで調べて、Telemetry.sendSpanMetricに測定期間の終了時に渡します。それにより、開始時刻はScoutの Top Activities(上位アクティビティ)とActivity Sequence(アクティビティシーケンス)の両方のパネルに表示されます。

その使用方法の詳細といくつかの例については、Telemetry APIのドキュメントを参照してください。

フレームティッカー

Flash Playerの中核にあるのが、フレームティッカーです。このハートビートは新しいフレームの開始時ごとに送信されます。フレームの開始時ごとに、あらゆるタイムラインタグを実行し、タイムライン上のあらゆるフレームスクリプトを呼び出して、いくつかの重要なActionScript 3イベントを送出します。次のようなフレームティッカーのアクティビティがあります。

  • Running SWF tags for frame(フレームの SWF タグの実行) - Flash Playerはフレームに関連付けられたSWFタグを実行しています。これは通常、Flash Professionalでの処理に相当します。例えば、フレームにアタッチしたオブジェクトを作成して、トゥイーンに従って動き回るようにすることなどです。
  • Running frame actions(フレームアクションの実行 ) - Flash ProfessionalのAction(アクション)パネルを使用して、タイムライン上のフレームにアタッチするスクリプトです。そのスクリプトはActionScript 2でもActionScript 3でもかまいません。ActionScript 3の場合は、すぐに実行されないことがありますが、キューに入れられ、フレームが終了するまでにはFlash Playerが実行します。
  • Running AS3 attached to frame(フレームに接続されている AS3 の実行) - タイムライン上のフレームにアタッチされていて、キューに入れられたActionScript 3スクリプトをFlash Playerが実行しています。
  • AS2 event "enterFrame"(AS2 イベント「enterFrame」) – ActionScript 2のMovieClip.onEnterFrameイベントハンドラーです。
  • Handling event "enterFrame"(イベント「enterFrame」の処理) – 新しいフレームの開始時、Flash PlayerはEvent.ENTER_FRAMEの登録済みのハンドラーを検索し、呼び出します。
  • Handling event "frameLabel"(イベント「frameLabel」の処理 ) – 新しいフレームの入力時、そのフレーム内のFrameLabelオブジェクトにEvent.FRAME_LABELの登録済みハンドラーがある場合、そのハンドラーを呼び出します。
  • Handling event "exitFrame"(イベント「exitFrame」の処理) – 現在のフレームの終了直前、Flash PlayerはEvent.EXIT_FRAMEの登録済みのハンドラーを検索し、呼び出します。

DisplayListのレンダリング

DisplayListは、Flash Playerで従来から使用されているレンダリング手法です。基本的に、ステージと呼ばれる空白のキャンバスに、表示オブジェクトと呼ばれるグラフィカルなエンティティをアタッチして配置することで描画します。ベクトルアート、ビットマップ、テキストなど、様々な種類の表示オブジェクトがあり、それらを階層的にネストして、複雑なシーンを作成できます。ActionScriptから表示オブジェクトを操作しても、Flash Proでそれらを配置してトゥイーンを設定しても、表示オブジェクトが実際にレンダリングされる方法について心配する必要はありません。Flash Playerがあなたに代わって難しい処理を実行し、画面上に表示される実際のピクセルにDisplayListを変換する方法を割り出します。

ActionScriptを使用してDisplayListを操作する場合、変更を加えるためにコールできるAPIがいくつかあることに気付くでしょう。こうした変更は即時実行のアクティビティとして考えることができます。APIをコールすると、そのAPIはDisplayListの内部状態を変更します。ただし、実行しないことは、画面上の表示の即時の変更です。代わりに、Flash Playerは変更された表示オブジェクトをdirty(ダーティ)としてマークして、再描画が必要であることを示します。しばらくしてから、コードの実行終了後に、Flash Playerがレンダリングパスを実行します。事実上、Flash Playerはすべての変更をまとめて収集するため、画面は一度更新するだけで済みます。ストップモーションアニメーションのように考えることができます。フレーム内で、すべての小さなクレーフィギュアを微妙に動かして、ポーズが決まったら、Flash Playerがそのフレームのシーンを撮影するようなものです。

ここでは、レンダリングパスがScoutでどのように表示されるかを説明します(図5参照)。

  • Calculating dirty regions(ダーティ領域の計算) - DisplayListをスキャンし、dirty(ダーティ)とマークされた(例えば位置が変更された)あらゆるオブジェクトを検索することで、レンダリングサイクルを開始しています。その後、すべてのdirty(ダーティ)オブジェクトを含む最大3つの長方形を生成します。これらは再描画する必要がある画面の領域です。これらの領域はScoutのDisplayList Rendering(DisplayList レンダリング)パネルで、赤い領域として表示されます。
  • Rendering dirty region(ダーティ領域のレンダリング) - ダーティ領域ごとに、Flash Playerは、新しいピクセルをどうするかを割り出す必要があります。そのために、内部バッファー(表示バッファー)にシーンを作成します。このプロセスに関連するいくつかの手順があります。
    • Building edges from DisplayObject(DisplayObject からのエッジの構築) - Flash PlayerはDisplayListを再びスキャンして、ダーティ領域に重なる表示オブジェクトを検索しています。見つかった各表示オブジェクトを一連のエッジ塗りに分割します(これらは場合によって、単色かグラデーション、またはエッジ間のスペースの色を定義するビットマップです)。表示オブジェクトに他の表示オブジェクトが含まれている場合、この同じプロセスがその他の表示オブジェクトにも再帰的に適用されます。基本的に、Flash Playerは階層的なシーンを様々な塗りの領域に平坦化します。
    • Rasterizing edges(エッジのラスタライズ) - Flash Playerはこの段階で、エッジと色を実際のピクセルに変換する必要があります。ダーティ領域を水平ライン(スキャンライン)に分割します。それぞれが各垂直ピクセルに対応します。スキャンラインはマシン上のコア間で共有されます。Flash Playerは、各スキャンラインをたどって、エッジ間の領域の塗りに基づいて、各ピクセルをどの色で塗るかを割り出します。この処理にかかる時間は、ピクセル数と、各ピクセルの描画コストによって異なります。単色は最小コストで描画できます。一方、回転や拡大/縮小されたビットマップで、アルファブレンドの複数のレイヤーで構成されているものは、コストがかなり高くなることがあります。
    • Applying filter(フィルターの適用): <name> - グローやドロップシャドウなどのフィルターを設定した場合、フィルターはこの段階で、ラスタライズされた画像に適用されています。ただし、表示オブジェクトの子にフィルターを設定した場合は、そのフィルターを適用した後に、親オブジェクトをラスタライズする必要があります。Flash Playerはそのために、子の表示オブジェクトを個別のサーフェスにラスタライズし(ScoutのDisplayList Rendering(DisplayList レンダリング)パネルで青で表示)、フィルターをそのサーフェスに適用します。その結果、新しいビットマップは、親の表示オブジェクトのエッジを作成するときに、アトミックな塗りとして扱われます。
  • Copying to screen(画面へのコピー) - レンダリングパスの最後で、Flash Playerはその表示バッファーから画面にデータをコピーしています。この処理はプレゼンテーションとも呼ばれます。この処理にかかる時間は、コピーする必要のあるピクセルの数によってほとんど決まります。ただし、オペレーティングシステムからのロックの取得時に遅延が生じることがあります。ハードウェアアクセラレーションを使用している場合、表示バッファーがグラフィックカード上に既にあります。つまり、Flash Playerはグラフィックカードにそのバッファー内のデータを表示させるだけで済みます。この処理にかかった時間は「Waiting for GPU(GPU を待機)」に表示されます(詳しくは、GPU関連のパフォーマンスの問題についての諸注意を参照)。表示されない場合は、Flash Playerの最新バージョン(11.5以降)を使用していることを確認してください。

多数のエッジがあり様々なフィルターが適用された複雑なシェイプを描画する場合、レンダリングコストが高くなることがあります。できるだけDisplayListを変更しないようにして、各フレームで再描画する必要があるダーティ領域の数とサイズを減らしてみてください。ほとんど変更することのない(ただし位置を変更することは除く)複雑にネストされたオブジェクトを描画する場合、レンダリングパフォーマンスを向上させるために、そのオブジェクトをキャッシュできます。これにより、表示オブジェクトはキャッシュされたサーフェスにラスタライズされ、変更された場合のみ再作成するだけで済みます。表示オブジェクトの変換のみを行っていた場合は、cacheAsBitmapプロパティを設定します。また、表示オブジェクトを回転したり拡大/縮小したりする場合は、cacheAsBitmapMatrix(AIR on mobileによってのみサポート)を使用してください。

Scoutで、キャッシュされたサーフェスに関連する次のアクティビティが表示されます(DisplayList Rendering(DisplayList レンダリング)パネルにオレンジ色で表示)。

  • Rendering from cached surface(キャッシュされたサーフェスからのレンダリング) - 表示オブジェクトに有効なキャッシュがある場合、Flash Playerはそのキャッシュを使用しています。そのエッジを作成してラスタライズしていません。
  • Updating cached surface(キャッシュされたサーフェスの更新) - キャッシュされた表示オブジェクトまたはその子を変更する場合、キャッシュは無効になるため、作成し直す必要があります。Flash Playerによるキャッシュされたサーフェスの更新に時間がかかりすぎる場合、キャッシュの使用に誤りがあるということです。キャッシュは、ほとんど変更されない表示オブジェクトにのみ使用するべきです。それ以外の場合は、キャッシュしないほうが、更新は速くなります。

Scoutでは、各レンダリングパスの一部として、特定の種類の表示オブジェクトに対して実行されたアクティビティについて、追加情報が表示されます。次のアクティビティはテキストのレンダリングに関係します。

  • Updating text layout(テキストレイアウトの更新) – テキスト表示オブジェクトが変更され(例えば、TextElementまたはTextFieldオブジェクトのtextプロパティが変更され)、再レイアウトが必要です。これにより、表示オブジェクトはdirty(ダーティ)としてマークされ、次のレンダリングパスで再描画も必要になります。
  • Rendering text(テキストのレンダリング) - TextFieldクラスを使用してテキストをレンダリングしています。
  • Rendering FTE text(FTE テキストのレンダリング) - flash.text.engineパッケージのFlash Text Engineクラスを使用してテキストをレンダリングしています。

次のアクティビティはBitmapオブジェクトに関係しており、それらのオブジェクトに関連付けられたビットマップデータ(Bitmap.bitmapData)を操作しています。

  • Creating BitmapData(BitmapData の作成) - BitmapDataオブジェクトのコンストラクターです。ScoutのDisplayList Rendering(DisplayList レンダリング)パネルにのみ表示されます。
  • Decompressing images(イメージの解凍) - JPEGやPNGなどの圧縮された画像を読み込むときは、解凍してからでないと、Flash Playerでは表示できません。この処理に長時間かかっていることが分かった場合は、Flash Playerで非同期デコードを使用するように設定します。それにより、画像は読み込み時にバックグラウンドスレッドを使用して解凍されるようになり、UIがブロックされることはなくなります。
  • BitmapData.copyPixelsBitmapData.copyPixels()のコールです。
  • BitmapData.drawBitmapData.draw()のコールです。

その他にも、DisplayListのレンダリングに関連して、Scoutで表示される可能性のある処理があります。

  • Creating Display Buffer(表示バッファーの作成) - Flash PlayerがDisplayListをラスタライズする表示バッファーを作成しています。この処理は通常、プレーヤーインスタンスの作成時に一度実行するだけで済みます。
  • Resizing Display Buffer(表示バッファーのサイズ変更) - 表示バッファーのサイズを調整しています。通常はステージのサイズ変更に応じて調整します。
  • Triggering UpdateAfterEvent(UpdateAfterEvent のトリガ) – レンダリングパスが開始されようとしています。updateAfterEvent()をコールしたためです。経験からすると、高いフレームレート(30 fpsや60 fpsなど)を設定した場合、この関数をコールする必要はまったくありません。Flash Playerが既にフレームごとに少なくとも1つのレンダリングパスを実行しているためです。
  • Handling event "render"(イベント「render」の処理) – 明示的にstage.invalidate()をコールする場合、Event.RENDERイベントが、あらゆる登録済みのハンドラーに送出され、その直後にレンダリングパスが開始されます。

Stage3Dのレンダリング

Stage3Dは、OpenGLとDirectXに基づくActionScript APIです。クロスプラットフォームのハードウェアアクセラレーションによるレンダリングが可能になります。その仕組みは従来のDisplayListモデルとはまったく異なります。ただし、Stage3Dの上で動作するStarlingフレームワークには、2DコンテンツのDisplayList用に類似したAPIが用意されています。Stage3Dコンテンツは、画面上ではDisplayListの下の独自の表示バッファーにレンダリングされます。

Stage3Dレンダリングサイクルの基本構造では、まず、GPUの状態(使用するテクスチャ、メッシュ、シェーダーをアップロード中)を設定してから、多数の描画コールをGPUに発行して、一連の三角形を目的のバッファーにレンダリングさせます。シーンを作成できたら、Context3D.present()をコールして、実際にそのシーンを画面に表示します。実際の処理は次の2つの場所で実行されます。

  • ActionScript API内部 - flash.display3Dパッケージを使用したコールです。この処理にかかる時間を確認するには、ActionScript Sampler(ActionScriptサンプラー)をScoutで有効にします。Summary(概要)パネルでActionScriptカテゴリを開くと、Stage3D APIにかかっている時間を確認できます。ActionScriptパネルでは、最も遅いコールを調査できます。
  • GPU上 - 最終的に、ほとんどの処理(実際のレンダリングなど)を実行しているのは、グラフィックカードです。Scoutでは現在のところ、GPUの処理時間に関する情報は表示されませんが、SummaryパネルでGPUのメモリ使用率を確認できます。ボトルネックがGPUだと考える場合は、この後のGPU関連のパフォーマンスの問題についての諸注意を参照してください。

SWFのLoader

Flash Playerが新しいプレーヤーインスタンスを起動するときは、まず、メインのSWFファイルをダウンロードし、解析して、メモリに読み込んでから、その実行を開始できるようになります。Scoutで、この処理に関連する次のアクティビティが表示されます(Flash Playerのネットワークコンポーネントのものと多数重複していることに注意)。

  • Loading SWF(SWF の読み込み): <url> - Flash Playerが読み込もうとしているメインのSWFのURLです。Flash Playerのスタンドアロンバージョンを実行しているときに表示されます。
  • Loading file(ファイルの読み込み): <url> - 指定したURLにあるファイルをダウンロードしています。
  • Receiving Loader data(Loader データの受信)Loader.load()を使用して読み込むリソースのデータをネットワーク経由で受信しています。データが受信されるたびに、ProgressEvent.PROGRESSイベントが登録済みのハンドラーに送出されます。
  • Receiving SWF data(SWF データの受信) - SWFファイルの一部であるデータを受信しています。
  • Receiving image data(イメージデータの受信) - JPEG、PNG、GIFなどの画像の一部であるデータを受信しています。
  • Decoding SWF file(SWF ファイルのデコード) - SWFデータを解析し、必要に応じて解凍しています。
  • Closing Loader(Loader のクローズ) - Loaderによって使用されていたネットワーク接続を閉じています。これは、読み込みの完了、エラーの発生、Loader.close()のコールにより発生している可能性があります。
  • Preparing ActionScript bytecode(ActionScript バイトコードの準備) - ActionScriptバイトコードをデコードして、実行可能な形式に変換しています。
  • Initializing AS globals(AS グローバルの初期化) - あらゆる関数やクラス定義の外で定義された変数を初期化しています。
  • Handling event "onLoadInit"(イベント「onLoadInit」の処理) – ActionScript 2のMovieClipLoader.onLoadInitイベントハンドラーです。

ネットワーク

Flash Playerでサポートされるネットワーク処理には主に3種類あります。ローカル接続、TCP/HTTP接続、ストリーミングメディアです。いずれを使用する場合も通常は、ネットワーク接続の設定か要求の開始から始めます。ネットワーク処理には時間がかかるため、同期的には実行されません。何らかの処理を要求したら、ActionScriptコードが他の処理を実行している間に、Flash Playerがバックグラウンドでネットワーク処理を実行します。処理が終了したかを調べて、最新のステータスを取得できます。そのためには、該当するイベントのイベントハンドラーを登録します。

同じマシン上で2つのプレーヤーインスタンスがやり取りをできるようにするには(例えば、ヘルパーSWFを読み込んだ場合)、LocalConnectionオブジェクトを設定して、関数間での呼び出しを可能にできます。Scoutでは、ローカル接続に関連する次のアクティビティが表示されます。

  • LocalConnection callback(LocalConnection コールバック) – 受信側のLocalConnectionオブジェクト内でfunctionName(arguments)を呼び出し、送信側のLocalConnectionオブジェクトのsend(connectionName, functionName, arguments)のコールの結果として使用しています。
  • Handling LocalConnection traffic(LocalConnection トラフィックの処理) - LocalConnectionオブジェクトのデータの送受信など、ローカル接続の一般的な処理を実行しています。

コンテンツ(画像やその他のSWFなど)をダウンロードするときは通常、HTTPを使用するLoaderまたはURLLoaderオブジェクトを利用します。また、HTTP NetConnectionを使用してサーバーからデータを送受信することもできます。Scoutでは、この処理に関連する次のアクティビティが表示されます。

  • Sending URL requests(URL 要求の送信) –HTTPを使用して行われる要求、例えばNetConnection.call()による要求は、Flash Playerによってキューに入れられます。定期的に、これらのキュー内の要求はネットワーク経由で送信されます。
  • URL request timestamp(URL 要求のタイムスタンプ) - URL要求が送信された時刻です。
  • URL request(URL 要求): <url> - Flash Playerが要求しているURLです。
  • URL request ID(URL 要求 ID): <id> - URL要求の一意の識別子です。
  • Responder callback(Responder コールバック) – Responderオブジェクトのコンストラクターに渡されたいずれかの関数のコールです。NetConnection.call()の成功またはエラー返却に対応します。
  • Processing network buffers(ネットワークバッファーの処理) - 一般的なネットワークのオーバーヘッドです。例えば、バッファー内を調べて、あらゆるデータが到着したかどうかを確認しています。

Flash Playerは、サーバーからのストリーミングメディア(オーディオやビデオのデータなど)用の多数のプロトコルもサポートしています。プロトコルを指定したNetConnectionを使用して、NetStreamを作成できます。Real Time Messaging Protocol(RTMP)はTCP上で機能し、Real Time Media Flow Protocol(RTMFP)はUDP上で機能します。Scoutでは、ストリーミングに関連する次のアクティビティが表示されます。

  • Receiving NetStream audio/video(NetStream オーディオ / ビデオの受信) - サーバーから一連のオーディオまたはビデオデータを受信しています。
  • Decoding media from network(ネットワークからのメディアのデコード) - ネットワーク経由で受信したオーディオまたはビデオデータを解凍して、Flash Playerで再生できるようにしています。
  • Receiving NetStream metadata(NetStream メタデータの受信) - 要求されたメディアのメタデータ(作成時間、継続時間、テーマなど)を受信しています。メタデータの受信時に呼び出すイベントハンドラーを登録できます。そのためには、onMetaDataプロパティ(NetStream.clientオブジェクトのプロパティ)を設定します。
  • Receiving NetStream commands(NetStream コマンドの受信) - サーバーからのコマンドメッセージを処理しています。例えば、これらのメッセージはFlash Playerに、以前に要求されたコマンドの状態を通知しています。
  • Closing network connection(ネットワーク接続のクローズ) – これは、ストリームの終了、エラーの発生、NetStream.close()のコールにより発生している可能性があります。
  • Receiving NetStream shared objects(NetStream 共有オブジェクトの受信) - サーバー上に保存されているActionScript 3オブジェクトのデータを受信しています(複数のクライアント間で共有)。これはSharedObject.connect()のコールの結果である可能性があります。

サウンド

ほとんどのデスクトップコンピューターで、Flash Playerはサウンドを効率的に再生します。サウンドの処理の実行にかかった時間は、SoundオブジェクトやSoundChannelオブジェクトなどでのflash.mediaパッケージの関数のコールとして、ScoutのActionScriptパネルで表示されます。次のアクティビティが表示される場合もあります。

  • Dispatching Sound Complete(サウンド完了の送出) – ActionScript 2ではSound.onSoundCompleteハンドラーです。ActionScript 3ではSoundChannelオブジェクトのEvent.SOUND_COMPLETEハンドラーです。

ビデオ

Flash Playerでのビデオ再生は基本的には、実行時間の長いネットワーク処理です。Flash Playerで再生するビデオを指定すると、継続実行のアクティビティがバックグラウンドで開始されます。データは定期的に、ネットワーク経由で到着し、解凍されてから、画面上に表示されます。必要なCPU時間は、プラットフォーム、コーデック、その他のビデオの設定によって、大きく異なることがあります。

Scoutでは現在のところ、ビデオパフォーマンスについてそれほど多くの情報は表示されませんが、次のアクティビティが表示される場合があります。

  • Initializing StageVideo(StageVideo の初期化) - StageVideoオブジェクトを設定しています。

その他のアクティビティ

上記のいずれのカテゴリにも完全には当てはまらないFlash Playerアクティビティがいくつかあります。

  • Running AS2(AS2 の実行) - ActionScript 2コードを実行しています。これは、ActionScript 2を記述していない場合でも表示される場合があります。Flash Playerが何らかのActionScript 2コードを自動的に生成して、特定の初期化関数やハウスキーピング関数を実行するためです。
  • AIR startup(AIR の起動) - AIRアプリケーションの起動時にActionScriptコードを実行しています。
  • Button hit testing(ボタンヒットのテスト) - Flash Playerには、旧式のボタンオブジェクト(Flash Professionalで作成したボタンオブジェクトなど)を処理できるように特殊なコードが用意されています。マウスイベントのActionScriptイベントハンドラーの検索とは関係なく、マウスが動かされるたびに、Flash PlayerはこれらのボタンのいずれかのDisplayListを検索します。DisplayListに多数のオブジェクトがある場合、この処理のコストは高くなることがあります。既知の問題として、旧式のボタンオブジェクトを使用しない場合でも、この処理が発生します。アドビはこの問題の解決に取り組んでいます。
  • Runtime overhead(ランタイムのオーバーヘッド) - その他のあらゆるアクティビティにかかる時間に対応します。Flash Playerは通常、長時間かかるアクティビティのみを測定します。そのため、実行するその他の細かいアクティビティは、このカテゴリにまとめて分類されます。そうしたアクティビティにかかるわずかな時間は無視してもかまわず、心配する必要はありません。

非アクティブ時間

Flash Playerが何らかの処理の発生を待機しているとき、それは非アクティブ時間としてScoutに表示されます。原因として考えられるのは、何かにブロックされているか、実行する処理がないことです。ScoutのSummary(概要)パネルで「Inactive(非アクティブ)」カテゴリを展開すると、次の全部または一部のサブカテゴリが表示されます。

  • Waiting for next frame(次のフレームを待機) - 現在のフレームで実行するべき処理は残っていません。そのため、プレーヤーインスタンスは、次のフレームの処理が発生するか、何らかの外部イベント(マウスイベント、ネットワークイベントなど)が発生するまで、スリープ状態になります。
  • Waiting for GPU(GPU を待機) - Flash Playerはグラフィックカードによる何らかの処理の実行を待機しています。詳しくは、GPU関連のパフォーマンスの問題についての諸注意を参照してください。
  • Waiting for condition(条件の待機) – ワーカースレッドがCondition.wait()MessageChannel.send()、またはMessageChannel.receive()コールでブロックされています。

Scoutでのメモリのレポート

様々なアクティビティにかかる時間を測定するだけでなく、Flash Playerは使用されるメモリも追跡します。ScoutのSummary(概要)パネルで、ちょうどCPU時間のように、メモリをカテゴリ別に確認できます。Flash Playerは、明示的に割り当てるメモリのみを追跡します。一部のメモリはオペレーティングシステムが割り当てます。例えば、Flash Playerの実行可能ファイルを格納するためになどです。そうしたメモリはScoutには表示されません。

Scoutでセッションのメモリ使用率を確認するとき、知っておくべき重要なことは、メモリ合計が、動作中のすべてのプレーヤーインスタンスによって使用されているメモリだということです。他のプレーヤーインスタンスによって使用されているメモリは、「Other Players(別のプレイヤー)」の「Other(その他)」カテゴリに表示されます。さらに、「Uncategorized(未分類)」のメモリの一部も、他のプレーヤーインスタンスによって使用されている可能性があります。一部のデータ構造は、Flash Player内で共有されるため、そのデータ構造がどのプレーヤーインスタンスに属するかを把握することは難しくなります。ブラウザーでコンテンツのプロファイリングを行うとき、可能であればSWFのみを実行することをお勧めします。

Flash Playerは、メモリを大量に使用する主要なデータ構造をできる限り追跡しようとしますが、領域によって追跡の程度は異なります。現在のところ、オーディオおよびビデオバッファーによって使用されるメモリ、JITコンパイルされたActionScriptコードによって使用されるメモリは測定されません。こうしたメモリは、追跡対象外の他の内部データ構造と共に、「Uncategorized(未分類)」に表示されます。

GPU関連のパフォーマンスの問題についての諸注意

GPUはグラフィックカード上の特化したプロセッサーであり、ハードウェアアクセラレーションによるレンダリングを行うことができます。GPUは大量の三角形の配置や色付けなど、大規模な並列計算が得意です。この点はCPUとは対照的です。CPUははるかに複雑な処理を実行できますが、得意なのは一度に1つの処理を実行することです。Stage3Dでは、GPUを利用するために、GPUと直接やり取りができるActionScript APIが用意されています。作業をより楽にするには、高レベルのフレームワークを使用します。例えば、2DコンテンツにはStarling、3DコンテンツにはAway3Dを使用します。ただし、これらのフレームワークでは、GPUを舞台裏で使用していることを忘れないでください。

Stage3Dの使用時に覚えておくべきことは、GPUがCPUと並列に実行されることです。つまり、コンテンツの速度が最も遅いコンポーネントによって制限されるということです。ActionScriptが高速であっても(その結果CPUに過負荷がかからなくても)、GPUに割り当てる処理が多すぎた場合、目的のフレームレートを達成することはできません。GPU使用時の最も一般的なパフォーマンスの問題は次の2つです。

  • GPUへの処理負荷が高すぎる。その最も一般的な原因は、GPUへの描画コールが多すぎること、GPUの状態の変更が頻繁すぎること、使用するメッシュとテクスチャが大きすぎることです。コンテンツを最適化する方法は多数あります。例えば、圧縮されたテクスチャを使用すること、Starlingのテクスチャアトラスを使用すること、もちろん、レンダリングしようとしているオブジェクトを単純化することです。現在のところScoutでは、GPUによる処理は表示されません。しかし、ScoutのStage3D Rendering(Stage3D レンダリング)パネルを使用すると、実行しているStage3Dコマンドを確認したり、最適化する方法を見つけ出したりできます。
  • GPUの処理能力を超えた速度で画面を更新しようとしている。グラフィックカードは、ダブルバッファリングと呼ばれる手法を使用して動作します。一方のバッファーは、現在画面に表示されているデータの格納に使用され、他方のバッファー(バックバッファー)は、表示する次の画像の作成に使用されます。 Context3D.present()をコールするとき、描画していたものをGPUに表示するように指示します。つまり、GPUはこれらの2つのバッファーを切り替える必要があります。しかし、GPUは1/60秒ごとにしかバッファーを切り替えることはできません。これはVSyncとして知られており、モニターによる画像の更新速度に関係します。GPUはバッファー切り替えの準備ができていない場合はブロックされ、Scoutで「Waiting for GPU(GPU を待機)」として表示されます。これは通常は問題になりませんが、GPUがVSync速度に追いつくことができず、何度も更新期限に遅れた場合、GPUによる次のVSyncの更新を待機することがあります。この場合は、パフォーマンスを向上させるために、フレームレートを下げて、待機時間が増えないようにできます。

ここで大きなヒントがあります。コンテンツについて「Waiting for GPU(GPU を待機)」に表示される時間が長すぎる場合、Flash Playerでハードウェアアクセラレーションを一時的に無効にしてみてください(右クリックして「Settings(設定)」を選択)。これにより、Flash Playerがソフトウェアレンダリングに切り替わり、待機時間がなくなったら、問題がGPUに関係していることを確認できます。

次のステップ

ここでは、Flash Playerの仕組みについてより詳しく理解できました。Adobe Scoutを使用してコンテンツをより効果的に最適化できるようになります。Scoutの使用中に、表示されるアクティビティの意味を忘れてしまった場合は、参考としてこの記事を使用できることを覚えておいてください。Scoutをプロファイリングに大いにお役立てください。