Android TextureView vs VideoView Performance
j'ai besoin de pouvoir faire tourner une vidéo à l'écran, donc j'ai créé une version TextureView personnalisée qui fournit une couche de confort au-dessus D'un Médiaplayer similaire à celle de L'implémentation actuelle de VideoView. ce billet de blog sur Android dit ce qui suit à propos de TextureView:
parce que le contenu D'un SurfaceView ne vit pas dans la fenêtre de l'application, il ne peut pas être transformé (déplacé, mis à l'échelle, tourné) efficacement. Cela rend difficile l'utilisation D'un SurfaceView dans un ListView ou un ScrollView. De plus, SurfaceView ne peut pas interagir correctement avec certaines caractéristiques de la boîte à outils de L'interface utilisateur, comme les bords de décoloration ou la vue.setAlpha ().
pour résoudre ces problèmes, Android 4.0 introduit un nouveau widget appelé TextureView qui s'appuie sur le matériel accéléré 2D rendering pipeline et SurfaceTexture. TextureView offre les mêmes fonctionnalités que SurfaceView mais, contrairement à SurfaceView, se comporte comme une vue régulière. Vous pouvez par exemple utiliser un TextureView pour afficher un Scène OpenGL ou un flux vidéo. Le TextureView lui-même peut être animé, scrolled, etc.
cependant, il semble que le TextureView ait du mal à lire les vidéos. Le périphérique cible sur lequel je le teste possède un processeur Rockchip RK3066 à 1,2 Ghz À Double noyau, un processeur Quad Mali-400 GPU (ARM) et une RAM de 1 Go. Le même code utilisant VideoViews sur cet appareil fonctionne bien, mais les TextureViews soit "bégaie" tout en jouant ou ne pas apparaître du tout (Boîte Noire avec des carrés blancs dans le haut à gauche), selon l'appareil. Les TextureViews exécutent fine sur l'émulateur en utilisant le "périphérique" x86 fourni par Intel.
cette performance est-elle attendue, ou devrais-je chercher ailleurs pour trouver le problème? Merci
2 réponses
Oui, c'est prévu avec TextureView. TextureView permet à la vidéo de passer par la vue normale-le compositing pour le rendu, contrairement à SurfaceView qui est composé directement dans le GPU (le pipeline de décodage rend directement à la zone de l'écran où vous placez le SurfaceView). Alors que les TextureView le rendu est hardware-accelerated, il passe encore par Plus d'étapes pour la flexibilité supplémentaire, et il y a un coup de performance défini. De plus, tout code tournant sur le thread-UI peut affecter TextureView pas comme SurfaceView.
information supplémentaire:
Vous pouvez voir ce article
SurfaceView et TextureView remplissent des rôles similaires, mais ont des implémentations très différentes. Pour décider qui est le mieux nécessite une compréhension des compromis. Parce que TextureView est un véritable citoyen de la hiérarchie de la vue, il se comporte comme n'importe quelle autre vue, et peut se chevaucher ou être superposé par d'autres éléments. Vous pouvez effectuer des transformations arbitraires et récupérer le contenu sous forme de bitmap avec des appels API simples.
la frappe principale contre TextureView est la performance de l'étape de composition. Avec SurfaceView, le contenu est écrit sur une couche séparée qui se compose de SurfaceFlinger, idéalement avec une superposition. Avec TextureView, la composition de la vue est toujours effectuée avec GLES, et les mises à jour de son contenu peuvent entraîner d'autres éléments de vue à redessiner aussi bien (par exemple, si elles sont positionnées sur le dessus de la TextureView). Une fois que le rendu de la vue est terminé, la couche app UI doit alors être composée avec d'autres couches par SurfaceFlinger, donc vous composez effectivement chaque pixel visible deux fois. Pour un lecteur vidéo plein écran, ou toute autre application qui n'est en fait que des éléments UI superposés sur le dessus de la vidéo, SurfaceView offre une bien meilleure performance.