💾 Lesson 2.2: Hunting Memory — The Memory Profiler

Two Kinds of Memory

Before you can read a memory snapshot, you need to know that a Unity game holds memory in two very different places, and confusing them will send you hunting in the wrong one.

The relationship matters: a Texture2D you created in code is a small managed wrapper pointing at a large native buffer. Drop the last managed reference and the GC eventually collects the wrapper — but the native buffer only frees when Unity unloads that asset (via Resources.UnloadUnusedAssets, Addressables.Release, or Destroy for a runtime-created one). Forget that, and you leak megabytes of native memory while the managed heap looks innocent.

The Memory Profiler Package

The Memory module you met in Lesson 2.1 gives you live totals and per-frame allocation — a smoke alarm. To actually investigate what is in memory, you install the separate Memory Profiler package: Window → Package Manager → Unity Registry → Memory Profiler → Install. It adds a new window under Window → Analysis → Memory Profiler.

Where the CPU Profiler streams continuous data, the Memory Profiler works in snapshots: a full, frozen dump of every managed and native object in memory at the instant you press capture, complete with sizes and — crucially — the references between them. A snapshot is heavy to take (the game hitches for a moment) and that's fine; you take a handful deliberately, not continuously.

💡 Snapshot, don't stream. Memory problems are about accumulation over time, not one bad frame. The right rhythm is: capture a snapshot at a known-good baseline, do something (load a level, open and close a menu, play a wave), capture again, and diff. The difference between two snapshots is the story.

Capturing a Snapshot

With the window open and your game in Play mode (or, better, a Development Build connected — the same on-device rule from Lesson 2.1 applies), press Capture. After a moment the snapshot appears in the left-hand list with a timestamp and total size. Each snapshot is saved to disk in your project, so you can reopen and compare them across sessions.

You can capture from either a connected player (real device memory — what you trust) or the editor (convenient, but inflated by editor overhead exactly as CPU timings were). For any decision that ships, capture from the build on device.

Once captured, a snapshot opens into several views. The most useful two are the Tree Map (what's using memory, by category and size) and the All Of Memory / object table (every object, searchable, with its references). Let's read the tree map first.

Reading the Tree Map

The tree map is a set of nested rectangles where area is proportional to bytes. Big categories are big rectangles; you find your heaviest memory users literally by looking for the largest boxes. Typical top-level categories are Native Objects (broken down into Texture2D, Mesh, AudioClip, RenderTexture…), the Managed Heap, Graphics driver memory, and executable/other. Click a box to drill in.

Here is the Memory Profiler reconstructed — a tree map on the left, and on the right the snapshot-comparison table that turns it into a leak-finding tool.

💡 Why a diagram, not a screenshot? Like the Profiler, the Memory Profiler is a UI Toolkit window that can't be captured cleanly, so it's reconstructed from the real layout, real category names, and a real reference path. The numbers illustrate the exact pattern you'll hunt: a comparison where things that should have gone away didn't.

Comparing Snapshots to Find a Leak

The single most valuable thing the Memory Profiler does is diff two snapshots. One snapshot tells you what's in memory now — useful, but you can't tell a legitimate 148 MB of textures from a leak. Two snapshots taken around a repeatable action tell you what changed, and change is where leaks live.

The technique — call it the bracket test — is:

1. Get to a stable baseline (e.g. main gameplay, nothing transient open). Capture A.
2. Do a complete round-trip that should end where it started: open a menu and close it, load a level and return, spawn a wave and clear it.
3. Capture B.
4. Switch the window to Compare mode with A and B. Sort by Δ Count or Δ Size.

If the round-trip was truly balanced, most deltas are zero. Any type with a positive delta that shouldn't have grown is your suspect — exactly the red EnemyView +40 row in Figure 1. Repeat the round-trip several times before capturing B and the leak compounds (+40 becomes +120), making it unmistakable and proving it's not just one-time initialization.

What Keeps an Object Alive

Once the diff names a leaking type, the question becomes why won't the GC collect it? The GC frees anything not reachable from a root (a static field, a live local, a running thread). So a leak is always: "there's still a reference path from some root to this object." The Memory Profiler shows you that path (the reference panel in Figure 1). Three sources cause the overwhelming majority of managed leaks:

🔎 The "destroyed but alive" trap. Destroy(gameObject) tears down the native Unity object, but the managed C# object behind it only dies when the GC can prove it's unreachable. If an event still holds it, you get a zombie: the GameObject is gone from the scene, yet its MonoBehaviour instance sits in the heap forever, its Update quietly not running but its memory never freed. This is why "I destroyed it, why is it still in the snapshot?" is one of the most common questions in memory work — and the answer is nearly always a missing -=.

A Real Leak and Its Fix

Here is the exact bug behind Figure 1. An EnemyView subscribes to a static score event so it can flash when the player scores. It subscribes in OnEnable but never unsubscribes — so when the enemy is destroyed, the static event keeps the view alive:

// A long-lived (often static) event bus — survives the whole session.
public static class GameEvents
{
    public static event System.Action<int> OnScore;
    public static void RaiseScore(int total) => OnScore?.Invoke(total);
}

public class EnemyView : MonoBehaviour
{
    void OnEnable()
    {
        // Subscribing makes GameEvents.OnScore hold a delegate
        // whose target is THIS instance...
        GameEvents.OnScore += HandleScore;
    }

    // ...but we never unsubscribe. When this GameObject is destroyed,
    // the static event still references us, so the GC can never
    // collect this EnemyView. Every enemy ever spawned leaks.

    void HandleScore(int total) { /* flash the UI */ }
}

The snapshot diff caught it: after opening and closing the enemy view forty times, forty EnemyView instances and forty delegates survived. The fix is one line — unsubscribe in the mirror-image callback:

public class EnemyView : MonoBehaviour
{
    void OnEnable()
    {
        GameEvents.OnScore += HandleScore;
    }

    void OnDisable()
    {
        // Mirror every subscription with an unsubscription.
        // Now nothing long-lived references us; the GC can collect us.
        GameEvents.OnScore -= HandleScore;
    }

    void HandleScore(int total) { /* flash the UI */ }
}

Re-run the bracket test after the fix and the EnemyView delta drops to zero — proof, not hope. The discipline generalizes: every += needs a matching -=, and the natural place is the paired lifecycle callback (OnEnable/OnDisable, or Awake-region subscribe / OnDestroy unsubscribe). The same rule applies to manual C# events, UnityEvent listeners added in code, and input-action callbacks.

Hands-on Challenge

Summary

🚀 What's Next?

Leaks are memory that never comes back. The other memory problem is churn: memory allocated and freed so fast that the garbage collector itself becomes a frame-time spike. In Lesson 2.3: Writing Garbage-Free Code, we hunt down every common allocation source — boxing, closures, LINQ, string building, hidden array copies — and refactor a method from allocating to completely garbage-free.