koobas.hobune.stream
Use of Awake() vs Start()
I as wondering if there was a general best practices use for using Start() versus using Awake()? Pretty simple question, but I didn't find a good answer that seemed canonical in my googleing.
All Awakes run before any Starts run before any Updates. You usually use Awake if you need something initialized so somebody's Start function can use it.
Another hint: never use Find functions in Awake, only in Start - Awake runs when the object is instantiated, and the target object may not have been created yet.
"Awake is called after all objects are initialized so you can safely speak to other objects or query them using eg. GameObject.FindWithTag." - $$anonymous$$onoBehaviour.Awake
"The difference between Awake and Start is that Start is only called if the script instance is enabled. This allows you to delay any initialization code, until it is really needed." - $$anonymous$$onoBehaviour.Start
You can certainly Find and GetComponent another script in Awake, however you have no knowledge as to whether that script has executed it's Awake yet and hence whether it is in any state to receive actual messages or requests. So message passing should be deferred until Start.
And that's only true for scene-serialized objects when a level is loaded. When you use Instantiate Awake is even called before the Instantiate call returns. Start is always delayed to the start of the next frame. If you setup links in Awake you can't adjust something when you instantiate a prefab. Start is the better place in most cases.
Like someone else said: use Awake to initialize the object itself, use Start to setup links to other objects.
[$$anonymous$$eta]
I'm just wondering. We had this question a couple of times, but looking at the related questions just brings up ??? in my $$anonymous$$d. How are those related questions? This looks like random picking... There are things about shaders, item pickup, draw calls, $$anonymous$$mwork, memory leaks, static variables, ... but nothing actually related to the question.
The accepted answer is wrong :( The correct answer is in the comments from bdjnk
"Awake is called after all objects are initialized so you can safely speak to other objects or query them using eg. GameObject.FindWithTag." - MonoBehaviour.Awake
"The difference between Awake and Start is that Start is only called if the script instance is enabled. This allows you to delay any initialization code, until it is really needed." - MonoBehaviour.Start
You might like to copy this beefed-up template of a standard MonoBehaviour class:
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class MyBestClassEver : MonoBehaviour {
/* MAIN DIFFERENCES BETWEEN Start & Awake:
Awake: Here you setup the component you are on right now (the "this" object)
Start: Here you setup things that depend on other components.
If you split it that way you can always be sure that the other object is ready
to work with you as game objects in scenes on scene load are loaded in blocks:
* All Awake() methods are executed, even if the object's component is disabled, then
* all Start() methods (if the relevant component is enabled) are executed; then finally
* all enabled objects go into Update().
*/
// Awake is called when the script is being loaded, even if the component is not enabled.
// Awake is used to initialize any variables or game state before the game
// starts. Awake is called only once during the lifetime of the script instance,
// after all objects are initialized, so you can safely speak to other objects
// or query them using, eg, GameObject.FindWithTag. Each GameObject's Awake
// is called in a random order between objects. Because of this, you should
// use Awake to set up references between scripts, and use Start to pass any
// information back and forth.
// *Start is always called after any Awake functions*, this allows you to order
// initialization of scripts. Awake cannot act as a coroutine.
// For C# use Awake instead of the constructor for initialization, as the
// serialized state of the component is undefined at construction time.
// Awake is called once, just like the constructor.
void Awake () {
print("Object Awake!");
}
// Use this for initialization and finding objects
// The difference between Awake and Start is that Start is only called if
// the script instance (component) is enabled. This allows you to delay any
// initialization code until it is really needed.
// Also all Awakes run *before* any Starts.
// Start will only be called on an (enabled) object before its first Update.
// By delaying or controllying when a component is enabled, you can modify the
// initialisation process of gameObjects and variables.
// Note that both Start and Awake are called at most once, eg Start would not
// be rerun by disabling and re-enabling.
void Start () {
print("Object Start");
}
// Update is called once per frame at a variable rate, with gaps of Time.deltaTime .
void Update () {
print("Frame update");
}
// FixedUpdate is called at a constant rate, independent of the frame-rendering rate.
// The (constant) gap between calls to FixedUpdate is Time.fixedDeltaTime .
// This makes is ideal for motion, collision and other physics work, since these events
// should be processed regularly and in-sync regardless of how fast or slow your
// computer is rendering the visual game frames or user-interface.
// In order to get the elapsed time since last call to Update(), use Time.deltaTime.
// You can speed-up or slow-down all physics calculations in the world by changing
// the value of Time.timeScale (which is set to 1.0f by default, obviously). E.G., if
// Time.timeScale is set to zero, the game is basically paused (if all your functions
// are framerate-independent).
void FixedUpdate () {
print("Fixed-rate update call");
}
}
From my little experience: Awake is something like a constructor. Start is something like a "do this once" as the first Update. Update is update.
If I instantiate a GameObject and just after that I want to call its public method I have to initialize all necessary fields in Awake of that GameObject, not in Start.
