Qingswe
1096 words
5 minutes
发布前优化
为什么发布前还要单独做一轮优化
开发中做过很多局部优化，不等于发布前已经达标。真正临近上线时，需要把“局部问题”收敛成“版本是否可交付”的结果：帧率稳不稳、内存会不会爆、包体是否超线、发热和耗电能否接受。
【重点】发布前优化不是再做一次大而全的技术研究，而是把版本风险按优先级收口，优先清掉会影响上线和回归的硬问题。
先固定验收条件
发布前测试最怕“每次条件都不一样”，所以第一步不是调代码，而是锁定基准：
- 设备矩阵：至少覆盖低中高档目标机型
- 测试场景：主城、战斗、加载、长时间挂机、切后台恢复等高风险路径
- 画质档位：和实际上线配置一致
- 构建方式：尽量接近 Release，只保留必要的分析开关
发布前性能检查清单
1. 帧率与帧时间
- 是否稳定达到目标帧率
- 峰值帧时间是否集中在少数可解释场景
- CPU 或 GPU 谁是主要瓶颈，是否有明显 GC、加载、Shader 编译尖刺
2. 内存与资源峰值
- 常驻内存是否在设备安全线内
- 关卡切换、长时间游玩后是否只增不降
- 纹理、Mesh、音频、托管堆是否有异常峰值
- 首次进入核心场景时是否发生大批资源同步加载
3. 包体与首包资源
- 是否有明显可剔除的冗余资源、重复贴图、未引用 Shader 变体
- 首包是否过大，首次下载和安装体验是否可接受
- 热更新或分包策略是否和当前资源组织一致
4. 发热与耗电
- 连续游玩 10 到 30 分钟后帧率是否下降
- 设备是否出现明显发烫、降频、续航异常
- 高画质档是否应该限制在特定机型开放
5. 加载与切场景体验
- 首次加载、回主城、战斗前后、切后台恢复是否存在黑屏或长卡顿
- 是否有资源预热遗漏，导致首次特效或首次 UI 打开抖一下
一条可执行的回归流程
第一步：建立基线
先在候选版本上跑一遍关键路径，记录每台设备的帧率、帧时间、内存峰值、温度变化和包体大小。没有基线，后续就只有“感觉”。
第二步：只修高优先级问题
优先处理：
- 稳定复现的卡顿尖刺
- 会导致降频、闪退、内存告警的问题
- 关键路径中的 GPU 或 CPU 大头
发布前阶段通常不适合做结构性大改，除非当前问题已经影响上线。
第三步：同条件复测
优化完成后，必须在同设备、同路径、同画质下复测。否则前后数据没有可比性。
第四步：形成验收结论
最后输出的不是“我们做了很多优化”，而是：
- 哪些指标已经达标
- 哪些风险仍存在但可接受
- 哪些机型需要降档或限制特效
我会重点看的几个风险点
- Editor 数据很好看，但真机发热后 15 分钟开始掉帧
- 峰值内存只在某个切场景瞬间爆掉，平时很难注意到
- 包体优化只看总大小，没有检查首包和首次加载体验
- 为了最后冲性能做了高风险改动，结果引入回归 Bug
【注意】发布前优化的目标不是“指标无限漂亮”，而是版本稳定、风险可控、回归成本能接受。
简化版验收模板
- 帧率：目标帧率 / 1% low / 关键场景峰值帧时间
- 内存：冷启动、热启动、长玩 30 分钟、切场景峰值
- 温度：10 分钟、20 分钟、30 分钟机身温度与是否降频
- 包体：安装包、首包、热更新首日下载量
- 结论：通过 / 降档后通过 / 延后发布
【技巧】如果时间只够做一件事，优先把“真实设备上的关键路径基线”补齐。这比零散修几个小问题更能降低上线风险。