美术与性能取舍

先把题目说成人话

一场雨战既要让玩家看清敌人、感到风暴很重，也要在目标设备上稳定运行；这些要求彼此牵扯，谁也不能只凭职位拍板。先把“绝不能丢”的战斗信息和氛围讲清，再把每个方案会牺牲什么、节省什么放在同一条件下比较。这就是有证据的取舍（Trade-off）：不是争论谁赢，而是一起决定哪份代价值得付。

这是虚构教学故事，不是个人项目经历。

场景：先让问题变得看得见

移动副本里有浓雾、两层贴地水汽和技能粒子。策划必须让远处攻击预警清楚，美术必须保住湿冷气氛和首领轮廓，程序必须让中端手机按时出帧。全关雾确实会变快，却让空间层次一起消失。

真正冲突不是“雾要不要”，而是哪一层画面承担了可读性和气氛，哪一层只是在重复盖住同一批像素。

（右脑）画面： 三方站在同一张白板前。策划用红圈标出远处攻击提示，美术用蓝圈标出必须保留的湿冷空气和首领外形，程序在角落画出每一帧不能越过的时间线；雾、水汽、粒子和阴影被写成可以逐项调整的成本。团队先做一个“全关”版本确认大致嫌疑，再沿同一版本链每次只减一层，所有人都看同一段战斗。只有战斗提示仍清楚、气氛和轮廓仍成立、长时间运行也没有越过预算，三道签字才把候选变成成功方案；缺任何一道，它都只是调查证据。

（左脑）对表： 为了不让平均值把偶发卡顿藏起来，先把 300 秒里每一帧的耗时从快到慢排队，站在 95% 位置的那一帧就是 P95。大约 95% 的帧不比它更慢，但最慢的 5% 仍可能更糟。随后固定中端 Android、质量档、预热和同一条 BOSS 战路线；60 FPS 对应约 16.7 ms，基线 CPU P95 为 10.4 ms、GPU P95 为 28.0 ms。性能分析器（Unity Profiler）负责阶段计时，帧调试器（Frame Debugger）把阶段对应到雾、水汽和粒子绘制，真机并排画面分别交给策划与美术验收。全关雾只证明这条链路值得查；后续按版本号每次改一个变量，记录同一窗口的 P95，再对合并版本跑热稳态与 Player Frame Time，才能形成共同决策。

小明：先形成一个完整猜测

小明提出关掉全部雾。GPU 进入预算，攻击预警也清楚了，但场景空间层次和湿冷气氛一起消失。这个方案证明雾相关工作占了重要成本，却没有同时满足已经约定的画面目标，因此只能作为诊断对照，不能直接上线。

小红：把猜测放回现实检查

小红先让三方确认同一组验收镜头，再按顺序提交单变量版本。教学捕获中的 GPU P95 依次为：基线 28.0 ms；体积雾改为半分辨率后 21.0 ms；在这个版本上把两层水汽减为一层后 18.7 ms；再收紧粒子贴片空白并缩短不可见长尾后 16.2 ms。

这些是同一条顺序构建链的重新测量，不是把三个独立实验的“节省值”相加。最终 CPU P95 仍为约 10.4 ms，GPU P95 为 16.2 ms，两端都低于 16.7 ms；还要检查帧调度与长时间发热，不能只看一次短捕获。

我：用检查结果修正模型

我把结果整理成一个已完成验证的方案，以及一个仍在假设栏的后备。方案 A 使用半分辨率雾、一层水汽和收边粒子，300 秒路线的 GPU P95 为 16.2 ms；随后连续运行 20 分钟，再取同一条 300 秒路线，GPU P95 为 16.5 ms、Player Frame Time P95 为 16.6 ms，均低于 16.7 ms。美术确认仍保有雾层和 BOSS 轮廓，策划确认远处预警没有损失，程序确认热稳态门禁通过，三方签字后方案 A 才成为这则虚构故事里的成功落地。方案 B 设想保留双层水汽、进一步缩短阴影距离，但没有同条件合并数据，仍不能宣称进入预算。最终决定与回滚条件写进版本记录。

这才是“说服”的实际含义：不是话术压过别人，而是先承认各方目标，再让可复现证据产生可选方案。本页不能代替本人的真实经历；成功案例必须换成自己的会议结论、A/B 构建、职责和真机数据。

（右脑）画面修正： 小明全关雾后 GPU 进入预算，却丢掉湿冷氛围，因此这个版本只能证明雾链路昂贵，不能上线。小红沿同一条顺序构建链复测：基线 28.0 ms，半分辨率雾后 21.0 ms，减为一层水汽后 18.7 ms，收紧粒子空白与长尾后 16.2 ms；这些是逐版本结果，不是把独立节省值相加。方案 A 又通过 20 分钟热稳态与三方画面验收，故事才真正收口；没有同条件合并数据的方案 B 仍留在假设栏，不能与证据完整的方案 A 并列宣称成功。

（左脑）严格对表： 决策记录先固定设备、路线、16.7 ms门禁和三方画面要求；对每个候选建立版本号，只在前一版本上改一个变量并重新测CPU/GPU P95；合并候选再跑热稳态与长帧门禁，并由美术验氛围、策划验预警、程序验性能。发布条件、责任人和回滚阈值写入版本记录；个人案例只能引用本人组织或实现的证据，团队选择与他人贡献分别归属，不把“说服”写成可背话术。

老师解惑

• 先定义共同验收条件：目标设备、镜头、帧预算、画面重点和制作截止时间。
• 诊断用的“全关版本”可以证明成本范围，但不自动成为最终方案。
• 单项变化应顺序记录；最终方案必须整体重测，因为效果之间会相互影响。
• 决策记录要写清谁验收什么、为什么选、何时回滚，避免下次迭代重新争论。

工具分工

• Unity Profiler 与 GPU 捕获：把性能争议落到同一设备、同一路线和 P95 数据。
• Frame Debugger/Overdraw 视图：确认雾、水汽和粒子实际覆盖了什么；不拿它们冒充计时器。
• A/B 真机构建：让美术和策划看到方案的真实画面，而不是看口头描述。
• 决策与版本记录：保存责任人、验收结论、数据和回滚条件。

记忆钩子

先把“必须看见什么”说清，再把每个方案的画面与毫秒摆在一起；团队选择证据，不选择立场。