竞技游戏技能系统性能优化实践

一、为什么要做技能重构？

技能系统是竞技游戏的核心战斗模块，每帧都在高频运转。当它成为性能瓶颈时，影响链路非常长 — 从客户端帧率到服务器承载、从用户体验到运营成本。本次重构的驱动力来自客户端和服务器两个方向。

1.1 客户端：机型下探与卡顿分析

项目 M2 阶段的目标是将最低适配机型下探到骁龙 450 级别，长期目标是 430。然而优化初期的实机数据令人担忧：

帧率只是表象。通过 Profiler 抓取，我们进一步分析了帧率波动（卡顿）情况：

结合 Profile 数据，按严重程度排列，卡顿来源如下：

性能绝对值的组成也很清晰：

1. Polaris 被动技能（范围检测、图标显示判定等）— 常驻高频 tick，数量最多
2. Polaris 主动技能（震慑脉冲、近战搏击等）— 单次开销大，节点图复杂

1.2 服务器：成本对比与压力

与同品类成熟产品对比（取 7 月线上数据），服务器资源利用率差距明显：

1.3 关键结论：技能开销占比 39%+

二、技能重构之最佳实践

优化分为两个维度：优化点 1 — 去掉 Polaris 框架开销（架构层面），优化点 2 — 重构技能逻辑本身（业务层面）。两者叠加才能取得最大收益。

2.1 优化点 1：去 Polaris — 方案对比与架构演进

Polaris 是项目现有的可视化技能编辑框架，策划通过拖拽节点图（.mth 文件）来配置技能逻辑。它对策划非常友好，但运行时存在显著的框架调度开销和节点入口调用开销。

四种替代方案评估

性能对比

最终选择手写 Python 方案：性能提升最显著，代码完全可控，且能渐进式迁移 — 新旧方案可以共存，逐步替换而不影响整体进度。

2.2 两套手写体系：hybrid_skill_system & skill_system

根据技能的生命周期和运行特征，手写方案分为两套体系：

hybrid_skill_system 需要处理的 .mth 文件总计 439 个：

2.3 核心设计原则与代码结构

原则一：一对一映射

一个 .mth 文件对应一个 .py 文件，命名规范清晰：

// Polaris 版本
change_pose.mth

// 手写 Python 版本
hybrid_change_pose.py

原则二：实例化运行

技能从"跑一个节点图"变为"跑一个 Class 实例"。每个技能实例拥有自己的状态和生命周期：

原则三：System 接口组合

大部分原 Polaris 节点的逻辑已经封装在各种 System 接口中。手写版本直接调用这些接口，跳过 Polaris 的调度层，实现相同功能但开销更低。

原则四：组件式代码复用

对于跨技能的通用逻辑，使用 skill_logic_component 实现组件式复用，分为两类：

2.4 优化点 2：逻辑重构方法论

"去 Polaris"解决的是框架层面的开销，但很多技能的逻辑本身也存在不必要的浪费。重构思路分三步：

常见的重构手段包括：

• 降频 — 减少 tick 频率（如 0.4s → 2s），利用数学关系（公约数/公倍数）合并计算
• 动态降频 — 根据状态自适应调整频率（满血时 30s tick，回血中 1s tick）
• 事件驱动替代轮询 — 用事件/回调替代周期性检测（如高处下落）
• 距离分级 — 根据距离动态调整更新频率（近处高频，远处低频）
• 从玩家级提升到 Space 级 — 将"每人挂一个被动"改为"Space 挂一个 System"，消除重复计算

三、案例讲解

以下 6 个案例覆盖了不同的技能类型和优化手段，每个都附有前后对比和性能数据。

案例总览

可参考案例编号

#31778 体力值回复重构 · #31746 呼吸回血重构 · #31745 AFK 机制重构 · #32213 门锁干扰器 · #32092 鹰眼主动 · #32201 替身徽主动 · #31867 change_pose