Diferença entre o SurfaceView e o View?


211

Quando é necessário ou melhor usar um em SurfaceViewvez de um View?

Respostas:


210

As visualizações são todas desenhadas no mesmo encadeamento da GUI, que também é usado para toda a interação do usuário.

Portanto, se você precisar atualizar a GUI rapidamente ou se a renderização demorar muito e afetar a experiência do usuário, use SurfaceView.


2
Verifique a resposta do pierr, que contém mais detalhes.
Helin Wang


Não é mais tão simples assim. Verifique a resposta do pierr; ele possui um link para o documento de arquitetura detalhado ( source.android.com/devices/graphics/architecture.html ) e explica por que a aceleração de hardware da renderização do Canvas pode fazer com que as vistas personalizadas sejam uma escolha melhor.
Fadden

1
Quando usar o FrameLayout para empilhar vistas, em vez do SurfaceView?
IgorGanapolsky

103

Algumas coisas que notei:

  • O SurfaceViews contém um bom mecanismo de renderização que permite que os threads atualizem o conteúdo da superfície sem usar um manipulador (bom para animação).
  • As visualizações de surf não podem ser transparentes, elas podem aparecer apenas atrás de outros elementos na hierarquia de visualizações.
  • Descobri que eles são muito mais rápidos para animação do que renderizados em uma View.

Para obter mais informações (e um ótimo exemplo de uso), consulte o projeto LunarLander na seção de exemplos do SDK.


36
FYI ... Agora, um SurfaceView pode ser transparente: stackoverflow.com/questions/5391089/…
Steve

@ Ralphleon: O que você quer dizer com vistas de superfície não pode ser transparente? Outras vistas podem se sobrepor à vista de superfície? Por exemplo, posso exibir temporariamente um ListView em uma exibição de superfície?
Ashwin

78

atualizado em 09/09/2014

ESTÁ BEM. Temos um documento oficial agora. Ele falou tudo o que mencionei, de uma maneira melhor.


Leia mais detalhadamente aqui .

Sim, a principal diferença é que o surfaceView pode ser atualizado no encadeamento em segundo plano. No entanto, há mais que você pode se importar.

  • O surfaceView dedica o buffer de superfície, enquanto toda a exibição compartilha um buffer de superfície que é alocado pelo ViewRoot. Em outra palavra, o surfaceView custa mais recursos.

  • O surfaceView não pode ser acelerado por hardware (a partir do JB4.2), enquanto 95% das operações no View normal são aceleradas por HW usando o openGL ES.

  • Mais trabalho deve ser feito para criar seu surfaceView personalizado. Você precisa ouvir o evento surfaceCreated / Destroy, criar um encadeamento de renderização, mais importante, sincronizar o encadeamento de renderização e o encadeamento principal. No entanto, para personalizar o modo de exibição, tudo que você precisa fazer é substituir o onDrawmétodo.

  • O tempo para atualização é diferente. O mecanismo de atualização de exibição normal é restrito ou controlado pela estrutura: Você chama view.invalidateno thread da interface do usuário ou view.postInvalidem outro thread para indicar à estrutura que a exibição deve ser atualizada. No entanto, a visualização não será atualizada imediatamente, mas aguarde até o próximo evento VSYNC chegar. A abordagem fácil de entender o VSYNC é considerá-lo como um temporizador que dispara a cada 16ms para uma tela de 60fps. No Android, toda a atualização normal da exibição (e a exibição realmente, mas não falarei hoje) é sincronizada com o VSYNC para obter uma melhor suavidade. Agora, de volta ao surfaceView, você pode renderizá-lo a qualquer momento que desejar. No entanto, mal posso dizer se é uma vantagem, pois a tela também está sincronizada com o VSYNC, como afirmado anteriormente.

2
Pela sua resposta, sinto que é melhor usar uma classe derivada de View do que SurfaceView. Ou estou entendendo algo errado? Isso seria contrário à maioria dos tutoriais de desenvolvimento de jogos 2D.
tempestade

2
O @Storm algo a ser levado em consideração é que um SurfaceView por design não deve bloquear o thread da interface do usuário, onde um modo de exibição só pode ser modificado pelo thread da interface do usuário. Na maioria dos jogos, o SurfaceViews realiza uma boa renderização que bloqueia o thread da interface do usuário com uma visualização simples. Esse é o principal benefício, do meu entendimento, de um SurfaceView.
Zgc7009

O que você quer dizer com criar um thread de renderização . Temos que criar isso manualmente toda vez?
IgorGanapolsky

44

A principal diferença é que eles SurfaceViewpodem ser desenhados por segmentos de fundo, mas Viewsnão podem. SurfaceViewsuse mais recursos para não usá-los, a menos que seja necessário.


"Eles usam mais recursos para que você não os queira, a menos que precise." - Quem usa mais recursos? Views ou SurfaceViews?
Dror

6
SurfaceView usar mais recursos do que pontos de vista
Ritesh Gune

1
@RiteshGune Quanto?
Alex Sifuentes

Quando precisamos ?
IgorGanapolsky

12

A SurfaceViewé uma visualização personalizada no Android que pode ser usada para desenhar dentro dela.

A principal diferença entre a Viewe a SurfaceViewé que uma View é desenhada na UI Thread, que é usada para toda a interação do usuário.

Se você deseja atualizar a interface do usuário com rapidez suficiente e renderizar uma boa quantidade de informações, um SurfaceView é uma escolha melhor.

Mas existem alguns detalhes técnicos no SurfaceView:

1. Eles não são acelerados por hardware.

2. Visualizações normais são renderizadas quando você chama os métodosinvalidate ou postInvalidate(), mas isso não significa que a visualização será atualizada imediatamente (A VSYNCserá enviada e o sistema operacional decidirá quando será atualizada. A atualização SurfaceViewpoderá ser imediata.

3. Um SurfaceView possui um alocado surface buffer, por isso é mais caro


Por que é importante ter o hardware acelerado ?
IgorGanapolsky

8

Uma das principais diferenças entre a visualização de surf e a visualização é que, para atualizar a tela para uma visualização normal, precisamos chamar o método invalidate do mesmo encadeamento em que a visualização é definida. Mas mesmo se chamarmos invalidar, a atualização não ocorrerá imediatamente. Ocorre somente após a próxima chegada do sinal VSYNC. O sinal VSYNC é um sinal gerado pelo kernel que ocorre a cada 16,6 ms ou também é conhecido como 60 quadros por segundo. Portanto, se quisermos ter mais controle sobre a atualização da tela (por exemplo, para animações em movimento muito rápido), não devemos usar a classe de exibição normal.

Por outro lado, no caso da visualização de surf, podemos atualizar a tela o mais rápido que queremos e podemos fazê-lo a partir de um encadeamento em segundo plano. Portanto, a atualização da visualização da surf realmente não depende do VSYNC, e isso é muito útil se queremos fazer animações em alta velocidade. Eu tenho poucos vídeos de treinamento e aplicativos de exemplo que explicam bem todas essas coisas. Por favor, dê uma olhada nos seguintes vídeos de treinamento.

https://youtu.be/kRqsoApOr9U

https://youtu.be/Ji84HJ85FIQ

https://youtu.be/U8igPoyrUf8


0

Por que usar o SurfaceView e não a classe clássica do View ...

Um dos principais motivos é que o SurfaceView pode renderizar a tela rapidamente.

Em palavras simples, um SV é mais capaz de gerenciar o tempo e renderizar animações.

Para entender melhor o que é um SurfaceView, devemos compará-lo com a classe View.

Qual é a diferença ... confira esta explicação simples no vídeo

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

Bem, com o View, temos um grande problema ... o tempo de renderização das animações.

Normalmente, o onDraw () é chamado no sistema de tempo de execução do Android.

Portanto, quando o sistema de tempo de execução do Android chama onDraw (), o aplicativo não pode controlar

o tempo de exibição, e isso é importante para a animação. Temos uma lacuna de tempo

entre o aplicativo (nosso jogo) e o sistema de tempo de execução do Android.

O SV pode chamar o onDraw () por um Thread dedicado.

Assim: o aplicativo controla o tempo. Assim, podemos exibir a próxima imagem de bitmap da animação.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.