Untersuchung des Speichers mit dem neuen Memory Profiler-Paket

In diesem Blog werden wir fünf wichtige Arbeitsabläufe im neuen Memory Profiler-Paket behandeln, mit denen Sie speicherbezogene Probleme in Ihrem Spiel diagnostizieren und untersuchen können. Diese sind:

• Überwachung des Speicherbedarfs Ihrer Anwendung
• Die Verteilung von Unity-Objekten sehen
• Erkennen von schlecht konfigurierten Assets
• Unbeabsichtigte doppelte Objekte aufspüren
• Vergleich von Speicheraufzeichnungen zur Überprüfung von Optimierungen

Eine Einführung in den Memory Profiler finden Sie in unserem aktuellen Blog, Alles, was Sie über Memory Profiler 1.0.0 wissen müssen.

Dieser erste Workflow überwacht, wie stark Ihre Anwendung die Speicherressourcen eines Geräts beansprucht. Dieser Prozess ist entscheidend, um festzustellen, ob für Ihre Anwendung das Risiko von Leistungsproblemen besteht oder ob sie sogar vom Betriebssystem entfernt und beendet wird, weil sie zu viel Speicher verbraucht.

Zu Beginn haben wir ein Build eines Beispielspiels, das auf dem Zielgerät läuft. Natürlich ist es unabdingbar, dass wir eine Speichererfassung des Spiels machen, die auf der tatsächlichen Hardware läuft, um zu sehen, wie es die verfügbaren Speicherressourcen des Geräts nutzt. Außerdem verhält sich der Speicher im Unity-Editor anders als in der Unity-Laufzeitumgebung, so dass eine Speichererfassung des Editors im Spielmodus keine gute Darstellung dessen ist, wie der Speicher eines Spiels auf einem Gerät aussehen wird. (Die Aufnahme eines Speicherauszugs des Editors ist sinnvoll, wenn Sie Werkzeuge für den Editor entwickeln, z. B. benutzerdefinierte Editorfenster).

Nachdem wir zu der Phase in unserem Spiel navigiert haben, in der wir die Speichernutzung analysieren wollen, verbinden wir den Memory Profiler mit unserem Gerät, indem wir die Dropdown-Liste im Memory Profiler verwenden. Wir können dann eine Speichererfassung machen, wie unten gezeigt.

Nach dem Öffnen dieser Aufzeichnung zeigt der Memory Profiler den Speicherbedarf unserer Anwendung oben auf der Seite Zusammenfassung als "Speichernutzung auf dem Gerät" an.

Hier sehen wir, dass der Speicherbedarf unserer Anwendung 492,5 MB beträgt, bei einer verfügbaren Speicherkapazität von 3,50 GB. Wir müssen nun nach bestem Wissen und Gewissen entscheiden, ob dies ein vernünftiger Anteil des physischen Speichers (RAM) des Geräts ist, der zum Zeitpunkt der Erfassung verwendet wird. Denken Sie daran, dass der physische Speicher eines Geräts von allen laufenden Prozessen gemeinsam genutzt wird.

Sie werden feststellen, dass dieser visuelle Indikator den gesamten residenten Speicher anzeigt. Der gesamte residente Speicher bezieht sich darauf, wie viel des Speichers Ihrer Anwendung sich in der physischen Speicherhardware (RAM) des Geräts befindet. Dies ist aus zwei Gründen der deutlichste Indikator dafür, wie anspruchsvoll die aktuelle Speichernutzung Ihrer Anwendung auf dem Zielgerät ist. Erstens steigt mit der Gesamtnutzung des residenten Speichers Ihrer Anwendung auch die Wahrscheinlichkeit, dass häufige Auslagerungsfehler auftreten, bei denen das Betriebssystem den virtuellen Speicher in den physischen Speicher des Geräts auslagern muss. Häufige Seitenfehler führen zu erheblichen Leistungseinbußen bei Ihrer Anwendung. Zweitens verwenden viele Betriebssysteme die Nutzung des residenten Speichers Ihrer Anwendung, um deren aktuellen Speicherbedarf zu ermitteln. Wenn der Speicherbedarf Ihrer Anwendung zu groß wird, entfernt das Betriebssystem Ihre Anwendung und beendet sie, was zu einem Absturz Ihrer Spieler führt.

Daher können Sie den visuellen Indikator für die Speichernutzung auf dem Gerät im Memory Profiler verwenden, um festzustellen, ob bei einer Anwendung die Gefahr besteht, dass sie aufgrund einer übermäßigen Speichernutzung zum Zeitpunkt der Erfassung Leistungsprobleme hat oder vom Betriebssystem beendet wird.

Dies steht im Gegensatz zu Allocated Memory, manchmal auch Committed Memory genannt, das in verschiedenen Grafiken unterhalb dieses Indikators angezeigt wird und derzeit die Standardoption für alle anderen Ansichten ist, z. B. Unity Objects. Zugewiesener Speicher bezieht sich auf den gesamten Speicher, der Ihrer Anwendung derzeit zugewiesen ist, unabhängig davon, ob er im physischen Speicher resident gemacht wurde oder nicht, und entspricht daher eher der Sichtweise Ihrer Anwendung auf den Speicher. Dies kann nützlich sein, um den gesamten aktuell zugewiesenen Speicher Ihrer Anwendung zu untersuchen, während die Nutzung des residenten Speichers der Schlüssel zum Verständnis der Speicherbelastung ist, die Ihre Anwendung zu einem bestimmten Zeitpunkt auf die Hardware ausübt.

Die Registerkarte " Unity-Objekte" des Memory Profiler bietet Ihnen einen Überblick über den Speicher Ihrer Anwendung aus der Perspektive der Unity-Objekte, also der Texturen, Shader, Meshes, Materialien usw. Ihrer Anwendung. Dies ist ein großartiger Ort, um mit der Untersuchung im Memory Profiler zu beginnen, da Unity-Objekte vielen Unity-Benutzern von Natur aus vertraut sein werden, da die meisten von uns direkt im Unity-Editor damit arbeiten. Dies bietet nicht nur einen vertrauten Einstiegspunkt, um den Speicher unserer Anwendung zu verstehen, sondern kann auch dabei helfen, eine Reihe von potenziellen Problemen zu diagnostizieren und zu beheben, indem dieser Unity-spezifische Kontext bereitgestellt wird.

Um die Ansicht "Unity-Objekte" zu sehen, wählen Sie einfach die Registerkarte "Unity-Objekte" oben im Memory Profiler, nachdem Sie eine Speichererfassung geöffnet haben, wie oben gezeigt.

Sie können sehen, wie die Unity Objects-Ansicht uns schnell einen Überblick über die Verteilung der Unity-Objekttypen in unserer Anwendung gibt. Auf diese Weise können wir sowohl einen Überblick darüber gewinnen, welche Typen zum Zeitpunkt der Erfassung am meisten Speicher verbraucht haben, als auch Schlussfolgerungen ziehen, z. B. ob zu erwarten ist, dass eine bestimmte Szene viele AudioClip-Objekte enthält. Durch Erweitern jedes Typs können wir auch jedes Unity-Objekt, das derzeit zugewiesen ist, einzeln betrachten, wie unten gezeigt.

Es ist wichtig, daran zu denken, dass Unity-Objekte einen Teil des gesamten zugewiesenen Speichers unserer Anwendung ausmachen. Wie viel genau, können Sie dem Indikator über der Tabelle entnehmen, der unten hervorgehoben ist.

Hier können Sie sehen, dass die gesamte zugewiesene Speichergröße, "Total Memory In Snapshot", 4,64 GB beträgt und dass unsere Unity-Objekte 2,37 GB davon ausmachen. Wenn wir die Tabelle filtern, z. B. über die Suchfunktion, wird diese Leiste entsprechend den Suchergebnissen aktualisiert. Mit anderen Worten, es wird die Größe des gesamten derzeit in der Tabelle angezeigten Speichers angezeigt. Dies hilft Ihnen, den Überblick darüber zu behalten, wie viel Speicherplatz Sie im Verhältnis zum gesamten Capture inspizieren, und kann Ihnen dabei helfen, herauszufinden, wo Sie Ihre Optimierungsbemühungen investieren sollten.

In Version 1.0 des Memory Profiler zeigt die Tabelle Unity Objects den zugewiesenen Speicher an, oder anders ausgedrückt, sie zeigt alle Unity Objects an, die in Ihrer Anwendung aktiv sind. Wir erwägen, diese Ansichten in einer der nächsten Versionen um die Sichtbarkeit von Residentem Speicher zu erweitern, damit Sie genau sehen können, welche Ihrer Unity-Objekte derzeit im physischen Speicher resident sind, und somit genau sehen können, welche direkt zum aktuellen Speicherbedarf Ihrer Anwendung beitragen.



Sie können die Registerkarte "Gesamter Speicher" verwenden, um den restlichen Speicher Ihrer Anwendung zum Zeitpunkt der Erfassung zu untersuchen. Dazu gehört auch Speicher außerhalb von Unity-Objekten, wie verschiedene Unity-Subsysteme, reiner verwalteter (C#-)Speicher sowie DLLs und ausführbare Dateien.

Die Ansicht "Unity Objects" kann uns bei der Diagnose einer Reihe von möglichen Problemen helfen. Ein solches Problem ist die Erkennung von Assets, die schlecht konfiguriert sind und dadurch mehr Speicher als nötig verbrauchen.

In der Aufnahme unten können Sie sehen, dass ein großer Teil unserer Unity-Objekte Texturen sind. Die Aufnahme stammt aus einem Projekt mit hoher grafischer Wiedergabetreue, das die High Definition Render Pipeline verwendet und stark auf visuelle Effekte setzt. Vor diesem Hintergrund erwarten wir eine starke Nutzung von Texturen, und das tun wir auch.

Wenn wir jedoch unsere zweite große Kategorie, Textur2D, erweitern, können wir feststellen, dass zwei Texturen viel größer erscheinen als die anderen. Aufgrund unserer Kenntnisse über unser Projekt sind wir überrascht, dass diese Texturen größer sind als vergleichbare Texturen wie HoloTable_Normal oder HoloTable_Mask, da wir erwartet hatten, dass sie ähnlich groß sind.

Wir wählen also eine dieser Texturen in der Tabelle aus, um mehr Details darüber zu erfahren und zu untersuchen, was die Ursache dafür sein könnte. Hier, in der Detailansicht, finden wir unsere Erklärung - unsere Textur ist beschreibbar, oder "Read/Write Enabled".

Dies ist ein häufiges Problem, das wir in vielen Benutzerprojekten sehen: Versehentlich wird eine Textur schreibbar gemacht, obwohl sie nicht benötigt wird, indem die Einstellung "Lesen/Schreiben" in den Importeinstellungen der Textur aktiviert wird. Wenn eine Textur diese Option aktiviert hat, verdoppelt sich ihre Größe im Speicher. Dies liegt daran, dass eine zweite Kopie der Texturdaten erforderlich ist, damit die CPU auf sie zugreifen kann. Ein verräterisches Zeichen dafür ist, dass die Gesamtgröße einer Textur doppelt so groß ist wie erwartet, oder doppelt so groß wie bei ähnlichen Texturen.

Nachdem wir das "Lesen/Schreiben"-Flag für beide Texturen deaktiviert und eine zweite Aufnahme gemacht haben, können wir sehen, dass sich die Größe beider Texturen halbiert hat.

Wir prüfen, ob wir in einer zukünftigen Version eine Spalte für Grafikspeicher (GPU) zur Unity-Objekt-Tabelle hinzufügen können, um das Auffinden von Fällen, in denen ein Unity-Objekt Grafikspeicher zugewiesen hat, wie in diesem Beispiel, zu erleichtern.

Ein häufiger Fehler, den wir in Unity-Projekten sehen, ist das unbeabsichtigte Erstellen von doppelten Unity-Objekten. Es ist zum Beispiel sehr einfach, versehentlich ein doppeltes Material zu erstellen, indem man auf die Materialeigenschaft eines MeshRenderers zugreift. Nicht nur, dass sich dies in diesem Fall schnell summiert - wenn es z.B. bei jeder Instanz eines bestimmten MeshRenderers gemacht wird -, sondern diese dynamisch erzeugten Materialien müssen auch explizit zerstört werden.

Um die Suche nach dieser Art von Problemen zu erleichtern, bietet die Tabelle der Unity-Objekte einen Schnellfilter, der nur potenzielle doppelte Unity-Objekte anzeigt. In dieser Ansicht wird die Tabelle so gefiltert, dass nur Unity-Objekte angezeigt werden, die mehrere Instanzen mit identischem Namen und identischer Größe haben. Es ist wichtig zu beachten, dass viele potenzielle Duplikate zu erwarten sind und keinen Grund zur Sorge darstellen. Zum Beispiel könnten mehrere Instanzen eines Prefab identisch benannte und gleich große Transform-Komponenten haben, und diese würden als Duplikate erwartet. Wir sind nur an der Entdeckung unbeabsichtigter Duplikate interessiert, was wir in diesem Workflow anhand eines Beispiels veranschaulichen werden.

Die Aufnahme unten wurde in einer einfachen Szene mit zwei Instanzen einer Türvorlage gemacht, und wir haben den Filter Nur potenzielle Duplikate anzeigen aktiviert, der sich unterhalb der Tabelle Unity-Objekte befindet. Dadurch wurde die Tabelle so gefiltert, dass nur Unity-Objekte angezeigt werden, die mehrere Instanzen mit demselben Namen und derselben Größe haben.

Da wir zwei Instanzen einer Türvorlage in unserer Szene haben, haben wir auch, wie erwartet, zwei Instanzen aller relevanten Objekte: MeshRenderer, Transform, GameObject, und so weiter. Wir haben jedoch auch zwei Instanzen des "Tür"-Materials in unserer Aufnahme oben. Diese Türinstanzen sehen in unserer Szene gleich aus, so dass zu erwarten ist, dass sie ein gemeinsames Material haben werden. Es handelt sich also um ein unbeabsichtigtes Duplikat, das in diesem speziellen Beispiel durch den Zugriff auf die Materialeigenschaft des MeshRenderers in der Vorabversion verursacht wurde. Das Entfernen dieses Eigenschaftszugriffs und eine zweite Aufnahme zeigen, dass das doppelte Material nicht mehr in der Tabelle Unity Objects vorhanden ist.

Es ist wichtig, daran zu denken, dass dieser Filter einfach alle Unity-Objekte anzeigt, die mehrere Instanzen mit demselben Namen und derselben Größe haben. Es erfordert Ihr Wissen über Ihr Projekt, um zu interpretieren, ob die potenziellen Duplikate, die Sie sehen, erwartet werden oder tatsächlich unbeabsichtigt sind und Anlass zur Untersuchung geben. Es empfiehlt sich, auf den Balken Gesamtspeicher in der Tabelle am oberen Rand zu achten, der Ihnen einen visuellen Hinweis darauf gibt, welchen Anteil des Ihrer Anwendung zugewiesenen Speichers Sie in der Tabelle sehen. Dies kann Ihnen helfen, den Überblick darüber zu behalten, wo Sie Ihre Optimierungsbemühungen investieren sollten.

Der Memory Profiler bietet auch die Möglichkeit, zwei Speicheraufzeichnungen zu vergleichen. So können wir Änderungen an unserem Projekt vornehmen, um beispielsweise ein Problem zu beheben, das wir entdeckt haben, und anschließend testen, ob unsere Änderungen tatsächlich das gewünschte Ergebnis gebracht haben. Es ist wichtig, immer zu prüfen, ob Ihre Hypothese richtig ist und Ihre Änderungen das gewünschte Ergebnis auf der tatsächlichen Hardware haben. Im Folgenden wollen wir uns ein Beispiel für diesen Vergleichs-Workflow ansehen.

Nachfolgend sehen Sie eine Aufnahme unseres Handyspiels aus dem ersten Level. Wir können sehen, dass die größte Kategorie von Unity-Objekten Texture2D ist. Nachdem wir diese Kategorie geöffnet haben, um zu sehen, was unsere größten Texturen sind, können wir sehen, dass es ein paar UI-Texturen gibt, die im Verhältnis zum Rest unseres Spiels ziemlich groß sind - jeweils ein Megabyte. Dies weckt bei uns einen Verdacht: Warum sind diese Texturen so viel größer als die anderen und müssen sie das sein? Um herauszufinden, warum das so ist, können wir zunächst die Quelltextur in unserem Projekt ausfindig machen, indem wir die Textur im Memory Profiler auswählen und die Schaltfläche "Im Editor auswählen" verwenden, wodurch die Quelltextur in unserem Projektfenster markiert wird.

Im Inspektor-Fenster können wir sehen, dass alle großen UI-Texturen nicht komprimiert werden, da ihre Abmessungen keine Zweierpotenz sind, wie der Text "NPOT" (non-power-of-two) zeigt.

Dies erklärt diese großen Texturgrößen. Wir können nun unser Wissen über unser Projekt nutzen, um diesen Speicherverbrauch zu reduzieren. Wir wissen, dass drei dieser Texturen (die Hilfskontrollen) immer zusammen in der Benutzeroberfläche angezeigt werden, ebenso wie die anderen drei Texturen (die Kreaturen). Daher können wir mit hoher Wahrscheinlichkeit davon ausgehen, dass die Erstellung von zwei Sprite-Atlanten für jeden Satz von drei Texturen den Speicherverbrauch reduzieren wird, da sie komprimiert werden können, ohne die Anzahl der Texturen im Speicher zu erhöhen.

Um zwei Snapshots zu vergleichen, öffnen Sie zunächst den ersten Snapshot. Dies ist die "Basis", mit der wir uns vergleichen wollen. Wählen Sie nun oberhalb des geöffneten Snapshots die Registerkarte "Snapshots vergleichen" und wählen Sie den zweiten Snapshot aus. Der Memory Profiler zeigt nun eine Zusammenfassung an, in der die beiden Snapshots verglichen werden, wie unten dargestellt.

Um die Auswirkung unserer Änderung zu sehen und zu überprüfen, ob sie tatsächlich die Größe des unserer Anwendung zugewiesenen Speichers für die Texture2D-Kategorie verringert hat, können wir die Registerkarte Unity-Objekte auswählen. Hier finden Sie eine Vergleichstabelle, die zeigt, welche Unity-Objekttypen sich geändert haben und wie sie sich zwischen den Erfassungen verändert haben (siehe unten).

Wir sehen, dass unser Texture2D-Typ als Ganzes um 3,6 MB kleiner geworden ist und vier Texturen weniger hat als vorher. Wenn wir diese Kategorie erweitern, können wir sehen, dass wir unsere einzelnen, unkomprimierten Sprite-Texturen entfernt und unsere beiden Sprite-Atlas-Texturen hinzugefügt haben, was zu einer Nettoreduzierung von 3,6 MB und 4 Texture2D-Objekten führt.

Dies war also ein Erfolg - wir haben mit Hilfe der Vergleichsfunktionalität bestätigt, dass unsere Hypothese richtig war, und wir haben die Größe dieser Texturen im zugewiesenen Speicher verringert.

Nach der Lektüre dieses Blogs sollten Sie nun ein besseres Verständnis der fünf wichtigsten Arbeitsabläufe im neuen Memory Profiler-Paket haben. Diese Arbeitsabläufe sind für die Diagnose und Untersuchung von speicherbezogenen Problemen in Ihrem Spiel gedacht. Wir hoffen, dass das in Unity 2022.2 veröffentlichte Memory-Profiler-Paket Ihnen hilft, den Speicherbedarf Ihres Spiels besser zu überwachen, zu untersuchen und zu verstehen. Bitte wenden Sie sich an das Team und teilen Sie uns Ihr Feedback zur Verbesserung der Tools für die Leistungsprofilerstellung über unsere Forumsseite mit - oder teilen Sie uns Ihre Vorschläge über unsere Roadmap-Seite mit, auf der Sie auch einige der Funktionen sehen können, an denen wir gerade arbeiten.

Wenn Sie an weiteren Details zu diesem Thema interessiert sind, werden wir in den kommenden Wochen einen weiteren Blog veröffentlichen, in dem wir uns eingehender mit der Berechnung des Speicherbedarfs einer Anwendung befassen und Themen wie residenter und zugewiesener Speicher genauer behandeln werden.