Unity3d_02_ base class monobehaviour/self-function and the life cycle of script execution

Guidance:

Where time,input,physics are global variables in unity. Gameobject is the basic object in the game. Gameobject is a combination of component, Gameobject itself must have transform component, which also deepened our understanding of gameobject, that is, Gameobject is the real existence of the game scene, And there is a position of an object.

But how do we manipulate this gameobject? This requires the introduction of the script component, which is the base class monobehaviour of all the script components.

The life cycle of Monobehaviour:

Monobehaviour is the base class for all scripts in unity, and if you use JS, the script automatically inherits the Monobehaviour. If you use C #, you need to explicitly inherit monobehaviour.

When we use Monobehaviour, it is especially important to note that there are overridable functions that can be called when certain events occur in the game. Some of the overridable functions we use most often in unity are these:

Awake: Awake is called when a script instance is loaded. Most of us do the initialization of member variables in this class
Start: Called only before the update function is called for the first time. Because it is called after awake, we can initialize some variables that need to depend on awake in start. At the same time, most of us execute startcoroutine in this class to perform some process triggering. Note that when you write a script in C #, you must start a co-process using Startcoroutine, but you do not need to do this if you are using JavaScript.
Update: When Monobehaviour is enabled, its update is called at each frame.
Fixedupdate: When Monobehaviour is enabled, its fixedupdate is called at each fixed frame.
Onenable: This function is called when the object becomes active or active.
Ondisable: This function is called when the object becomes unavailable or inactive.
OnDestroy: This function is called when Monobehaviour will be destroyed.

Other information:

Editors (editor)
The Reset:reset function is called to initialize the Script property when the script is first attached to the object and is also invoked when the Reset command is used.
Editor's note: Reset is called when the user clicks the Reset button on the Inspector panel or when the component is first added. Reset is most often used to give a default value in the Insight panel.
First scene load
These functions are called at the beginning of a scene (once each object in the scene is called only once).

Awake: This function is always called after a preset is instantiated before any start () function, and if a gameobject is inactive (inactive), the awake function is not invoked during startup until it is active (active).
Onenable: Called only if the object is active (active), this function is not called until the objects are enabled (enable). This can happen when a Monobehaviour instance is created, such as when a level is loaded or a gameobject with a script component is instantiated.
Note: When a scene is added to the scene, The Awake () and oneable () functions on all scripts will be called before start (), Update (), and so on, before any functions in them are called. Naturally, this cannot be enforced when an object is instantiated during gameplay.

Before the first frame is updated (before, update)

Start: As long as the script instance is enabled, the start () function will be called before the first frame of the update () function.
For objects that are added to the scene, the start () function on all scripts will be called before any of the update () functions in them, which, naturally, cannot be enforced when an object is instantiated during gameplay.

Between frames (in between frames)

Onapplicationpause: This function will be called at the end of a frame when the pause is detected to be valid between the normal frame updates. After the onapplicationpause is called, there will be an extra frame to allow the game display display image to be displayed in the paused state.
Update Order

There are several different event functions you can use when you are tracking the game logic and status, animation, camera position, etc. The common pattern is to perform most tasks in the update () function, but there are other functions you can use.

The Fixedupdate:fixedupdate function is often called more frequently than the update function. It is called more than once, and if the frame rate is low it may not be called between frames, even if the frame rate is high. All graphical calculations and updates are executed immediately after fixedupdate. When performing a mobile calculation in fixedupdate, you do not need time.deltatime multiplied by your value, because fixedupdate is called at the actual time, independent of the frame rate.

Update:update is called every frame, and it is the primary load function for frame updates.
Lateupdate:lateupdate will be called at each frame after the update is completed, and any calculations executed at the end of the update when Lateupdate begins. Lateupdate is commonly used for third person view camera follow.
Rendering (Rendering)

Onprecull: Called before the camera rejects the scene. Culling is dependent on which objects are visible to the camera, and Onprecull is called only before culling works.

Onbecamevisible/onbecameinvisible: Called when an object becomes visible/invisible to any camera.

OnPreRender: Called before the camera starts rendering the scene.

Onrenderobject: Called after the specified scene render is complete, you can use the GL class or Graphics.drawmeshnow to draw the custom geometry here.

Onpostrender: Called after the camera has finished rendering the scene.

Onrenderimage (Pro only): Allows the screen image post-processing call after the scene Xuran finishes.

Ongui: In response to GUI events, each frame is called multiple times (typically two times minimum). Layout layouts and repaint events are processed first, followed by
Layout and keyboard/mouse events correspond to each input event.

Ondrawgizmos: Used to visualize the drawing of some gadgets in the scene view.
Collaborative program (Coroutines)

A normal co-program update runs after the update function returns. A synergistic program can suspend execution (yield) until the given compliance instruction (Yieldinstruction) is completed, written in a different application:

Yield: On the next frame where all the update functions have been called, the process will continue to execute.
Yield Waitforseconds: Continues after a specified time delay after all the update functions have finished calling the frame.

Yield waitforfixedupdate: The Fixedupdate function on all scripts continues after the call has been executed.

Yield www: lasts after the WWW download is complete.

Yield Startcoroutine: The cooperative program chain will wait until the Mufunc function is completed first.
Destroy (when the Object is destroyed)

Ondestory: This function will be called at the previous frame when an object is destroyed, it will be executed after the last frame of an object is updated in all frames, and the object may be destroyed when the Object.destroy or a scene is closed.
Exit the game (when quitting)
These functions are invoked on all active objects in your scene:

Onapplicationquit: This function is called on all game objects before the app exits, and is invoked when the user stops PlayMode in the editor mode, which is called when the Page view is closed in the Web player.
Ondisable: Called when the behavior becomes non-enabled (disable) or inactive (inactive).

Here is a graph to illustrate how these classes are called in the life cycle of Monobehaviour:

The order in which the event functions are executed in the official script is as follows:

Unity system comes with functions:

1 usingUnityengine; 2 usingSystem.Collections; 3 4  Public classTest:monobehaviour5 {  6 7     voidAwake ()8     {  9Print"Awake"); Ten     }   One  A     voidonenable () -     {   -Print"onenable");  the     }   -  -     voidStart () -     {   +Print"Start");  -     }   +  A     voidUpdate () at     {   -Print"Update");  -     }   -  -     voidlateupdate () -     {   inPrint"lateupdate");  -     }   to  +     voidOngui () -     {   thePrint"Ongui");  *     }   $ Panax Notoginseng     voidOnDestroy () -     {   thePrint"OnDestroy");  +     }   A  the     voidondisable () +     {   -Print"ondisable");  $     }   $}

The order of self-carrying functions is as follows:

Run Time:

at the end:

Will find that the end of the time than the runtime two more methods, Ondisable and OnDestroy, the above is the order of function execution!

Compilation Order of scripts

The compilation order of the script is a headache, the official statement is a bit vague, see the official explanation:

Because the compilation order of scripts involves special folders, such as the plugins, editor, and standard assets, which are mentioned above, the location of the script is very important. Here is an example of the compilation order of scripts in different folders:

If you build the folder hierarchy as shown in your project, the project files are generated in the project folder after you compile the project file with the words editor and Firstpass in the file name. For example, according to the folder structure, we open the project folder to see what the resulting project file is?

1, first from the scripting language type, Unity3d support 3 scripting languages, will be compiled into the CLI DLL
If the project contains C # scripts, then Unity3d will produce a project prefixed with Assembly-csharp, with the name "vs" generated for Vistual studio, and not "vs" generated for MonoDevelop.
Project script language engineering prefix engineering suffix C # assembly-csharp csproj unityscript assembly-unityscript unityproj Boo assembly-boo booproj
If all three of these scripts exist in the project, unity will generate 3 types of prefix-type projects.

2, for each scripting language, according to the location of the script placement (in fact, in part according to the role of script, such as editor extension script, must be placed in the Editor folder), unity will generate 4 suffix of the project. The firstpass means to compile first, and editor to represent the script placed under the Editor folder.
In the example above, we got two project engineering files: used by Virtual studio and MonoDevelop (suffix package does not contain vs), for simplicity, we only analyze vs projects. The resulting file list is as follows:
Assembly-csharp-filepass-vs.csproj
Assembly-csharp-editor-filepass-vs.csproj
Assembly-csharp-vs.csproj
Assembly-csharp-editor-vs.csproj
According to the official explanation, they are compiled in the following order:
(1) All scripts in standard Assets, Pro standard Assets, or plugins folder generate a assembly-csharp-filepass-vs.csproj file and compile it first;

(2) All in standard Assets/editor, Pro standard assets/editor or plugins/ The script in the Editor folder produces the Assembly-csharp-editor-filepass-vs.csproj project file, which is then compiled;

(3) All the script files outside the Assets/editor and not in (1), (2) (usually these scripts are the non-editor extension scripts that we write ourselves) will produce the Assembly-csharp-vs.csproj project file and be compiled;

(4) All scripts in Assets/editor produce a assembly-csharp-editor-vs.csproj project file, which is compiled.

The reason for building the project in this order and compiling it in this sequence is also determined by the dependencies that exist between the DLLs.

Unity3d_02_ base class monobehaviour/self-function and the life cycle of script execution