Amazon Developer

as

Settings
Sign out
Notifications
Alexa
Amazonアプリストア
Ring
AWS
ドキュメント
Support
Contact Us
My Cases
開発
設計と開発
公開
リファレンス
サポート
メインコンテンツへスキップ
Simpleperfは、Vegaデバイスにおけるアプリのパフォーマンスを分析するのに役立つ、コマンドラインのネイティブCPUプロファイリングツールです。Simpleperfを使用すると、CPUのボトルネック、過剰なコンテキスト切り替え、非効率的なスレッドスケジューリング、その他のコードレビューだけでは明らかにならない可能性のあるパフォーマンスの問題を特定できます。コア全体のCPU使用パターン、関数呼び出しの頻度と実行時間、ハードウェアパフォーマンスカウンター、プロセススケジューリング動作、コンテキスト切り替えパターンに関する分析情報を提供します。 Simpleperfは、次の2つのモードで動作します。
  • [On-device] - 実行中のアプリとシステムアクティビティを監視して、リアルタイムのパフォーマンスデータを収集します。
  • [On-host] - デバイス上でこれまでに収集されたデータを処理して表示します。
Simpleperfは、アプリで予期しないフレーム落ち、バッテリー消耗、応答の遅延が発生した場合、またはCPU使用率が想定より高いと疑われる場合に使用します。

Simpleperfを使用するケース

前提条件

開始する前に、以下の準備が整っていることを確認してください。
  • Vega SDKのインストールが完了していること
  • Fire TV StickデバイスがVDA経由で接続されていること
  • アプリをデバイス上でビルドして実行していること

Simpleperfのセットアップ

Simpleperfはデフォルトではデバイスイメージに含まれていません。Vega SDKに含まれるバイナリをデバイスにサイドロードする必要があります。

手順1:ビルドバリアントを確認する

デバイスでuser-externalまたはuserビルドバリアントが使用されていることを確認します。どちらのビルドもSimpleperfで機能しますが、user-externalの方が一般的です。
想定される出力:
または

手順2:開発者モードを有効にする

デバイスで開発者モードを有効にします。
開発者モードの詳細については、開発者モードの有効化を参照してください。

手順3:デバイスに接続してアプリを起動する

デバイスへのシェル接続を開きます。
vmsgrを使用してアプリを起動します。以下に例を示します。

手順4:Simpleperfバイナリをデバイスにプッシュする

SimpleperfバイナリはSDKの次の場所にあります。
そのバイナリをアプリのスクラッチフォルダにプッシュします。
出力の例:
これで、バイナリがコンポーネントシェルのtmp/scratchフォルダで使用可能になります。

手順5:コンポーネントシェルにアクセスする

ホストマシンで新しいターミナルを開きます。最初のターミナルは手順3のvda shellセッションを実行しているため、別のターミナルが必要です。 コンポーネントシェルに接続します。
バイナリをプッシュしたスクラッチディレクトリに移動します。
これで、このディレクトリからSimpleperfコマンドを実行できるようになります。

アプリのプロセスIDを確認する

プロファイリングを行う前に、アプリのプロセスID(PID)を確認します。
出力の例:
PID、アプリID、またはpidofでアプリを参照できます。

利用可能なイベントの一覧を表示する

simpleperf listを使用して、デバイスがサポートしているイベントを確認します。
他にも、次のようなフィルタリングオプションがあります。
  • cache - ハードウェアキャッシュイベント
  • raw - 未処理のCPU PMUイベント
  • tracepoint - トレースポイントイベント
  • cs-etm - CoreSight ETMの命令トレースイベント
  • pmu - システム固有のPMUイベント
サポートされている機能をデバイスに表示するには、次のようにします。
ハードウェアイベントの出力例:
ソフトウェアイベントの出力例:
表示されたイベントはいずれも、simpleperf statコマンドとsimpleperf recordコマンドの実行時に-eオプションで指定できます。

statによるパフォーマンス統計の収集

simpleperf statを使用して、CPUイベントの集計パフォーマンス統計を収集します。このモードでは、詳細なサンプリングデータによるオーバーヘッドなしに、ハードウェアとソフトウェアのイベントの簡潔な概要を提供します。これは、迅速なパフォーマンス評価や最適化のA/Bテストに役立ちます。
出力の例:

stat結果の解釈

出力を解釈するには、次のガイドラインを使用してください。 使用可能なオプションの一覧は、simpleperf help statを実行すると確認できます。

詳細なパフォーマンスデータの記録

事前定義された間隔でCPUイベントをサンプリングして詳細なCPUパフォーマンス指標を収集するには、simpleperf recordを使用します。記録されたすべてのデータは、後で分析できるようにperf.dataファイルに保存されます。 イベントには、ユーザースペースのみ(:u)またはカーネルスペースのみ(:k)をモニタリングするようにスコープを指定できます。ほとんどの場合、Vegaアプリのプロファイリングでは、ユーザースペースの監視を使用してください。
使用可能なオプションの一覧は、simpleperf help recordを実行すると確認できます。

パフォーマンスデータをホストマシンに転送する方法

パフォーマンスデータは、コンポーネントシェルの/scratchディレクトリに保存されます。これらのファイルを取得するには、ホストマシン(コンポーネントシェルの外部)でターミナルを開き、次のコマンドを実行します。

レポートによるパフォーマンスデータの分析

ホストマシンでsimpleperf reportを使用して、収集したperf.dataファイルを分析します。次の場所にあるSDKに含まれるホスト版のSimpleperfを使用します。
をインストールしたSDKのバージョン(例:0.23.6323)に置き換えます。
出力の例:
使用可能なすべてのオプションについて、simpleperf help reportを実行します。

その他のコマンド

simpleperfには、プロファイリング用途に特化した追加のコマンドが含まれています。 サブコマンドとそのオプションを一覧表示するには、次のようにします。

既知の制限事項

Simpleperfはperf_event_paranoidカーネルパラメーターに基づいて操作権限を決定します。Vega OSでは、この値はデフォルトで2に設定され、セキュリティ上の理由から特定のプロファイリング機能が制限されます。 user-externalビルドバリアントを搭載したデバイスで開発者モードが有効になっている場合は、この値が自動的に1に調整され、より包括的なプロファイリングが可能になります。ただし、権限のないユーザーでは引き続き次の操作が制限されます。
  • カーネルスペースイベントのプロファイリング
  • ハードウェアPMUイベントへのアクセス
  • 他のユーザーのプロセスのプロファイリング
  • 未処理のトレースポイントイベントの収集
  • カーネルコールグラフへのアクセス
  • カーネルモードのスタックトレースの収集

ベストプラクティス

データの収集

  • 必ず期間を指定するか、制御された方法で終了させます。
  • 適切なサンプリング頻度を使用します。
  • プロファイリング中にシステム負荷を監視します。

イベントの選択

  • 基本的なイベント(cpu-cycles、instructions)から始めます。
  • 同時に発生するハードウェアイベントの数が多くなりすぎないようにします。
  • ターゲットデバイスのハードウェア制限を考慮します。

レポート分析

  • 複数の実行を比較すると、一貫した結果が得られます。
  • 適切なフィルターを使用して結果を絞り込みます。
  • 必ずサンプルの欠落がないか確認します。

リソースの管理

  • 古いperf.dataファイルをクリーンアップしてデバイスストレージを解放します。
  • サンプリングの頻度を制限してCPUオーバーヘッドを制御します。

例:スクロール中のフレーム落ちの診断方法

このチュートリアルでは、Simpleperfを使用して、コンテンツ一覧のスクロール中にフレーム落ちするアプリを調査する方法を説明します。 1. statで問題を確認する
cpu-cyclesと比較してcontext-switches(500/秒を超える)またはcache-missesの値が高い場合は、調査に値するパフォーマンス上の問題が生じている可能性があります。 2. 問題のあるインタラクション中にコールグラフを記録する
10秒間の記録期間中に、コンテンツ一覧をスクロールします。 3. ホストマシン上のデータを取得して分析する
4. ボトルネックを特定する Overheadの割合が高い関数を探します。以下に例を示します。
この場合、CPU時間の35%がHermesのJavaScriptの実行に、22%がReactのシャドウツリーのコミットに費やされています。これは、スクロールハンドラーで実行されているフレームあたりのJS処理が多すぎることを示唆しています。 5. 修正および検証する 最適化(たとえば、スクロールハンドラー内の高コスト計算をメモ化するなど)の後で、同じstatコマンドを再実行し、指標が改善されることを確認します。

関連トピック


最終更新日 2026年10月26日