第3章：软件工程基础 — 零基础讲义

讲义说明
本讲义基于 Jason Gregory 所著《Game Engine Architecture Volume I》第4版第3章（Fundamentals of Software Engineering for Games, p.93-185），由10年经验游戏引擎工程师执笔，逐节专业翻译、逐步展开推导。
细到 x.x.x 三级章节，零基础读者不必看原书也能完全理解。
本版插画由 ImageGen + Guizang 材质插画标准流程生成。

学习目标

1. 理解 C++ 封装、继承、多态三大特性在游戏引擎中的具体应用
2. 掌握断言、异常、返回值三种错误处理方式的取舍
3. 能画出程序在内存中的四段结构图
4. 理解内存层次结构如何影响游戏性能
5. 明白栈分配比堆分配快 100-1000 倍的根本原因
6. 了解虚函数表、虚拟内存、内存对齐等底层概念
7. 掌握面向数据设计（DOD）的核心思想

3.1 C++ 与面向对象

游戏引擎是大型 C++ 软件系统。Unreal Engine 5 有数千万行 C++ 代码。这一节我们从面向对象三大特性讲起，逐步深入到指针/引用、虚函数表等关键概念。

3.1.1 面向对象三大特性

一句话总览：封装 = 隐藏细节，继承 = 复用代码，多态 = 统一接口不同行为。

3.1.1.1 封装

生活类比：你按遥控器上的音量键。你不知道遥控器内部是红外线发射还是蓝牙信号——你也不在乎。你只关心"声音变大了"。这就是封装：把内部实现隐藏起来，对外只暴露有限的、稳定的接口。

在游戏引擎中：

class Player {
public:
    // ---- 公开接口：其他人只能通过这些函数操作 Player ----
    void TakeDamage(float amount);   // 受伤
    void Heal(float amount);         // 治疗
    float GetHealth() const;         // 查询血量
    bool IsAlive() const;            // 是否存活

private:
    // ---- 私有实现细节：外部代码不能直接访问 ----
    float m_health;                  // 当前血量
    float m_maxHealth;               // 最大血量
    bool m_isInvincible;             // 是否无敌（可能被道具激活）

    // 内部辅助函数，外部不需要知道它的存在
    void ClampHealth() {
        if (m_health < 0.0f) m_health = 0.0f;
        if (m_health > m_maxHealth) m_health = m_maxHealth;
    }
};

外部代码只能通过 TakeDamage()、GetHealth() 等函数与 Player 交互。它们不能直接写 player.m_health = 999999——因为 m_health 是 private 的。

这有什么好处？如果在某个版本中你要把血量计算公式从"减去伤害值"改为"减去伤害值 x 护甲穿透系数"，你只需要修改 TakeDamage() 内部。所有调用者不需要改任何代码——这就是封装的威力：修改内部实现不影响外部调用者。

3.1.1.2 继承

生活类比：你想做一个"带灯的办公椅"。你有普通椅子的设计图（基类）——它有四条腿、一个坐垫、一个靠背。你现在要做的是在它上面加两个零件：灯和电源线。你不用从零画椅子的四条腿——你继承普通椅子，然后添加灯的部件。

游戏引擎的典型继承链：

// 基类：所有"能放在游戏世界里的东西"的共性
class Actor {
public:
    Vector3 m_position;              // 世界坐标
    Vector3 m_rotation;              // 旋转
    Vector3 m_scale;                 // 缩放

    virtual void Tick(float deltaTime) {
        // 每帧被调用一次。基类什么都不做
    }
};

// 派生类：角色（有血量的 Actor）
class Character : public Actor {
public:
    float m_health;
    float m_maxHealth;

    virtual void TakeDamage(float amount) {
        m_health -= amount;
        if (m_health <= 0.0f) Die();
    }

    virtual void Die() {
        // 播放死亡动画、掉落道具等
    }
};

// 进一步派生：玩家角色（有输入控制的 Character）
class PlayerCharacter : public Character {
public:
    void HandleInput(InputInfo input) {
        // 处理键盘/手柄输入
    }

    void Tick(float deltaTime) override {
        // 重写 Tick，每帧检查输入
        HandleInput(GetInput());
        Character::Tick(deltaTime);   // 调用父类的 Tick
    }
};

这个继承链一共三层：Actor → Character → PlayerCharacter。每一层都在上一层的基础上增加新的能力。

如果引擎里要加一个"敌人角色"，你可以继承 Character：

class EnemyCharacter : public Character {
public:
    AIComponent m_ai;                // AI 组件
    void Tick(float deltaTime) override {
        m_ai.Update(deltaTime);      // 更新 AI 逻辑
        Character::Tick(deltaTime);
    }
};

不需要重写血量、受伤、死亡这些逻辑。它们已经写在 Character 里了，EnemyCharacter 直接继承过来就能用。这就是继承的价值：复用代码，避免重复造轮子。

3.1.1.3 多态

生活类比：都叫"播放"——播放 MP3 是音乐响起，播放 DVD 是电影开始，播放黑胶唱片是唱针落下。调用者不需要知道具体是哪种设备——只管说"播放"，设备自己知道怎么做。

游戏引擎中最经典的例子——武器系统：

class Weapon {
public:
    // 纯虚函数 = 所有武器必须实现 Fire()
    virtual void Fire() = 0;
};

class Gun : public Weapon {
public:
    void Fire() override {
        SpawnBullet(m_muzzlePosition, m_barrelDirection);
        PlaySound("gun_shot.wav");
        m_ammo--;
    }
};

class Bow : public Weapon {
public:
    void Fire() override {
        SpawnArrow(m_owner.GetAimDirection());
        PlaySound("bow_release.wav");
        m_energy -= 10.0f;
    }
};

class MagicStaff : public Weapon {
public:
    void Fire() override {
        CastSpell("fireball", m_target);
        PlaySound("magic_fire.wav");
        m_mana -= 30.0f;
    }
};

现在，玩家切换武器时，游戏逻辑只需要这样写：

void PlayerCharacter::FireWeapon() {
    // currentWeapon 可以是 Gun / Bow / MagicStaff 中的任意一种
    // 但这里只需要调用 Fire()——多态机制自动决定调用哪个版本的 Fire
    currentWeapon->Fire();
}

currentWeapon 是一个 Weapon* 类型的指针。它指向 Gun 时调用 Gun::Fire()，指向 Bow 时调用 Bow::Fire()。调用者（FireWeapon()）完全不知道也不关心玩家当前拿的是什么武器。这就是多态的魅力。

3.1.2 指针 vs 引用

一张表讲清楚：

游戏引擎惯例：Unreal Engine 用 UObject* 指针管理所有对象——因为对象可以被销毁、移动、重新创建。引用通常用于函数参数（传递大对象时避免拷贝）。

3.1.3 虚函数与虚函数表（vtable）

多态在底层是怎么实现的？答案是虚函数表（vtable）。

每个有虚函数的类，编译器会为它生成一个隐藏的函数指针数组——这个数组就叫虚函数表（vtable）。

每个对象有一个隐藏的成员变量——vptr（指向自己类的 vtable 的指针）。

// 概念伪代码
Weapon::vtable = {
    &Weapon::Fire   // 纯虚函数 = 0
};

Gun::vtable = {
    &Gun::Fire
};

Bow::vtable = {
    &Bow::Fire
};

当调用 weapon->Fire() 时，底层执行的是：

// 概念伪代码——实际由编译器生成
void CallVirtualFire(Weapon* w) {
    // 第一步：从对象读取 vptr（间接访问 #1）
    VTable* vt = w->vptr;
    // 第二步：从 vtable 中读取 Fire 函数地址（间接访问 #2）
    FunctionPtr func = vt[0];
    // 第三步：跳转到该地址执行
    func(w);
}

三步操作，两次间接内存访问（读 vptr、读 vtable）。而普通函数调用只需要"直接跳转到编译期确定的地址"——一步到位。这就是虚函数比普通函数调用稍微慢一点的原因（大约多 2-10 个 CPU 周期）。

在性能关键的代码中（比如每帧执行几百万次的渲染循环），游戏引擎有时会避免使用虚函数，改用编译期多态（如模板/CRTP 模式）。但对于大多数日常代码，虚函数的性能开销可以忽略不计。

3.2 错误处理与断言

游戏中的错误处理与普通应用软件不同——你可能没有"返回错误页"的选项。本节讲三种错误处理方式及其在游戏引擎中的取舍。

3.2.1 三种错误处理方式

3.2.1.1 返回值检查

File file;
if (!file.Open("config.ini")) {
    // 打开失败——处理错误
    LogError("无法打开配置文件 config.ini");
    return;
}
// 继续执行……

优点：简单、直接、无隐藏开销。
缺点：调用者可能忘记检查返回值。多层调用链中错误被掩盖，定位困难。

3.2.1.2 C++ 异常

try {
    int* hugeArray = new int[1000000000000];
    ProcessArray(hugeArray);
} catch (std::bad_alloc& e) {
    LogError("内存不足：" + string(e.what()));
    GracefulShutdown();
}

优点：异常自动沿调用栈向上传播，不需要每层都检查返回值。
缺点（致命）：游戏引擎几乎全部禁用 C++ 异常。原因：

1. 性能开销：编译器需要生成额外的栈展开代码（unwind tables），增加二进制文件大小。即使在没抛出异常的正常路径中，也有少量性能损失。
2. 不可预测性：异常抛出时的栈展开耗时不确定——可能微秒级，也可能毫秒级。在游戏引擎的 16.7ms 帧预算中，这种不确定性是不可接受的。
3. 最佳实践：Unreal Engine、Unity 等主流引擎都使用编译选项 -fno-exceptions 或 /EHsc- 禁用 C++ 异常。

3.2.1.3 断言（assertion）

void SetPlayerName(const char* name) {
    // 断言：name 不能是空指针
    // 如果 name 是 nullptr，程序立即停止
    assert(name != nullptr && "Player name cannot be null!");

    // 断言通过后才执行实际逻辑
    m_name = name;
}

断言的含义是："这里不应该发生这种情况。如果发生了，说明程序有 bug——停下来让我修。"

断言在 Debug 版本中生效。在 Release 版本中，assert() 被完全编译掉——不产生任何代码。所以断言不影响玩家电脑的运行性能。

3.2.2 断言哲学

生活类比：飞机安检。身份不对立刻拦下，比让问题混进去好得多。

一个完整的断言系统通常包括：

• assert(condition)：基础断言
• verify(condition)：无论 Debug 还是 Release 都生效的断言
• check(condition)：Unreal 自定义的类似 verify 的宏
• ensure(condition)：Unreal 的"软断言"——只记录一次不崩溃

3.3 数据、代码与内存布局

你的程序在内存中长什么样？这是编译器决定的事情，但理解它对写出高性能代码至关重要。

图3-1：程序在内存中的四段结构

3.3.1 四段结构详解

用一个具体例子来理解四段：

// 数据段：程序启动时分配，结束时释放
int g_globalCounter = 0;           // 全局变量 → 数据段(.data)
static float s_pi = 3.14159f;      // 静态变量 → 数据段(.data)

void SomeFunction() {
    // 栈：函数调用时分配，函数返回时释放
    int localVar = 42;              // 局部变量 → 栈
    float array[100];               // 局部数组 → 栈

    // 堆：手动分配，手动释放
    int* heapVar = new int(100);    // new → 堆
    delete heapVar;                 // delete → 从堆释放

    // 代码段：编译时就确定的机器指令
    // SomeFunction 的指令就在代码段中
}

3.3.1.1 代码段（.text）

存储 CPU 要执行的机器指令。只读，编译期固定。生活类比：法律条文——每个人都必须遵守，不能随意修改。

3.3.1.2 数据段（.data / .bss）

存储全局变量和静态变量。程序启动时分配，结束时销毁。生活类比：市政府档案——从城市建立到消亡一直存在。

3.3.1.3 堆（Heap）

存储 new/malloc 动态分配的对象。运行时动态变化，手动管理。生活类比：自由市场——随时可以租摊位（分配），随时可以退租（释放）。

3.3.1.4 栈（Stack）

存储局部变量、函数参数、返回地址。每帧动态变化，自动管理（进入函数压栈、退出函数出栈）。生活类比：临时停车场——后进先出，自动管理。

3.3.2 栈 vs 堆：性能差异

3.3.2.1 栈分配原理

void StackExample() {
    // 栈分配：编译器生成一条指令 "sub rsp, 4"
    // 把栈顶指针（RSP 寄存器）向下移动 4 字节 = 分配完成
    int x = 42;

    // 释放：编译器生成 "add rsp, 4"
    // 栈顶指针移回来 = 释放完成
}

栈分配只需要 1 条指令，约 0.5 纳秒。

3.3.2.2 堆分配原理

void HeapExample() {
    // 堆分配：调用 malloc() → 内部做以下工作
    // ① 在空闲链表中查找大小合适的块
    // ② 如果找到的块比需要的更大，分割成两块
    // ③ 更新空闲链表
    // ④ 返回分配的内存地址
    // ⑤ （可能还需要加锁，防止多线程冲突）
    int* p = new int(42);

    // 堆释放：调用 free() → 内部做以下工作
    // ① 根据指针找到对应的内存块
    // ② 检查块的前后是否有相邻空闲块——合并
    // ③ 更新空闲链表
    delete p;
}

堆分配约 50-200 纳秒，比栈慢 100-400 倍。

3.3.3 实战对比

3.4 计算机硬件基础

图3-2：内存层次结构——越大越慢、越小越快

3.4.1 内存层次结构

这张图是全书最重要的概念之一。不理解它，你写出来的代码可能无形中"很慢"却不知道为什么。

关键数字：

• CPU 主频约 4GHz → 1 个周期 = 0.25 纳秒
• 内存延迟约 100 纳秒 → CPU 要等 400 个周期才能从内存读到一个数据
• 400 个周期中，CPU 理论上可以执行 400 条指令——但它卡在等待数据上

3.4.2 缓存行（Cache Line）

CPU 从内存读取数据时，不是一次只读一个字节，而是读一整条缓存行——通常是 64 字节。

这意味着：你访问 array[0]（4 字节）时，array[1] 到 array[15]（一共 16 个 int 共 64 字节）也被自动加载到了缓存中。下次访问它们时——免费，从缓存秒取。

3.4.3 性能影响：糟糕设计 vs DOD 设计

// 糟糕的设计：4 个数组，数据分散
struct Position { float x, y, z; };
struct Velocity { float vx, vy, vz; };
struct Health { float hp; };
struct Name { char str[32]; };

Position pos[1000];
Velocity vel[1000];
Health hp[1000];
Name name[1000];

// 更新位置：每读一个 pos 就从内存取——大量 cache miss！
for (int i = 0; i < 1000; i++) {
    pos[i].x += vel[i].vx * dt;
}

// 优秀的设计：DOD（面向数据设计）
struct Entity {
    float x, y, z;      // 位置
    float vx, vy, vz;    // 速度
    float hp;
    char name[32];
};
Entity entities[1000];

// 更新位置：读 entities[0] 时，整个结构体加载到缓存
// 读 entities[1] 时，它已经在缓存里——几乎全部 cache hit！
for (int i = 0; i < 1000; i++) {
    entities[i].x += entities[i].vx * dt;
}

第一个版本：每次迭代 ~100ns，1000 次 = 100μs。
第二个版本：每次迭代 ~1ns，1000 次 = 1μs。
差距 100 倍。

这就是著名的"面向数据设计"（Data-Oriented Design, DOD）的核心思想：根据数据的访问模式来组织数据在内存中的布局。

3.5 内存架构

3.5.1 虚拟内存

操作系统给每个程序一个"假象"——每个程序都以为自己占用了整个内存空间（32 位 = 4GB，64 位更大）。实际上，物理内存被多个程序共享。

操作系统通过页表（Page Table）把程序使用的"虚拟地址"翻译成真正的"物理地址"：

// 程序看到的地址（虚拟地址）：0x00400000
// 经过页表翻译后的真正位置（物理地址）：0x7F3B_4000
// 两个地址完全不同！程序不知道也不关心真实位置

虚拟内存的好处：

1. 隔离性：程序 A 不能访问程序 B 的内存
2. 简化编程：每个程序有"连续"的地址空间
3. 交换（Swapping）：不常用的内存页可被换到磁盘上

3.5.2 内存对齐

CPU 在读取内存时，对地址有对齐要求：

• int（4 字节）应该从 4 的倍数地址开始
• short（2 字节）应该从 2 的倍数地址开始
• double（8 字节）应该从 8 的倍数地址开始

如果不对齐会怎样？

struct BadLayout {
    char a;         // 1 字节（假设在偏移 0）
    int b;          // 4 字节（被填充推到偏移 4）
    short c;        // 2 字节（偏移 8）
};
// sizeof(BadLayout) = 12 字节（不是 1+4+2=7！多了 3 字节 padding）

优化版本：

struct GoodLayout {
    int b;          // 4 字节（偏移 0）
    short c;        // 2 字节（偏移 4）
    char a;         // 1 字节（偏移 6）
};
// sizeof(GoodLayout) = 8 字节 ✓

3.5.3 内存优化策略

游戏引擎中的内存优化常用手段：

• 对象池：预分配固定大小对象数组，用完放回池中复用
• 内存映射文件：把磁盘文件直接映射到内存，避免 read/write 调用
• 预分配：加载关卡时一次性分配好所有需要的内存
• NUMA-aware 分配：在多核 CPU 中，优先从本地内存节点分配

本章核心洞察

📝 课后练习题（含答案）

点击每题展开答案——先自己思考再看解答：

高地址
+------------------+  ← 栈顶（向下增长）
|      栈（Stack）        |  局部变量、函数参数、返回地址
|        ↓                |  自动管理，LIFO
|                          |
|        ↑                |
|      堆（Heap）         |  new/malloc 动态分配，手动管理
+------------------------+
|    数据段（.data）       |  有初始值的全局/静态变量
|    数据段（.bss）        |  零初始化的全局/静态变量
+------------------------+
|    代码段（.text）       |  机器指令，只读，编译期固定
低地址 +------------------+

struct Example {    // 原始布局
    bool flag;      // 偏移 0，1 字节
                    // [padding 7 字节，因为 double 需要 8 字节对齐]
    double value;   // 偏移 8，8 字节
    int count;      // 偏移 16，4 字节
    short id;       // 偏移 20，2 字节
                    // [padding 2 字节，让 sizeof 是 8 的倍数]
};                  // sizeof = 24

struct ExampleOpt {
    double value;   // 8 字节，偏移 0
    int count;      // 4 字节，偏移 8
    short id;       // 2 字节，偏移 12
    bool flag;      // 1 字节，偏移 14
                    // [padding 1 字节]
};                  // sizeof = 16 ✓（节省 8 字节）

🤖 qAagent 零基础问答区