Différence entre SurfaceView et View?

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

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.

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.

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.

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.

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

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

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.