5.3 性能监控与热管理

5.3 性能监控与热管理

本节摘要：防线要有人巡逻。本节建立运行时性能仪表盘的最小指标集（帧时间分布、重投影率、温度墙、内存带宽），给出掉帧事故的分层定位流程，并把"热是帧率的慢性税"讲透：降频如何偷走预算、充电与握持如何影响温度、分级画质如何守住底线。

系统防线最后一站从"建设"转到"运维"。前面两节把预算立起来了，但预算只在实验室成立——用户家里夏天没空调、充电时玩、后台挂着下载，每一项都在偷预算。没有监控的热与帧，防线建得再好也是盲飞。本节与前两节的关系：预算是宪法，监控是执法。

最小指标集：仪表盘上只放五块表

指标太多等于没有。给团队的最小集：帧时间分布（不只看平均帧率，尾部指标更诚实——最差的百分之一帧时间决定体验下限）、重投影率（第二章的健康区口径直接复用）、GPU 与 CPU 各自的忙闲占比（区分渲染瓶颈与逻辑瓶颈的第一信号）、设备温度与降频状态（热管理的直接读数）、可用内存与带宽余量（接近上限时系统会开始换页，掉帧随之而来且难以归因）。

五块表都要进运行时采集：开发期接性能分析器细看，发布期以低频采样上报汇总——生产环境里，指标的意义是发现"哪类场景、哪类设备在掉帧"，而不是逐帧诊断。采集纪律：采样本身有开销，运行时指标采集的频率要压到不影响预算的水平，高频诊断只在开发构建启用。

运行时指标采集与告警（伪代码口径）
每秒采样一次：
  p99_frame_ms   ← 最近120帧的第99百分位帧时间
  reprojection   ← 重投影帧占比
  gpu_busy       ← GPU 忙碌占比
  cpu_busy       ← CPU 大核忙碌占比
  soc_temp       ← 芯片温度  throttled ← 是否降频中
告警线（进入观察日志，而非直接杀进程）：
  p99_frame_ms > 帧间隔的1.1倍  或  reprojection > 2%
  或 throttled == true 持续超过10秒
上报：会话结束时汇总，按 场景/设备/画质档 分组
​

掉帧事故的分层定位

事故处理流程讲"分层"：先确认层级，再进层内细查。第一层看现象分布：全场景掉帧还是特定场景？持续还是突发？与特定动作（转头、加载、大范围移动）相关吗？第二层分瓶颈：GPU 忙占比高是渲染瓶颈，转第一、二节与 5.1 的减负清单；CPU 忙占比高是逻辑瓶颈，转 5.1 的物理与脚本瘦身；两者都不忙却掉帧，多为等待类问题（IO 卡顿、换页、同步原语），查资源加载策略与异步管线。第三层验证环境：温度是否已撞墙、是否充电中、后台是否有占用——环境问题改部署策略，不改代码。

演练一例：灰度反馈"玩到后半段越来越卡"。第一层，现象随时间恶化，场景不变——排除场景负载，指向累积类原因。第二层，GPU 与 CPU 都不忙，但换页计数飙升——内存泄漏嫌疑。第三层，定位到每次进入副本重复加载一套材质未释放；修复后复测，后半段帧时间尾部指标恢复。归档要点：这类"时间型掉帧"与"负载型掉帧"的定位路径完全不同，事故单必须记录时间线，否则误入 GPU 减负的死胡同。

热管理：慢性的帧率税

热的因果链：芯片功耗转为热量，结温逼近设计上限时触发降频保护，频率下调直接削减每帧算力——预算在用户手里悄悄缩水。所以热是"慢性的税"：开机前十分钟一切正常，半小时后画质档位实际已经降了两档，用户只觉得"越玩越糊越玩越晕"。

热的三个入口。芯片自热：负载决定，回到预算纪律——持续满载的渲染策略在一体机上等于自缴热税，留有余量的预算才有热余量。环境传热：夏季室温、直晒、被褥里使用（儿童用户常见），环境温度每升几度，撞墙时间显著提前，发布说明与门店提示要写明使用环境。充电入热：边充边玩是热雪上加霜，设备端通常会限流保护，体感即"充电时更卡"，产品策略要么提示充电休息、要么在充电时自动切低功耗档。

💡 关键直觉：热管理的最高境界不是散热更强，而是负载更平。峰值负载决定温度墙高度，把渲染峰（加载瞬间的尖刺）用预加载与流式加载削平，比任何散热贴片都有效。

分级画质：守住底线的自动降级

预案要自动化，不能靠用户手动切档。分级策略的设计原则：先降"不可察"的，再降"可察但不致晕"的，绝不降帧率。第一级：特效类（粒子密度、阴影距离、各向异性过滤）——画质敏感度低；第二级：动态分辨率下限再放宽、注视点外围再降采样——可察但不破坏功能；第三级：可视距离与精简远处物件——体验受损但帧率保住。每一级触发与回落都要带迟滞（降低容易恢复难，避免画质在阈值边缘震荡），且降级事件要上报——某场景频繁触发三级降级，就是该场景超支的铁证，回炉优化。

演练：立一份门店巡检制度

把运维落成制度。某连锁门店反馈"下午体验普遍不如上午"。巡检走五步。第一步拉数据：按小时分组看重投影率与降频标记，下午两点后降频比例明显上升。第二步现场勘察：门店下午西晒，设备位正对阳光，机身温度触顶。第三步短改：调整设备位避开直晒，加遮光帘。第四步制度：巡检清单加入"环境温度、机身温度、设备朝向"三项，每日开班前检查。第五步产品侧：充电策略改为课间统一充电、营业中拔除，发布说明提示使用环境。结论：性能问题的终局常常不在代码里，而在部署环境里——运维与工程同权。

⚠️ 常见坑：只在空调房验收性能。实验室环境是一切热条件的最好组合，交付验收要包含"最差环境组合"（高温、满电充电、连续使用）的加压测试，否则用户手里的体验必然低于演示间的承诺。

巡检与告警的落地模板

把指标与预案落成两份可执行模板。部署侧巡检清单（每日开班前）：环境温度与设备朝向、机身触感温度、充电状态与策略执行、场地光照是否被改造或遮挡。运行侧告警分级（自动触发）：一级告警只记录（重投影率单次越线、短时帧时间尖刺），供周报聚合分析；二级告警进当班日志（连续多秒降频、重投影率持续越线），触发当场降档预案；三级告警暂停会话（持续高温墙、内存见底），保护用户优先于保住时长。两级模板的共同口径：告警必须带上下文（场景、画质档、环境温度），裸数字告警会让值班者无从下手。这套模板在门店与课堂都验证过同一件事：性能运维的价值在"早期发现"，而早期发现的前提是指标有人看、告警有响应路径。

长周期视角：性能债的记账法

最后补一个管理视角。性能债与代码债一样需要记账：每次"先这样，回头优化"的决定都记一笔（场景、超支幅度、承诺的还债时点），随版本发布检查归还情况。性能债的复利比代码债更凶——超支场景往往恰是用户停留最久的场景，债务利息以眩晕投诉的形式支付。给管理层的汇报口径也用账本语言：不是"优化了性能"，而是"帧预算的赤字从多少降到多少、对应量表分数的变化"——用第一章的量化语言谈性能，预算纪律才守得住。

版本对比的固定基准场景

性能数据要有可比性，离不开固定基准场景。做法：锁定一个代表典型负载的场景（中等复杂度、含移动、交互与特效），锁定测试路径与操作脚本，每个版本在相同环境温度下跑一遍，记录帧时间分布、重投影率与温度曲线三组数据。基准场景的意义在于把"这个版本好像更卡了"的感觉变成曲线——回归定位时，基准数据的差值直接指向引入超支的提交。基准的成本很低（半天搭建，每次十分钟），是性能债记账法（前文）的数据来源。给它配一条纪律：基准数据不允许当宣传素材——它是对内的体温计，不是对外的奖状。

本节回收站

• 最小指标集五块表：帧时间尾部、重投影率、双端忙占比、温度降频、内存余量。
• 掉帧定位先分层再细查：现象分布、瓶颈归类、环境验证，"时间型"与"负载型"路径不同。
• 热是慢性的帧率税：撞墙时间由负载、环境、充电三入口共同决定。
• 分级画质三级预案自动执行，先降不可察、绝不降帧率，触发带迟滞。
• 性能验收必须包含最差环境组合，部署环境与工程同权。

至此系统防线闭合：预算、平台、运维三位一体，帧率底线有人守了。下一章把镜头转向网络——当多人共享同一个虚拟世界，延迟与不一致会从另一侧进攻前庭。