Discussion A Comprehensive Guide to the Execution Order of Unity Event Functions

Update: V2 released

The section Order of execution for event functions in the Unity manual, while detailed and exhaustive, is confusing to say the least, where not directly wrong and/or misleading. Other similar diagrams found over the internet include similar imprecise or misleading information, probably influenced by the Unity manual.

Even as an experienced Unity developer I also encounter issues in my own code related to not entirely counting on how the Unity event functions actually work. Also I often see third-party code making questionable use of the event functions, specially about initialization and finalization, which leads to issues and exceptions on common situations such as disabling and re-enabling components, or recompiling the scripts while in play mode (domain reload).

So I decided to create a correct diagram showing the actual execution order of the main Unity event functions and the considerations every developer should know about. I'm also including essential information to help understand when and how to use each event method, and the consequences of doing so.

​

Other event functions not included in this diagram can be found in the original execution order page in the Unity manual. You can easily locate their place in this diagram by consulting the manual.

This guide is available in other resolutions and formats, including PDFs and a "Dark Mode" version, here:
https://www.edy.es/dev/docs/a-comprehensive-guide-to-the-execution-order-of-unity-event-functions/



Feel free to let me know if there's anything unclear in the diagram or the information. I know there could be many more events and details here, but I prefer to keep it with the strictly necessary information to understand the actual execution flow.

 

For all intents and purposes completely true! But to be annoying, technically not entirely. On Demand Rendering can alter this, for example this property shows that sometimes an Update call is not done for every visually presented frame.

 

Good one, thanks for pointing it out! This seems a corner case introduced in Unity 2019.3. If I've understood it correctly, the Update call still happens normally, with a correct Time.deltaTime, etc. Only the block "Scene Rendering" in the diagram wouldn't actually render a frame sometimes.

If this case becomes relevant enough it may deserve adding a new footnote to the diagram. For now, I'm trying to keep the information to the minimum according to the default Unity settings.

Anyone feel free to remark any other corner or specific cases, so we could have them documented here!

EDIT: After reviewing this in depth I came to the conclusion that rephrasing the sentence to

- Called before processing each visually presented frame​

would make the statement entirely true regardless of the On Demand Rendering feature. Update is called for each display frame. If On Demand Rendering is set not to render the scene then the previously rendered frame will still be visible for the current display frame. Only the "Scene Rendering" part of the diagram would be skipped.

 

One thing I didn't want to write a whole test case to answer for myself is whether a created object's Awake is called before InstantiateObject returns or not; I know Start() happens potentially much later. Thanks for including that exact verbiage. There might be no good way to show this "non-aligned" relationship between two objects in the diagram without spelling it out verbally.

The original state diagram also shows how Reset() is called if you're in the editor, and also where in the loop all your Coroutines get serviced. Not sure if you wanted to cover all those bases too.

 

Not for now. These may be located easily in this diagram once you look at the original one.

I wanted to keep this diagram to the essentials because I've found that people new to Unity have significant difficulty understanding the basics of how component scripts work. The original diagram doesn't help with this at all. I hope mine will lower the barrier to entry and make it easier for people to understand.

 

Is OnEnable() also called when an object is already active and the script is already active and Play mode is entered? IOW, not only when the Object is actively set to enabled by a script, but also on entering Playmode (and Scene Loading where it's on an object that's active on loading and the script is active)?

 

Yes, of course. Loading a scene is equivalent to instance all the GameObjects and Components, but it's done from the Unity code. This happens when entering the Play mode or when loading a scene in runtime. Components pass through all the stages: Awake, OnEnable, Start, etc. Likewise, when unloading the scene or exiting the Play mode the GameObjects are destroyed by Unity, so the ending stages (OnDisable, Destroy) apply as well.

 

I also needed it, and I've been programming in Unity for 13 years now xD

 

Thank you for the diagram, solved some misunderstandings for me especially for Awake and OnEnable callbacks.

Just one note, I think for the FixedUpdate we should use Time.fixedDeltaTime rather than using Time.deltaTime, or am I misunderstood again?

 

As MelvMay said. Just for additional clarification, the best practice is to use Time.deltaTime from both Update and FixedUpdate. The property will return the correct value depending on where it's read from.

 

I've released the version 2 of the guide, adding some details for disambiguation and better clarity.
https://www.edy.es/dev/docs/a-comprehensive-guide-to-the-execution-order-of-unity-event-functions/

 

Random questions
- OnDisabled gets called if destroy gameobject destroy/destroyimmediate?
- Does new input system happen on that internal input update spot also?

 

OnDisable will be called before OnDestroy when a Unity object (not just game objects) are destroyed, yes.

The New Input System has options for updating in Update and Fixed Update. I believe the package hooks into the player loop to recieve its updates. I wouldn't know where in player loop they specifically reside though.

 

Yes. Every solid line in this diagram will be forcefully followed during the lifecycle of any MonoBehaviour. Dashed lines or multiple path choices depend on specific events or conditions (see the corresponding remarks).

 

Great!
How about events in the order, for example OnPointerClick etc.

 

Those may be easily located here by looking at the original diagram from the Unity manual. Indeed, those are enclosed within the "Internal Input Update" block called right before Update, after the Internal Input Update. I wanted to leave this diagram with the minimum essentials.

 

I see, just another curious, does the "Internal Input Update" block always invoked before "Update" between different MonoBehaviour instances, for example:

Code (CSharp):

1. class A{
2.  
3. OnPointerDown() ...
4.  
5. }
6.  
7. class B{
8.  
9. Update()
10.  
11. }

For my testing, i need to change the Executing order in the project setting to place B after A, to ensure every time A.OnPointerDown() will be called before B.Update in a frame.

But, I am not very sure.

 

As for my understanding, the "Internal Update Block" itself doesn't trigger any event function, it just reads the input devices and updates the internal values in Unity. Then the corresponding event functions are called for each MonoBehaviour instance based on the new input state, and applying the execution order. I've edited my previous reply for clarification.