Android TextureView vs VideoView Performance

Question

Devo essere in grado di ruotare un video sullo schermo, così ho creato un TextureView personalizzato che fornisce un livello di comodità su un MediaPlayer simile a quello dell'attuale implementazione di VideoView. This Android blog post dice il seguente su TextureView:

Poiché il contenuto di un SurfaceView non vive nella finestra dell'applicazione, essa non può essere trasformata (spostato, in scala, ruotata) in modo efficiente. Ciò rende difficile l'uso di un SurfaceView all'interno di un ListView o ScrollView. SurfaceView inoltre non può interagire correttamente con alcune funzionalità del toolkit dell'interfaccia utente come i bordi di dissolvenza o View.setAlpha().

Per risolvere questi problemi, Android 4.0 introduce un nuovo widget chiamato TextureView che si basa sulla pipeline di rendering 2D con accelerazione hardware e SurfaceTexture. TextureView offre le stesse funzionalità di SurfaceView ma, a differenza di SurfaceView, si comporta come una vista normale. Ad esempio, puoi utilizzare TextureView per visualizzare una scena OpenGL o un flusso video. Lo stesso TextureView può essere animato, scrollato, ecc.

Tuttavia, sembra che TextureView stia cercando di riprodurre i video. Il dispositivo di destinazione su cui sto eseguendo il test ha una CPU Dual Core Rockchip RK3066 da 1,2 Ghz, una GPU Mali-400 quad core (ARM) e 1 GB di RAM. Lo stesso codice che utilizza VideoViews su questo dispositivo funziona bene, ma TextureViews "balbetta" durante la riproduzione o non viene visualizzato affatto (riquadro nero con riquadri bianchi in alto a sinistra), a seconda del dispositivo specifico. TextureViews funziona correttamente sull'emulatore utilizzando il "dispositivo" x86 fornito da Intel.

È previsto un calo delle prestazioni, oppure dovrei cercare altrove per trovare il problema? Grazie

Answer 1

Sì, è previsto con TextureView. TextureView fa sì che il video passi attraverso il normale compositing di visualizzazione per il rendering, a differenza di SurfaceView che è composto direttamente nella GPU (la pipeline di decodifica viene visualizzata direttamente nell'area dello schermo in cui si posiziona lo SurfaceView). Mentre il rendering di TextureView è accelerato dall'hardware, sta ancora attraversando più passaggi per la flessibilità aggiuntiva, e c'è un netto calo di prestazioni. Inoltre, qualsiasi codice in esecuzione sul thread dell'interfaccia utente potrebbe influire su TextureView a differenza di SurfaceView.

Ulteriori informazioni:

• Advanced UI Fundamentals: Develop and Design
• AOSP Graphics Architecture: SurfaceView or TextureView?

Answer 2

si può vedere questo article

SurfaceView e TextureView ricoprire ruoli simili, ma sono molto diverse implementazioni. Per decidere quale sia la cosa migliore è necessario comprendere i compromessi. Poiché TextureView è un cittadino appropriato della gerarchia View, si comporta come qualsiasi altra vista e può sovrapporsi o essere sovrapposto ad altri elementi. È possibile eseguire trasformazioni arbitrarie e recuperare i contenuti come bitmap con semplici chiamate API.

Il colpo principale contro TextureView è la prestazione del passaggio di composizione. Con SurfaceView, il contenuto viene scritto su un livello separato che SurfaceFlinger compone, idealmente con una sovrapposizione. Con TextureView, la composizione View viene sempre eseguita con GLES, e gli aggiornamenti al suo contenuto possono far sì che anche altri elementi View vengano ridisegnati (ad es. Se sono posizionati in cima a TextureView).Una volta completato il rendering della vista, il livello dell'interfaccia utente dell'app deve quindi essere composto con altri livelli da SurfaceFlinger, in modo da comporre efficacemente tutti i pixel visibili due volte. Per un lettore video a schermo intero o qualsiasi altra applicazione che sia effettivamente solo gli elementi dell'interfaccia utente sovrapposti ai video, SurfaceView offre prestazioni decisamente migliori.