对Unity的Update和FixedUpdate的进一步个人理解

Unity在执行游戏逻辑的时候
在一个场景中有多个挂载着脚本的游戏物体的时候
脚本的执行顺序并不是并行执行的
执行顺序相当于
操作系统的调度的那种的，类似的
反正我会在这一帧的时间内执行完这个场景中所有Enable物体上的Update函数

FixedUpdate函数（）
刚体物理相关的计算，一般扔到这个里面
每秒根据你所定的每一帧的执行时间来计算
你要定义是每帧执行时间为0.02秒，那你用1/0.02那就是每秒执行50次
物理计算不应该扔到Update函数内，因为物理计算较为复杂，且消耗性能，
所以放在Update函数的话，每秒进行如此高速的运算，
会使我们的机器CPU负担及大
而且你放Update里面的话，update受系统性能的影响，每秒的帧数是不一样的
你好比我要让一个Cube从A点走到B点，A点和B点距离6m，然后是每帧走0.1m
具体代码就是 transform.Translate(this.transform.forward*0.1f);
你机子性能好的时候，可能1秒60帧，那1秒就是走6m，刚好到B点
那你要是帧率到120呢？一秒内你就走了12m
那你要是帧率30呢？同样的一秒你只走了3m
而且多好的机子你也没法保证时刻都稳定在一个帧率

具体看这段代码
         float i = 10f;

        private void Update()
        {
            if (i > 0)
            {
                transform.Translate(this.transform.forward);
                 i -= Time.deltaTime;
            }
        }

我第一次运行的时候这个Cube只跑了598m
                     第二次为595m
                      第三次为597m
                        第四次599m

这几次我的帧率都是在57.8到60.35之间跳动的
这个时候就体现出Update再进行刚体计算的时候体现出的不可靠，
你把这个代码放FixedUpdate里去，你就发现每次运动的距离都一样

而且你把这段代码分别放到FixedUpdate和Update中去运行，你会发现，
放在FixedUpdate里面运行的Cube移动的，没有Update里的顺滑，
当然你那个TimeStep那是保持默认的情况下,还有你机子配置得够，你别运行Unity就很卡那样的。

你设计游戏的时候，就要想到，玩家的机子虽然有好坏之分，
但是但凡能玩的你要保证玩家的体验一样啊，
不能你拿个IphoneX你1秒飙6m，我拿个千元机就只能1秒走3米啊
你拿IphoneX只能说是你每秒跑的帧数多，但是我设定你的FixedUpdate每秒运行50次
transform.Translate(this.transform.forward * 0.1f);把这个放fixedUpdate里
那无论好手机，还是坏手机，每秒移动的次数都只能是5m

而Update函数的执行次数是根据你机器的硬件水平来看的
你机器好，Update在1秒内执行的次数也就越多，画面看起来也就越平滑

但是这个FixedUpdate和Update是由不同的定时器控制的
就好像这俩不是用的同一个表来计时的
FixedUpdate在Update函数之前每帧在执行
我FixedUpdate()就按着我自己的那个表来看，（按上面说的那个时间来啊），
我不管你这机器多叼，或者多垃圾
我就看着我那个表，心里有B数
我就一秒内执行50次，你Update每秒执行的再快
我每秒该运行几次还运行几次

所有就是说当Update函数在执行了多次的时候，
FixedUpdate()可能才执行了一次，
所以说Update里拿到的物理计算的结果，
可能是Update函数已经运行了好几帧之后的那个值
换句话就是说我这运行的这几帧所用到的物理计算的结果
用到的值可能都是相同的。直到下一次FixedUpdate函数执行
你Update里才能拿到我最新的值
当然这是在你机器运行速度正常，或者稍快些的时候
还有一种情况是当你电脑垃圾的时候，你Update执行的慢了是什么样呢？
就反过来了，你FixedUpdate执行的快了，一帧好几次
我update()一帧运行一次，你运行的再快我也就是拿你最后的值

所以就是说后面的渲染部分拿到的数据，也是拿到的最后的值，

还拿移动来举例，我后面渲染拿到的值越密集，画面也就越多，
人眼看到的也就越流畅，反过来就是，
transform.Translate(this.transform.forward * Time.fixedDeltaTime);
当我fixedupdate执行多次的时候，算出越来越多的结果的时候
你渲染的时候只拿我最后的那个坐标，
你一开始的坐标是（0，0，0）
我在你按下按键就开始结算，
（0，0，0.1）
（0，0，0.2）
（0，0，0.3）
（0，0，0.4）
（0，0，0.5）
    。
    。
    。
比方说我算了5次，正常来说，就是说你机器配置够，性能足够强的时候，
渲染的时候就是这五次坐标的变换都能拿到，
在Game视窗就是。。。嗯。。。拿那种手绘的翻页动画来举例吧，
从z轴=0（因为是forword嘛）开始，你机器配置够，性能足够强的时候，就相当于你在那个画本上画了五张Cube不断移动的画面
这样你开始掰着那话本开始忽悠忽悠的播放的时候，你在一秒内看到的就是5张画面
相反，你机器很垃圾
你再播放你画本的时候，从z轴=0开始，你就只能看到一张，你的视角就是这个Cube直接从0闪现到了0，0，0.5那个位置
这样就是我们说的帧数低。

但是为啥用俩表计算时间的函数却有执行次序之分呢？
我们需要知道FixedUpdate和Update是运行在同一个线程上的
你平时FixedUpdate函数工作完了，休息了
我Update就继续赶工，
你休息的时候，我就拿着你工作完的结果继续工作，
当咱们（注意这里用到了咱们）我就在后面等着你当前工作完，
我拿到你计算的新的结果了，如果我需要你这个结果的话
我再拿着这个结果去更新我的下一次也就是当前即将进行的这次工作。