Here are the 10 most common architectural and performance crimes I see in Unity projects, and how to stop committing them.
1. The Update() Addiction
New developers treat Update() like a jack of all trades where all logic lives. They poll for state changes every single frame. If you are checking if (health <= 0) Sixty times a second, when the player only takes damage once every minute, you are wasting cycles.
The Fix: Move to an event-driven architecture. Use C# Events or
UnityEventsto trigger logic only when data actually changes. Your CPU will thank you.
2. GetComponent and Find in Hot Paths
I still see this constantly. GameObject.Find() and GetComponent() are expensive operations. Calling them inside Update(), FixedUpdate(), or a loop is a guaranteed way to tank your frame rate, especially on mobile.
Bad: Searching for the "Player" object every frame to move towards it.
Good: Cache the reference in
Awake()orStart(). If the reference changes dynamically, use a Singleton manager or Dependency Injection to hand it over.
3. Physics in Update (The Jitter Factory)
Unity has two timelines: the variable rendering loop (Update) and the fixed physics loop (FixedUpdate). If you apply forces or modify Rigidbody velocities in Update, your physics simulation will desync from the frame rate. This results in movement that looks jittery or "stuttery," even at 60 FPS.
The Rule: If it involves a Rigidbody, put it in
FixedUpdate. If it involves input detection, put it inUpdate.
4. The "Resources" Folder Trap
It’s tempting to drag everything into a folder named Resources so you can lazy-load it with Resources.Load(). Don’t.
Unity creates a lookup tree for everything in those folders when the game launches. As your project grows, this increases startup time and memory footprint significantly, even if you aren't using the assets yet.
The Fix: Use Addressables or direct references in the Inspector. The Resources folder is legacy tech; treat it as such.
5. UI Canvas Splitting
Unity’s UI system (UGUI) has a specific quirk: if one element on a Canvas changes (moves, rotates, changes color), the entire Canvas re-batches and rebuilds its geometry.
If you put a spinning coin icon on the same Canvas as your static inventory background, you are forcing the static background to redraw every single frame.
The Strategy: Separate your UI into different Canvases based on update frequency. Put dynamic elements (health bars, timers) on one Canvas, and static elements (backgrounds, labels) on another.
6. Garbage Collection (GC) Spikes
In C#, memory management is automatic, but it isn't free. When you create temporary objects (class instances) in a loop, the Garbage Collector eventually has to pause your game to clean them up. This causes those micro-freezes that players hate.
Common offenders:
String concatenation in Update:
text.text = "Score: " + score;creates a new string object every frame.LINQ:
list.Where(x => x.active).ToList()generates garbage.Returning new arrays: Methods that return
new int[]instead of populating a pre-allocated list.
7. The Singleton Spaghetti
Singletons are a useful tool, but they are often abused to create tight coupling. If your PlayerController talks to the AudioManager, which talks to the UIManager, which talks back to the PlayerController via static instances, you have created a codebase that is impossible to debug or unit test.
The Pivot: Use Singletons sparingly (mostly for "Manager" classes). For everything else, look into Dependency Injection (Zenject/VContainer - TBH I never used Depedency Injection due to a lot of boilerplate code, i prefer own custom system or central manager like thing) or strictly defined ScriptableObject architectures to decouple your systems.
8. Ignoring .meta Files
This is how you break version control. Unity uses .meta files to assign unique IDs (GUIDs) to assets. If you move a texture in Windows Explorer instead of the Unity Project window, or if you commit a file but "forget" the meta file, the link is broken.
To your team, that texture will show up as "Missing Reference." Always commit the asset and its meta file together.
9. Coroutine Micro-Management
Coroutines are great for simple delays, but they lack error handling and return values. When you start nesting Coroutines or having Coroutines wait for other Coroutines across different scripts, you enter "Callback Hell."
The Modern Way: Start using Async/Await (UniTask library). It allows you to write asynchronous code that looks synchronous, has proper try/catch error handling, and generally performs better.
10. Bloated Monobehaviours
If your Player.cs script is 2,000 lines long and handles movement, health, inventory, and animation, you have failed the Single Responsibility Principle.
Huge scripts are brittle. Breaking them creates bugs, and reading them is a nightmare. Break your logic into small, composable components (PlayerMovement, PlayerHealth, PlayerInventory) that do one thing well.
.png)
0 Comments