Différence entre SurfaceView et View?


211

Quand est-il nécessaire, ou mieux d'utiliser un SurfaceViewau lieu d'un View?

Réponses:


210

Les vues sont toutes dessinées sur le même thread GUI qui est également utilisé pour toutes les interactions utilisateur.

Donc, si vous devez mettre à jour rapidement l'interface graphique ou si le rendu prend trop de temps et affecte l'expérience utilisateur, utilisez-le SurfaceView.


2
Vérifiez la réponse de pierr qui contient plus de détails.
Helin Wang


Ce n'est plus aussi simple que cela. Vérifiez la réponse de pierr; il contient un lien vers le document d'architecture détaillé ( source.android.com/devices/graphics/architecture.html ) et explique pourquoi l'accélération matérielle du rendu Canvas peut faire des vues personnalisées un meilleur choix.
fadden

1
Quand utiliser FrameLayout pour empiler des vues, au lieu de SurfaceView?
IgorGanapolsky

103

Quelques choses que j'ai notées:

  • SurfaceViews contient un joli mécanisme de rendu qui permet aux threads de mettre à jour le contenu de la surface sans utiliser de gestionnaire (idéal pour l'animation).
  • Les vues de surface ne peuvent pas être transparentes, elles ne peuvent apparaître que derrière d'autres éléments de la hiérarchie des vues.
  • J'ai constaté qu'ils sont beaucoup plus rapides pour l'animation que le rendu sur une vue.

Pour plus d'informations (et un excellent exemple d'utilisation), reportez-vous au projet LunarLander dans la section des exemples du SDK.


36
Pour info ... Une SurfaceView peut maintenant être transparente: stackoverflow.com/questions/5391089/…
Steve

@Ralphleon: Que voulez-vous dire par les vues de surface ne peuvent pas être transparentes? D'autres vues peuvent-elles chevaucher la vue Surface? Par exemple, puis-je afficher temporairement un ListView sur une vue Surface?
Ashwin

78

mis à jour 05/09/2014

D'ACCORD. Nous avons maintenant un document officiel. Il a parlé de tout ce que j'ai mentionné, d'une meilleure façon.


Pour en savoir plus, cliquez ici .

Oui, la principale différence est que surfaceView peut être mis à jour sur le thread d'arrière-plan. Cependant, vous pourriez vous en soucier de plus.

  • surfaceView a un tampon de surface dédié tandis que toute la vue partage un tampon de surface alloué par ViewRoot. En d'autres termes, surfaceView coûte plus de ressources.

  • surfaceView ne peut pas être accéléré par le matériel (à partir de JB4.2) tandis que 95% des opérations sur View normal sont accélérées par HW en utilisant openGL ES.

  • Plus de travail doit être fait pour créer votre surfaceView personnalisée. Vous devez écouter l'événement surfaceCreated / Destroy, créer un fil de rendu, plus important encore, synchroniser le fil de rendu et le fil principal. Cependant, pour personnaliser la vue, il vous suffit de remplacer la onDrawméthode.

  • Le moment de la mise à jour est différent. Le mécanisme de mise à jour de la vue normale est contraint ou contrôlé par le framework: vous appelez view.invalidatedans le thread d'interface utilisateur ou view.postInvaliddans un autre thread pour indiquer au framework que la vue doit être mise à jour. Cependant, la vue ne sera pas mise à jour immédiatement, mais attendez l'arrivée du prochain événement VSYNC. L'approche facile pour comprendre VSYNC consiste à considérer qu'il s'agit d'un minuteur qui se déclenche toutes les 16 ms pour un écran à 60 ips. Dans Android, toute la mise à jour de la vue normale (et l'affichage en fait, mais je n'en parlerai pas aujourd'hui), est synchronisée avec VSYNC pour obtenir une meilleure fluidité. Maintenant, revenons à la surfaceView, vous pouvez le rendre à tout moment comme vous le souhaitez. Cependant, je peux à peine dire si c'est un avantage, car l'affichage est également synchronisé avec VSYNC, comme indiqué précédemment.

2
D'après votre réponse, j'ai l'impression qu'il vaut mieux utiliser une classe dérivée de View que de SurfaceView. Ou est-ce que je me trompe? Cela serait opposé à la majorité des didacticiels de développement de jeux 2D.
Tempête

2
@Storm quelque chose à prendre en considération est qu'une SurfaceView par conception ne doit pas bloquer le thread d'interface utilisateur où une vue ne peut être modifiée que par le thread d'interface utilisateur. Avec la plupart des jeux, SurfaceViews effectuera un bon rendu qui bloquerait le thread d'interface utilisateur avec une vue simple. C'est le principal avantage, à ma connaissance, d'une SurfaceView.
zgc7009

Que voulez-vous dire par créer un fil de rendu . Nous devons créer cela manuellement à chaque fois?
IgorGanapolsky

44

La principale différence est que cela SurfaceViewpeut être dessiné par les têtes d'arrière-plan, mais Viewspas. SurfaceViewsutilisez plus de ressources, donc vous ne voulez pas les utiliser à moins que vous ne deviez.


"Ils utilisent plus de ressources, donc vous ne voulez pas les utiliser à moins que vous ne le deviez." - Qui utilise le plus de ressources? Vues ou SurfaceViews?
Dror

6
Surfaceview utilise plus de ressources que de vues
Ritesh Gune

1
@RiteshGune combien?
Alex Sifuentes

Quand devons-nous le faire ?
IgorGanapolsky

12

A SurfaceViewest une vue personnalisée dans Android qui peut être utilisée pour être dessinée à l'intérieur.

La principale différence entre a Viewet a SurfaceViewest qu'une vue est dessinée dans le UI Thread, qui est utilisée pour toutes les interactions utilisateur.

Si vous souhaitez mettre à jour l'interface assez rapidement et y restituer une bonne quantité d'informations, une SurfaceView est un meilleur choix.

Mais il y a quelques aspects techniques SurfaceView:

1. Ils ne sont pas accélérés par le matériel.

2. Les vues normales sont rendues lorsque vous appelez les méthodes invalidateou postInvalidate(), mais cela ne signifie pas que la vue sera immédiatement mise à jour (A VSYNCsera envoyée et le système d'exploitation décidera quand elle sera mise à jour. Elle SurfaceViewpeut être immédiatement mise à jour.

3. Une SurfaceView a une allocation surface buffer, il est donc plus coûteux


Pourquoi est-il important d' accélérer le matériel ?
IgorGanapolsky

8

L'une des principales différences entre la vue de surface et la vue est que pour rafraîchir l'écran pour une vue normale, nous devons appeler la méthode invalidate à partir du même thread où la vue est définie. Mais même si nous appelons invalider, le rafraîchissement ne se produit pas immédiatement. Il ne se produit qu'après la prochaine arrivée du signal VSYNC. Le signal VSYNC est un signal généré par le noyau qui se produit toutes les 16,6 ms ou cela est également connu comme 60 images par seconde. Donc, si nous voulons plus de contrôle sur l'actualisation de l'écran (par exemple pour une animation en mouvement très rapide), nous ne devons pas utiliser la classe de vue normale.

En revanche en cas de surfaceview, nous pouvons rafraîchir l'écran aussi vite que nous le souhaitons et nous pouvons le faire à partir d'un thread d'arrière-plan. Le rafraîchissement de la vue de surface ne dépend donc pas vraiment de VSYNC, ce qui est très utile si nous voulons faire une animation à grande vitesse. J'ai quelques vidéos de formation et un exemple d'application qui expliquent bien toutes ces choses. Veuillez consulter les vidéos de formation suivantes.

https://youtu.be/kRqsoApOr9U

https://youtu.be/Ji84HJ85FIQ

https://youtu.be/U8igPoyrUf8


0

Pourquoi utiliser SurfaceView et non la classe View classique ...

L'une des principales raisons est que SurfaceView peut rapidement rendre l'écran.

En termes simples, un SV est plus capable de gérer le timing et les animations de rendu.

Pour mieux comprendre ce qu'est une SurfaceView, nous devons la comparer avec la classe View.

Quelle est la différence ... vérifiez cette explication simple dans la vidéo

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

Eh bien avec la vue, nous avons un problème majeur .... le timing du rendu des animations.

Normalement, onDraw () est appelé depuis le système d'exécution Android.

Ainsi, lorsque le système d'exécution Android appelle onDraw (), l'application ne peut pas contrôler

le moment de l'affichage, ce qui est important pour l'animation. Nous avons un intervalle de temps

entre l'application (notre jeu) et le système d'exécution Android.

Le SV qu'il peut appeler onDraw () par un Thread dédié.

Ainsi: l'application contrôle le timing. Nous pouvons donc afficher la prochaine image bitmap de l'animation.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.