問題タブ [systrace]

デフォルトのsystraceオプションを設定して、Android Studio からsystraceを使用しようとしています。電話をルート化していません。HTC Sense v6.0、Android 5.0.1、HTC SDK API レベル 6.55。そうすると、「システム トレースを収集できません。理由: システム トレースの収集中に予期しないエラーが発生しました」という恐ろしいメッセージが表示されます。ADB シェルを使用して、/sys/kernel/debug が存在することを確認しましたが、/sys/kernel/debug/tracing は存在しません。

systraceと HTC One M8 / Lollipop で運が良かった人はいますか?

systrace を実行できますが、SurfaceFlinger のトレースを表示できません。GPU、bufferQueues など。

次のコマンドを実行しました: systrace.py --time=10 -o mynewtrace.html sched gfx view wm hal video workq

CPU0、workqueues、irqs、kworkerなどの出力のみを提供します。

カーネルのコンパイル中に有効にする必要がある特定のトレーサーはありますか? 他に何か不足していますか？

ありがとう！

ビデオの再生でフレーム ドロップの問題が発生しています。ICS から KK4.4 に移行しました。ビデオは非常に小さい 320x240 解像度です。物事を簡単にするためのオーディオはありません。

Systrace は次の場所にあります: https://www.dropbox.com/s/bee6xymg3kpn4ft/mytrace2.html?dl=0

トリプル バッファリングを有効にしましたが、hwcomposer が SurfaceFlinger に対して偽の vsync を生成しています。

次の問題が見られます。

1. videodecoder が 7 つのバッファ キューを割り当てるため、トリプル バッファリングが適切に有効化されていません。TimedEventQueue(OnVideoEvent) からキューに入れられる各フレームに対してトリプル バッファリングが正常に機能していた場合、キューから取り出されるバッファは 2 スロット遅れているはずです。例: buf 4 をキューに入れると、buf 2 をデキューする必要がありますが、デキューされるのは直前のバッファであり、Surfaceflinger は次回実行する機会を得たときにのみ解放されます。したがって、遅延により、ビデオのキャンセルバッファが追いつくことになります。

2. SurfaceFlinger 自体が完了するまでに時間がかかります。

3. 30 fps ビデオの場合、33 ミリ秒ごとなど、適切なタイミングで Vsync がオンにならない。HWComposer の vsync 生成ロジックに関する問題、または実際のバッファーがキューに入れられていないため、eventControl によって vsync が有効にされていませんか?

私が行った以下のコメントからの更新: 私が指摘したその他のことは、async フラグと mDequeueBufferCannotBlock フラグが両方とも false であるため、getMinUndequeuedBufferCount() が 1 を返すため、2 スロット遅れたバッファーではなく、直前のバッファーがデキューを要求されていることがわかります。 . 上記の理解に穴がある場合はお知らせください。そして、これを回避するために私ができることは何でも

どんな助けでも大歓迎です。

現在、アプリのアニメーションの流動性を改善しようとしています。

Android systrace を実行したところ、systrace によるとジャンクの原因となるスケジューリング遅延アラートがいくつか見つかりました。

残念ながら、systrace によって提示される他のデータを理解できません。スケジュールの遅延の原因を見つける方法について、誰かが正しい方向に向けることができますか?

前もって感謝します

私のアプリは、フレームごとにいくつかの非常に単純なビュー (回転、平行移動) のプロパティを変更します。Android のパフォーマンスに関する記事でアドバイスされているように、systrace を使用して、フレームがドロップしているかどうかを確認しました。

本当に予想外のことが起きました。デバイスが静止しているとき (画面に触れていても)、CPU 使用率が高くなり、systrace でアラートが発生し、GPU レンダリング プロファイラーの赤い部分が長くなりました。デバイスを非常に速く回転させたり振ったりすると、すべて問題ありませんでした。

以下、結果のリンクです。Shakeデバイスを非常に速く回転させたno_shakeとき、机の上に置いたままにしたときです。

ソース コードという 1 つの翻訳アニメーションを使用する、非常に単純なテスト アプリを作成しました。

Systrace:揺れない、揺れる

CPU使用率：

GPU プロファイラー:

フレームレートがスムーズなシェイク systrace を見ると、HW_VSYNC_0 および HW_VSYNC_ON_0 ラインにデータがないのはなぜですか? CPU 周波数を読み取るにはどうすればよいですか (トレースをキャプチャするときにオプションを有効にしました)。

この問題に関して、私の理論では、デバイスが CPU 周波数を下げている可能性があります。systrace でこれを読み取るにはどうすればよいですか? この仮説をテストするためにサードパーティのアプリを使用しましたが、以下に示すように真実です。では、この問題を回避するにはどうすればよいでしょうか。

デバイスがこれを行う理由は何ですか? 最初は、デバイスが加速度計のデータを使用して使用されていないかどうかを理解し、CPU 周波数を下げたと思いました。しかし、CPU 周波数を上げるには、デバイスを激しく振る必要があります。通常の人のようにそれを保持しても、CPU 周波数は増加しません。

たくさんの質問があることは承知していますが、Android グラフィックス パイプラインに関する関連記事をすべて読んだので、アイデアがありません。

この問題は、Android 5.1 を実行している Sony Xperia Z3 で発生しました。この問題は、Android 6 を実行している Nexus 5 では再現できませんでした。

アップデート

パフォーマンスの問題は、CPU/GPU スロットリングが原因のようです。同じデバイスの Xperia Z3 で Android 4.4 を実行すると、クロック速度は低下しますが、Systrace によるとパフォーマンスが向上します。また、振っても速度が上がりません。

CPU 速度を上げるために必要なシェイク ジェスチャに関しては、デバイスを縦向きから横向きに、またはその逆に回転させようとすると、(アプリの向きが変わらなくても) CPU クロックが増加することに気付きました。したがって、このジェスチャーが監視される理由は、考えられる向きの変更を高速化するためだと思います。