Optimizing Scene Transition Spikes in Unity: Mitigating Resources.UnloadUnusedAssets and GC.Collect Overhead with Incremental GC, Async Unload, and Object Pooling

When developing games in Unity, you will inevitably hit a common performance bottleneck: severe stuttering or freezing (CPU spikes) during scene transitions. Even if your game runs at a buttery-smooth 60fps during gameplay, you might experience abrupt frame drops, frozen screens, or stuttering audio when moving to the next level or returning to the main menu.

You might wonder, "Why does the game freeze even though I am loading scenes asynchronously using SceneManager.LoadSceneAsync or Addressables.LoadSceneAsync?" The reality is that while asynchronous loading handles "loading new assets into memory" in the background, cleaning up old memory and activating the new scene are synchronous operations executed on the main thread.

In this article, we will dive deep into the two primary culprits of scene transition spikes: Resources.UnloadUnusedAssets and GC.Collect, and explore how to optimize them to deliver seamless scene transitions.

1. Root Causes: Main Thread Blocking Operations During Transitions

The moment a background load completes, Unity executes several heavy operations sequentially on the main thread. This synchronous work is what triggers the transition spikes.

[Async Load of New Scene] (Runs on background thread)
       │
       ▼ (Load complete)
[Destroy Old Scene Objects] (Main thread: Synchronous) ──> Heavy GameObject destruction
       │
       ▼
[Global Asset Sweep] (Main thread: Synchronous & High Overhead)
  └─> Resources.UnloadUnusedAssets() scans and sweeps unreferenced assets
       │
       ▼
[Garbage Collection (GC)] (Main thread: Synchronous)
  └─> Sweeping unused managed memory (GC.Collect)
  

(1) Scanning Cost of Resources.UnloadUnusedAssets

Once Unity destroys objects from the previous scene, it automatically (or via explicit script calls) runs Resources.UnloadUnusedAssets(). This method lists all assets currently in memory (textures, materials, audio clips, meshes, etc.) and scans them one-by-one to determine if they are still referenced by any active GameObjects in a mark-and-sweep fashion.

Because this database-wide sweep runs synchronously on the main thread, the time it takes grows exponentially as your project scales and the number of loaded assets increases (into the thousands). In large projects, this operation alone can block the main thread for 200ms to 2000ms (up to 2 seconds), causing a noticeable freeze.

(2) Forced Execution of GC.Collect

In tandem with asset unloading, a garbage collection (GC.Collect) cycle is typically triggered to clean up unreferenced C# objects and reorganize the managed heap.
By default, Unity's garbage collector (without Incremental GC) is a "Stop-the-World" collector. It halts all game execution until it completes the mark-and-sweep process. When your managed heap is large (hundreds of MBs), this halts the game for dozens to hundreds of milliseconds.

2. Solution 1: Controlling the Timing of Resources.UnloadUnusedAssets

The first step to address this is to prevent Unity from automatically triggering asset cleanup at arbitrary times and manually call it when the freeze is invisible to the user (such as during a screen fade-out or when a loading screen is displayed).

By default, unloading a scene automatically schedules a sweep. We can bypass and manage this manual control using the following pattern:

Scene Manager implementation with timing control

using System.Collections;
using UnityEngine;
using UnityEngine.SceneManagement;

public class SceneTransitionManager : MonoBehaviour
{
    public static SceneTransitionManager Instance { get; private set; }

    private void Awake()
    {
        if (Instance == null)
        {
            Instance = this;
            DontDestroyOnLoad(gameObject);
        }
        else
        {
            Destroy(gameObject);
        }
    }

    public void TransitionToScene(string sceneName)
    {
        StartCoroutine(TransitionRoutine(sceneName));
    }

    private IEnumerator TransitionRoutine(string sceneName)
    {
        // 1. Fade out the screen to black
        yield return StartCoroutine(FadeOutCanvasGroup(1.0f));

        // 2. Show the loading screen UI
        ShowLoadingUI(true);

        // 3. Unload the old scene and async-load the new scene
        // Set allowSceneActivation = false to prevent immediate activation
        AsyncOperation loadOp = SceneManager.LoadSceneAsync(sceneName, LoadSceneMode.Single);
        loadOp.allowSceneActivation = false;

        while (loadOp.progress < 0.9f)
        {
            UpdateProgressBar(loadOp.progress);
            yield return null;
        }

        // 4. While the loading screen is active, explicitly trigger the asset sweep
        // This hides the inevitable CPU spike behind the loading screen
        UpdateStatusText("Releasing unused assets...");
        AsyncOperation unloadAssetsOp = Resources.UnloadUnusedAssets();
        
        // Wait for the sweep to complete
        while (!unloadAssetsOp.isDone)
        {
            yield return null;
        }

        // 5. Force garbage collection now to clean up the C# heap
        System.GC.Collect();
        yield return null; // Wait 1 frame to finalize garbage collection

        // 6. Activate the new scene
        UpdateStatusText("Activating scene...");
        loadOp.allowSceneActivation = true;
        
        while (!loadOp.isDone)
        {
            yield return null;
        }

        // 7. Hide the loading screen and fade in
        ShowLoadingUI(false);
        yield return StartCoroutine(FadeInCanvasGroup(1.0f));
    }

    // Fade and UI helpers (implementations omitted for brevity)
    private IEnumerator FadeOutCanvasGroup(float duration) { yield return new WaitForSeconds(duration); }
    private IEnumerator FadeInCanvasGroup(float duration) { yield return new WaitForSeconds(duration); }
    private void ShowLoadingUI(bool show) {}
    private void UpdateProgressBar(float value) {}
    private void UpdateStatusText(string text) {}
}

With this setup, the heaviest operations (asset unloading and GC) are encapsulated inside the dark loading phase. To the player, this only looks like a slightly longer loading screen, removing the frustrating stutter that occurs mid-transition.

3. Solution 2: Enabling Incremental GC

To prevent GC spikes not only during scene transitions but also during normal gameplay, you should enable Incremental GC.

Incremental GC divides the "mark-and-sweep" process into multiple small phases. Instead of halting the main thread for one large block, it distributes the garbage collection workload in tiny slices (hundreds of microseconds each) across multiple frames.

[Standard Stop-the-World GC]
  |========= GC execution halts game for 30ms =========|

[Incremental GC]
  [F1: 1ms] ──> [F2: 1ms] ──> [F3: 1ms] ──> [F4: 1ms] (Runs alongside normal frames)
  

How to Enable Incremental GC

1. Open Project Settings > Player in the Unity Editor.
2. Navigate to the Configuration section.
3. Check the box for Use incremental GC.

Note: While this is enabled by default in newer versions of Unity (2022.3 LTS and later), it is always best practice to verify it in your project configuration.

[!IMPORTANT]
Even if Incremental GC is enabled, calling System.GC.Collect() directly without parameters forces a synchronous, non-incremental "Stop-the-World" collection immediately. Therefore, only call System.GC.Collect() manually during safe periods (like loading screens) and avoid calling it during gameplay loop.

4. Solution 3: Individual Async Unloading with Addressables

Relying on Resources.UnloadUnusedAssets is fundamentally unscalable because it must scan the entire asset database. In modern Unity workflows, using the Addressable Asset System (Addressables) is the optimal solution. Addressables lets you load and unload assets individually using a reference counting system.

Instead of running a global scan, you load an asset via Addressables.LoadAssetAsync() and release it with Addressables.Release() when it is no longer needed. This removes the asset from RAM/VRAM instantly and asynchronously as soon as its reference count drops to 0, without sweeping the entire database.

Releasing individual assets via Addressables

using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;

public class EnemySpawner : MonoBehaviour
{
    [SerializeField] private string enemyAddress = "Prefabs/Enemies/Goblin";
    
    private GameObject _enemyPrefab;
    private AsyncOperationHandle _loadHandle;

    private void Start()
    {
        // Load the asset asynchronously
        _loadHandle = Addressables.LoadAssetAsync(enemyAddress);
        _loadHandle.Completed += handle =>
        {
            if (handle.Status == AsyncOperationStatus.Succeeded)
            {
                _enemyPrefab = handle.Result;
                SpawnEnemy();
            }
        };
    }

    private void SpawnEnemy()
    {
        if (_enemyPrefab != null)
        {
            Instantiate(_enemyPrefab, transform.position, Quaternion.identity);
        }
    }

    private void OnDestroy()
    {
        // Release the asset handle when this GameObject is destroyed.
        // Once the internal reference count hits 0, the asset is automatically unloaded.
        // No call to Resources.UnloadUnusedAssets is needed!
        if (_loadHandle.IsValid())
        {
            Addressables.Release(_loadHandle);
        }
    }
}

Transitioning your project to an Addressables-based architecture completely bypasses the need for global database sweeps. By releasing scene assets individually, you can reduce transition overhead to almost zero.

5. Solution 4: Eliminating Bulk Destroys via Object Pooling

Another major source of transition stutters is the cost of destroying hundreds of GameObjects from the old scene and instantiating new ones in the next scene. Instantiating and destroying objects frequently triggers native-to-managed allocations and spikes the garbage collector.

For common objects used across scenes (e.g., impact effects, particles, bullets, floating damage UI, etc.), keep them alive under a global DontDestroyOnLoad container using an Object Pool. Instead of destroying them on scene exit, return them to the pool and deactivate them. This saves significant CPU cycles during transition frames.

For a detailed guide on creating optimized pools, see our related article: "Optimizing Object Pooling in Unity".

6. Performance Comparison Metrics

We measured the main thread block time during scene transitions in a medium-sized project containing 5,000 assets and a 350MB managed heap.

Conclusion: In our unoptimized test, the main thread was locked for over 1.2 seconds, resulting in bad player experience. By shifting the sweep timing to the fade phase, enabling Incremental GC, pooling objects, and migrating to Addressables for individual asset release, we slashed main thread blocking time down to just 45ms (around 2 to 3 frames). This enables smooth, near-instantaneous transitions between game scenes.

7. Summary

1. Async Load != Stutter-Free: LoadSceneAsync only runs file reading in the background. Asset unloading, object cleanup, and GC still occur synchronously on the main thread.
2. Hide Global Sweeps: Unloading assets is highly expensive. Call Resources.UnloadUnusedAssets() manually during a screen black-out or loading animations.
3. Enable Incremental GC: Distribute garbage collection workload across multiple frames to avoid Stop-the-World stutters.
4. Adopt Addressables: Migrate to reference-counted asset management to release individual items asynchronously, completely bypassing the expensive database-wide UnloadUnusedAssets.