如果玩家的屏幕刷新率只有60赫兹，云端却以每秒120帧渲染，多出来的那一半画面从未被任何人看到过。这不是极端例子，而是云游戏里相当常见的浪费：服务端按最高帧率跑，终端按自己的节奏显示，中间的差距就是纯粹的算力消耗。反过来，在另一些场合，60帧和120帧的差别玩家又确实能感觉到。问题不是“帧率高不高”，而是“这一帧有没有机会被玩家的眼睛和手用上”。
从60帧到120帧，到底少了多少时间？
先算一笔基础账。每秒30帧时，两帧之间隔约33.3毫秒；60帧是约16.7毫秒；120帧是约8.3毫秒。从60提到120，单帧间隔只缩短了大约8.4毫秒。这个数字放进云游戏里就要和别的延迟项一起比较：视频编码要几毫秒，网络往返可能是几十毫秒，终端解码和显示还要几毫秒，玩家手指自身的反应时间则是上百毫秒。也就是说，帧率带来的那几毫秒，能不能被感知，取决于它站在整条延迟链的哪个位置。
帧率的价值也分为两种。一种是画面流畅度，即运动是否连贯、快速转动镜头时是否拖影；另一种是输入到画面的响应，即按键后多久看到变化。前者主要影响观感，后者主要影响操作。竞技类射击游戏对两者都敏感，回合制游戏对两者几乎都不敏感，这是预算需要分层的起点。
屏幕不支持时，多渲染的帧去了哪里？
终端的显示能力是第一道闸门。屏幕刷新率是60赫兹，多出来的帧要么被直接丢弃，要么在显示端被合并，玩家看到的仍然是每秒60次更新。更麻烦的是，有些设备在系统层面限制了刷新率，比如省电模式下自动降到较低档，或者外接显示设备实际只支持较低模式。云端如果只看“设备型号支持120赫兹”，就会做出错误判断。因此九游会AI的设计里，帧率预算必须读取终端当前实际生效的刷新率，而不是型号标称值；在连接建立时检测，并在设备状态变化时重新确认。
另一个角度是解码能力。终端能不能在每帧的时间窗口里完成解码，也决定了120帧能否稳定送达。手机连续解码高帧率视频时，发热会逐渐拖低性能，前几分钟流畅、后面开始掉帧，这样的场景要在预算里留出回退空间。设备侧的细节可以参考《手机、电视和高性能电脑玩同一个云游戏，为什么服务器不该给它们同样的画面》。
为什么帧时间的稳定比平均帧率更重要？
平均每秒60帧，并不意味着每一帧都是16.7毫秒。如果一部分帧用了10毫秒，另一部分用了30毫秒，平均值看起来正常，玩家却会感觉到画面在“抖”。这种帧时间抖动（frame-time jitter）对体验的伤害，常常大于把平均帧率下调一档。云端渲染的帧时间本来就有波动：场景变复杂、特效爆发时渲染变慢；编码端遇到剧烈变化的画面也会产生更大的帧；再叠加网络传输的排队，到达终端的间隔就更不均匀。
稳定的每秒60帧，往往比忽高忽低的平均每秒90帧更好用。
所以九游会AI的预算对象不是“一个帧率数字”，而是“目标帧率、可接受的帧时间波动范围、允许降到的下限”这一组约束。预算在下限之内可以浮动，但不能频繁在两个档位间来回切换，因为切换本身就会制造新的节奏变化。
网络抖动会把高帧率的收益吃掉多少？
假设某段网络的延迟在20毫秒到45毫秒之间波动（示例设定），也就是抖动约25毫秒。此时把帧率从60提到120所换来的8毫秒左右，比网络自身的起伏小得多，玩家的实际感受主要由网络抖动决定。为了抵抗抖动，终端往往要加抖动缓冲，缓冲一深，延迟又被推高。这种情况下继续追求高帧率，云端多付出的渲染成本，玩家很难体会到收益；更划算的做法是把帧率保持在稳定的档位，把带宽留给分辨率与码率，先让网络路径稳下来。
这里还有一个常被忽略的细节：帧率和码率并不是线性关系。帧率翻倍，相邻两帧之间的差异变小，编码器可以借助更强的帧间预测，所需码率通常不会同比例翻倍；但每帧能分到的比特变少，画面在剧烈运动时更容易出现块状伪影。所以提高帧率并不是“白拿”的收益，它同样要在带宽预算里付账，九游会App在规划中会把这笔账显示给玩家，让人明白高帧率与高画质之间的取舍。
换一个场景：有线宽带、抖动很小、玩家使用高刷新率显示器并玩竞技射击。这时帧率提升所对应的输入响应改善才可能被感知到，预算值得向高帧率倾斜。可见，同一个120帧，在两个场景里的价值完全不同。
游戏类型、终端和网络怎么组合成一份预算？
下面这张表是示例，用来说明思路，并不是对具体游戏的结论。
| 组合（示例） | 倾向的帧率预算 | 理由 |
|---|---|---|
| 竞技射击 + 高刷新率屏 + 低抖动网络 | 较高，可到120帧 | 输入响应与运动清晰度都能被感知 |
| 竞技射击 + 60赫兹屏 | 60帧，稳定优先 | 屏幕无法显示更多，多余的帧没有价值 |
| 动作冒险 + 手机 + 无线网络 | 30到60帧，跟随网络与发热浮动 | 抖动与发热会抵消高帧率收益 |
| 回合制或策略 + 任意终端 | 30到60帧即可 | 画面变化慢，可把预算让给画质与省电 |
表里的每一行，其实都是一次“先定体验下限，再分预算”的过程。这和《网络只有20Mbps时还渲染最高画质有意义吗》里的思路相通：带宽有限时，帧率、分辨率、渲染质量共享同一个预算池，多给一个就要少给另一个。竞技游戏优先帧率和延迟，可以牺牲一部分纹理细节；解谜或叙事类游戏则相反，宁可保留画质，也不必追求高帧率。
预算被突破时，先让哪一项退让？
当网络恶化或终端发热，预算不够用时，九游会AI计划按一个固定顺序处理，避免临时起意的随机降级：
- 先削减玩家最不容易察觉的部分，比如视觉上不可见的渲染细节和过剩的帧数（超出屏幕能显示的部分）。
- 再在帧率下限之内，降低分辨率或码率，保持画面节奏稳定。
- 最后才触碰帧率下限，并明确告知玩家原因，允许玩家手动改写偏好，比如选择“帧率优先”或“画质优先”。
其中玩家自己的选择始终高于自动判断。喜欢高帧率的玩家可以要求锁定目标，系统需要提示这样做可能带来的代价，而不是悄悄替他改掉。
还有两个问题目前并没有令人满意的答案。第一，玩家对帧率的敏感度存在个体差异，同一款游戏，有人在60帧时毫无不适，有人却明显觉得拖沓，系统如何在不做侵入式测试的前提下了解这种差别；第二，帧率预算的验证需要主观评价，纯靠客观指标很容易高估玩家的感受。这两件事都要靠长期的对照测试来回答，而不是靠一次性的参数表。
