unity知识点

Unity 脚本生命周期

2021-12-05  本文已影响0人  合肥黑

参考
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 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<ExecutionOrder>();
            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<ExecutionOrder>()执行完，默认是enabled状态，然后进入disabled状态，执行了onDisable。此时，没有执行Start。

现在按下B键：


image.png

再按下C键：


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

注：这里使用go.SetActive(false);直接控制了对象是否激活，如果使用go.GetComponent<StartAwakeTest>().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<ExecutionOrder>();
            go.GetComponent<ExecutionOrder>().Test();
            //go.SetActive(false);
        }

按下A键：


image.png

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

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

相同点：

不同点：

二、FixedUpdate、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
image.png

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

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


image.png
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 中

实际游戏感觉

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

一般的 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
和游戏性和手感有很大关系 ! ! !

上一篇下一篇

猜你喜欢

热点阅读