
Profiler et analyser l'utilisation de la mémoire avec les outils de profilage de mémoire de Unity

-
En profilant et en perfectionnant les performances de votre jeu pour un large éventail de plateformes et d'appareils, vous pouvez élargir votre base de joueurs et augmenter vos chances de succès.
-
Les informations ici sont extraites du Guide ultime pour le profilage des jeux Unity (édition Unity 6), un e-book créé par des experts externes et internes de Unity en développement de jeux, profilage et optimisation.
Qu'est-ce que le profilage de mémoire ?
Le profilage de mémoire est largement sans rapport avec les performances à l'exécution mais est utile pour tester les limites de mémoire de la plateforme matérielle ou si votre jeu plante. Il peut également être pertinent si vous souhaitez améliorer les performances CPU/GPU en apportant des modifications qui augmentent réellement l'utilisation de la mémoire.
Il existe deux façons d'analyser l'utilisation de la mémoire dans votre application dans Unity :
- Le module du profiler de mémoire : C'est un module de profiler intégré qui vous donne des informations de base sur l'utilisation de la mémoire par votre application dans le profiler régulier.
- Le profiler de mémoire : C'est un outil dédié disponible en tant que package Unity que vous pouvez ajouter à votre projet. Il ajoute une fenêtre de profiler de mémoire supplémentaire à l'éditeur Unity, que vous pouvez ensuite utiliser pour analyser l'utilisation de la mémoire dans votre application de manière encore plus détaillée. Vous pouvez stocker et comparer des captures d'écran, afin de localiser les fuites de mémoire ou de visualiser sa configuration pour déterminer d'éventuels problèmes de fragmentation. Nous aborderons cela plus en détail plus tard dans ce guide et nous concentrerons ici sur les considérations générales que vous devez prendre en compte.
Ces deux outils vous permettent de surveiller l'utilisation de la mémoire, de localiser les zones d'une application où l'utilisation de la mémoire est plus élevée que prévu, et de trouver et améliorer la fragmentation de la mémoire.

Comprendre et définir le budget mémoire
Comprendre et budgétiser les limitations de mémoire de vos appareils cibles est essentiel pour le développement multiplateforme. Lors de la conception de scènes et de niveaux, vous devez respecter le budget mémoire qui est fixé pour chaque appareil cible. En fixant des limites et des directives, vous pouvez vous assurer que votre application fonctionne bien dans les limites des spécifications matérielles de chaque plateforme.
Vous pouvez trouver les spécifications de mémoire des appareils dans la documentation des développeurs.
Il peut également être utile de définir des budgets de contenu autour de la complexité des maillages et des shaders, ainsi que pour la compression des textures. Tous ces éléments influencent la quantité de mémoire allouée. Ces chiffres budgétaires peuvent être référencés pendant le cycle de développement du projet.
Déterminer les limites de RAM physique
Comme chaque plateforme a une limite de mémoire, votre application aura besoin d'un budget mémoire pour chacun de ses appareils cibles. Utilisez le profiler de mémoire pour examiner un instantané capturé de votre utilisation de la mémoire. L'instantané des ressources matérielles (voir l'image ci-dessous) montre les tailles de mémoire vive physique (RAM) et de mémoire vidéo à accès aléatoire (VRAM). Ce chiffre ne tient pas compte du fait que tout cet espace pourrait ne pas être disponible à l'utilisation. Cependant, cela fournit une estimation utile pour commencer à travailler.
Il est judicieux de croiser les spécifications matérielles des plateformes cibles, car les chiffres affichés ici ne montrent pas toujours l'ensemble du tableau. Le matériel du kit de développement a parfois plus de mémoire, ou vous pouvez travailler avec un matériel qui a une architecture de mémoire unifiée.

Déterminer la spécification RAM la plus basse
Identifiez le matériel avec la spécification de RAM la plus basse pour chaque plateforme que vous supportez, et utilisez cela pour guider votre décision de budget mémoire. N'oubliez pas que toute cette mémoire physique n'est pas forcément disponible à l'utilisation. Par exemple, une console pourrait avoir un hyperviseur en cours d'exécution pour prendre en charge les anciens jeux qui pourraient utiliser une partie de la mémoire totale. Pensez à un pourcentage (par exemple, 80 % du total) à utiliser par équipe en fonction de votre scénario spécifique. Pour les plateformes mobiles, vous pourriez également envisager de diviser en plusieurs niveaux de spécifications pour mieux soutenir la qualité et les fonctionnalités pour ceux qui ont des appareils haut de gamme.
Considérez les budgets par équipe pour les équipes plus importantes
Une fois que vous avez défini un budget mémoire, envisagez de définir des budgets mémoire par équipe. Par exemple, vos artistes d'environnement obtiennent un certain montant de mémoire à utiliser pour chaque niveau ou scène chargée, l'équipe audio obtient une allocation de mémoire pour la musique et les effets sonores, et ainsi de suite. Bien que cela puisse sembler rigide, considérez-le comme des lignes directrices pour informer les décisions créatives prises par rapport au coût des ressources.
Il est important d'être flexible avec les budgets à mesure que le projet progresse. Si une équipe reste en dessous du budget, attribuez le surplus à une autre équipe si cela peut améliorer les domaines du jeu qu'elle développe.
Une fois que vous avez décidé et défini des budgets mémoire pour vos plateformes cibles, l'étape suivante consiste à utiliser des outils de profilage pour vous aider à surveiller et à suivre l'utilisation de la mémoire dans votre jeu, vous permettant de prendre des décisions éclairées et d'agir si nécessaire.
Quelques conseils pour le profilage de mémoire
Pour déterminer à un niveau élevé quand l'utilisation de la mémoire commence à approcher les budgets de la plateforme, utilisez le calcul suivant :
Mémoire utilisée par le système (ou mémoire totale réservée si la mémoire utilisée par le système montre 0) + tampon approximatif de mémoire non suivie / mémoire totale de la plateforme
Lorsque ce chiffre commence à approcher 100 % du budget mémoire de votre plateforme, utilisez le package Memory Profiler pour comprendre pourquoi.
Dans Unity 6, de nombreuses fonctionnalités du module Memory Profiler sont remplacées par le package Memory Profiler, mais vous pouvez toujours utiliser le module pour compléter vos efforts d'analyse de mémoire. Par exemple :
- Pour repérer les allocations GC : Bien qu'elles apparaissent dans le module, il est plus facile de les suivre en utilisant Project Auditor ou le Profilage Approfondi.
- Pour regarder rapidement la taille Utilisée/Réservée du tas
- Analyse de la mémoire des shaders
- Utilisez la vue Détail dans le module Memory Profiler pour explorer les arbres de mémoire les plus élevés afin de découvrir ce qui utilise le plus de mémoire.
Voici quelques ressources supplémentaires pour vous aider à explorer d'autres cas d'utilisation et fonctionnalités du Profiler Unity :
- Vue d'ensemble du Profiler dans le manuel Unity
- Introduction au profilage dans Unity
- Comment profiler et optimiser un jeu
Vous voudrez généralement profiler en utilisant un système de développement puissant avec beaucoup de mémoire disponible (l'espace pour stocker de grands instantanés de mémoire ou charger et enregistrer ces instantanés rapidement est important).
Le profilage de la mémoire est une bête différente par rapport au profilage CPU et GPU car il peut entraîner une surcharge de mémoire supplémentaire. Vous devrez peut-être profiler la mémoire sur des appareils haut de gamme (avec plus de mémoire), mais faites particulièrement attention à la limite de budget mémoire pour la spécification cible de bas de gamme.
Des paramètres tels que les niveaux de qualité, les niveaux graphiques et les variantes d'AssetBundle peuvent avoir une utilisation de mémoire différente sur des appareils plus puissants. Cela dit, voici quelques détails à garder à l'esprit pour tirer le meilleur parti du profilage de la mémoire :
- Les paramètres de qualité et graphiques peuvent affecter la taille des textures de rendu utilisées pour les cartes d'ombre.
- L'échelle de résolution peut affecter la taille des tampons d'écran, des textures de rendu et des effets de post-traitement.
- Les paramètres de texture peuvent affecter la taille de toutes les textures.
- Le LOD maximum peut affecter les modèles et plus encore.
Si vous avez des variantes d'AssetBundle comme une version HD (Haute Définition) et une version SD (Définition Standard), et que vous choisissez laquelle utiliser en fonction des spécifications de votre appareil cible, vous pourriez obtenir des tailles d'actifs différentes en fonction de l'appareil sur lequel vous profilez.
- La résolution de l'écran de votre appareil cible affectera la taille des textures de rendu utilisées pour les effets de post-traitement.
- L'API graphique prise en charge d'un appareil peut affecter la taille des shaders en fonction des variantes qu'elle prend en charge (ou ne prend pas en charge).
- Un système par niveaux qui utilise différentes qualités et paramètres graphiques, ainsi que des variantes d'AssetBundle, est un excellent moyen de cibler une plus large gamme d'appareils.
Par exemple, vous pouvez charger une version HD d'un AssetBundle sur un appareil mobile de 4 Go, et une version SD sur un appareil de 2 Go. Cependant, prenez en compte les variations ci-dessus de l'utilisation de la mémoire et assurez-vous de tester les deux types d'appareils, ainsi que les appareils avec différentes résolutions d'écran ou API graphiques prises en charge.
Remarque : L'éditeur Unity affichera généralement toujours une empreinte mémoire plus grande en raison des objets supplémentaires chargés depuis l'éditeur et le profileur. De plus, l'empreinte mémoire des textures est plus élevée car elles doivent toutes avoir la lecture/écriture activée dans l'éditeur.

Package du Profileur de mémoire
Le package Profileur de mémoire peut vous aider à comprendre et à optimiser l'utilisation de la mémoire de votre projet. Il vous permet de capturer des 'instantanés' de la mémoire de votre application à des moments spécifiques, à la fois dans l'éditeur Unity et dans les builds Player en cours d'exécution sur votre appareil cible.
Les instantanés fournissent une répartition complète de l'utilisation de la mémoire, montrant les allocations dans tout le moteur. Cela vous aide à identifier les sources d'utilisation excessive ou inutile de la mémoire, à traquer les fuites de mémoire et à inspecter des problèmes comme la fragmentation de la mémoire.
Après avoir installé le package Profileur de mémoire, ouvrez-le via Fenêtre > Analyse > Profileur de mémoire.
La barre de menu supérieure du Profileur de mémoire vous permet de changer la sélection du joueur cible et de capturer ou d'importer des instantanés. Le menu déroulant de sélection de cible dans le coin supérieur gauche vous permet de profiler la mémoire directement sur votre matériel cible en connectant le Profileur de mémoire à l'appareil distant. Notez que le profilage dans l'éditeur Unity vous donnera des chiffres inexacts en raison des surcharges ajoutées par l'éditeur et d'autres outils.

Composant des instantanés
Sur le côté gauche de la fenêtre du Profileur de mémoire se trouve le composant Instantanés. Utilisez ceci pour gérer et ouvrir ou fermer des instantanés de mémoire sauvegardés. Le composant Snapshot fournit deux vues, Instantané unique et Comparer l'instantané.
Semblable à l'Analyseur de profil, le Profiler de mémoire vous permet de charger et de comparer deux instantanés de mémoire côte à côte. Utilisez cette comparaison pour suivre la croissance de la mémoire au fil du temps, analyser l'utilisation entre les scènes ou identifier d'éventuelles fuites de mémoire.
Le Profiler de mémoire a un certain nombre d'onglets dans la fenêtre principale qui vous permettent d'explorer les instantanés de mémoire, les principaux étant Résumé, Objets Unity et Toute la mémoire. Examinons chacune de ces options en détail.

L'onglet Résumé
L'onglet Résumé vous donne un aperçu de haut niveau de l'utilisation de la mémoire de votre projet au moment où une capture de mémoire a été effectuée. C'est parfait lorsque vous souhaitez un aperçu rapide et informatif sans plonger dans une analyse détaillée.
Cette vue met en évidence des indicateurs clés et peut vous aider à repérer rapidement d'éventuels problèmes de mémoire ou des modèles d'utilisation inattendus. C'est particulièrement utile lors de la comparaison d'instantanés ou du débogage de l'utilisation de la mémoire au fil du temps. Examinons quelques-unes de ses sections clés.
Conseils : Dans le panneau de droite (voir l'image ci-dessous), vous trouverez des informations contextuelles utiles sur votre instantané. Celles-ci peuvent vous alerter sur d'éventuels problèmes ou vous guider dans l'interprétation des résultats.
Utilisation de la mémoire sur l'appareil : Cela montre l'empreinte de l'application dans la mémoire physique. Il inclut toutes les allocations Unity et non-Unity résidentes en mémoire au moment de la capture.
Distribution de la mémoire allouée : Cette vue visualise comment la mémoire allouée est répartie entre différentes catégories de mémoire.
Notez la barre de mémoire Non suivi*. Cela correspond à la mémoire que Unity ne suit pas à travers son système de gestion de la mémoire. De telles allocations peuvent provenir de plugins et de pilotes natifs. Utilisez le profileur spécifique à la plateforme pour analyser l'utilisation de la mémoire non suivie pour votre appareil cible.
Utilisation du tas géré : Dans cette vue, vous obtiendrez une répartition de la mémoire que gère la VM de script de Unity, qui inclut la mémoire du tas géré utilisée pour les objets gérés, l'espace de tas vide qui a pu être utilisé précédemment par des objets ou avoir été réservé lors de la dernière expansion du tas, et la mémoire utilisée par la machine virtuelle elle-même.
Principales catégories d'objets Unity : Cela affiche quels types d'objets Unity utilisent le plus de mémoire dans l'instantané (par exemple, Texture2D, maillage, GameObject).

L'onglet Objets
L'onglet Objets Unity affiche tous les objets Unity qui ont alloué de la mémoire, combien de mémoire native et gérée l'objet utilise, et le total combiné. Utilisez ces informations pour identifier les domaines où vous pouvez éliminer les entrées de mémoire en double ou pour trouver quels objets utilisent le plus de mémoire. Et via la barre de recherche, vous pouvez trouver les entrées dans le tableau qui contiennent le texte que vous entrez.
Par défaut, le tableau répertorie tous les objets pertinents par taille allouée par ordre décroissant. Vous pouvez cliquer sur le nom d'un en-tête de colonne pour trier le tableau par cette colonne ou pour changer si la colonne est triée par ordre croissant ou décroissant.
Utilisez cela à votre avantage lors de l'optimisation de l'utilisation de la mémoire et en visant à empaqueter la mémoire plus efficacement pour les plateformes matérielles où les budgets mémoire sont limités.

Techniques et flux de travail de profilage de la mémoire
Commencez par analyser un instantané du profileur de mémoire pour identifier les zones à forte utilisation de mémoire. Une fois que vous capturez ou chargez un instantané du profileur de mémoire, utilisez l'onglet Objets Unity pour inspecter les catégories, classées de la plus grande à la plus petite en taille d'empreinte mémoire.
Les actifs du projet sont souvent les plus gros consommateurs de mémoire. En utilisant le mode Table, localisez les textures, les maillages, les clips audio, les textures de rendu, les variantes de shader et les tampons préalloués. Ce sont souvent de bons candidats pour commencer à optimiser l'utilisation de la mémoire. L'Auditeur de Projet est un excellent outil complémentaire ici car il peut fournir des recommandations sur la façon de réduire l'utilisation de la mémoire pour les actifs (s'assurer que l'actif est correctement configuré dans l'Inspecteur des Paramètres d'Importation est un bon point de départ).
Localiser les fuites de mémoire
Une fuite de mémoire est une situation où des actifs, objets ou ressources inutilisés ne sont pas correctement libérés de la mémoire. Cela peut entraîner une augmentation progressive de l'utilisation de la mémoire et des problèmes de performance ou des plantages.
Une fuite de mémoire se produit généralement lorsque :
- Un objet n'est pas libéré manuellement de la mémoire par le code.
- Un objet reste involontairement en mémoire parce qu'un autre objet détient encore une référence à celui-ci.
Le Profiler de Mémoire a un mode Comparer les Instantanés qui peut aider à trouver des fuites de mémoire en comparant deux instantanés sur une période de temps spécifique. Cette comparaison peut révéler des objets qui persistent en mémoire alors qu'ils devraient être désalloués.
Un scénario fréquent de fuites de mémoire dans les jeux Unity est après le déchargement d'une scène. Les objets de la scène déchargée peuvent ne pas être correctement collectés par le ramasse-miettes si des références à ceux-ci existent encore.
Localiser les allocations de mémoire récurrentes au cours de la durée de vie de l'application
Grâce à la comparaison différentielle de plusieurs instantanés de mémoire, vous pouvez identifier la source des allocations de mémoire continues pendant la durée de vie de l'application.
Les sections suivantes fournissent quelques conseils pour aider à identifier les allocations de tas gérées dans vos projets.

Allocations gérées comme indiqué dans le module du Profileur de mémoire
Le module Profiler de Mémoire dans le Profiler Unity représente les allocations gérées par image avec une ligne rouge. Cela devrait être 0 la plupart du temps, donc toute augmentation de cette ligne indique des images que vous devriez examiner pour des allocations gérées.

Aperçu Timeline dans le module du profileur d'utilisation du processeur
La vue Timeline dans le module Profiler d'Utilisation du CPU montre les allocations, y compris celles gérées, en rose, ce qui les rend faciles à cibler.

Piles d'exécution d'allocations
Les piles d'appels d'allocation fournissent un moyen rapide de découvrir les allocations de mémoire gérées dans votre code. Celles-ci fourniront les détails de la pile d'appels dont vous avez besoin avec moins de surcharge par rapport à ce que le profilage approfondi ajouterait normalement, et elles peuvent être activées à la volée en utilisant le Profiler standard.
Les piles d'appels d'allocation sont désactivées par défaut dans le Profiler. Pour les activer, cliquez sur le bouton Piles d'appels dans la barre d'outils principale de la fenêtre du Profiler. Changez la vue Détails en Données connexes.
Remarque : Si vous utilisez une version plus ancienne de Unity (avant le support des piles d'appels d'allocation), alors le profilage approfondi est un bon moyen d'obtenir des piles d'appels complètes pour aider à trouver les allocations gérées.
Les échantillons GC.Alloc sélectionnés dans la Hiérarchie ou la Hiérarchie brute contiendront désormais leurs piles d'appels. Vous pouvez également voir les piles d'appels des échantillons GC.Alloc dans l'info-bulle de sélection dans la Timeline.

Vue hiérarchique dans le module du profileur d'utilisation du processeur
La vue Hiérarchie dans le Profiler d'utilisation du CPU vous permet de cliquer sur les en-têtes de colonne pour les utiliser comme critères de tri. Trier par GC Alloc est un excellent moyen de se concentrer sur ceux-ci.

Auditeur de projet
L'Auditeur de projet, introduit en tant que package dans Unity 6.1, est un outil d'analyse puissant pour les projets Unity, conçu pour aider les développeurs à optimiser les performances, à maintenir les meilleures pratiques et à identifier les problèmes et goulets d'étranglement potentiels dans leurs projets.
L'Auditeur de projet analyse l'ensemble de votre projet et fournit des rapports détaillés sur les inefficacités, telles que les appels de script lourds, les actifs inutilisés, les comptes d'entités excessifs, etc.
L'Auditeur de projet couvre plusieurs domaines différents :
Optimisation des performances : Il identifie les problèmes qui pourraient affecter les performances d'exécution de votre projet, tels que la génération excessive de déchets, les allocations d'objets inutiles ou les appels de fonctions coûteux.
Revue de code et d'actifs : Il met en évidence les actifs inutilisés, les modèles de code inefficaces ou les API obsolètes qui peuvent être refactorisées. Cela aide à réduire la taille de la build, à améliorer la maintenabilité globale du projet et à optimiser l'utilisation de la mémoire.
Diagnostics et meilleures pratiques : Il fournit des recommandations basées sur les meilleures pratiques de Unity et met en évidence les erreurs ou avertissements liés à la configuration de votre projet, comme les références manquantes ou les paramètres de Player ou de qualité sous-optimaux.
Rapports personnalisables: Il organise les résultats en catégories, facilitant la priorisation des optimisations. Vous pouvez également créer des règles personnalisées pour adapter l'analyse à votre projet ou à vos besoins spécifiques.
💡Conseils:
- Exécutez le Project Auditor à des étapes clés du développement (par exemple, avant les jalons, les versions bêta, les versions finales). Des audits réguliers aident à détecter les goulets d'étranglement de performance, les actifs inutilisés ou le code obsolète tôt, empêchant les problèmes de devenir plus importants à mesure que votre projet évolue.
- Vous pouvez automatiser l'exécution du Project Auditor dans le cadre de votre CI ou de votre configuration de build (comme indiqué ici dans le manuel) et utiliser les rapports pour vous assurer que personne n'ajoute d'actifs ou de code qui créent de nouveaux problèmes (en utilisant l'API détaillée ici).
- Vous pouvez ajouter vos propres règles s'il y a des éléments particuliers que vous souhaitez vous assurer de capturer dans votre jeu ; par exemple, les paramètres de texture, les tailles ou des règles plus compliquées. Voir cette page dans le manuel pour plus de détails sur la façon de procéder.
Les rapports générés par le Project Auditor sont classés par gravité (Majeur, Modéré et Info). Concentrez-vous d'abord sur les problèmes les plus graves, car ils mettent souvent en évidence des problèmes critiques de performance, tels que la surallocation de mémoire ou une collecte de déchets excessive. Ils sont également susceptibles d'être dans des chemins de code qui sont appelés plus fréquemment, comme Update, où tout problème de performance qu'ils entraînent sera plus évident pour les joueurs.
Le Project Auditor vérifie également des paramètres comme Paramètres du joueur et Paramètres de qualité et fait des recommandations sur ce que vous pourriez changer. Utilisez cela pour vous assurer que vos cibles de build, votre résolution, votre compression de texte ou d'autres paramètres de projet sont optimisés pour votre plateforme prévue.
Rechargement de domaine
L'éditeur Unity vous permet de configurer des paramètres concernant l'entrée en mode Play ; cette page contient plus de détails à ce sujet, mais vous pouvez souvent accélérer votre temps d'itération dans l'éditeur en désactivant le rechargement de domaine. Cependant, cela ne réinitialisera plus votre état de script chaque fois que vous entrez en mode Play, vous devez donc le faire manuellement dans votre code.
La zone de code dans le Project Auditor peut analyser les scripts de votre projet pour vous aider à trouver où vous devez réinitialiser vos variables de script. Il est considéré comme une bonne pratique de corriger tous les problèmes affichés dans la vue de rechargement de domaine, puis de désactiver le rechargement de domaine. Pour remplir cette vue avec des données, vous devez activer le paramètre Utiliser les analyseurs Roslyn dans la fenêtre Préférences. Ensuite, vous pouvez parcourir la liste des problèmes, en suivant les instructions dans le manuel pour les résoudre. Une fois qu'ils sont tous traités, vous pouvez désactiver le rechargement de domaine lors de l'entrée en mode jeu.

Optimisations de la mémoire et du GC
Unity utilise le collecteur de déchets Boehm-Demers-Weiser pour nettoyer automatiquement la mémoire lorsqu'elle n'est plus nécessaire pour votre application. Le GC arrête l'exécution de votre code de programme et ne reprend l'exécution normale qu'une fois son travail terminé.
Bien que la gestion automatique soit pratique, des allocations inutiles ou fréquentes peuvent entraîner des problèmes de performance car le collecteur de déchets doit mettre votre jeu en pause pour nettoyer la mémoire inutilisée (également connu sous le nom de pics de GC). Voici quelques pièges courants à garder à l'esprit :
Chaînes : En C#, les chaînes sont des types de référence, pas des types de valeur. Cela signifie que chaque nouvelle chaîne sera allouée sur le tas géré, même si elle n'est utilisée que temporairement. Réduisez la création ou la manipulation de chaînes inutiles. Évitez d'analyser des fichiers de données basés sur des chaînes tels que JSON et XML, et stockez les données dans des ScriptableObjects ou des formats comme MessagePack ou Protobuf à la place. Utilisez la classe StringBuilder si vous devez construire des chaînes à l'exécution.
Appels de fonction Unity : Certaines fonctions de l'API Unity créent des allocations sur le tas, en particulier celles qui retournent un tableau d'objets gérés temporaires. Mettez en cache les références aux tableaux plutôt que de les allouer au milieu d'une boucle. De plus, profitez de certaines fonctions qui évitent de générer des déchets. Par exemple, utilisez GameObject.CompareTag au lieu de comparer manuellement une chaîne avec GameObject.tag (car retourner une nouvelle chaîne crée des déchets).
Vous pouvez également utiliser l'Auditeur de Projet pour lister ces alternatives ; cela peut aider à garantir que vous utilisez les versions non allouantes chaque fois que possible.
Boxing : La conversion se produit lorsqu'un type valeur (par exemple, int, float, struct) est converti en un type référence (par exemple, object). Évitez de passer une variable de type valeur à la place d'une variable de type référence. Cela crée un objet temporaire, et les déchets potentiels qui l'accompagnent convertissent implicitement le type valeur en un type objet (par exemple, int i = 123; object o = i). Essayez plutôt de fournir des remplacements concrets avec le type valeur que vous souhaitez passer. Les génériques peuvent également être utilisés pour ces remplacements.
Coroutines : Bien que yield ne produise pas de déchets, la création d'un nouvel objet WaitForSeconds le fait. Mettez en cache et réutilisez l'objet WaitForSeconds plutôt que de le créer dans la ligne yield.
LINQ et expressions régulières : Ces deux-là génèrent des déchets à partir de la conversion en arrière-plan. Évitez LINQ et les expressions régulières si la performance est un problème. Écrivez des boucles for et utilisez des listes comme alternative à la création de nouveaux tableaux.
Collections génériques et autres types gérés : Ne déclarez pas et ne remplissez pas une liste ou une collection à chaque image dans Update (par exemple, une liste d'ennemis dans un certain rayon du joueur). Au lieu de cela, faites de la liste un membre de MonoBehaviour et initialisez-la dans Start. Il suffit de vider la collection avec Clear à chaque image avant de l'utiliser.
Collecte des déchets de temps chaque fois que possible
Si vous êtes certain qu'un gel de collecte des déchets n'affectera pas un point spécifique de votre jeu, vous pouvez déclencher la collecte des déchets avec System.GC.Collect. Un exemple classique de cela est lorsque l'utilisateur est dans un menu ou met le jeu en pause, où cela ne sera pas perceptible.
Voir Comprendre la gestion automatique de la mémoire pour des exemples de la façon de l'utiliser à votre avantage.
Utilisez le collecteur de déchets incrémental pour répartir la charge de travail du GC
Au lieu de créer une seule interruption longue pendant l'exécution de votre programme, la collecte de déchets incrémentale utilise plusieurs interruptions plus courtes qui répartissent la charge de travail sur de nombreux frames. Si la collecte de déchets provoque un taux de rafraîchissement irrégulier, essayez cette option pour voir si elle réduit le problème des pics de GC. Utilisez l'analyseur de profil pour vérifier son avantage pour votre application.
Notez que l'utilisation du GC en mode incrémental ajoute des barrières de lecture-écriture à certains appels C#, ce qui entraîne un certain surcoût pouvant atteindre ~1 ms par frame d'appel de script. Pour des performances optimales, il est idéal de ne pas avoir d'allocations GC dans les boucles de jeu principales afin de ne pas avoir besoin du GC incrémental pour un taux de rafraîchissement fluide et de pouvoir cacher le GC.Collect là où un utilisateur ne le remarquera pas, par exemple, lors de l'ouverture du menu ou du chargement d'un nouveau niveau. Dans de tels scénarios optimisés, vous pouvez effectuer des collectes de déchets complètes et non incrémentales (en utilisant System.GC.Collect()).
Pour en savoir plus sur le profiler de mémoire, consultez les ressources suivantes :
Guide et tutoriel du profiler de mémoire
Documentation du profiler de mémoire
Améliorez l'utilisation de la mémoire avec le profiler de mémoire dans Unity
Profiler de mémoire : L'outil pour résoudre les problèmes liés à la mémoire

Vous pouvez trouver de nombreuses autres bonnes pratiques et conseils pour les développeurs et créateurs Unity avancés dans le hub des bonnes pratiques Unity. Choisissez parmi plus de 30 guides, créés par des experts de l'industrie, des ingénieurs et des artistes techniques Unity, qui vous aideront à développer efficacement avec les outils et systèmes de Unity.