RAM Optimization in Games: From Audit to Implementation
A crash without warning on devices with 3 GB RAM is not a coincidence. In our practice, every second project encounters Unity memory leaks. iOS and Android silently accumulate memory pressure until the system kills the process with SIGKILL — no log, no stack trace. Developers often blame "engine instability," but the real cause is uncontrolled heap growth in Mono/IL2CPP and untimely asset unloading. We guarantee that analysis with Memory Profiler reveals the true sources of leaks, not just surface-level indicators.
The problem is that the Unity Memory Profiler often shows "everything is fine" — 400 MB seems non-critical. But native memory held by Texture2D objects without explicit references is not visible there. You need Total System Memory from the Profiler window, not just Managed Heap. Our experience shows that ignoring this leads to crashes during testing.
Why Does the Standard Profiler Not Show the Full Picture?
The Unity Memory Profiler (com.unity.memoryprofiler) takes snapshots, but its Managed Heap often does not reflect real native resource consumption. Textures, shaders, AudioClip — all live outside the C# heap. We use Compare Snapshots at multiple session points: after startup, after scene load, mid-gameplay, after scene change. Only this shows objects growing from snapshot to snapshot. This is a proven method developed over 7 years of optimizations (see Unity Memory Profiler documentation).
Three Sources of Leaks We Find in Every Second Project
Unclosed AssetBundle references. A developer loads an AssetBundle, extracts a sprite, but never calls bundle.Unload(false). The sprite stays in memory. Even after the sprite is destroyed, the native Texture2D object is still retained via a WeakReference in ResourceManager. After 10 location loads/unloads, memory is not reclaimed. This is classic Unity native heap fragmentation. Solution: switch to Addressables with explicit lifetime management via AsyncOperationHandle.Release(). Addressables are better than Resources: they give explicit control and reduce peak consumption by 2–3 times.
Texture duplication on scene changes. When transitioning between scenes using SceneManager.LoadScene with LoadSceneMode.Single, the old scene is unloaded. But if the new scene has textures with the same names loaded via Resources.Load in code, they may appear in memory twice until Resources.UnloadUnusedAssets() is called. On projects with heavy scenes (100+ MB textures), this causes a memory peak at the transition moment — exactly when crashes occur. Savings after fixing: up to $2000 per month on cloud testing by reducing the number of restarts.
AudioClip with incorrect Load Type settings. AudioClip with Load Type = Decompress On Load decompresses PCM into memory on loading and keeps it there. For a long music track, this can be 50–80 MB for just one clip. Rule: music → Streaming, short SFX → Compressed In Memory, critical low-latency SFX → Decompress On Load only if length < 2 seconds. This approach ensures stable performance on devices with 2 GB RAM.
| Load Type | Use Case | Memory | Latency |
|---|---|---|---|
| Decompress On Load | Short SFX | High | Low |
| Compressed In Memory | Medium sounds | Medium | Medium |
| Streaming | Music, long clips | Low | High |
How Addressables Solve the Duplication Problem?
Switching from Resources to Addressables gives explicit control over asset lifetime. AssetReference + LoadAssetAsync + Release — full cycle without "magic." We configure memory profiles via Addressables Analyze: Check Duplicate Bundle Dependencies finds assets packed into multiple bundles simultaneously (a typical cause of duplication). In one project, this reduced peak consumption from 847 MB to 480 MB on an iPhone 8 (see case below).
Case from practice: a mobile action game with 9 levels. After completing 3 levels in a row, the game crashed on iPhone 8. Memory Profiler showed 847 MB at the start of level 4. Source — 12 unique UI atlases loaded via Resources.Load in the Lobby scene, not unloaded between levels. After migrating to Addressables with explicit Release when entering the game scene and Resources.UnloadUnusedAssets in a coroutine, the peak dropped to 480 MB. Savings amounted to $1500 per month on the device farm.
Object pooling instead of Instantiate/Destroy. Each Instantiate allocates new memory, each Destroy does not return it immediately — GC Alloc accumulates. ObjectPool<T> from Unity 2021 LTS completely eliminates this category of allocations for projectiles, enemies, VFX. Comparison: with 1000 spawns, pooling gives zero allocations, while Instantiate/Destroy spends 10+ MB on GC.
What Is Included in Our Work?
- Audit of current memory state with Memory Profiler snapshots on the target device
- Detailed report with top-10 leak sources and priorities
- Implementation of fixes: Addressables, object pooling, AudioClip optimization, AssetBundle fixes
- Repeated load testing (1 hour without restart)
- Team training: Profiler usage, Addressables, best practices
- Result guarantee: stability on devices with 3 GB RAM — written commitment
Our team has 7+ years in game dev, over 50 optimization projects for iOS and Android. We work turnkey — from audit to implementation.
Work Stages
- Capture baseline metrics via Profiler on target device (not Editor)
- Series of Memory Profiler snapshots across the game cycle
- Analyze top-10 objects by memory consumption
- Identify leak sources via Compare Snapshots
- Prioritize by impact: textures → AudioClip → Managed Heap → pooling
- Implement fixes with intermediate measurements
- Load testing: 1 hour game session without restart
| Task Scale | Estimated Timeline |
|---|---|
| Memory audit + report | 2–4 days |
| Fix 2–3 specific leak sources | 1–2 weeks |
| Resources → Addressables migration + optimization | 3–6 weeks |
| Full architectural rework of asset management | 6–12 weeks |
Contact us for a consultation. If your game crashes on older devices, get an audit in 2 days and discover the real leak sources. Order a memory audit today — we'll assess your project within 24 hours.