The Blog

This article explains why mobile games can crash from out-of-memory even when GC.Alloc looks low or C# shows no exception. It breaks Unity memory into managed, unmanaged C# buffers, and engine-native resources, then shows common causes like large textures, read/write enabled textures, long audio clips set to Decompress On Load, and Addressables or runtime objects that are never released. It also covers why Android LMK and iOS Jetsam can terminate a game without a C# stack trace, and recommends testing on weak devices with repeated playthroughs and Memory Profiler snapshots to find what stays in memory after each cycle.

The article explains why calling GC.Collect() in Unity may not make RAM drop right away: GC can free C# objects without shrinking the managed heap, Unity may keep reserved memory for future allocations, and game memory also includes textures, meshes, audio, graphics memory, and runtime metadata. It shows how to check the right metrics with Profiler.GetMonoUsedSizeLong() and Profiler.GetMonoHeapSizeLong(), warns not to confuse Reserved with physical RAM, and recommends using Memory Profiler snapshot comparisons across gameplay loops to find memory that keeps growing or references that prevent cleanup.

The article explains why rebuilding UI text every frame in Unity creates unnecessary garbage, even when using StringBuilder. It shows that StringBuilder can reduce temporary allocations but does not eliminate output string allocations, and that boxing is a separate issue. For TextMeshPro, it recommends sending data directly to SetText or StringBuilder overloads instead of prebuilding strings, and stresses that text should only update when the displayed value changes. It also notes cases where precomputed strings or ZString may help, while warning that Zero-Alloc UI is not truly free because layout and mesh work still cost CPU and some paths can still allocate.

The article asks whether Incremental GC is a magic fix for game stutter. It explains that GC (Garbage Collector) reclaims unused C# objects, and Incremental GC only splits that work across frames to reduce long pauses, while still costing CPU and not fixing stutter caused by the GPU, physics, or asset loading. Using Unity examples, it shows how frequent temporary allocations, like rebuilding UI strings every frame, can keep causing GC pressure, and recommends reducing repeated allocations with reused Lists, buffers, and pools. It also notes that Incremental GC does not solve memory fragmentation, that disabling GC can let memory keep growing, and that `GC.Collect()` itself can cause blocking hitches. The main advice is to profile on the target device, find repeated allocations, fix their source, and only then consider adjusting the GC time slice.

This article explains two common Unity performance problems: too many Draw Calls and too much Overdraw. It defines a Draw Call as a command the CPU sends to the GPU to draw objects, then shows how changing materials, shaders, textures, passes, or render states can increase the number of calls. It also covers why high Draw Call counts hurt CPU performance and FPS, and suggests ways to reduce them with shared materials, Sprite Atlas, GPU Instancing, Static Batching, SRP Batcher, LOD, and Occlusion Culling. The article then explains Overdraw as the same pixel being drawn multiple times in one frame, especially with particles, transparent sprites, layered UI, fullscreen effects, and transparent shaders. It describes the GPU cost of Overdraw and gives practical ways to reduce it, such as cutting down transparent layers, using tighter sprites, disabling unused UI, preferring opaque or alpha-clipped shaders when possible, and checking Overdraw View in Scene View. Finally, it compares Draw Call and Overdraw, and recommends using Game View Stats, Frame Debugger, Profiler, and Overdraw view in Unity to diagnose the real bottleneck before optimizing.

This article explains the difference between Unity’s [SerializeField] and [Serializable]. [SerializeField] tells Unity to save a specific field and show it in the Inspector, while [Serializable] tells Unity that a custom class or struct can be stored as data. Using a weapon example, it shows that a private field can appear in the Inspector with [SerializeField], but a custom type like WeaponData also needs [Serializable] before Unity can serialize it. The post includes a comparison table, notes that MonoBehaviour and ScriptableObject do not need [Serializable], explains why properties and unsupported types like Dictionary do not work the same way, and briefly introduces [SerializeReference] for more advanced cases such as polymorphic data or shared references.