Vérification de la version: 2017.3 -Difficulté: Avancé
Parfois, il n'existe aucun moyen propre d'optimiser l'interface utilisateur. Cette section contient des suggestions qui peuvent aider à améliorer les performances de l'interface utilisateur, mais certaines suggestions sont de structure «impure», peuvent être difficiles à maintenir ou peuvent avoir des effets secondaires indésirables. D'autres méthodes peuvent être de résoudre le comportement dans l'interface utilisateur, le but est de simplifier le développement initial, mais aussi de rendre relativement simple la création de problèmes de performances.
Dispositions basées sur RectTransform
Le coût des composants de mise en page est relativement élevé, car chaque fois qu'ils sont marqués comme éléments sales, ils doivent recalculer la taille et la position des éléments enfants. (Pour plus de détails, veuillez vous référer à la section de reconstruction graphique de la section de base.) Si le nombre d'éléments dans une mise en page donnée est relativement petit et fixe, et que la mise en page a une structure relativement simple, vous pouvez remplacer la mise en page par une mise en page basée sur RectTransform.
En affectant le point d'ancrage du RectTransform, la position et la taille du RectTransform peuvent être mises à l'échelle en fonction de son nœud parent. Par exemple, vous pouvez utiliser deux RectTransform pour implémenter une mise en page simple à deux colonnes:
- Les ancres de la colonne de gauche doivent être X: (0, 0,5) et Y: (0, 1)
- Les ancres de la colonne de droite doivent être X: (0,5, 1) et Y: (0, 1)
Le système Transform lui-même pilotera le calcul de la taille et de la position de RectTransform dans le code natif. C'est généralement plus performant que de s'appuyer sur le système de mise en page. Vous pouvez également écrire pour définir un comportement unique basé sur la disposition de RectTransform. Cependant, il s'agit d'une tâche relativement complexe qui dépasse le cadre de ce guide.
Désactivation des toiles
Lors de l'affichage ou du masquage de parties discrètes de l'interface utilisateur, GameObject est généralement activé ou désactivé à la racine de l'interface utilisateur. Cela garantit qu'aucun composant de l'interface utilisateur désactivée ne recevra une entrée ou des rappels uniformes.
Cependant, cela obligera également Canvas à supprimer ses données VBO. La réactivation du canevas nécessitera le canevas (et tout sous-canevas) pour exécuter le processus de reconstruction et de rebatch. Si cela se produit fréquemment, l'augmentation de l'utilisation du processeur entraînera une augmentation de la fréquence d'images de l'application.
Une solution possible mais piratée consiste à placer l'interface utilisateur à afficher / masquer sur votre canevas ou sous-canevas, puis à activer / désactiver uniquement le composant canevas sur cet objet.
Cela empêchera le dessin des grilles de l'interface utilisateur, mais elles resteront en mémoire et leurs lots d'origine seront conservés. En outre, les rappels OnEnable ou OnDisable ne seront pas appelés dans la hiérarchie de l'interface utilisateur.
Cependant, notez que cela ne désactivera aucun comportement unique dans l'interface utilisateur masquée, de sorte que ces comportements uniques recevront toujours des rappels de cycle de vie Unity, tels que Update.
Pour éviter ce problème, les MonoBehaviors de l'interface utilisateur qui seront désactivés de cette manière ne doivent pas implémenter directement les rappels de cycle de vie d'Unity, mais doivent recevoir des rappels du MonoBehavior "Callback Manager" sur le GameObject racine de l'interface utilisateur. Chaque fois que vous affichez / masquez l'interface utilisateur, vous pouvez notifier ce "Gestionnaire de rappel" et vous assurer que les événements du cycle de vie sont propagés ou non propagés selon les besoins. Une explication plus détaillée de ce mode «Gestionnaire de rappel» dépasse le cadre de ce guide.
Attribution de caméras d'événement
Si vous utilisez le paramètre de canevas à côté du gestionnaire d'entrée intégré de Unity dans World Space ou Screen Space-Camera, vous devez définir respectivement les propriétés de la caméra d'événement ou de la caméra de rendu. À partir du script, cela est toujours exposé en tant que propriété WorldCamera.
Si cette propriété n'est pas définie, UnityUI recherchera la caméra principale en recherchant les composants de caméra attachés à GameObjects avec l'étiquette de caméra principale. Cette recherche se produira au moins une fois, chaque espace du monde ou espace de caméra Canvases. En raison de la vitesse lente de GameObject.FindWithTag, il est fortement recommandé que toutes les toiles World Space et Camera Space attribuent leurs propriétés de caméra pendant la conception ou l'initialisation.
Ce problème ne se produit pas sur les toiles qui se chevauchent.
Personnalisation du code source de l'interface utilisateur
Le système d'interface utilisateur est conçu pour prendre en charge un grand nombre de cas d'utilisation. Cette flexibilité est excellente, mais cela signifie également que certaines optimisations ne sont pas faciles à réaliser sans interrompre d'autres fonctionnalités. Si vous pouvez enfin obtenir des cycles de processeur en modifiant le code source de l'interface utilisateur C #, vous pouvez recompiler la DLL de l'interface utilisateur et écraser les cycles de processeur fournis avec Unity. Ce processus est documenté dans le fichier Lisez - moi du référentiel Bitbucket . Assurez-vous d'obtenir le code source correspondant à votre version d'Unity.
Cependant, cela ne peut être utilisé qu'en dernier recours, car il y a des lacunes importantes. Tout d'abord, vous devez trouver un moyen de distribuer cette nouvelle DLL à vos développeurs et de construire la machine. Ensuite, chaque fois que vous mettez à niveau Unity, vous devez fusionner les modifications avec le nouveau code source de l'interface utilisateur. Assurez-vous que vous ne pouvez pas simplement étendre les classes existantes ou écrire votre propre version des composants avant de vous déplacer dans cette direction.