Implementing Object Pooling for Mobile Games
Every time a bullet, coin, or explosion particle spawns in a game, Unity calls Instantiate, and on destroy—Destroy. Unnoticed on desktop. On mobile GPU with 4 GB shared memory and a Garbage Collector running in the same thread as render, this manifests as a characteristic 30–80 ms freeze when enemies spawn or explosion with particles trigger.
Where It Breaks Without Pooling
The problem isn't memory allocation itself—it's that GC in Mono (which Unity mobile still often uses) stops the world for collection. Instantiate creates managed objects eventually collected. On frequent spawn/destroy, collection triggers at the heaviest moments—explosions, many on-screen enemies, level transitions.
Typical symptoms: Profiler shows periodic GC.Collect spikes of 40–120 ms on Galaxy A53 or iPhone 12 devices. Flagships have smaller spikes, but on target devices with Android 10–12 and 3–4 GB RAM they're consistent.
Second aspect—memory fragmentation. Frequent allocation and freeing leaves many small "holes" in the heap. On next large allocation, the system requests a new block from OS. On Android this sometimes triggers LMK (Low Memory Killer) sooner than expected.
How We Implement Pooling
Basic pattern—ObjectPool<T> with two stacks: active and inactive. On object request, take from inactive, activate (SetActive(true)), add to active. On return—opposite. No Instantiate in hot path.
Starting Unity 2021, there's built-in UnityEngine.Pool.ObjectPool<T>, eliminating reinvention. Thread-safe via ConcurrentStack under hood, supports actionOnGet / actionOnRelease / actionOnDestroy callbacks. Write thin wrapper for each pool type—bullets, enemies, particles—with explicit maxSize to prevent unbounded growth.
var pool = new ObjectPool<Bullet>(
createFunc: () => Instantiate(bulletPrefab),
actionOnGet: b => b.gameObject.SetActive(true),
actionOnRelease: b => b.gameObject.SetActive(false),
actionOnDestroy: b => Destroy(b.gameObject),
maxSize: 100
);
For particles (ParticleSystem)—special logic. Return particle to pool not by timer, but on OnParticleSystemStopped event. Otherwise return happens while particles still fly, effect cuts off visually.
Pool Warm-up
A pool is useless if it fills during gameplay. Warm up on loading screen: create needed quantity, immediately return to pool. This moves allocations where user doesn't notice.
Count—not "with headroom", but based on analysis of max simultaneous objects on heaviest level. If 60 bullets peak on screen—warm up 80.
Pools with Addressables
If project uses Addressables, pooling gets complex: Instantiate works via Addressables.InstantiateAsync, result is AsyncOperationHandle. On return to pool, can't just call Destroy—must Addressables.ReleaseInstance. Write pool manager accounting this, or get native memory leak in IL2CPP build.
Profiling Before and After
Before pooling: Profiler shows GC.Alloc 2–8 KB per bullet spawn + periodic GC.Collect 50+ ms. After: hot path has zero allocations, GC.Collect fires only on level transitions.
On Pixel 6a with 20 simultaneous enemies and active pool—stable 60 FPS vs 45–55 without pool.
Process
Audit existing code → identify hot paths with Instantiate/Destroy → implement pools with warm-up → integrate into SpawnManager → profile in Editor Profiler and on device via Android GPU Inspector or Xcode Instruments. Testing on low-end device (Galaxy A32 level) mandatory—difference is most noticeable there.
Timeline: two-five workdays depending on object types and existing architecture.