第一章游戏循环与时间管理#

一句话理解：游戏循环是引擎的心跳。你写的每一行 Update 逻辑，都在这个循环的某个固定节拍上执行。如果节拍搞错了——物理放在 Update 里、输入读在 FixedUpdate 里——Bug 就像定时炸弹。

📋 前置知识：OS Ch1（进程与线程——渲染线程与逻辑线程的关系）

1.1 概念直觉 —— Why & What#

普通应用 vs 游戏#

1
// ============ 普通 GUI 应用 ============
2
// 事件驱动——用户不操作，程序就闲着
3
int main() {
4
    Window window;
5
    while (window.IsOpen()) {
6
        auto event = window.WaitForEvent();  // 阻塞等待
7
        if (event.type == EVENT_MOUSE_CLICK) {
8
            HandleClick(event.mousePos);
9
        }
10
        // 用户不操作，CPU 占用 ≈ 0%
11
    }
12
}
13

14
// ============ 游戏 ============
15
// 持续运行——即使玩家什么都不做，世界也在动
16
int main() {
17
    GameWorld world;
18
    while (world.IsRunning()) {
19
        ProcessInput();       // 1. 收集输入
20
        UpdateWorld(dt);      // 2. 更新世界（物理/AI/动画/逻辑）
21
        RenderFrame();        // 3. 渲染画面
22
        // 每秒钟跑 60 次，风雨无阻
23
    }
24
}

为什么游戏需要循环？ 因为游戏世界是连续的模拟。即使玩家手离开键盘，敌人还在走、粒子还在飘、天空还在转。游戏循环以固定（或尽量固定）的频率推进这个模拟。

核心矛盾#

游戏循环有一个根本性的矛盾：

1
理想：每帧间隔 = 16.67ms（60 FPS），稳定不变
2
现实：帧间隔从 5ms 到 50ms 不等，取决于场景复杂度
3

4
矛盾：如果逻辑依赖固定步长（物理模拟要求 dt 恒定），
5
      但渲染帧率是变化的——怎么调和？

这个矛盾催生了三种游戏循环模型。

1.2 三种游戏循环模型#

模型一：可变步长（Variable Timestep）#

1
// 最简单的游戏循环——来多快跑多快
2
void GameLoop() {
3
    while (running) {
4
        float dt = GetDeltaTime();  // 距上一帧的实际时间
5
        ProcessInput();
6
        Update(dt);   // 逻辑更新——dt 是变量
7
        Render();
8
    }
9
}

1
帧 1: dt = 16ms  → Update(16ms)  → 角色移动 16ms × 速度
2
帧 2: dt = 25ms  → Update(25ms)  → 角色移动 25ms × 速度
3
帧 3: dt = 10ms  → Update(10ms)  → 角色移动 10ms × 速度

优点：简单，渲染越快逻辑越快（高配电脑跑得更流畅）。

致命缺点：

不确定性：同样的操作在不同帧率下结果不同。碰撞检测、物理模拟在 dt 变化时行为不一致。这就是为什么帧率同步的格斗游戏不能用这个模型
物理不稳定：可变 dt 会让数值积分产生不同的误差。dt = 16ms 时角色的跳跃高度可能和 dt = 25ms 时不一样

模型二：固定步长（Fixed Timestep）#

1
// 逻辑以固定间隔更新，与渲染分离
2
const float FIXED_DT = 1.0f / 60.0f;  // 16.67ms
3

4
void GameLoop() {
5
    float accumulator = 0.0f;
6

7
    while (running) {
8
        float frameDt = GetDeltaTime();
9
        accumulator += frameDt;
10

11
        // 追赶：如果渲染慢了，物理可能一帧跑多次
12
        while (accumulator >= FIXED_DT) {
13
            ProcessInput();
14
            Update(FIXED_DT);   // 逻辑始终用固定 dt
15
            accumulator -= FIXED_DT;
16
        }
17

18
        Render();
19
    }
20
}

1
帧 1: frameDt = 16ms  → accumulator = 16ms  → Update 跑 1 次（16ms ≈ FIXED_DT）
2
帧 2: frameDt = 30ms  → accumulator = 30ms  → Update 跑 1 次，accumulator 剩 13ms
3
帧 3: frameDt = 20ms  → accumulator = 33ms  → Update 跑 2 次，accumulator 剩 0ms

优点：逻辑确定——同样的输入在任何帧率下结果完全一致（这就是帧同步的原理）。

缺点：

渲染帧率掉到 30 时，一帧要跑 2 次 Update——如果 Update 本身很重，会螺旋减速
需要累积器 + 追赶机制，复杂度高

模型三：半固定步长（Semi-Fixed Timestep）—— Unity 的方案#

Unity 采用的是混合策略：渲染用可变步长，物理用固定步长。这就是你看到的 Update（可变）和 FixedUpdate（固定）的分工。

1
// Unity 内部简化版
2
void UnityMainLoop() {
3
    while (running) {
4
        float dt = CalculateDeltaTime();
5

6
        // 第一层：可变步长——逻辑更新
7
        CallUpdate(dt);           // 你写的 Update()
8
        CallLateUpdate(dt);
9

10
        // 第二层：固定步长——物理追赶（如果需要）
11
        physicsTimer += dt;
12
        while (physicsTimer >= fixedDeltaTime) {
13
            CallFixedUpdate();    // 你写的 FixedUpdate()
14
            Physics.Simulate(fixedDeltaTime);
15
            physicsTimer -= fixedDeltaTime;
16
        }
17

18
        // 渲染
19
        RenderFrame();
20
    }
21
}

这就是为什么 FixedUpdate 可能在 Update 之后被调用多次——当渲染帧率低于物理步长时。

1.3 Unity 主循环的完整帧分解#

sequenceDiagram participant Input as 输入系统 participant Update as Update participant Anim as 动画更新 participant Fixed as FixedUpdate+物理 participant Late as LateUpdate participant Render as 渲染 Note over Input,Render: ======= 一帧开始 ======= Input->>Update: 1. 输入事件派发（Input.GetKey 等在此之后才更新） loop 物理追赶（物理步长内执行 0~N 次） Fixed->>Fixed: 2. FixedUpdate Fixed->>Fixed: 3. 物理模拟（PhysX） Fixed->>Fixed: 4. OnTrigger/OnCollision 回调 end Update->>Update: 5. Update（dt = 上一帧的实际时间） Update->>Anim: 6. 动画状态机更新 Update->>Anim: 7. IK 解算 Late->>Late: 8. LateUpdate（摄像机跟随放这里） Render->>Render: 9. 渲染（Culling → 排序 → DrawCall → 后处理） Render->>Render: 10. WaitForEndOfFrame（协程的 yield 指令在此恢复） Note over Input,Render: ======= 下一帧 =======

关键时序要点：

阶段	时机	适合放的逻辑	禁止放的逻辑
`Awake`	对象创建时，只调一次	组件引用缓存（`GetComponent`）	依赖其它对象 Awake 的逻辑
`Start`	第一帧 Update 之前	初始化需要等其它对象 Awake 完的逻辑	—
`FixedUpdate`	物理步长内 0~N 次	物理操作（`AddForce`、`MovePosition`）	`Input.GetKeyDown`（会丢失）
`Update`	每帧 1 次	大部分游戏逻辑	物理操作（用 FixedUpdate）
`LateUpdate`	Update 全部结束后	摄像机跟随、第三人称臂	会影响 Update 中行为的逻辑
`OnDestroy`	对象销毁时	清理资源、注销事件	—

1.4 deltaTime 的精确语义#

deltaTime 可能是 Unity 中最被低估的概念。它不是”一帧的时间”那么简单。

四个时间 API 的区别#

1
// ============ 四个时间 API，四个不同含义 ============
2

3
// 1. Time.deltaTime —— 上一帧的实际耗时（秒）
4
//    受 timeScale 影响。timeScale = 0 时，deltaTime = 0
5
void Update() {
6
    // 移动：每秒移动 5 个单位，不受帧率影响
7
    transform.Translate(Vector3.forward * speed * Time.deltaTime);
8
    // 60 FPS: dt ≈ 0.0167 → 每帧移动 0.083
9
    // 30 FPS: dt ≈ 0.0333 → 每帧移动 0.167
10
    // 结果：每秒都移动 5 个单位——与帧率无关
11
}
12

13
// 2. Time.fixedDeltaTime —— 物理步长（默认 0.02 = 50 Hz）
14
//    不受 timeScale 影响吗？受！timeScale = 0 → FixedUpdate 不执行。
15
//    但 fixedDeltaTime 本身的值不变。
16
void FixedUpdate() {
17
    // 物理操作使用 Time.fixedDeltaTime，不使用 Time.deltaTime
18
    rb.AddForce(Vector3.up * force, ForceMode.Force);
19
    // ForceMode.Force 内部已经乘以 fixedDeltaTime
20
}
21

22
// 3. Time.unscaledDeltaTime —— 不受 timeScale 影响的真实时间
23
//    用于暂停界面、加载进度条、粒子效果等——停不下来的东西
24
void Update() {
25
    // 即使 timeScale = 0（游戏暂停），这个 UI 动画依然动
26
    loadingSpinner.Rotate(0, 0, rotateSpeed * Time.unscaledDeltaTime);
27
}
28

29
// 4. Time.timeScale —— 时间缩放
30
//    1.0 = 正常速度, 0.5 = 慢动作, 0 = 完全暂停, 2.0 = 快进
31
void OnGamePaused() {
32
    Time.timeScale = 0f;
33
    // Update 中所有依赖 Time.deltaTime 的逻辑全停
34
    // FixedUpdate 也全停
35
}

timeScale = 0 时谁还在跑#

1
// timeScale = 0 时：
2
// ❌ Update —— 不跑了（因为 deltaTime = 0，虽然回调本身还在被调用）
3
// ❌ FixedUpdate —— 不跑了（物理也不模拟了）
4
// ✅ 协程 WaitForSecondsRealtime —— 还在跑
5
// ✅ Update + Time.unscaledDeltaTime —— 逻辑还在执行，只是你用的 dt 不同
6
// ✅ OnGUI —— 仍然每帧调用
7

8
// 典型用法：暂停菜单的动画
9
void Update() {
10
    if (isPaused) {
11
        // 用 unscaledDeltaTime —— 即使 timeScale = 0，暂停菜单的呼吸灯还在动
12
        pausePanel.transform.localScale = Vector3.Lerp(
13
            pausePanel.transform.localScale,
14
            targetScale,
15
            Time.unscaledDeltaTime * 3f
16
        );
17
    }
18
}

deltaTime 不加会怎样#

这是面试最常见的基础题：

1
// ❌ 没有 deltaTime —— 移动速度依赖帧率
2
void Update() {
3
    transform.Translate(Vector3.forward * 5f * Time.deltaTime);  // ✅ 正确
4
    // 60 FPS: 每秒移动 5 单位
5
    // 30 FPS: 每秒移动 5 单位（每次移动更多但频率低）
6
}
7

8
void Update() {
9
    transform.Translate(Vector3.forward * 5f);  // ❌ 缺少 deltaTime
10
    // 60 FPS: 每秒移动 5 × 60 = 300 单位
11
    // 30 FPS: 每秒移动 5 × 30 = 150 单位
12
    // 换个电脑跑，游戏难度都变了！
13
}

1.5 MonoBehaviour 生命周期全景#

graph TD Start["对象 Instantiate"] Start --> Awake["Awake\n（创建时，只一次）\n组件引用缓存"] Awake --> OnEnable["OnEnable\n（每次激活时）\n事件注册"] OnEnable --> Start2["Start\n（第一帧 Update 前，只一次）\n需要等其它对象 Awake 的初始化"] Start2 --> Loop{"每帧循环"} Loop --> Fixed["FixedUpdate\n（0~N 次/帧）\n物理操作"] Fixed --> Update2["Update\n（1 次/帧）\n逻辑更新"] Update2 --> Late["LateUpdate\n（1 次/帧，Update 之后）\n摄像机跟随"] Late --> Loop Loop -->|"禁用时"| OnDisable["OnDisable\n事件注销"] OnDisable -->|"重新激活"| OnEnable OnDisable -->|"销毁时"| OnDestroy["OnDestroy\n清理资源、注销所有事件"] style Awake fill:#d00000,stroke:#e85d04,color:white style Update2 fill:#d00000,stroke:#e85d04,color:white style Fixed fill:#e85d04,stroke:#f48c06,color:white style OnDestroy fill:#2d6a4f,stroke:#40916c,color:white

决策速查：逻辑放哪里#

1
public class Player : MonoBehaviour {
2
    // ===== Awake：引用缓存 =====
3
    private Rigidbody rb;
4
    private Animator animator;
5
    private HealthBarUI healthBar;
6

7
    void Awake() {
8
        // 获取自身组件——Awake 是最佳位置
9
        rb = GetComponent<Rigidbody>();
10
        animator = GetComponent<Animator>();
11

12
        // ⚠️ 不要在这里找其他对象——
13
        //    其他对象的 Awake 可能还没跑完，引用可能是 null
14
        // healthBar = FindObjectOfType<HealthBarUI>();  ← 危险
15
    }
16

17
    // ===== Start：依赖其他对象的初始化 =====
18
    void Start() {
19
        // Start 在所有 Awake 之后执行——此时可以安全地找其他对象
20
        healthBar = FindObjectOfType<HealthBarUI>();
21
    }
22

23
    // ===== OnEnable / OnDisable：事件注册/注销 =====
24
    void OnEnable() {
25
        EventBus.Subscribe<OnDamageEvent>(OnDamageReceived);
26
    }
27

28
    void OnDisable() {
29
        EventBus.Unsubscribe<OnDamageEvent>(OnDamageReceived);
30
        // 如果不注销，禁用后事件回调仍然触发 → 空引用异常
31
    }
32

33
    // ===== Update：输入 + 逻辑 =====
34
    void Update() {
35
        // 输入检测——只能在 Update 中检测（原因见 1.7 节）
36
        float horizontal = Input.GetAxis("Horizontal");
37
        float vertical = Input.GetAxis("Vertical");
38

39
        // 移动计算
40
        Vector3 movement = new Vector3(horizontal, 0, vertical) * moveSpeed;
41
        Vector3 newPosition = rb.position + movement * Time.deltaTime;
42

43
        // 用 MovePosition 而非直接设置 position——正确地与物理交互
44
        rb.MovePosition(newPosition);
45

46
        // 动画参数
47
        animator.SetFloat("Speed", movement.magnitude);
48
    }
49

50
    // ===== FixedUpdate：物理 =====
51
    void FixedUpdate() {
52
        // 持续的物理力
53
        if (isJumping && isGrounded) {
54
            rb.AddForce(Vector3.up * jumpForce, ForceMode.Impulse);
55
            isJumping = false;
56
        }
57
    }
58

59
    // ===== LateUpdate：摄像机 =====
60
    void LateUpdate() {
61
        // 保证角色已经在 Update 中移动完，摄像机再跟上
62
        Camera.main.transform.position = transform.position + cameraOffset;
63
        Camera.main.transform.LookAt(transform);
64
    }
65
}

1.6 帧率波动的三个典型问题#

问题一：隧道效应#

1
// 快速移动的子弹穿过墙壁——因为两帧之间子弹位移超过了墙的厚度
2
//
3
// 帧 N:   子弹 ●────────墙────────● 帧 N+1
4
//         穿过去了！检测不到碰撞
5

6
// Unity 的解决方案：在 Rigidbody 上设置 Collision Detection
7
// Discrete:     每帧检测一次位置（默认，快速物体会穿透）
8
// Continuous:   使用当前帧和前一帧的位置做扫掠检测（运动物体用这个）
9
// Continuous Dynamic: 对高速物体和被碰撞物体都做扫掠
10
// Continuously Speculative: 基于速度预测碰撞（新版 PhysX）
11

12
void Awake() {
13
    Rigidbody rb = GetComponent<Rigidbody>();
14
    rb.collisionDetectionMode = CollisionDetectionMode.ContinuousDynamic;
15
}

问题二：FixedUpdate 的螺旋减速#

1
// 场景：FixedUpdate 中做了重计算，导致单次 FixedUpdate 耗时 > fixedDeltaTime
2

3
// fixedDeltaTime = 0.02s（50 Hz）
4
// Update 耗时 = 0.03s（33 FPS——已经慢了）
5
// FixedUpdate 耗时 = 0.025s（本身就很重）
6

7
// 循环：
8
// 帧 1: physicsTimer += 0.03 → 0.03 > 0.02，跑 1 次 FixedUpdate，花了 0.025s
9
//       → accumulator = 0.01 → 又 0.01 > 0.02？否 → 渲染
10
//       但 FixedUpdate 花了 0.025s 而 dt 只扣了 0.02s！
11
//       实际消耗时间远超物理积累时间 → physicsTimer 追不上 → 螺旋减速
12

13
// 解决方案：
14
// 1. FixedUpdate 中不能放重计算
15
// 2. Unity 默认设置了 Maximum Allowed Timestep = 0.333s
16
//    如果 FixedUpdate 积累超过这个值，直接丢弃多余步长
17
// 3. 在 Time 设置中调整 Maximum Allowed Timestep

问题三：死亡螺旋#

1
帧率下降 → FixedUpdate 跑更多次 → 总耗时更长 → 帧率继续下降 → FixedUpdate 跑更多次 → ……
2

3
这是帧率掉到个位数的常见原因。
4
Unity 的 Maximum Allowed Timestep（默认 0.333s）防止了完全卡死，
5
但会丢失物理更新——表现为物体变慢或瞬移。

1.7 🎮 完整示例#

示例一：帧率无关的跳跃#

1
// 一个在任何帧率下跳跃高度完全一致的实现
2
public class FrameRateIndependentJump : MonoBehaviour {
3
    [SerializeField] private float jumpHeight = 2f;  // 目标跳跃高度（米）
4
    private Rigidbody rb;
5
    private bool jumpRequested;
6

7
    void Awake() {
8
        rb = GetComponent<Rigidbody>();
9
        // 用 Continuous 防止高速移动穿透地面
10
        rb.collisionDetectionMode = CollisionDetectionMode.Continuous;
11
    }
12

13
    void Update() {
14
        // 输入检测放 Update——不会丢
15
        if (Input.GetButtonDown("Jump") && IsGrounded()) {
16
            jumpRequested = true;
17
        }
18
    }
19

20
    void FixedUpdate() {
21
        if (jumpRequested) {
22
            // 物理公式：v² = 2gh  → v = sqrt(2gh)
23
            float jumpVelocity = Mathf.Sqrt(2f * Mathf.Abs(Physics.gravity.y) * jumpHeight);
24
            rb.velocity = new Vector3(rb.velocity.x, jumpVelocity, rb.velocity.z);
25
            jumpRequested = false;
26
        }
27
    }
28

29
    private bool IsGrounded() {
30
        float rayLength = 0.2f;
31
        return Physics.Raycast(transform.position, Vector3.down, rayLength);
32
    }
33
}

为什么这个实现是正确的？

输入在 Update —— GetButtonDown 只在按键当帧返回 true，放在 FixedUpdate 会丢失（如果 FixedUpdate 这帧不跑）
物理在 FixedUpdate —— 直接设置 velocity 是物理操作，需要固定步长保证一致性
用物理公式而非经验值 —— sqrt(2gh) 保证了跳跃高度就是 jumpHeight，跟设备帧率无关

示例二：确定性回放系统#

1
// 帧同步的核心理念：相同的输入 + 相同的固定步长 = 相同的结果
2
public class DeterministicReplay {
3
    private const float FIXED_DT = 1f / 60f;
4
    private float accumulator;
5
    private int currentFrame;
6

7
    // 记录每帧的输入（回放文件的内容就是这些）
8
    private List<InputSnapshot> recordedInputs = new List<InputSnapshot>();
9
    private List<InputSnapshot> replayInputs;
10

11
    // 记录所有实体的状态用于校验一致性
12
    private List<EntitySnapshot> entityStates = new List<EntitySnapshot>();
13

14
    public void RecordFrame(float deltaTime) {
15
        accumulator += deltaTime;
16

17
        while (accumulator >= FIXED_DT) {
18
            // 记录这一帧的输入
19
            var input = CaptureInput();
20
            recordedInputs.Add(input);
21

22
            // 用固定步长推进游戏状态
23
            StepSimulation(input, FIXED_DT);
24

25
            accumulator -= FIXED_DT;
26
            currentFrame++;
27
        }
28
    }
29

30
    public void Playback(int targetFrame) {
31
        // 从第 0 帧重新模拟到 targetFrame
32
        ResetSimulation();
33
        for (int i = 0; i <= targetFrame && i < replayInputs.Count; i++) {
34
            StepSimulation(replayInputs[i], FIXED_DT);
35
        }
36
    }
37

38
    private void StepSimulation(InputSnapshot input, float dt) {
39
        // 1. 应用输入
40
        ApplyInput(input);
41

42
        // 2. 更新所有 System（用固定顺序）
43
        MovementSystem.Update(dt);
44
        CombatSystem.Update(dt);
45
        AbilitySystem.Update(dt);
46

47
        // 3. 物理模拟
48
        Physics.Simulate(dt);
49

50
        // 4. 记录状态快照（用于校验一致性）
51
        entityStates.Add(TakeSnapshot());
52

53
        // ⚠️ 关键：不能使用任何非确定性数据
54
        // ❌ Time.time（运行时不固定）
55
        // ❌ Random.Range（除非用确定的随机种子）
56
        // ❌ Physics.Raycast（不同设备可能浮点精度不同）
57
        // ✅ 固定种子随机数
58
        // ✅ 确定性浮点运算（或使用定点数）
59
    }
60
}
61

62
struct InputSnapshot {
63
    public int frame;
64
    public float horizontal;
65
    public float vertical;
66
    public bool jump;
67
    public bool attack;
68
    // ... 所有输入
69
}

1.8 常见坑#

坑一：FixedUpdate 中读 Input#

1
// ❌ GetButtonDown 只在按键"当帧"返回 true
2
void FixedUpdate() {
3
    if (Input.GetButtonDown("Jump")) {  // 如果这帧 FixedUpdate 不跑 → 丢失！
4
        Jump();
5
    }
6
}
7

8
// ✅ 输入检测放 Update，标记位给 FixedUpdate
9
private bool jumpQueued;
10

11
void Update() {
12
    if (Input.GetButtonDown("Jump")) jumpQueued = true;
13
}
14

15
void FixedUpdate() {
16
    if (jumpQueued) {
17
        Jump();
18
        jumpQueued = false;
19
    }
20
}

坑二：协程中没 yield#

1
// ❌ 死循环——卡死主线程
2
IEnumerator BadCoroutine() {
3
    while (health > 0) {
4
        // 没有任何 yield！
5
        TakeDamage(Time.deltaTime * 10);
6
    }
7
}
8

9
// ✅ 每帧执行一次
10
IEnumerator GoodCoroutine() {
11
    while (health > 0) {
12
        TakeDamage(Time.deltaTime * 10);
13
        yield return null;  // 等下一帧
14
    }
15
}

坑三：协程中 WaitForSeconds 受 timeScale 影响#

1
// WaitForSeconds 在 timeScale = 0 时永远不完成
2
IEnumerator ShowDelayedUI() {
3
    yield return new WaitForSeconds(2f);
4
    // 如果在这 2 秒内设置了 timeScale = 0（暂停），
5
    // 这行永远不会执行
6
    uiPanel.SetActive(true);
7
}
8

9
// ✅ 用 WaitForSecondsRealtime
10
IEnumerator ShowDelayedUIRealtime() {
11
    yield return new WaitForSecondsRealtime(2f);
12
    // 即使 timeScale = 0，2 秒后也会执行
13
    uiPanel.SetActive(true);
14
}

坑四：Update 中 Instantiate#

1
// ❌ 每帧 Instantiate——GC Alloc 灾难
2
void Update() {
3
    if (Input.GetKey(KeyCode.Space)) {
4
        Instantiate(bulletPrefab, transform.position, Quaternion.identity);
5
        // 按住空格：每秒 60 次 new + 60 次 GC 压力
6
    }
7
}
8

9
// ✅ 用对象池（设计模式 Ch2）+ 限频
10
[SerializeField] private BulletPool bulletPool;
11
[SerializeField] private float fireRate = 0.1f;
12
private float nextFireTime;
13

14
void Update() {
15
    if (Input.GetKey(KeyCode.Space) && Time.time >= nextFireTime) {
16
        bulletPool.Acquire(transform.position, transform.forward);
17
        nextFireTime = Time.time + fireRate;
18
    }
19
}

坑五：GetComponent 在 Update 中#

1
// ❌ 每帧 GetComponent——每个调用约 0.0001ms，积少成多
2
void Update() {
3
    var animator = GetComponent<Animator>();     // 每帧找一遍
4
    var rb = GetComponent<Rigidbody>();           // 每帧找一遍
5
    animator.SetFloat("Speed", rb.velocity.magnitude);
6
}
7

8
// ✅ Awake 时缓存，Update 直接使用
9
private Animator animator;
10
private Rigidbody rb;
11

12
void Awake() {
13
    animator = GetComponent<Animator>();
14
    rb = GetComponent<Rigidbody>();
15
}
16

17
void Update() {
18
    animator.SetFloat("Speed", rb.velocity.magnitude);  // 零额外开销
19
}

1.9 本章回顾#

概念	一句话	面试怎么答
游戏循环三模型	可变/固定/半固定	Unity 用了半固定——物理固定步长保证确定性，渲染可变步长保持流畅
Update vs FixedUpdate	逻辑 vs 物理	Update 放输入和逻辑（每帧一次），FixedUpdate 放物理（固定步长，可能多次）
deltaTime	让运动与帧率解耦	不加 deltaTime → 高配电脑跑得快，低配跑得慢
timeScale	全局变速器	timeScale = 0 暂停一切依赖 deltaTime 的逻辑，但 unscaledDeltaTime 不受影响
隧道效应	高速穿越	没检测到碰撞因为一帧位移 > 物体厚度 → Continuous 检测模式
死亡螺旋	帧率越慢越卡	FixedUpdate 吃掉 CPU 时间 → 帧率更低 → Unity 的 Max Timestep 兜底

📖 下一章：第二章场景管理与空间划分 —— 四叉树/八叉树、场景流式加载、LOD。当你理解了引擎的心跳（游戏循环），下一步就是理解世界的组织方式。

音乐

音乐

第一章游戏循环与时间管理#

1.1 概念直觉 —— Why & What#

普通应用 vs 游戏#

核心矛盾#

1.2 三种游戏循环模型#

模型一：可变步长（Variable Timestep）#

模型二：固定步长（Fixed Timestep）#

模型三：半固定步长（Semi-Fixed Timestep）—— Unity 的方案#

1.3 Unity 主循环的完整帧分解#

1.4 deltaTime 的精确语义#

四个时间 API 的区别#

timeScale = 0 时谁还在跑#

deltaTime 不加会怎样#

1.5 MonoBehaviour 生命周期全景#

决策速查：逻辑放哪里#

1.6 帧率波动的三个典型问题#

问题一：隧道效应#

问题二：FixedUpdate 的螺旋减速#

问题三：死亡螺旋#

1.7 🎮 完整示例#

示例一：帧率无关的跳跃#

示例二：确定性回放系统#

1.8 常见坑#

坑一：FixedUpdate 中读 Input#

坑二：协程中没 yield#

坑三：协程中 WaitForSeconds 受 timeScale 影响#

坑四：Update 中 Instantiate#

坑五：GetComponent 在 Update 中#

1.9 本章回顾#

文章分享

评论区

音乐

目录

音乐

音乐

第一章 游戏循环与时间管理

第一章 游戏循环与时间管理#

1.1 概念直觉 —— Why & What#

普通应用 vs 游戏#

核心矛盾#

1.2 三种游戏循环模型#

模型一：可变步长（Variable Timestep）#

模型二：固定步长（Fixed Timestep）#

模型三：半固定步长（Semi-Fixed Timestep）—— Unity 的方案#

1.3 Unity 主循环的完整帧分解#

1.4 deltaTime 的精确语义#

四个时间 API 的区别#

timeScale = 0 时谁还在跑#

deltaTime 不加会怎样#

1.5 MonoBehaviour 生命周期全景#

决策速查：逻辑放哪里#

1.6 帧率波动的三个典型问题#

问题一：隧道效应#

问题二：FixedUpdate 的螺旋减速#

问题三：死亡螺旋#

1.7 🎮 完整示例#

示例一：帧率无关的跳跃#

示例二：确定性回放系统#

1.8 常见坑#

坑一：FixedUpdate 中读 Input#

坑二：协程中没 yield#

坑三：协程中 WaitForSeconds 受 timeScale 影响#

坑四：Update 中 Instantiate#

坑五：GetComponent 在 Update 中#

1.9 本章回顾#

文章分享

评论区

音乐

目录

第一章游戏循环与时间管理

第一章游戏循环与时间管理#