タッチスクリーンのAndroid LollipopでのビデオラグとFPSドロップ

Question

私はMediaCodecを使用して1080p @ 60fpsビデオを再生しています。これはAndroid Lollipop 5.1を搭載したフリースケールSabreSDプラットフォーム上にあります。

最初はBufferQueue Synchronous Modeのため、FPSは60未満でした.BufferQueueをJBossのようにAsynchronousに変更することで、70FPSで再生できるようになりました。

私が直面している次の課題は、画面とのやり取り（通知バーのプルダウン、音量ボタンの押しなど）を開始するときに、ビデオの遅延とFPSが大幅に40に低下することです。

私はrafika MultiSurfaceActivityとRecord GLを実行したので、画面が触れられたり乱れたりしてもスムーズにすべてのテストを見ることができますが、一番上から通知バーをスクロールして長時間続けば、 35〜40FPSに削減されます。

私はKitkat 4.4.2とJB 4.2.2で同じテストを確認しており、正常に動作しているようです。

ギャラリーからMP4を再生するときと同じ動作です。

この問題（VSync、トリプルバッファリング？）を引き起こす可能性のあるKitkatからLollipopへの変更について誰もが説明できます。 Grafika issue trackerから少し逆流

Answer 1

：

バウンドするボールは、ソフトウェアレンダリングなので、CPU時間を吸い上げるものは、それが遅く作るために起こっています。中程度のCPUと大きなディスプレイ（Nexus 10など）のデバイスでは、60fpsに近づくことはありません。だから遅くの間にあなたがナビゲーションバーで遊んでいる私を驚かせることはありませんが、それはあなたがナビバーで遊んで停止した後でも遅くなり続ける場合、それは少し奇妙です。

ビデオの再生は、CPUの影響を受けにくいので、影響を受けません。

このような問題の調査は、通常、「良い」状態と「悪い」状態のトレースをキャプチャし、その2つを比較するためにsystraceを使用することで開始されます。

BufferQueueの「非同期モード」のポイントは、コンシューマがプロデューサに追いつかない場合にフレームをドロップできるようにすることです。 SurfaceTextureは、プロデューサとコンシューマが同じアプリ内にあり、同じスレッド上にある可能性があるため、コンシューマを待っているプロデューサのストールによってプログラムがハングアップする可能性があります。 60fpsを超える必要があるということをどういう意味なのか分かりませんが、フレームレートを上げるよりも速くフレームを投げているように思えます。 Choreographerを使って自分でドロップする必要があるときを決めるのではなく、BufferQueueを使ってフレームをドロップするだけです。

いずれにせよ、私はLollipopが完成するずっと前にGoogleを2014年6月に退社しました。 KitKatで何かが正しく動作しているが、Lollipopで変わったことがあれば、私は多くの洞察力を提供することはできないと思う。ビヘイビアを簡単に再現できる場合は、問題を示すビデオをキャプチャする価値があるかもしれません（問題を抱えているデバイスで2番目のスマートフォンを指しているため、デバイスの操作方法を確認できます）。http://b.android.com/のバグを報告してください。OPによってアップロード

---

いくつかの痕跡：

• https://www.dropbox.com/s/luwovq7ohozccdy/Lollipop_bad.zip
• https://www.dropbox.com/s/zkv0aqw0shecpw2/lollipop_good.zip
• https://www.dropbox.com/s/g7qe01xvmfyvpak/kitkat.zip

キットカットの跡を見るには、奇妙な何かがSurfaceFlingerの中で起こっています。メインスレッドは、非常に長い時間（23-32ms）の間、postFrameBufferに座っています。最終的には目を覚まし、CPU行は、私が慣れていない "galcoreデーモン"（Vivante GPU特有のようです）からアクティビティを待っていたことを示唆しています。

ロリポップトレースは、キャプチャが必要なタグなしで行われたかのように、CPU行のみを表示します。私はsystraceのキャプチャコマンドがkitkatとlollipopの間で大幅に変更されたとは思わないので、私はユーザスペースで開始されたロギングが消えてしまう理由について困惑しています。 sched gfx viewが指定されていることを確認してください。

---

最新のロリポップトレースには、約1秒間の良好なデータしかありません。 「完了していない」と表示された場合、「開始」レコードに一致する「終了」レコードがないことを意味します。 -bフラグを使用して、systraceログバッファサイズを増やすことができます。私はそこに十分だと思う。

/system/bin/surfaceflingerの行を見ると、「良い」トレースでは、通常約16msで終了するpostFrameBufferが、まだgalcoreで待機しています。 388msをズームインする（WASDキーを使用）。 388.196msで、CPU 2の行で、galcoreが何かをしているのを見ることができます。それが完了すると直ぐに、サーフェスフリンジャー行の最上部の細い線が明るい灰色（スリープ）から緑色（実行中）に変わります。 388.548msで再びCPU2でgalcoreが再び実行され、その直後にサーフェスフリンジャーの行にqueueBufferの実行が開始されます。

"不良"トレースは同じように見えます。たとえば、101.146msと101.666msで2回のガルコア実行を見ることができ、サーフェスプレーンガ行に同様の効果があると思われます。主な違いは、postFrameBufferで費やされた時間です。これは「良い」では約16ms、「悪い」では約30msです。

これは動作上のシフトではありません。むしろ、事態に時間がかかり、期限を逃しています。

私が知る限り、SurfaceFlingerはgalcoreデーモンによってサポートされています。これは「良い」ケースと「悪い」ケースの両方に当てはまります。タイミングがのように見えるようにするには、Nexusデバイスでsystraceを実行するか、他のデバイスのトレースと比較してください（例：this case studyまたはthis SO question）。ズームインすると、doCompositionが数ミリ秒で実行され、postFrameBufferが数ミリ秒で終了することがわかります。

要約：あなたは悪くない、悪い、悪いです。 :-)私はgalcoreが何であるか分かりませんが、GPU OEMと会話する必要があるでしょう。