Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
Why does Unity use reflection in order to access MonoBehaviour message methods like Awake, Update, Start,...?
Wouldn't it be slow to use reflection? Why doesn't it leverage other approaches like Template Method? It could simply define the methods as abstract in MonoBehaviour base class and force the subclasses to implement it.
How Update is called
No, Unity doesn’t use System.Reflection to find a magic method every time it needs to call one.
Instead, the first time a MonoBehaviour of a given type is accessed the underlying script is inspected through scripting runtime (either Mono or IL2CPP) whether it has any magic methods defined and this information is cached. If a MonoBehaviour has a specific method it is added to a proper list, for example if a script has Update method defined it is added to a list of scripts which need to be updated every frame.
During the game Unity just iterates through these lists and executes methods from it — that simple. Also, this is why it doesn’t matter if your Update method is public or private.
As for the reasons it is done this way, I'll largely refer you (the reader) to DMGregory's answer, which boils down to a balance of two competing things:
A new developer just wants it to Work and doesn't want to have to figure out "how do I connect this in to the event system?" but it should still run fast with minimal overhead.
The solution is probably the best that can be achieved within these two constraints. Or at least, the best the Unity dev team was able to come up with at the time. We may never know.
Also, this is why it doesn’t matter if your Update method is public or private. I don't understand, how are they able to call private methods from outside?
\$\endgroup\$
It could simply define the methods as abstract in MonoBehaviour base class and force the subclasses to implement it.
One of the advantages of the system Unity uses is that you don't have to implement every MonoBehaviour message, of which there are over 60.
Usually we just need one or a small handful of these methods. Since some are specific to 2D/3D physics, some unique to cameras or particle systems, it's highly unlikely that any one script would ever need all of them.
By leaving the messages we don't need as unimplemented, we can clearly signal to the runtime "don't even bother calling OnCollisionStay2D on this object — I don't need it"
This can be a substantial efficiency win. Now the engine can filter down a short-list to call Update on only the ~20 objects in my scene that need custom update logic every frame, and not all ~200 objects that make up all the scenery or only respond to physics events.
