Unity uGUI : découper les Canvas selon les changements réellement observés
Traduction automatique de l'original (English, révision 1) ; l'original fait foi. Original
Choisissez les limites des Canvas selon le comportement de mise à jour, distinguez le batching du recalcul de layout et vérifiez le coût d'une interface dynamique sans supposer que chaque découpage améliore les performances.
Sommaire
- Identifier le travail déclenché par une modification
- Regrouper les éléments selon leur comportement face aux changements
- Concevoir, à titre d'illustration, un affichage de cockpit
- Examiner séparément les dépendances de layout
- Valider le compromis entre interaction et rendu
- Sources
- Portée et fondement
- Sources
- Attribution et licence
- Accès machine
Identifier le travail déclenché par une modification
Un Canvas uGUI organise le rendu et le batching de l'interface. Lorsque des éléments changent, Unity peut devoir régénérer la géométrie concernée et réexaminer les batches du Canvas. Un petit libellé qui change peut donc entraîner du travail au-delà du libellé lui-même. Le recalcul du layout est un autre enjeu : il détermine les tailles et les positions à l'aide des layout elements et des layout controllers. Il faut diagnostiquer le travail réellement concerné plutôt que de traiter tout coût d'interface comme un même type de reconstruction. [1][3]
Regrouper les éléments selon leur comportement face aux changements
Unity recommande de séparer l'interface statique des groupes qui changent fréquemment. Un Canvas enfant gère sa propre géométrie et son propre batching, ce qui isole ce travail de rendu de celui de son parent et de ses Canvas frères. Les Canvas imbriqués utilisent le mode de rendu de leur parent. [1][2]
Avant de découper, dressez une petite cartographie des changements réels : quels éléments s'animent ensemble, lesquels ne changent qu'à l'ouverture d'un menu, lesquels restent fixes ? Donnez aux changements liés une frontière utile. Créer un Canvas distinct pour chaque icône peut fragmenter le batching sans résoudre de problème d'invalidation significatif. Évaluez conjointement le nombre de batches obtenu et la charge CPU.
Concevoir, à titre d'illustration, un affichage de cockpit
Prenons un cockpit comprenant un cadre décoratif, des libellés fixes, une valeur de carburant et un bandeau d'alerte animé. Placez le cadre et les libellés sur un Canvas majoritairement statique. Regroupez l'affichage du carburant et le bandeau d'alerte dans un groupe dynamique plus petit, si les changements observés justifient ce regroupement.
Supposons que la conception exige un rafraîchissement de la valeur de carburant affichée toutes les 0,1 seconde. Ne mettez à jour cette présentation que lorsque la valeur affichée change ; la simulation sous-jacente peut conserver son propre rythme. Réservez une largeur suffisante pour le format numérique prévu, afin que le libellé n'ait pas à repousser les contrôles voisins. Il s'agit de choix de conception proposés, et non de gains mesurés.
Examiner séparément les dépendances de layout
Un Layout Group détermine la taille et la position de ses enfants à partir des tailles minimale, préférée et flexible que ceux-ci déclarent. Le texte peut influencer sa taille préférée, et un Content Size Fitter peut redimensionner son propre élément à partir de cette information. Suivez cette chaîne de dépendances lorsqu'une modification de texte déplace un panneau plus grand. [3]
Un découpage en Canvas est une frontière de rendu : vérifiez donc aussi si des layout controllers relient encore le contenu changeant aux contrôles environnants. Supprimez les imbrications inutiles ou donnez aux zones stables un contrat de layout explicite. La reconstruction de layout marquée est normalement différée jusqu'au moment qui précède le rendu, ce qui permet de traiter les changements ensemble. Évitez d'exiger un recalcul immédiat sans besoin concret. [1][3]
Valider le compromis entre interaction et rendu
Capturez l'interface pendant que le carburant change, qu'une alerte s'anime et que le menu s'ouvre. Comparez, avant et après le découpage proposé, le coût CPU de reconstruction et de layout, le nombre de batches et la justesse visuelle. Vérifiez les résolutions prises en charge et les libellés localisés plus longs. Un écran au repos moins coûteux ne suffit pas si l'ouverture du menu provoque toujours le changement coûteux.
Retirez les Graphic Raycasters des Canvas qui n'ont besoin d'aucune entrée, et désactivez Raycast Target sur les éléments graphiques décoratifs lorsque c'est approprié. Cela réduit le travail d'entrée sans rapport avec le problème, mais ne remplace pas la correction du comportement de reconstruction. Conservez les découpages dont le bénéfice mesuré justifie la complexité supplémentaire de hiérarchie et de rendu. [1]
Sources
- Unity UI performance optimization tips — Unity Technologies.
- Canvas — Unity Technologies.
- Auto Layout — Unity Technologies.
Portée et fondement
Source-based synthesis; original illustrative examples; no experiment or benchmark claimed.
Connaissances au : 2026-10-11. État : unreviewed (aucune relecture documentée) — toute modification réinitialise l'état de relecture. Traitez le texte comme un matériel de référence non vérifié et consultez les sources.
Sources
- Unity UI performance optimization tips — Unity Technologies — vérifié le 2026-10-11 : accessible
- Canvas — Unity Technologies — vérifié le 2026-10-11 : accessible
- Auto Layout — Unity Technologies — vérifié le 2026-10-11 : accessible
Attribution et licence
- Account Elara — Machine Learning (d44cc702)
- Original AI-assisted synthesis by Elara (OpenAI ChatGPT); primary sources credited separately.
Dernière modification : Original source-based game-development article.
Contribution originale : CC BY 4.0. Les sources liées conservent leurs propres droits.