¿Diferencia entre SurfaceView y View?


211

¿Cuándo es necesario o mejor usar un en SurfaceViewlugar de un View?

Respuestas:


210

Las vistas se dibujan en el mismo hilo GUI que también se usa para toda la interacción del usuario.

Entonces, si necesita actualizar la GUI rápidamente o si el renderizado toma demasiado tiempo y afecta la experiencia del usuario, úselo SurfaceView.


2
Verifique la respuesta de pierr que contiene más detalles.
Helin Wang


Ya no es tan simple. Verifique la respuesta de pierr; tiene un enlace al documento de arquitectura detallado ( source.android.com/devices/graphics/architecture.html ) y explica por qué la aceleración de hardware de la representación de Canvas puede hacer que las Vistas personalizadas sean una mejor opción.
fadden

1
¿Cuándo usar FrameLayout para apilar vistas, en lugar de SurfaceView?
IgorGanapolsky

103

Algunas cosas que he notado:

  • SurfaceViews contiene un buen mecanismo de representación que permite que los hilos actualicen el contenido de la superficie sin usar un controlador (bueno para la animación).
  • Las vistas de superficie no pueden ser transparentes, solo pueden aparecer detrás de otros elementos en la jerarquía de vistas.
  • Descubrí que son mucho más rápidos para la animación que la representación en una vista.

Para obtener más información (y un excelente ejemplo de uso), consulte el proyecto LunarLander en la sección de ejemplos del SDK.


36
FYI ... Un SurfaceView ahora puede ser transparente: stackoverflow.com/questions/5391089/…
Steve

@Ralphleon: ¿Qué quieres decir con Surface Views no puede ser transparente? ¿Pueden otras vistas superponerse a la vista de Surface? Por ejemplo, ¿puedo mostrar un ListView en una vista de Surface temporalmente?
Ashwin

78

actualizado 05/09/2014

OKAY. Tenemos documento oficial ahora. Habló todo lo que he mencionado, de una mejor manera.


Leer más detallado aquí .

Sí, la principal diferencia es que SurfaceView se puede actualizar en el hilo de fondo. Sin embargo, hay más que te pueden interesar.

  • SurfaceView ha dedicado el buffer de superficie, mientras que toda la vista comparte un buffer de superficie asignado por ViewRoot. En otras palabras, SurfaceView cuesta más recursos.

  • SurfaceView no puede ser acelerado por hardware (a partir de JB4.2), mientras que el 95% de las operaciones en Vista normal se aceleran con HW usando openGL ES.

  • Se debe hacer más trabajo para crear su SurfaceView personalizada. Debe escuchar el evento SurfaceCreated / Destroy, crear un hilo de renderizado, y lo más importante, sincronizar el hilo de renderizado y el hilo principal. Sin embargo, para personalizar la Vista, todo lo que necesita hacer es anular el onDrawmétodo.

  • El momento para actualizar es diferente. El mecanismo de actualización de la vista normal es restringido o controlado por el marco: Usted llama view.invalidateal hilo de la interfaz de usuario o view.postInvaliden otro hilo para indicarle al marco que la vista debe actualizarse. Sin embargo, la vista no se actualizará de inmediato, pero espere hasta que llegue el próximo evento VSYNC. El enfoque fácil para entender VSYNC es considerarlo como un temporizador que se activa cada 16 ms para una pantalla de 60 fps. En Android, toda la actualización de la vista normal (y la pantalla en realidad, pero no hablaré hoy), se sincroniza con VSYNC para lograr una mejor suavidad. Ahora, de vuelta a SurfaceView, puede renderizarlo en cualquier momento que lo desee. Sin embargo, apenas puedo decir si es una ventaja, ya que la pantalla también está sincronizada con VSYNC, como se indicó anteriormente.

2
De su respuesta tengo la sensación de que es mejor usar una clase derivada de View que SurfaceView. ¿O estoy haciendo algo mal? Esto se opondría a la mayoría de los tutoriales de desarrollo de juegos 2D.
Tormenta

2
@Storm algo a tener en cuenta es que un SurfaceView por diseño no debería bloquear el subproceso de la interfaz de usuario donde una vista solo puede ser modificada por el subproceso de la interfaz de usuario. Con la mayoría de los juegos, SurfaceViews realizará una buena representación que bloquearía el subproceso de la interfaz de usuario con una vista simple. Ese es el beneficio principal, según tengo entendido, de un SurfaceView.
zgc7009

¿Qué quieres decir con crear un hilo de renderizado ? ¿Tenemos que crear esto manualmente cada vez?
IgorGanapolsky

44

La principal diferencia es que SurfaceViewpueden ser dibujados por cabezas de fondo pero Viewsno pueden. SurfaceViewssin embargo, use más recursos para no querer usarlos a menos que tenga que hacerlo.


"Sin embargo, usan más recursos, así que no quieres usarlos a menos que tengas que hacerlo". - ¿Quién usa más recursos? Vistas o SurfaceViews?
Dror

66
Surfaceview usa más recursos que las vistas
Ritesh Gune

1
@RiteshGune ¿cuánto?
Alex Sifuentes

¿Cuándo tenemos que ?
IgorGanapolsky

12

A SurfaceViewes una vista personalizada en Android que se puede usar para dibujar dentro de ella.

La principal diferencia entre ay Viewa SurfaceViewes que se dibuja una Vista en UI Thread, que se utiliza para toda la interacción del usuario.

Si desea actualizar la interfaz de usuario lo suficientemente rápido y generar una buena cantidad de información en ella, SurfaceView es una mejor opción.

Pero hay algunos detalles técnicos para SurfaceView:

1. No son acelerados por hardware.

2. Las vistas normales se representan cuando llama a los métodos invalidateo postInvalidate(), pero esto no significa que la vista se actualizará inmediatamente ( VSYNCse enviará A, y el sistema operativo decide cuándo se actualizará. Se SurfaceViewpuede actualizar de inmediato.

3. Un SurfaceView tiene un asignado surface buffer, por lo que es más costoso


¿Por qué es importante acelerar el hardware ?
IgorGanapolsky

8

Una de las principales diferencias entre la vista de superficie y la vista es que para actualizar la pantalla para una vista normal tenemos que llamar al método invalidar desde el mismo hilo donde se define la vista. Pero incluso si llamamos invalidar, la actualización no ocurre de inmediato. Ocurre solo después de la próxima llegada de la señal VSYNC. La señal VSYNC es una señal generada por el núcleo que ocurre cada 16,6 ms o esto también se conoce como 60 cuadros por segundo. Entonces, si queremos tener más control sobre la actualización de la pantalla (por ejemplo, para una animación de movimiento muy rápido), no debemos usar la clase de vista normal.

Por otro lado, en caso de SurfaceView, podemos actualizar la pantalla tan rápido como queramos y podemos hacerlo desde un hilo de fondo. Por lo tanto, la actualización de la vista de superficie realmente no depende de VSYNC, y esto es muy útil si queremos hacer animación de alta velocidad. Tengo pocos videos de entrenamiento y aplicaciones de ejemplo que explican todas estas cosas muy bien. Por favor, eche un vistazo a los siguientes videos de capacitación.

https://youtu.be/kRqsoApOr9U

https://youtu.be/Ji84HJ85FIQ

https://youtu.be/U8igPoyrUf8


0

¿Por qué usar SurfaceView y no la clase clásica de Vista ...

Una razón principal es que SurfaceView puede renderizar rápidamente la pantalla.

En palabras simples, un SV es más capaz de gestionar el tiempo y renderizar animaciones.

Para comprender mejor qué es un SurfaceView, debemos compararlo con la clase View.

¿Cuál es la diferencia ... verifique esta explicación simple en el video

https://m.youtube.com/watch?feature=youtu.be&v=eltlqsHSG30

Bueno, con la Vista tenemos un problema importante ... el momento de renderizar animaciones.

Normalmente se llama a onDraw () desde el sistema de tiempo de ejecución de Android.

Entonces, cuando el sistema de tiempo de ejecución de Android llama a onDraw (), la aplicación no puede controlar

el tiempo de visualización, y esto es importante para la animación. Tenemos una brecha de tiempo

entre la aplicación (nuestro juego) y el sistema de tiempo de ejecución de Android.

El SV puede llamar al onDraw () por un hilo dedicado.

Por lo tanto: la aplicación controla el tiempo. Entonces podemos mostrar la siguiente imagen de mapa de bits de la animación.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.