25、实战案例三：游戏引擎模块重构 - 性能优化与可扩展性提升

游戏引擎这东西，说白了就是一套「让游戏跑起来」的基础设施。我见过不少团队，一开始图快，把渲染、物理、音频、输入全揉在一个大模块里。结果呢？项目到中期，改一个物理参数要重启整个引擎，加一个新特效要动核心代码。

今天这个案例，就是我从一个中型手游项目里提炼出来的。当时帧率卡在 25fps 上下，玩家都在骂。我接手后做了一次模块化重构，把帧率拉到了 58fps，顺便让后续加功能变得轻松很多。

问题诊断：为什么卡？

先说说当时的状况。引擎核心模块大概长这样：

class GameEngine {
    update() {
        this.processInput();      // 处理输入
        this.updatePhysics();     // 更新物理
        this.updateAI();          // AI 逻辑
        this.renderFrame();       // 渲染
        this.playAudio();         // 播放音频
    }
}

看起来挺整齐对吧？但问题在于：所有模块都在同一个线程里串行执行。物理计算卡住了，渲染就得等着。AI 逻辑跑慢了，音频也跟着延迟。

我做了个性能分析，发现几个关键瓶颈：

模块	耗时占比	问题描述
物理更新	38%	碰撞检测全量遍历，O(n²) 复杂度
渲染	32%	每帧重建顶点缓冲区，未使用对象池
AI 逻辑	18%	路径搜索重复计算，无缓存
音频	12%	解码与播放耦合，阻塞主线程

嗯，这里要注意：串行架构下，任何一个模块的抖动都会拖累全局。我当时跟团队说，咱们得把「大泥球」拆成「乐高积木」。

重构方案：模块化 + 异步化

核心思路就两条：

1. 模块解耦：每个模块独立成类，通过事件总线通信
2. 异步调度：非关键模块丢到工作线程，主线程只做渲染和输入

重构后的架构图如下：

你想想看，物理和 AI 这些计算密集型任务，完全没必要跟渲染抢主线程。我个人习惯把这类模块设计成「可插拔」的——想换物理引擎？直接换一个实现类就行，不用动其他代码。

关键重构点：物理模块

物理模块是性能大头。原来的碰撞检测是这么写的：

// 重构前：全量遍历
for (let i = 0; i < objects.length; i++) {
    for (let j = i + 1; j < objects.length; j++) {
        if (checkCollision(objects[i], objects[j])) {
            resolveCollision(objects[i], objects[j]);
        }
    }
}

1000 个物体就要做 50 万次检测。我改成空间哈希后：

// 重构后：空间哈希 + 惰性更新
class SpatialHash {
    constructor(cellSize) {
        this.cellSize = cellSize;
        this.grid = new Map();
        this.dirty = true;
    }

    insert(obj) {
        const cellX = Math.floor(obj.x / this.cellSize);
        const cellY = Math.floor(obj.y / this.cellSize);
        const key = `${cellX},${cellY}`;
        if (!this.grid.has(key)) this.grid.set(key, []);
        this.grid.get(key).push(obj);
        this.dirty = true;
    }

    getNearby(obj) {
        const cellX = Math.floor(obj.x / this.cellSize);
        const cellY = Math.floor(obj.y / this.cellSize);
        const result = [];
        for (let dx = -1; dx <= 1; dx++) {
            for (let dy = -1; dy <= 1; dy++) {
                const key = `${cellX + dx},${cellY + dy}`;
                if (this.grid.has(key)) {
                    result.push(...this.grid.get(key));
                }
            }
        }
        return result;
    }
}

效果很明显：检测量从 O(n²) 降到了 O(n)。1000 个物体时，每帧碰撞检测从 8ms 降到了 0.3ms。

避坑指南：异步化的陷阱

我曾经在另一个项目里吃过亏。当时把物理丢到工作线程，结果主线程读取物理数据时没加锁，导致角色「瞬移」——位置数据读到一半被线程更新了。

解决方案是：共享数据用双缓冲 + 读写锁。物理线程写「后台缓冲区」，主线程读「前台缓冲区」，每帧交换一次指针。这样既不用加锁，又保证数据一致性。

class DoubleBuffer {
    constructor() {
        this.front = new Float32Array(1024);
        this.back = new Float32Array(1024);
    }

    swap() {
        [this.front, this.back] = [this.back, this.front];
    }

    // 物理线程调用
    writeBack(index, value) {
        this.back[index] = value;
    }

    // 主线程调用
    readFront(index) {
        return this.front[index];
    }
}

可扩展性：插件式模块注册

重构后，加一个新模块变得很简单。我设计了一个注册机制：

class EngineModule {
    constructor(name) {
        this.name = name;
        this.priority = 0;  // 优先级，决定执行顺序
    }

    async init() { /* 子类实现 */ }
    async update(deltaTime) { /* 子类实现 */ }
    async shutdown() { /* 子类实现 */ }
}

class Engine {
    constructor() {
        this.modules = new Map();
        this.eventBus = new EventBus();
    }

    registerModule(module) {
        this.modules.set(module.name, module);
        // 按优先级排序
        this.moduleList = [...this.modules.values()]
            .sort((a, b) => b.priority - a.priority);
    }

    async update(deltaTime) {
        // 主线程只处理高优先级模块
        for (const mod of this.moduleList) {
            if (mod.priority > 0) {
                await mod.update(deltaTime);
            }
        }
    }
}

想加一个天气系统？写个类继承 EngineModule，注册进去就行。不需要改引擎核心代码。这就是我说的「乐高积木」式架构。

总结

这次重构给我最大的感触是：性能优化和可扩展性不是矛盾的。把模块拆清楚，性能瓶颈自然就暴露出来了；把通信机制设计好，加功能就不再是噩梦。

嗯，最后说一句：别等到项目快上线了才想起重构。那时候改一个变量都心惊胆战，更别说动架构了。

---

公众号:蓝海资料掘金营，微信deep3321