本文不讨论“哪种渲染架构永远更快”。我们只解决一个具体问题：在已有画面和功能约束下，怎样减少中间目标的反复读写，同时把工程成本、画质风险和验证成本控制住。 一、先讲清楚三件事 1. 手机 GPU 是怎么画一帧的 许多移动 GPU 采用分块渲染。它们把画面切成 tile，在片上存储中处理这一块的颜色、深度和混合，适当的时候再把结果写回外存。tile 的大小和具体调度方式由 GPU 与...

实时图形系统遇到 CPU 瓶颈时，最容易想到的办法是增加工作线程：对象筛选放一组任务，实例复制放一组任务，绘制命令再放一组任务。 但线程增加之后，帧时间不一定下降。数据还是那些数据，复制还是那些复制，只是多出了任务提交、临时分配、结果归并和等待。有时还会出现更难解释的问题：偶发的画面闪动、材质修改污染旧帧、场景切换后的迟到回调，以及只在某个线程数量下复现的崩溃。 这些现象提醒我们：在讨论“谁...

一个按钮画出来，并不难。真正困难的是让它始终表现正确。 打开设置页时，角色应该停止接受摇杆输入；关闭弹窗时，最后一次点击不能落到背后的技能按钮；修改一段文字后，布局和实际绘制不能各算一套尺寸；接入矢量动画以后，后续绘制不能莫名其妙地使用错误管线；某一帧被取消后，下一帧还要能正常恢复。 这些问题看起来分散，根源却相似：多个模块对状态、所有权和时间的理解不一致。 UI 从来不只是控件集合。它是...

游戏引擎-帧相位与执行顺序：从约定到可验证契约 一个实时系统可以没有崩溃、没有数据竞争，甚至每个模块的单元测试都通过，却仍然在每一帧里稳定地产生错误。 原因可能非常简单：所有事情都做了，但做事的顺序不对。 先计算最终姿态，再推进动画与物理；先销毁网络对象，再处理携带对象引用的事件；先发布状态，再完成本轮仿真。这些调用在语法上完全合法，局部逻辑也可能各自成立，组合起来却破坏了同一帧的数据关系。...

把一个耗时函数提交给线程池，往往只需要改几行代码。但从这一刻开始，原来隐含在函数调用中的保证，也可能一起消失了。 过去，函数返回意味着它的计算已经完成，下一段代码可以读取结果。现在，提交函数返回，可能只意味着任务进入了队列。调用顺序没有变，数据的生产与消费顺序却已经变了。 帧相位解决“什么工作应该先发生”，JobSystem 解决“工作由谁执行、怎样完成”。两者真正联动的关键，不是给每个阶段...

真正困难的不是让任务跑到另一个线程，而是让每一份并发都有明确的归属、完成条件和退出方式。 引言：线程池解决“谁来做”，架构还要回答“何时算完” 谈起 JobSystem，人们经常从线程池、无锁队列和工作窃取讲起。这些技术很重要，但在一个逐渐复杂的实时应用中，最先失控的往往不是队列算法，而是责任边界。 图像加载器创建两条线程，材质编译器再创建两条，物理库按 CPU 核数创建一组线程...

在移动端优化渲染管线时，经常能看到这样的解释： “普通 Layout Transition 会把 tile 数据写回 DRAM、刷新缓存并清空管线；换成 Subpass 后，只改几个寄存器，数据直接进入 ALU，几乎没有成本。” 这个说法抓住了一个真实机会，却把机会描述成了硬件保证。 真实机会是：一个像素的中间结果，如果只交给后续同位置的片元使用，并且用完就能丢弃，那么驱动可能完全没有必...

渲染管线-Vulkan 间接绘制：GPU 驱动、批量绘制与 Bindless 在传统的图形渲染管线中，CPU 负责每帧计算可见性、调度 LOD、更新常量缓冲并将绘制命令（Draw Call）下发给 GPU。随着场景复杂度的几何级数增长（如数百万个独立 Instance、海量植被与建筑），CPU 端遍历场景树与频繁触发 Draw Call 带来的 API 开销成为了制约渲染性能的最大瓶颈...

后处理-Bloom、色调映射与 TAA：Vulkan 管线与带宽优化 后处理（Post-Processing）是现代 3D 实时渲染管线中连接“三维物理着色”与“二维屏幕呈现”的关键桥梁。在完成场景的 G-Buffer 绘制、光照计算与阴影叠加后，帧缓冲（Frame Buffer）中存储的是处于高动态范围（HDR, High Dynamic Range）下的辐射度数据。后处理阶段负责将...

后处理-SSAO 屏幕空间环境光遮蔽：采样、瑕疵修正与双边滤波 在实时 3D 图形渲染管线中，间接光照（Indirect Illumination）的计算是决定场景空间感与真实感的核心关键。然而，完整求解全局光照（Global Illumination, GI）的渲染方程开销极大。环境光遮蔽（Ambient Occlusion, AO） 作为一个高效的经验/物理近似模型，通过计算贴近表...