Top 10 Ways to Cache References in Unity 6 (and the Best Ones!), with Code Examples!

 

The beauty of the Unity Game Engine (and its downfall for some at the same time) is the amount of freedom it gives you when developing your game. There are multiple ways to structure something that result in the exact same outcome, but one approach is often better than another. Which one is best depends on your game design architecture, but overall it’s safe to say some methods are generally stronger regardless of your structure. Choosing the right way to cache references in Unity can greatly enhance the performance of your game.

Here are 10 ways you can cache references in Unity, along with their pros and cons, in no particular order:

1. Inspector Serialization

This one probably looks very familiar to you, it's one of the most common ways to cache a reference in Unity: Using a [SerializeField].

Example:

public class Player : MonoBehaviour
{
    [SerializeField] private Rigidbody _rb;

    private void Awake()
    {
        // already cached (by selection or drag and drop)        
        _rb.mass = 2f;
    }
}
  

Pros:

• Fast access at runtime
• You can see it in the Inspector

Cons:

• Must be manually assigned, either by selection or drag and drop.

2. GetComponent

Use Unity’s built-in method to cache components dynamically.

Example:

public class Player : MonoBehaviour
{
    private Rigidbody _rb;

    private void Awake()
    {
        _rb = GetComponent();
    }
}
  

Pros:

• No Inspector needed

Cons:

• Costly if called repeatedly (accidentally)
• Works only if the component is on the same GameObject

3. TryGetComponent

A safer alternative to GetComponent that omits null reference exceptions. Often implemented in conjunction with raycasts or ontrigger/exit systems that need to cache a component with an interface or abstract class.

Example:

if (TryGetComponent(out Rigidbody rb))
{
    _rb = rb;
}
  

Pros:

• Avoids manual null checks, like if (!= null)
• Cleaner, safer pattern

Cons:

• Same performance as GetComponent

4. GetComponentInChildren / GetComponentInParent

Useful when you need to grab references up or down the hierarchy. Keep in mind the Unity quirk that caches a parent component even if you explicitly specify use GetComponentInChildren (annoying)!

Example:

private Collider _childCollider;

private void Awake()
{
    _childCollider = GetComponentInChildren();
}
  

Pros:

• Automatically finds nested components

Cons:

• Slower than direct references
• Can cache the wrong component if multiple exist (usually goes in order)

5. FindObjectOfType / FindWithTag

One of the worst ways to cache components. Searches the entire scene for an object of a given type, you can probably already guess the downside of this.

Example:

private GameManager _gm;

private void Awake()
{
    _gm = FindObjectOfType();
}
  

Pros:

• Simple when there’s only one instance
• You just want to grab the component quickly to test something

Cons:

• Very slow on large scenes
• Breaks if multiple exist
• Find with tag requires a 'string'. A typo can break it. Or accidentally leaving a space in a word can be a headache to resolve it. FindWithTag("Player") is not the same as FindWithTag("Player ")

6. Static Singleton Reference

A common pattern for managers and services.

Example:

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }

    private void Awake()
    {
        Instance = this;
    }
}
  

Pros:

• Very fast global access

Cons:

• Harder to test
• Can lead to spaghetti code dependencies

7. A ScriptableObject Reference

Store references in ScriptableObject and share them across your project.

Example:

[CreateAssetMenu]
public class GameManagerRef : ScriptableObject
{
    public GameManager Manager;
}
  

Pros:

• Decouples data from scene objects
• Good for global references

Cons:

• Extra setup required

8. Dependency Injection

A more advanced but powerful approach, either manually or using frameworks like Zenject.

Example:

public class Player
{
    private readonly Rigidbody _rb;

    public Player(Rigidbody rb)
    {
        _rb = rb;
    }
}
  

Pros:

• Highly testable and clean
• Strong decoupling

Cons:

• More boilerplate (extra, repetitive setup code you have to write just to make the system work, not the actual 'game logic' itself.)(
• Requires a DI (Dependency Injection) setup

9. Events and Callbacks

Cache references dynamically via events when objects become available.

Example:

public class Player : MonoBehaviour
{
    private Camera _cam;

    private void OnEnable()
    {
        CameraManager.OnCameraReady += CacheCamera;
    }

    private void CacheCamera(Camera cam) => _cam = cam;
}
  

Pros:

• Dynamic and flexible
• Avoids polling

Cons:

• More complex to manage, especially when your project gets bigger

10. Service Locator

Centralize references in a 'service locator' that can be queried anywhere.

Example:

public static class ServiceLocator
{
    private static readonly Dictionary<Type, object> _services = new();

    public static void Register<T>(T service) 
        => _services[typeof(T)] = service;

    public static T Get<T>() 
        => (T)_services[typeof(T)];
}
  

Pros:

• Centralized access
• Cleaner than scattering singletons

Cons:

• Still global state, can hide dependencies

Wrap up:

Generally, it depends greatly on which caching reference option is best for your project. If it's just a small game, there's nothing wrong with FindObjectOfType for instance, since computers are fast enough for you to not even notice. But even then, I'd go by the golden rule (the way I like to do it :P), if a script needs to cache a component that's the same game object, use GetComponent. Use SerializeField for referencing UI components or Audio components such as Audio Clips. In my projects, I mainly use an 'Event and Callback' system for components that are not on a directly relevant game object. An example would be the AudioManager, but not the RigidBody (in which case you use GetComponent).

I cannot stress the importance of caching components in Unity enough, since it’s directly tied to the performance optimization of your game. Also, make sure you are consistent. Caching a component sometimes with GetComponent, and other times as a SerializeField on the same game object doesn’t make any sense.

Do you know about other ways to cache references in Unity? Or do you know an even better way? Feel free to comment!