Android TextureViewとVideoViewのパフォーマンス
画面上でビデオを回転できるようにする必要があるため、VideoViewの現在の実装と同様に、MediaPlayer上に便利なレイヤーを提供するカスタムTextureViewを作成しました。 This Android blog post は、TextureViewについて次のように述べています。
SurfaceViewのコンテンツはアプリケーションのウィンドウに表示されないため、効率的に変換（移動、拡大縮小、回転）することはできません。これにより、ListViewまたはScrollView内でSurfaceViewを使用することが困難になります。また、SurfaceViewは、フェードエッジやView.setAlpha（）などのUIツールキットの一部の機能と適切に対話できません。
これらの問題を解決するために、Android 4.0では、ハードウェアアクセラレーションによる2DレンダリングパイプラインとSurfaceTextureに依存するTextureViewという新しいウィジェットが導入されています。TextureViewはSurfaceViewと同じ機能を提供しますが、SurfaceViewとは異なり、通常の動作をします。ビュー。たとえば、TextureViewを使用してOpenGLシーンまたはビデオストリームを表示できます。TextureView自体は、アニメーション化、スクロールなどが可能です。
ただし、TextureViewがビデオの再生に苦労しているようです。私がテストしているターゲットデバイスには、1.2Ghz Rockchip RK3066デュアルコアCPU、クアッドコアMali-400 GPU（ARM）、および1GBRAMが搭載されています。このデバイスでVideoViewsを使用した同じコードは正常に実行されますが、特定のデバイスに応じて、TextureViewsは再生中に「途切れ」するか、まったく表示されません（左上に白い四角が付いた黒いボックス）。 TextureViewsは、Intelが提供するx86「デバイス」を使用するエミュレーターで正常に動作します。
このパフォーマンスヒットは予想されますか、それとも問題を見つけるために他の場所を探す必要がありますか？ありがとう
はい、TextureViewで期待されています。 TextureViewにより、GPUで直接合成されるSurfaceViewとは異なり、ビデオはレンダリングのために通常のビュー合成を通過します（デコードパイプラインは、SurfaceViewを配置する画面の領域に直接レンダリングされます）。 TextureViewレンダリングはハードウェアアクセラレーションですが、柔軟性を高めるためにさらに多くの手順が実行されており、パフォーマンスが確実に低下します。さらに、UIスレッドで実行されているコードは、TextureViewとは異なりSurfaceViewに影響を与える可能性があります。
追加情報：
あなたはこれを見ることができます 記事
SurfaceViewとTextureViewは同様の役割を果たしますが、実装は大きく異なります。どちらが最適かを判断するには、トレードオフを理解する必要があります。 TextureViewはビュー階層の適切な市民であるため、他のビューと同じように動作し、他の要素とオーバーラップまたはオーバーラップする可能性があります。簡単なAPI呼び出しで、任意の変換を実行し、コンテンツをビットマップとして取得できます。
TextureViewに対する主な攻撃は、構成ステップのパフォーマンスです。 SurfaceViewを使用すると、コンテンツは、SurfaceFlingerが合成する別のレイヤーに、理想的にはオーバーレイを使用して書き込まれます。 TextureViewを使用すると、ビューの構成は常にGLESで実行され、そのコンテンツを更新すると、他のビュー要素も再描画される可能性があります（たとえば、TextureViewの上に配置されている場合）。ビューのレンダリングが完了したら、SurfaceFlingerによってアプリのUIレイヤーを他のレイヤーと合成する必要があるため、表示されているすべてのピクセルを2回効果的に合成できます。フルスクリーンのビデオプレーヤー、または事実上ビデオの上にUI要素を重ねただけのその他のアプリケーションの場合SurfaceViewははるかに優れたパフォーマンスを提供します。