写在前面：卡顿不一定说明引擎不行
个人开发者遇到性能问题时，很容易怀疑底层方案。
“是不是 Unity 2D 不行？”
“是不是要改成自写渲染？”
“是不是要换引擎？”
“是不是必须上 ECS？”
这些问题有时成立，但大多数时候太早。
程砚做过一款 2D 横版动作游戏。
主角是一名纸伞剑客，在雨夜巷道中冲刺、格挡、反击。游戏画面由大量手绘帧动画、雨滴粒子、灯笼光效和前景遮挡组成。
第一次公开测试时，玩家反馈最多的不是难度，而是卡顿。
尤其是低端笔记本和集成显卡，战斗一激烈就掉帧。
程砚一开始想重写一套更轻的渲染管理。
后来他先做性能分析，发现真正问题不是引擎，而是资源管线混乱。
他最后没有换渲染方案。
通过贴图图集、对象池、动画裁剪、加载分段和特效分级，性能基本稳定。
一、先测量，而不是猜
程砚先选了三台测试机器：
- 主力开发机
- 一台普通办公笔记本
- 一台较老的集成显卡机器
他用固定场景测试：
- 空场景
- 普通跑图
- 3 个敌人战斗
- 8 个敌人加雨滴特效
- Boss 战
- 场景切换
然后记录：
- 平均帧率
- 1% low
- Draw Call
- 贴图内存
- GC 分配
- 加载时间
- 峰值对象数量
结果很快说明问题。
空场景和普通跑图没问题。
卡顿集中在敌人生成、特效爆发和场景切换。
这意味着不需要一上来重写渲染。
问题更可能在资源组织和运行时分配。
二、贴图太散导致批处理差
游戏里有很多手绘角色和场景小物件。
早期开发时，程砚为了方便，几乎每个角色、灯笼、雨棚、招牌都有独立贴图。
看起来管理清楚，但运行时 Draw Call 很多。
尤其是敌人和特效混在一起时，材质切换频繁。
他做了第一轮资源整理：
- 同一关卡常用小物件合成图集
- 敌人动画按章节分图集
- UI 图标单独成图集
- 特效贴图按类型合并
- 减少不必要的材质变体
这一步没有改变玩法代码，却明显降低了渲染开销。
很多 2D 性能问题不是画面太复杂，而是资源太碎。
个人开发者早期为了方便会随手导入资源。
到内容变多时，必须回头整理。
三、帧动画不是每一帧都要保留
程砚的主角动画非常细。
伞面展开、雨滴滑落、剑光回收都有很多帧。
美术效果很好，但部分动画体积过大。
他和美术一起检查后，做了裁剪：
- 删除肉眼几乎看不出的过渡帧
- 对高速动作降低单帧精度
- 把部分循环雨滴改成粒子或 shader
- 远处 NPC 使用低帧率动画
- 菜单预览使用压缩版本
这不是降低质量，而是把资源用在玩家能感知的地方。
动作游戏里，关键帧和打击反馈必须保留。
但角色站立时伞面轻微抖动，不一定需要 24 帧循环。
性能优化不是平均砍。
它要保护体验核心。
四、对象池解决的是尖峰，不是所有对象
卡顿最明显的时候，是敌人死亡后爆出纸片、雨水、光点和掉落物。
早期实现里，这些都是即时创建和销毁。
程砚给几类对象加了对象池：
- 命中特效
- 雨滴溅射
- 掉落物
- 伤害数字
- 临时碰撞提示
但他没有把所有对象都池化。
关卡里的固定机关、剧情 NPC、菜单 UI 没必要增加池化复杂度。
对象池本身也需要管理生命周期，滥用会让 bug 变多。
他只池化高频、短生命周期、容易造成尖峰的对象。
这个范围控制很重要。
五、加载要分段，而不是隐藏在黑屏里
场景切换也有卡顿。
问题不是切换时间长，而是黑屏后第一秒掉帧。
原因是场景出现后才集中初始化敌人、特效和音频。
程砚改成分段加载：
- 先加载关卡静态资源
- 再预热敌人和特效对象池
- 再加载音频片段
- 最后淡入场景
同时在淡入前跑一帧初始化，让第一波显示不再挤到玩家可操作时刻。
这让总加载时间略微增加，但体感更顺。
玩家不一定介意多等半秒。
但很介意刚能动就卡一下。
六、特效分级比全局开关更好
程砚最早只做了一个“低特效模式”开关。
后来发现太粗。
有些玩家机器能承受雨滴，但 Boss 光效会卡。
有些玩家喜欢保留打击闪光，但不在乎背景粒子。
他把特效分成几类：
- 背景雨量
- 命中特效
- 屏幕震动
- 前景遮挡
- 光照质量
- 残影数量
默认根据简单硬件检测给一个建议档位，玩家也可以手动调。
个人游戏不一定要做复杂画质系统。
但至少要知道哪些效果影响体验，哪些效果影响性能。
把它们分开，玩家更容易找到适合自己的设置。
七、为什么没有重写渲染
优化后，程砚再次测试。
低端机仍然不是完美满帧，但最严重的战斗卡顿消失了。
Boss 战 1% low 提升明显，场景切换也稳定。
这时他放弃了自写渲染管理。
原因很简单：
- 当前瓶颈已被解决
- 重写会引入新 bug
- 项目时间不足
- 现有工具链还能支撑内容制作
- 玩家关心的是稳定体验，不是底层是否优雅
技术重写很有诱惑力。
它让开发者感觉自己在解决根本问题。
但如果根本问题只是贴图、对象和加载混乱，重写底层就是绕远路。
结语：优化先从可见浪费开始
程砚的案例说明，2D 游戏性能问题不一定需要大方案。
先测量，再处理资源管线、动画体积、对象生命周期、加载顺序和特效分级。
这些工作不耀眼，却最接近真实问题。
个人游戏技术方案选择，最怕把局部混乱误判成架构失败。
在决定换引擎、换框架、重写渲染之前，先问：
- 我测过瓶颈了吗？
- 资源是否太散？
- 是否有运行时频繁创建销毁？
- 是否把玩家看不到的细节做得太重？
- 是否有低端机器验证？
如果这些还没做，所谓“大技术方案”很可能只是昂贵的逃避。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。