[Check the original post at Unity Save Memory Within OnDisable]
One of my students, Ryan, asked me last week how he could rescue the memory Unity was stealing from his game because of disabled game objects. Luckily, he was using Addressables, so I prepared an experiment...
In this post you'll learn:
When is it ok to have deactivated GameObject's
Why disabled GameObjects pose a threat to memory
How to get your memory back without destroying them
Ready?
Addressables-Save-Memory-OnDisable-Thumbnail
With Unity, there are many reasons you might want to deactivate entire GameObject hierarchies in your scenes...
Maybe you don't want specific elements to be visible or executing yet.
Or maybe you're doing object pooling.
In any case, deactivating a game object effectively disables invoking the Update behavior.
And that's great, because deactivating a GameObject will save you precious CPU cycles.
However, it's not all perfect...
There's one thing we're not saving on when disabling objects: memory.
You see, keeping a direct reference to your assets will keep them loaded in memory. It doesn't really matter if they're invisible, disabled or whatever. Direct reference = memory greed.
But today I have a trick up my sleeve for you.
I'll show you how to recover the memory your disabled game objects are feeding on.
No worries, we'll make sure they get their memory back once they awake. We're not that selfish after all.
Quick Navigation (redirects to new tab)​
Chapter 1: A Typical Scenario: Wasting Memory
Chapter 2: An Alternative Scenario: Saving Memory
Chapter 3: Conclusion & Comparison
CHAPTER 1:
A Typical Scenario: Wasting Memory
In this chapter, I'll show you a simple Unity scene that contains a few referenced assets.
You'll see how they refuse to exit memory when we deactivate their objects.
As simple as it is, this represents a vast amount of examples I've seen across a multitude of projects.
So my guess is that you suffer from this in your project.
Glutton-RAM-Memory
To make a case for the post, I created a simple Unity scene with the following scene hierarchy:
Pause Canvas
Image0 → Sprite0
Image1 → Sprite1
Image2 → Sprite2
SoldierCharacter → Static Mesh + 4 Materials
In this case, it doesn't always make sense to keep these objects active...
If you're not paused, there's no need to keep their sprites in memory.
If the soldier is pooled and waiting for its turn to spawn, it's better to keep it deactivated.
You might say: If I want the memory, I can just destroy it.
And you'd be right. You could destroy them to save memory.
However, some game architectures rely on persisting state within your objects. You might want to store the last parameters the pause menu had. Or you might want to save the customization parameters of that soldier that we will spawn after crossing that door.
No matter what, there'll be circumstances where you'll have deactivated objects for certain period. And it might be wise to save memory on those until the moment of the activation occurs.
Here's how the setup scene looks like (don't judge my art style, I'm a programmer)
Unity-Addressables-Save-Memory-OnDisable-Scene-Setup
Saving Memory OnDisable: Setup Scene
As you can see in the GIF below, deactivating the whole hierarchy won't release a single bit of memory (actually I'm not sad about it, as this keeps me employed).
Unity-Addressables-Save-Memory-OnDisable-1-Original
Unity Default Behavior: Memory GreedAnd that's the problem we are about to tackle in the next chapter.
CHAPTER 2:
An Alternative Scenario: Saving Memory
In the previous chapter, we've seen how deactivating game objects help reduce CPU usage. But it doesn't really help us reducing our memory usage.
In our example, we still pay memory for the following asset types:
Textures
Meshes
Sprites
In this chapter, we'll get rid of this memory cost in a sneaky way.
Alright...
We're going to use Addressables.
And the trick is going to be a relatively simple script.
From a high-level perspective, this is what we're going to do:
