0

既存の Android プロファイリング ツールに基づいて、アプリケーションのパフォーマンスの問題を検出するために FPS を計算したいと考えています。

Systrace では、performTraversals の長さを記録できることに注意しました。私の知る限り、performTraversals は、フレームを更新する際のほとんどのジョブを含む、測定、レイアウト、および描画を実行します。それでは、performTraversals は、フレームの更新に 60 ミリ秒かかるかどうかを測定するのに十分な代表的なものでしょうか?

また、Systrace が SurfaceFlinger に費やした時間を記録していることにも注目しました。SurfaceFlinger がレンダリング目的で提供されていることは知っていますが、フレームの正確な開始点と終了点はわかりません。SurfaceFlinger でフレーム レートに費やされた時間も考慮する必要がありますか? (ただし、SurfaceFlinger が performTraversals よりも頻繁に実行されることは確認していますが、これは、SurfaceFlinger が必ずしも performTraversals に従うとは限らないことを意味します。他のシナリオでもトリガーされます。)

PS sysdump gfxinfo は認識していますが、128 フレーム (~2 秒) しか記録できませんが、必要なものはもっと長く続く可能性があります。

4

1 に答える 1

1

Systrace は FPS 全体の測定には役立ちませんが、フレーム カウンターとSystem.nanoTime(). ただし、目標のフレームレートに達していない場合は、その理由を理解するのに役立ちます.

公式ドキュメントには役立つヒントがいくつか記載されていますが、情報が多く、操作が複雑になる可能性があります。知っておくべき重要なことは次のとおりです。

  • デバイスの表示パネルは vsync 信号を生成します。VSYNC ラインで確認できます。1 と 0 の間を遷移するたびに更新されます。
  • vsync は surfaceflinger を起動し、さまざまなウィンドウの着信バッファーを収集して合成します (OpenGL ES を使用するか、Hardware Composer を介して)。
  • アプリがパネルのリフレッシュ レート (通常は 60 fps) よりも速く実行されていた場合、それは surfaceflinger の待機をブロックします (たとえば、 でeglSwapBuffers())。surfaceflinger がバッファーを取得すると、アプリは自由に続行して別のフレームを生成できます。
  • オフスクリーンでレンダリングしない限り、surfaceflinger よりも高速に進むことはできません。

Android 4.3 (API 18) 以降では、 android.os.Traceクラスを使用して独自のイベントを systrace 出力に追加できます。draw メソッドをトレース マーカーでラップすると、非常に有益な情報を得ることができます。それらを表示するには、systrace でタグを有効にする必要があります。

60 fps で実行する場合、レンダリングは 16.7 ミリ秒未満で終了する必要があります。それよりも時間がかかる単一の呼び出しが表示された場合performTraversals、最大速度に達することはありません。

于 2013-07-30T05:01:31.407 に答える