mediaplayer - mediacontroller android studio
Android TextureView vs VideoView Performance (2)
Necesito poder rotar un video en la pantalla, así que creé un TextureView personalizado que proporciona una capa de conveniencia sobre un MediaPlayer similar a la forma en que lo hace la implementación actual de VideoView. Esta publicación del blog de Android dice lo siguiente sobre TextureView:
Debido a que el contenido de SurfaceView no se encuentra en la ventana de la aplicación, no se puede transformar (mover, escalar, rotar) de manera eficiente. Esto dificulta el uso de un SurfaceView dentro de un ListView o un ScrollView. SurfaceView tampoco puede interactuar correctamente con algunas características del kit de herramientas de la interfaz de usuario, como los bordes atenuados o View.setAlpha ().
Para resolver estos problemas, Android 4.0 presenta un nuevo widget llamado TextureView que se basa en la línea de renderización 2D acelerada por hardware y SurfaceTexture. TextureView ofrece las mismas capacidades que SurfaceView pero, a diferencia de SurfaceView, se comporta como una vista normal. Por ejemplo, puede usar un TextureView para mostrar una escena OpenGL o una transmisión de video. El TextureView en sí puede ser animado, desplazado, etc.
Sin embargo, parece que TextureView está luchando para reproducir los videos. El dispositivo de destino en el que lo estoy probando tiene una CPU Rockchip RK3066 de doble núcleo a 1,2 Ghz, una GPU de cuatro núcleos Mali-400 (ARM) y 1 GB de RAM. El mismo código que usa VideoViews en este dispositivo funciona bien, pero TextureViews o "tartamudea" mientras se reproduce o no aparece (caja negra con cuadrados blancos en la parte superior izquierda), dependiendo del dispositivo específico. TextureViews funciona bien en el emulador utilizando el "dispositivo x86" proporcionado por Intel.
¿Se espera este impacto de rendimiento o debo buscar en otro lugar para encontrar el problema? Gracias
Puedes ver este article
SurfaceView y TextureView cumplen roles similares, pero tienen implementaciones muy diferentes. Decidir cuál es el mejor requiere una comprensión de las compensaciones. Debido a que TextureView es un ciudadano apropiado de la jerarquía de vistas, se comporta como cualquier otra vista y puede superponerse o superponerse con otros elementos. Puede realizar transformaciones arbitrarias y recuperar el contenido como un mapa de bits con llamadas API simples.
La huelga principal contra TextureView es el rendimiento del paso de composición. Con SurfaceView, el contenido se escribe en una capa separada que SurfaceFlinger compone, idealmente con una superposición. Con TextureView, la composición de la Vista siempre se realiza con GLES, y las actualizaciones de su contenido pueden hacer que otros elementos de la Vista también se vuelvan a dibujar (por ejemplo, si están colocados sobre el TextureView). Una vez que se completa la representación de la Vista, SurfaceFlinger debe componer la capa de la interfaz de usuario de la aplicación para que esté compuesto de manera efectiva cada píxel visible dos veces. Para un reproductor de video de pantalla completa, o cualquier otra aplicación que sea efectivamente solo elementos de UI superpuestos al video, SurfaceView ofrece un rendimiento mucho mejor .
Sí, se espera con TextureView . TextureView hace que el video pase por la vista normal de composición para la representación, a diferencia de SurfaceView, que se compone directamente en la GPU (la canalización de decodificación se procesa directamente en el área de la pantalla donde se coloca SurfaceView ). Si bien el renderizado de TextureView es acelerado por hardware, todavía está atravesando más pasos para obtener flexibilidad adicional, y hay un impacto de rendimiento definitivo. Además, cualquier código que se ejecute en el subproceso de la interfaz de usuario puede afectar a TextureView diferencia de SurfaceView .
Información Adicional: