Optimisez les performances de vos jeux mobiles : Obtenez des conseils d'experts sur la physique, l'interface utilisateur et les paramètres audio.
Notre équipe Integrated Success soutient les clients d'Unity dans leurs problèmes techniques complexes. Nous avons rencontré cette équipe d'ingénieurs logiciels seniors et leur avons demandé de nous faire part de leur expertise en matière d'optimisation des jeux mobiles.
Notre équipe Accelerate Solutions connaît parfaitement le code source et travaille avec une pléthore de clients Unity pour les aider à tirer le meilleur parti du moteur. Dans le cadre de leur travail, ils se plongent dans les projets des créateurs afin d'identifier les points où les performances pourraient être optimisées pour plus de rapidité, de stabilité et d'efficacité.
Lorsque nos ingénieurs ont commencé à partager leurs idées sur l'optimisation des jeux mobiles, nous avons rapidement réalisé qu'il y avait beaucoup trop d'informations intéressantes pour le seul article de blog que nous avions prévu. Nous avons donc décidé de transformer cette montagne de connaissances en un livre électronique complet (que vous pouvez télécharger ici), ainsi qu'en une série d'articles de blog qui mettent en lumière quelques-uns de ces 75+ conseils pratiques.
Dans ce deuxième épisode de la série, nous allons nous pencher sur la façon d'améliorer les performances avec l'interface utilisateur, la physique et les paramètres audio. Au cas où vous l'auriez manqué, consultez notre précédent article sur le profilage, la mémoire et l'architecture du code - et restez à l'écoute de notre prochain article, consacré aux actifs, à la configuration du projet et aux graphiques.
Vous voulez tout savoir maintenant ? Télécharger le livre électronique gratuit.
Entrons dans le vif du sujet !
La physique intégrée à Unity (Nvidia PhysX) peut être coûteuse sur mobile, mais les conseils suivants peuvent vous aider à obtenir plus d'images par seconde.
Dans les paramètres du joueur, cochez l'option Prebake Collision Meshes lorsque c'est possible.
Veillez à modifier vos paramètres de physique(Paramètres du projet > Physique) et à simplifier la matrice de collision des couches dans la mesure du possible.
Désactiver les transformations de synchronisation automatique et activer les rappels de réutilisation des collisions.
Les collisionneurs de maillage peuvent être coûteux. Remplacer les collisions de mailles plus complexes par des collisions de mailles primitives ou simplifiées afin d'obtenir une forme approximative de la forme originale.
Utilisez des méthodes de classe telles que MovePosition ou AddForce pour déplacer vos objets Rigidbody. La traduction directe de leurs composants Transform peut entraîner des recalculs du monde physique, ce qui est coûteux dans les scènes complexes. Déplacer les corps physiques en FixedUpdate plutôt qu'en Update.
Le pas de temps fixe par défaut dans les paramètres du projet est de 0,02 (50 Hz). Modifiez cette valeur pour qu'elle corresponde à la fréquence d'images visée (par exemple, 0,03 pour 30 fps).
Cependant, si votre taux de rafraîchissement chute au moment de l'exécution, cela signifie qu'Unity appellera FixedUpdate plusieurs fois par image et créera potentiellement un problème de performance du processeur avec un contenu à forte composante physique.
Le paramètre Maximum Allowed Timestep limite le temps que les calculs physiques et les événements FixedUpdate peuvent utiliser en cas de baisse de la fréquence d'images. L'abaissement de cette valeur signifie que lors d'un problème de performance, la physique et l'animation peuvent être ralenties, tout en réduisant leur impact sur le taux d'images par seconde.
Utilisez la fenêtre de débogage physique(Window > Analysis > Physics Debugger) pour résoudre les problèmes liés aux collisionneurs ou aux divergences. Ceci montre un code couleur des GameObjects qui peuvent entrer en collision les uns avec les autres.
Pour plus d'informations, voir Physics Debug Visualization dans la documentation Unity.
L'interface Unity UI (UGUI) peut souvent être une source de problèmes de performances. Le composant Canvas génère et met à jour les maillages des éléments de l'interface utilisateur et lance des appels de dessin au GPU. Son fonctionnement peut être coûteux, il convient donc de garder à l'esprit les facteurs suivants lorsque l'on travaille avec l'UGUI.
Si vous avez un grand canevas avec des milliers d'éléments, la mise à jour d'un seul élément de l'interface utilisateur oblige l'ensemble du canevas à se mettre à jour, ce qui peut potentiellement générer un pic d'activité du processeur.
Tirez parti de la capacité de l'UGUI à prendre en charge plusieurs canevas. Divisez les éléments de l'interface utilisateur en fonction de la fréquence à laquelle ils doivent être rafraîchis. Les éléments statiques de l'interface utilisateur doivent être placés sur un canevas distinct et les éléments dynamiques qui sont mis à jour en même temps doivent être placés sur des sous-canevas plus petits.
Veiller à ce que tous les éléments de l'interface utilisateur dans chaque canevas aient la même valeur Z, les mêmes matériaux et les mêmes textures.
Vous pouvez avoir des éléments d'interface utilisateur qui n'apparaissent que sporadiquement dans le jeu (par exemple, une barre de santé qui apparaît lorsqu'un personnage subit des dégâts). Si l'élément invisible de l'interface utilisateur est actif, il est possible qu'il utilise encore des appels de dessin. Désactiver explicitement les composants invisibles de l'interface utilisateur et les réactiver si nécessaire.
Si vous avez seulement besoin de désactiver la visibilité du Canvas, désactivez le composant Canvas plutôt que GameObjects. Cela permet d'éviter de reconstruire les maillages et les sommets.
Les événements d'entrée tels que les touches ou les clics sur l'écran nécessitent le composant GraphicRaycaster. Il s'agit simplement de parcourir en boucle chaque point d'entrée à l'écran et de vérifier s'il se trouve à l'intérieur de la RectTransform de l'interface utilisateur.
Supprime le GraphicRaycaster par défaut du Canvas supérieur dans la hiérarchie. Au lieu de cela, ajoutez le GraphicRaycaster exclusivement aux éléments individuels qui doivent interagir (boutons, scrollrects, etc.).
Désactivez également la cible Raycast pour tous les textes et images de l'interface utilisateur qui n'en ont pas besoin. Si l'interface utilisateur est complexe et comporte de nombreux éléments, tous ces petits changements peuvent réduire les calculs inutiles.
Les groupes de présentation se mettent à jour de manière inefficace, il faut donc les utiliser avec parcimonie. Évitez-les complètement si votre contenu n'est pas dynamique et utilisez plutôt des ancres pour les mises en page proportionnelles. Sinon, créez un code personnalisé pour désactiver les composants du groupe de présentation une fois qu'ils ont configuré l'interface utilisateur.
Si vous devez utiliser des groupes de disposition (horizontale, verticale, grille) pour vos éléments dynamiques, évitez de les imbriquer pour améliorer les performances.
Les grandes listes et les grilles sont coûteuses. Si vous devez créer une liste ou une grille de grande taille (par exemple, un écran d'inventaire comportant des centaines d'articles), envisagez de réutiliser un ensemble plus restreint d'éléments d'interface utilisateur plutôt que de créer un élément d'interface utilisateur pour chaque article. Consultez cet exemple de projet GitHub pour le voir à l'œuvre.
La superposition de nombreux éléments d'interface utilisateur (par exemple, des cartes empilées dans un jeu de bataille de cartes) crée un effet de surcharge. Personnalisez votre code pour fusionner les éléments superposés au moment de l'exécution en un nombre réduit d'éléments et de lots.
Les appareils mobiles utilisant désormais des résolutions et des tailles d'écran très différentes, créez des versions alternatives de l'interface utilisateur afin d'offrir la meilleure expérience possible sur chaque appareil.
Utilisez le Device Simulator Devices pour prévisualiser l'interface utilisateur sur une large gamme d'appareils pris en charge. Vous pouvez également créer des dispositifs virtuels dans XCode et Android Studio.
Si votre écran de pause ou de démarrage couvre tout le reste de la scène, désactivez la caméra qui rend la scène 3D. De même, désactivez tous les éléments du canevas d'arrière-plan cachés derrière le canevas supérieur.
Envisagez d'abaisser l'Application.targetFrameRate lors d'une interface utilisateur plein écran, puisque vous ne devriez pas avoir besoin de mettre à jour à 60 fps.
Le fait de laisser le champ Event ou Render Camera vide oblige Unity à remplir Camera.main, ce qui est inutilement coûteux.
Pensez à utiliser Screen Space - Overlay pour votre Canvas RenderMode si possible, car cela ne nécessite pas de caméra.
Bien que l'audio ne soit normalement pas un goulot d'étranglement pour les performances, vous pouvez toujours l'optimiser pour économiser de la mémoire.
Si vous utilisez un format compressé (tel que MP3 ou Vorbis), Unity le décompressera, puis le recompressera pendant la construction. Il en résulte deux passages avec perte, ce qui dégrade la qualité finale.
Réduisez la taille de vos clips et l'utilisation de la mémoire grâce à la compression :
- Utilisez Vorbis pour la plupart des sons (ou MP3 pour les sons qui ne sont pas destinés à être mis en boucle).
- Utilisez l'ADPCM pour les sons courts et fréquemment utilisés (par exemple, bruits de pas, coups de feu). Cela réduit la taille des fichiers par rapport au PCM non compressé, mais le décodage est rapide pendant la lecture.
Sur les appareils mobiles, les effets sonores doivent avoir une fréquence maximale de 22 050 Hz. L'utilisation de paramètres inférieurs n'a généralement qu'un impact minime sur la qualité finale ; utilisez vos propres oreilles pour en juger.
Le réglage varie en fonction de la taille du clip.
- Les petits clips (< 200 kb) devraient Décompresser au chargement. La décompression d'un son en données audio PCM 16 bits brutes entraîne des coûts de CPU et de mémoire, et n'est donc souhaitable que pour les sons courts.
- Les clips de taille moyenne (>= 200 kb) doivent rester compressés en mémoire.
- Les fichiers volumineux (musique de fond) doivent être réglés sur Streaming, sinon l'intégralité du fichier sera chargée en mémoire en une seule fois.
Lorsque vous mettez en place un bouton de mise en sourdine, ne vous contentez pas de mettre le volume à 0. Vous pouvez détruire le composant AudioSource pour le décharger de la mémoire, à condition que le lecteur n'ait pas besoin de l'activer et de le désactiver très souvent.
Dans le prochain article de blog, nous nous pencherons sur les graphiques et les actifs. Mais si vous souhaitez accéder à la liste complète des conseils et astuces de l'équipe d'aujourd'hui, notre livre électronique complet est disponible ici.
TÉLÉCHARGER LE LIVRE ÉLECTRONIQUE
Si vous souhaitez en savoir plus sur les services d'assistance intégrée et donner à votre équipe un accès direct aux ingénieurs, aux conseils d'experts et aux meilleures pratiques pour vos projets, consultez les plans de réussite d'Unity ici.
Nous voulons vous aider à rendre vos applications Unity aussi performantes que possible, alors s'il y a des sujets d'optimisation sur lesquels vous aimeriez en savoir plus, n'hésitez pas à nous en faire part dans les commentaires.