GPU > 80% 卡顿量化方法论

把“性能差”“感觉卡”转成团队能共同执行的红线：GPU 占用超过 80% 时，卡顿风险明显上升。

GPU 红线< 80%

卡顿样本250-400ms

治理目标可量化验收

背景

6.0.0 路测阶段，一张图出现明显性能问题：GPU 占用超过 95%，帧率只有 45-50fps，卡顿时长达到 250-400ms。这个阶段最大的难点不是“知道它卡”，而是团队很难围绕主观体验排优先级。

性能治理需要一个所有人都能理解的工程语言：什么时候算危险，优化先看哪里，验收以什么为准。

问题

症状	原始表达	工程化缺口
帧率下降	体验不流畅	缺帧率和卡顿关联
GPU 高占用	看起来满载	缺可执行阈值
多模块抢资源	不知道先关哪里	缺模块级占比

如果没有量化标准，性能优化容易变成“谁声音大先改谁”，也无法向产品解释为什么要牺牲某些视觉效果。

方法

第一轮：识别问题

先用路测数据把问题从体验描述转成可测量指标。

指标	实测	初始目标
GPU 占用	> 95%	降低峰值
帧率	45-50fps	接近 60fps
卡顿	250-400ms	< 100ms

第二轮：拆模块

围绕 GPU 时间做模块级占比量化，重点检查高开销渲染项。典型发现是 SR/LD 的 fxaa 与 msaa 叠加，抗锯齿成本被重复支付。

第三轮：建立红线

通过两轮路测对比，得到可沟通的结论：

• GPU < 80%：整体流畅。
• GPU 80-90%：偶发卡顿风险上升。
• GPU > 90%：明显卡顿。

因此团队红线被定义为：GPU 占用必须控制在 80% 以下。

决策

性能治理不只做技术优化，也包括产品取舍。大屏帧率从 60fps 调整到 40fps，是一次典型的工程决策：视觉上可接受，但能显著降低 GPU 压力，为稳定性争取余量。

GC 与容器治理

飞书性能资料里还有一条和 GPU 并行的线索：高频容器使用不当会制造大量 GC。公开版本不展示内部实现细节，只保留工程原则。

问题	风险	治理方向
动态扩容策略不明确	高频场景产生不可控分配	预估容量，扩容规则显式化
Get 访问策略混乱	读写边界不清，容易隐藏拷贝成本	定义只读、可写、越界语义
高频 New 对象	GC 峰值叠加渲染压力	对象池化，生命周期统一回收
容器散落业务侧	优化无法收敛成框架能力	强制收口到框架容器或公共工具

这条线的价值在于提醒：性能治理不能只盯 GPU。渲染卡顿经常是 GPU、主线程、GC、日志和 I/O 一起叠加出来的结果。GPU 红线负责“外部体验阈值”，容器与对象池负责“内部成本治理”。

诊断闭环

路测现象
  -> GPU / 帧率 / 卡顿采样
  -> 模块级占比排序
  -> GC / 日志 / 线程补充排查
  -> 技术优化 + 产品取舍
  -> 复测与发布红线

产出

• GPU 80% 红线。
• 按模块 GPU 占比排序的性能 TODO。
• 路测数据和优化方向说明。
• 后续监控链路的指标口径。
• StructArray / 高频对象分配治理清单。

可复用方法论

1. 先把主观体验翻译成指标。
2. 指标要能驱动优先级，而不只是记录现象。
3. GPU、GC、线程和日志要放在同一张成本账里。
4. 性能优化要同时准备技术方案和产品取舍。
5. 阈值一旦成立，就要进入监控、复盘和发布标准。

复盘

这次方法论的价值在于把性能优化从“临场救火”推进到“红线治理”。飞书资料补入后，页面不再只讲 GPU，还把 GC、容器扩容和对象池化纳入同一套发布质量语言。下一轮应补充模块级占比图、路测记录和优化前后对比图，脱敏后放入站点。