📚 课程目录第2章模块化渲染架构简介

模块化渲染架构：如何拆解与解耦

说实话，我第一次接触渲染引擎时，满脑子都是“怎么这么多代码堆在一起”。那个项目号称是轻量级渲染器，结果光一个 Renderer.cpp 就三千多行，改个阴影参数得同时动五个文件。后来我才意识到——模块化不是炫技，是保命。

这一章我们就聊清楚一件事：渲染系统应该切成几块？块与块之间怎么断开连接？ 我按自己在几个项目里的踩坑经验，给你画出这张“分家谱”。

为什么必须拆模块？

你先想一个问题：你写的渲染代码，有没有试过改一个光照模型，结果把后处理特效搞崩了？我在一个游戏引擎项目里就经历过。当时没拆模块，光影和后期用的是同一个全局变量池。项目经理催得急，我图省事，随手加了个“临时方案”——嗯，后面花了两周重构。

我的原则：一个模块只做一件事，做好就锁死接口。你不拆开，测试和调优就是噩梦。

核心模块划分

通常来说，一个模块化渲染架构至少包含这五大块。我习惯按数据流方向来分，从上往下看更清晰。

模块名称	职责	典型类	解耦方式
场景管理	组织物体、灯光、相机数据	`SceneGraph`	只输出纯数据结构，不调用任何渲染 API
资源管理	加载、缓存、卸载纹理/网格/材质	`ResourceManager`	接口：`Load()` / `Get()`，内部线程安全
渲染核心	驱动 GPU 绘制管线，生成 draw calls	`RenderCore`	通过命令缓冲区（command buffer）接收指令
特效/后处理	Bloom、SSAO、抗锯齿等滤镜	`PostEffectStack`	挂载到 RenderGraph 的 pass 中，完全可插拔
工具/调试层	性能统计、截帧、标记高亮	`DebugOverlay`	仅编译期宏开关，不影响 Release 包

你看，这五个模块各干各的，谁也不占谁的变量。我曾经有个同事非要把场景遍历和 GPU 打包写在一起，结果加个阴影图就得改整个循环。后来被我拿着这份表格拉着他重构——再也没出过类似问题。

解耦的关键：接口即契约

模块分好了，怎么让它们不藕断丝连？秘诀就是把接口当成合同。我习惯在每个模块目录下放一个 Interfaces.h，里面只声明纯虚类或函数签名。

警告：不要用友元类，不要用 extern 全局变量。我在项目里看到过有人为了省事写了一个 extern RenderState g_state，结果测试时模块一替换就崩。这种写法，谁用谁后悔。

// 示例：渲染核心的接口定义
class IRenderCore {
public:
    virtual ~IRenderCore() = default;
    virtual void Draw(const DrawCmd& cmd) = 0;
    virtual void SubmitFrame() = 0;
    virtual void SetViewport(int x, int y, int w, int h) = 0;
};

// 场景管理模块只持有 IRenderCore*，不关心具体实现
class SceneRenderer {
    IRenderCore* m_RenderCore;
public:
    void Init(IRenderCore* core);
};

这样做的好处是，你可以轻易切换底层实现——比如从 OpenGL 换成 Vulkan，只需要写一个新的 VulkanRenderCore 类，场景管理那边一行代码都不用动。我跟你说，这种设计在跨平台项目里特别香。

解耦层次图解

为了让你一眼看明白，我画了张拓扑图。注意看，所有箭头都从上层指向下层，底层模块绝不反向依赖上层。

这根主线很清楚：应用层 → 场景/资源管理 → 渲染核心接口 → 具体 GPU 实现 → 后处理 → 调试。每一层只和紧邻的下一层通过窄接口通信。虚线箭头表示，“我可以换掉你这个实现，不影响上面的人”。

解耦的具体技巧

依赖注入：不要在模块内部 new 东西。我通常写一个 ModuleContext，外部统一构建好传进去。

// 不好
class SceneManager {
    ResourceManager m_Res;  // 内部 new，无法替换
};

// 好
class SceneManager {
    ResourceManager* m_Res;
    SceneManager(ResourceManager* res) : m_Res(res) {}
};

事件回调代替直接调用：比如场景物体被删除，不需要遍历所有系统，发一个 SceneEvent::ObjectRemoved，谁关心谁订阅。我用 std::function 加一个 EventBus 就能搞定。
数据驱动配置：后处理开启哪些效果，写在 JSON 里，模块启动时解析。不要写死 if-else。我踩过这坑——客户要换效果组合，改代码再编译，累死人。

避坑指南：我犯过的三个错误

  曾经我 把纹理加载直接写在渲染循环里，结果换 API 时每个纹理创建都要重写。后来抽成 IGraphicsResourceFactory 接口，改一行初始化代码就行。
曾经我 让后处理模块直接调用场景模块的 GetCamera 方法，结果场景模块一重构，后处理崩了两周。后来全改成通过 RenderGraph 传递结构体，不持有指针。
曾经我 图省事把调试标记和 Release 代码写在一起，上线前忘记关宏，导致性能掉了 5%。从此我强制所有调试层用 #ifdef DEBUG 包裹，接口在 Release 里直接展开为空函数。

小结：模块化给你带来什么？

说白了，模块化就是用前期的一点设计时间，换后期无限的改代码自由。我这些年带团队，最舒坦的项目都是能“拔掉一个模块换另一个”的架构。你想想看，测试的时候 mock 一个渲染核心，单元测试跑得飞快；性能优化时只改 GPU 驱动层，上面完全不受影响——这才是手艺活该有的样子。

好了，架构层讲完了，接下来你就能拿着这份“分家谱”去设计你的基准测试框架了。