大家好，我是丹。
我是Spooker的技术负责人，我们目前正在努力获得Steam Deck认证标签，并且在过去几天里花了大量时间优化游戏。

我想分享我们优化过程中所采取的具体步骤和步骤，希望这能帮助你们优化自己的原生Linux游戏！

基线（优化前）

为了给你们一个参考，我们从一开始就非常重视游戏的性能。我们使用Addressables进行手动内存加载和卸载，使用mipmap流式传输文本，并且对代码进行了严格的审查。我们避免使用重复循环，而是使用R3和VContainer进行注入，结合零分配库如UniTask来降低内存占用。

尽管我们已经做了这些，Steam Deck（64GB LCD）仍然表现如下：

• FPS： 稳定60帧
• GPU： 90%（1520MHz）
• CPU： 40%（1949MHz）
• VRAM： 2.9 GB
• RAM： 6.9 GB

虽然60帧的性能很好，但GPU的90%占用率意味着我们完全没有余地。如果我们推动图形更高，新功能会立即降低帧率。

Win #1：CPU降低

在解决GPU问题之前，我们做了一个简单的改变：我们移除了Amplify Imposters，并使用Unity 6.3中的新自动LOD系统代替。Amplify是一个很好的包，但它并不是我们所需的。

结果： CPU占用率从40%降低到15–20%。这是一个非常大的胜利。

大搜索：解决90%GPU瓶颈

我们进行了一系列不同的测试，以确定GPU瓶颈的具体位置。以下是我们所采取的具体步骤：

1. 关闭后处理： 没有效果。
2. 设置渲染比例为0.5： 巨大的降低。这告诉我们我们很可能是Fill Rate或像素着色器绑定的。我们通过限制帧率从60到30帧来确认这一点，这导致了类似的GPU负载降低。
3. （注：STP/FSR）我们可以简单地将上采样添加到这里，但这只是一种暂时的解决方案。如果我们解决了根源问题，STP/FSR就变得多余了。
4. Forward+ vs. Forward： 我们切换到Forward渲染，以查看Steam Deck是否在计算操作上卡住。没有效果。
5. “白色材料”测试： 我们将游戏中的每个材料都替换为一个基本的白色材料。这确认了我们是Fill Rate Bound——这意味着我们卡住在内存带宽、重绘或纹理上。
6. 帧调试器——骇人听闻的摄像头： 我们启动了帧调试器，立即发现了一个问题：一个渲染纹理摄像头在不该开启的情况下开启了。虽然它的影响相对较小，但这是一个免费的胜利。我们修复了它。
7. 帧调试器——主要罪魁祸首： 调试器捕获了59个绘制调用，位于SSAO和Decals之间。Decals在移动设备上并不理想，我们的SSAO设置在URP资产中被设置为最大值。
8. 解决方案： 我们完全禁用了Decals（我们并不需要它们，后面会用四边形/球体着色器代替）。然后，我们对SSAO设置进行了激进的优化，直到达到我们所需的视觉风格。

结果： 这第一次移动了GPU的指针，从90%降低到低70%。

最后的挤压

由于我们已经取得了进展，我们继续在其他地方进行优化：

• 光环： 关闭了高质量滤波。我们并不需要它来实现我们的风格。
• 不透明纹理： 将不透明纹理的分辨率降低到4x箱。这个改进带来了极小的视觉影响（数学计算结果约为256k像素降低到64k）。
• 地形洞： 关闭了地形洞。我们并不使用Unity地形，但提示声称它会加速构建。虽然我对此有些怀疑，但为什么不试试呢？
• 光照/反射： 关闭了主光源阴影、反射探针和反射探针图集。我们并不需要这些来实现我们的场景，并且我们已经禁用了单独光源的阴影。

最终结果（优化后）

以下是Steam Deck的当前状态：

• FPS： 仍然稳定60帧
• GPU： 舒适的55% – 70%（在一个更低的830MHz下）
• CPU： 15% – 20%
• VRAM： 2.4 GB（下降0.5 GB）
• RAM： 6.4 GB（下降0.5 GB）

最好的部分： Steam Deck的电池续航时间从约2小时增加到4.5小时。

总的来说，我们非常满意这样的结果。花费时间来解决瓶颈而不是简单地加上FSR，给我们带来了巨大的热效率和续航时间的提高。请注意，我们并没有使用Proton，而是选择了原生Linux构建。

希望这份诊断清单能帮助你们在自己的项目中获得一些额外的电池续航时间！