← 全部标签
# 性能
7 篇页面
页面
图形学GPU 并行架构GPU Parallel ArchitectureGPU 为吞吐量而设计：芯片大部分面积是成千上万个着色器核心，而不是缓存和控制逻辑。它靠在大量线程组 (warp/wavefront) 之间快速切换来隐藏访存延迟，用 SIMD 让一组线程锁步执行同一条指令。理解占用率和线程分歧，是写出高效着色器的关键。图形学着色频率与材质系统Shading Frequency & Material Systems实现着色时要按"计算频率"划分工作：整个 draw call 不变的放到应用端作为 uniform，其余放在相应的可编程阶段。实践中大多数着色在像素级完成，顶点着色器负责变换和变形。材质系统把面向美术的材质与底层着色器组织起来，处理海量着色器变体的组合问题。游戏开发 · GodotGodot 性能分析与优化Godot Performance先测量再优化：区分持续低帧、尖刺卡顿与加载卡顿。Godot 提供调试器 Profiler、监视器；手段包括减少节点复杂度、MultiMesh、线程安全 API 边界、GPU 合批与 LOD。游戏开发 · UE5移动端渲染优化Mobile Rendering Optimization移动端优化的核心是认清设备的 CPU/GPU 速度、线程、带宽和内存，然后控制最主要的几项开销：Draw Call（官方称其为当前导致图形性能低下的最大因素，在 Galaxy Tab S6 上建议约 700 个，低端设备少于 500 个）、材质复杂度和 overdraw。合并网格和材质（Substance 把多种材质画进同一张纹理，用顶点色作遮罩）是减少 Draw Call 最直接的办法。游戏开发 · UE5蓝图与 C++ 协作Blueprint & C++ InteropEpic 官方建议：多数项目混用蓝图 (Blueprint) 与 C++，以 C++ 作为基础、在其上构建蓝图类。C++ 适合“编程”——定义系统；蓝图适合“脚本”——在已有系统上定义具体行为。两者通过反射说明符互相调用：C++ 用 BlueprintCallable/BlueprintReadWrite 等暴露给蓝图，用 BlueprintImplementableEvent/BlueprintNativeEvent 让蓝图实现或覆盖 C++ 声明的函数。游戏开发字符串与唯一标识符Strings & Unique Identifiers字符串在 C/C++ 中只是字符数组，变长意味着要么硬编码长度上限、要么动态分配；比较和复制都是 O(n)。引擎内部大量用字符串做资源名和对象 ID，处理不当会严重拖慢游戏。GEA 的建议：运行时代码尽量避免字符串类，若用则了解其成本并按引用传递；路径类是值得专门做的例外；对象与资产的唯一标识用哈希字符串 ID（string id），兼得字符串的可读性与整数的比较速度。综合游戏编程模式选型：解耦与性能Choosing Game Programming Patterns本页把《Game Programming Patterns》里的 19 个模式放到同一张取舍图上：大多数模式要么为了解耦（降低改代码时需要装进脑子里的知识量），要么为了性能（利用对数据和硬件的具体假设），而这两个目标经常互相拉扯。下面先讲全书的定位和 Nystrom 的架构观，再给出按问题选模式的路线和与 UE 的对照。