Unity 脚本生命周期

参考
https://docs.unity.cn/cn/2019.4/Manual/ExecutionOrder.html

image.png

一、Awake OnEnable Start

参考

Unity中Awake和Start的区别

1.实验一

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class ExecutionOrder : MonoBehaviour
{
    // Start is called before the first frame update
    void Start()
    {
        Debug.Log("Start is called!");
    }

    void Awake()
    {
        Debug.Log("Awake is called!");
    }

    private void OnEnable()
    {
        Debug.Log("OnEnable is called!");
    }

    private void OnDisable()
    {
        Debug.Log("OnDisable is called!");
    }

    // Update is called once per frame
    void Update()
    {
        Debug.Log("Update is called!");
    }
}

将上面的脚本挂在一个未激活的GameObject上，然后运行，会发现控制台什么也没有。这说明，未激活的对象，连Awake也不会执行。

现在，激活该对象，控制台输出结果：

image.png

可以看出，Awake是在OnEnabled之前执行的，然后才是Start。

现在，将激活的对象重新变成未激活状态，输出结果：

OnDisable is called!

这个很好理解，重点来了，此时再重新激活GameObject:

image.png

这说明，反复激活一个GameObject时，OnEnable和OnDisable 会重复执行。但是Awake和Start只会执行一次。

2.实验二

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class StartAwakeTest : MonoBehaviour
{
    //此处通过一个引用来保存对象，因为被取消激活的对象是不能被find函数找到的！！！
    private GameObject go = null;

    void Awake()
    {
        go = new GameObject("create game object");
    }

    void Update()
    {
        //添加脚本组件，默认不激活
        if (Input.GetKeyUp(KeyCode.A))
        {
            go.AddComponent();
            go.SetActive(false);
        }

        //将其激活
        if (Input.GetKeyUp(KeyCode.B))
        {
            if (go == null)
                return;
            go.SetActive(true);
        }

        //将其取消激活
        if (Input.GetKeyUp(KeyCode.C))
        {
            if (go == null)
                return;
            go.SetActive(false);
        }
    }
}

image.png

把上面的脚本放在GameObject(1)上面，运行之后，会发现下面多出来的create game object，正是脚本在Awake里面创建的物体。现在按下A键，会将实验一的脚本用代码添加上去：

image.png

由这个结果，可以推断AddComponent()执行完，默认是enabled状态，然后进入disabled状态，执行了onDisable。此时，没有执行Start。

现在按下B键：

image.png

再按下C键：

image.png

后面反复按下B和C键，也不会触发Awake 和 Start。

注：这里使用go.SetActive(false);直接控制了对象是否激活，如果使用go.GetComponent().enabled = false;，结果也是一样的。

3.实验三

在上面实验二的基础上，对ExecutionOrder增加一个自定义方法：

    public void Test()
    {
        Debug.Log("Test in new GameObject is called");
    }

然后在StartAwakeTest脚本创建对象后，进行调用：

    void Update()
    {
        //添加脚本组件，默认不激活
        if (Input.GetKeyUp(KeyCode.A))
        {
            go.AddComponent();
            go.GetComponent().Test();
            //go.SetActive(false);
        }

按下A键：

image.png

Awake函数最先被调用了，然后接着是我们自定义的Test函数，最后才是Start函数！！！这里应该是很容易出现问题的地方，比如Test函数中要用到一些值，而这些值应该被初始化，如果我们把初始化放在了Start函数中，那么此处这些值还没有被初始化，那么就会出现空引用异常等错误。我之前也是遇到了很多次，查了半天发现都是把对象的初始化放在了Start函数中，结果浪费了大量的时间。

4.总结

未激活的对象，连Awake也不会执行。
Awake、OnEnabled、Start有先后顺序。
反复激活一个GameObject时，OnEnable和OnDisable 会重复执行。但是Awake和Start只会执行一次。
Awake和Start都是对象初始化时调用的，都在Update之前，场景中的对象都生成后才会调用Awake，Awake调用完才会调用Start，所有Start调用完才会开始Update。
使用代码AddComponent时，Awake和OnEnable会先执行。如果有初始化代码，需要放在Awake当中。在 Start中进行初始化不是很安全，因为它可能被其他自定义的函数抢先。

6.最后总结一下Awake和Start的异同点：

相同点：

1）两者都是对象初始化时调用的，都在Update之前，场景中的对象都生成后才会调用Awake，Awake调用完才会调用Start，所有Start调用完才会开始Update。
2）两者在对象生命周期内都只会被调用一次，即初始化时被调用，之后即使是在被重新激活之后也不会再次被调用。

不同点：

1）Awake函数在对象初始化之后立刻就会调用，换句话说，对象初始化之后第一调用的函数就是Awake；而Start是在对象初始化后，第一次Update之前调用的，在 Start中进行初始化不是很安全，因为它可能被其他自定义的函数抢先。
2）Awake不管脚本是否enabled都会被调用；而Start如果对象被SetAcive(false)或者enabled= false了是不会被调用的。
3）如果对象（GameObject）本身没激活，那么Awake，Start都不会调用。

二、FixedUpdate、Update、LateUpdate

FixedUpdate：调用 FixedUpdate 的频度常常超过 Update。如果帧率很低，可以每帧调用该函数多次；如果帧率很高，可能在帧之间完全不调用该函数。在 FixedUpdate 之后将立即进行所有物理计算和更新。在 FixedUpdate 内应用运动计算时，无需将值乘以 Time.deltaTime。这是因为 FixedUpdate 的调用基于可靠的计时器（独立于帧率）。
Update：每帧调用一次 Update。这是用于帧更新的主要函数。
LateUpdate：每帧调用一次 LateUpdate__（在 Update__ 完成后）。LateUpdate 开始时，在 Update 中执行的所有计算便已完成。LateUpdate 的常见用途是跟随第三人称摄像机。如果在 Update 内让角色移动和转向，可以在 LateUpdate 中执行所有摄像机移动和旋转计算。这样可以确保角色在摄像机跟踪其位置之前已完全移动。

1.FixedUpdate

参考
对Unity的Update和FixedUpdate的进一步个人理解
Unity3D Update和FixedUpdate的区别及深入探讨

image.png

如果你在Update中打印Time.deltaTime的话，就会发现deltaTime非常不稳定，最短可以达到你设置的帧间隔，但卡的时候甚至会卡成ppt那样几秒一帧。想象一下假如你现在做了一个3D的RPG游戏，主角的移动通过在Update中用速度 speed 乘以时间差 Time.deltaTime 模拟，如果某帧卡顿了很久，Time.deltaTime将会变得很大，导致下一帧主角会无视地图障碍直接瞬移到一个很远的距离。在物理系统中这种不稳定会带来大量的穿模、超出地图等bug，因此保证物理有较短且稳定的更新非常重要。

下面我用两个Log来演示Update及FixedUpdate的行为

image.png

在每帧中两个函数的执行顺序是【FixedUpdate -> Update】，FixedUpdate会以设定的间隔调用，这里由于帧率太高，FixedUpdate会跨过多个帧之后再调用。任意两个FixedUpdate间所有Update的时间加起来刚好是设定的0.02左右。

这时我们在Update中插入一个比较大的运算（随便写的）

image.png

可以看到Update间隔拉长了许多，但FixedUpdate依然是固定更新，每个FixedUpdate之间的间隔依然是0.02左右，如果FixedUpdate的较慢或两帧的间隔太大，在一帧内会调用多次FixedUpdate以保证和Update同步。

这时我们再把Update的计算量放大160倍，运行结果如下：

image.png

为了保证在两帧间隔较大的时候依然能精准模拟物理之类的运算，一帧之间会运行多次FixedUpdate。将较大的间隔切分成多个固定的小时间段计算。但这种切分不能是无节制的，FixedUpdate中的运算也会带来计算负荷，如果为了追上帧间隔而带来太多FixedUpdate调用会让下一帧的时间更长，而更长的帧间距则需要更多的FixedUpdate来追上，这会导致一个恶行循环，所以FixedUpdate的调用会有一个时间限制，在Edit -> Project Setting -> Time中有 Maximum Allowed Timestep 选项，在上图中可以看出，两帧之间所有FixedUpdate的调用在16到17次左右，也即 0.02*16 到 0.02*17 约等于0.333秒。而为了保证FixedUpdate和Update同步，Update的deltaTime也被限制到0.333以下。

这里可以看出，FixedUpdate的固定时间间隔，并不是真正意义的固定的时间差。而是相对Update来说一个类似节拍器的存在。当两帧的时差过大时，Unity会 “缩放” 时间至设定的最大帧间隔（比如这里是0.333秒），在游戏中看起来就像减慢了一样（变得又卡又慢）。这个设定可以有效防止在卡顿时游戏的物理系统彻底暴走的现象。

说完了Update，下面说说要是FixedUpdate计算量膨胀会怎么样。我们把上面Update做的长计算LongTask() 换到FixedUpdate中：

image.png

在多个Update连续调用的地方Update的间距还是很短的，但这比Update有较大计算相比更加不稳定了，毕竟Update会稳定的影响每一帧，而FixedUpdate带来的影响很不稳定。

如果FixedUpdate的运算量变得非常非常大时：（上图的基础放大8倍）

image.png

这时和Update运算量时已经没什么区别了（打印上看）。但从实际运行的情况下，这比在Update放这里的20倍的运算量还要卡的更更更严重。因为已经出现上面所说的恶性循环了：庞大的FixedUpdate会拉大帧间隔，最后会以每帧固定16到17个FixedUpdate运行，所以卡顿会比Update相同运算量情况下严重16到17倍左右。

因此说千万不要在FixedUpdate中放太多的负荷，否则会给游戏的运行带来严重的不稳定性以及卡顿。

2.有关 Input 一类的输入的命令要放在Update中执行

在https://docs.unity.cn/cn/2019.4/ScriptReference/Rigidbody-velocity.html可以看到这样的代码，原因是什么呢？

    void Update()
    {
        isJumpPressed = Input.GetButtonDown("Jump");
    }

    void FixedUpdate()
    {
        if (isJumpPressed)
        {
            // the cube is going to move upwards in 10 units per second
            rb.velocity = new Vector3(0, 10, 0);
            isMoving = true;
            Debug.Log("jump");
        }
...

可以参考Unity Tip Unity Update() 与 FixedUpdate()，原文详细解释了原因，这里简单转载部分：

举个栗子控制变量，游戏帧数分别设置为无限制 60帧和 30帧，并且将获取按键和执行命令的函数全部放在 FixedUpdate 中

实际游戏感觉

无限制: 很明显的感觉到有的时候按按键没反应跳不起来
60帧: 偶尔有的时候按按键没反应跳不起来
30帧: 按一下跳跃有反应,但是很难按出2段跳,要么直接把2段跳用完了，并且游戏也看的出来的卡卡的了

从前面的部分知道FixedUpdate的执行帧率为50(默认的fixed timestep 0.02)

无限制: Update的检测次数明显多于FixedUpdate (Update执行的帧率100>>50)
60帧: Update的检测次数略多于FixedUpdate (Update执行的帧率60>50)
30帧: Update的检测次数少于FixedUpdate (Update执行的帧率30<50)

一般的 Update执行的帧率会比FixedUpdate大 :
按下按键的帧的时间是Update的任一帧,因为Update的帧率比FixedUpdate大。所以在某一帧按下按键时,FixedUpdate很可能还没有执行帧，而按键获取在FixedUpdate中,所以FixedUpdate中漏掉了获取的按键。所以在无限制和60帧的时候会出现如上情况。

而在 Update执行的帧率比FixedUpdate小时：
在某一帧按下按键时,FixedUpdate很可能执行了几帧。而按键获取在FixedUpdate中,所以FixedUpdate中多算了获取的按键。而且因为"按的太快"所以要么两次按跳时间太短没算跳了两次，要么算的稍微有点间隔,一下子把2段跳跳完了。

把获取按键的函数放在Update中，这样任意一帧按下按键都会准确的传递按下按键的指令，然后在FixedUpdate中按固定的时间间隔执行。

有关 Input 一类的输入的命令放在Update中执行(获取输入的按键等)
有关计算的物理命令放在FixedUpdate中执行 (移动,跳跃等)
Update中用 Time.deltaTime
FixedUpdate中用 Time.fixedDeltaTime
和游戏性和手感有很大关系 ! ! !

Unity 脚本生命周期

一、Awake OnEnable Start

1.实验一

2.实验二

3.实验三

4.总结

6.最后总结一下Awake和Start的异同点：

二、FixedUpdate、Update、LateUpdate

1.FixedUpdate

2.有关 Input 一类的输入的命令要放在Update中执行

你可能感兴趣的:(Unity 脚本生命周期)