大家好，我是Dan。
我是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

虽然60fps很好，但在90%的GPU上意味着我们没有余地。如果我们推动图形更远，新特性就会溢出并立即丢帧。

Win #1：CPU下降

在解决GPU之前，我们做了一个快速更改：我们取出Amplify Imposters并替换为Unity 6.3中的新自动LOD系统。Amplify是一个伟大的包，但它在我们的场景中并不适用。

结果： 立即将CPU下降到 15–20%。这是一个巨大的胜利。

大搜索：90% GPU瓶颈

我们运行了许多不同的测试来确定GPU瓶颈。以下是我们遵循的确切顺序：

1. 关闭后处理： 没有变化。
2. 设置Render Scale为0.5： 巨大的下降。这立即告诉我们，我们很可能是Fill Rate或像素着色器绑定的。我们通过将帧率从60降至30fps来确认这一点，这会导致类似的GPU负载下降。
3. (STP/FSR的注：我们可以简单地在这里使用上采样，但这只是一个-band-aid。如果我们解决根源，STP/FSR就变得不需要或只是额外的糖衣。)
4. Forward+ vs. Forward： 我们切换到Forward渲染以查看Steam Deck是否在计算操作上卡住。没有变化。
5. “白色材料”测试： 我们将游戏中的每个材料都替换为一个基本的白色材料。这确认了我们是Fill Rate Bound的——这意味着我们在内存带宽、过度绘制或纹理上卡住了。
6. 帧调试器——骚乱的相机： 我们启动了帧调试器并立即发现了一点。一个渲染纹理相机在不该开启时开启，并且保持活动状态。虽然这在我们的设置中影响不大，但这是一个免费的胜利。修复了。
7. 帧调试器——主要的罪魁祸首： 调试器捕捉到了59个绘制调用，它们位于SSAO和Decals之间。Decals在移动硬件上并不是很出色，我们的SSAO设置在URP资产中完全开启了。

结果： 这是第一次我们移动了GPU的针。它从坚定的90%下降到 低70%。

最后的挤压

由于我们有了动力，我们就从其他地方开始削减：

• 光环： 关闭了高质量滤波。我们不需要这种效果。
• 不透明纹理： 把不透明纹理降采样到4x盒。这种替换几乎没有视觉影响（数学结果是大约256k像素降采样到64k）。
• 地形洞： 关闭了。我们甚至不使用Unity地形，但提示说它会加速构建。我对这一点有点疑虑，但为什么不试试呢？
• 光照/反射： 关闭了MainLightShadows、Reflection Probes和Reflection Probe Atlases。我们不需要这些效果来实现我们的场景，并且我们已经关闭了单个灯光上的阴影。

最终结果（优化后）

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构建。

希望这个诊断清单能帮助您在自己的项目中获得一些额外的电池寿命！