当前位置：首页 > news >正文

Unity SLG框架解析：Clash Engine六维系统架构与工程实践

news 2026/5/22 3:02:12

1. 这不是“又一个SLG模板”，而是把“部落冲突”式玩法真正拆开揉碎的工程实践

你有没有试过在Unity里搭一个像《部落冲突》那样的SLG？不是那种只有几个按钮、拖拽兵种就完事的Demo，而是真正能跑通资源采集→建筑升级→兵种训练→多线程战斗→联盟协作→实时状态同步这一整套闭环的底层框架？我见过太多团队卡在“看起来都对，但一加功能就崩”的阶段——UI改三次，战斗逻辑重写四遍，服务器一压测就丢状态。直到去年接手一个海外发行商的中重度SLG项目，我们决定不从零造轮子，而是反向解剖Clash Engine这个被社区称为“Unity最完整SLG模板”的开源工程。它不是教你怎么写UI动效，也不是讲“如何用DOTS加速”，而是把《部落冲突》背后那套资源-建筑-部队-战斗-联盟-事件六维耦合系统，用C#代码一层层剥开：资源增长不是靠Timer，而是基于TickableSystem的帧级调度；建筑升级不是简单修改level字段，而是通过StateMachine驱动的可中断、可回滚、带进度条的异步流程；连“村民自动采集”这种看似简单的功能，背后都是Entity-Component-System架构下，由Job System驱动的并行寻路+资源拾取+状态反馈三阶段流水线。

关键词“Clash Engine”“Unity SLG模板”“部落冲突核心系统”不是噱头——它确实把“原来这么简单”这句话落到了实处：简单，是因为所有复杂逻辑都被封装进可测试、可替换、可组合的模块；不简单，是因为每个模块的接口设计、状态流转、边界处理，都来自真实上线项目的千次迭代。这篇文章不讲“怎么导入Asset Store包”，而是带你亲手把Clash Engine的骨架拆出来，看清楚它的ResourcePool如何避免浮点精度丢失、BuildingManager怎样用ScriptableObject做配置热更、CombatResolver为什么必须区分“预演”和“执行”两个阶段。适合正在做SLG原型的独立开发者、想摆脱“脚本堆叠”困境的中小团队技术负责人，以及那些被“SLG太重”吓退、却不知道其实90%的复杂度都能被模板收敛的策划同学。

2. Clash Engine的底层架构：不是MVC，也不是ECS，而是一套“状态驱动+事件总线+配置中心”的三叉戟

很多人第一眼看到Clash Engine的目录结构，会下意识归类为“ECS架构”。错。它确实用了Unity DOTS的部分组件（比如IJobEntity用于批量处理村民移动），但整个系统的灵魂不在数据布局，而在**状态驱动（State-Driven）+事件总线（Event Bus）+配置中心（Config Hub）**这三根支柱的咬合。我花两周时间把它的核心模块逐个断点调试后发现：所谓“部落冲突的核心系统很简单”，本质是它把所有业务逻辑的触发点，全部收束到三个确定性入口——状态变更、事件广播、配置加载。下面拆解这三根支柱如何协同工作。

2.1 状态驱动：用有限状态机（FSM）替代if-else嵌套地狱

Clash Engine里没有if (player.level >= 5 && building.isUpgrading && resource.gold > cost) { StartUpgrade(); }这种散落在各处的条件判断。取而代之的是，每个核心实体（Player、Building、Troop）都持有一个StateMachine<TState>，其中TState是枚举类型，比如BuildingState.Idle、BuildingState.Upgrading、BuildingState.Destroying。状态切换不靠手动赋值，而是调用stateMachine.TransitionTo(BuildingState.Upgrading)，该方法内部会：

检查当前状态是否允许跳转（例如Idle → Upgrading合法，但Destroying → Upgrading直接抛异常）；
执行OnExit_CurrentState()清理旧状态资源（如取消寻路Job、释放占用的资源槽位）；
执行OnEnter_NewState()初始化新状态（如启动升级倒计时协程、注册资源消耗监听器）；
广播BuildingStateChangedEvent事件，通知UI、音效、成就系统等订阅者。

提示：这种设计让“建筑被摧毁时升级自动取消”这种需求，变成一行代码——在Destroying.OnEnter()里调用upgradeManager.CancelAllFor(building)，无需在升级逻辑里反复检查building是否还存在。我实测过，当建筑数量超过200个时，传统if-else方案的CPU帧耗波动达±12ms，而FSM方案稳定在±1.8ms。

2.2 事件总线：用强类型泛型事件替代SendMessage的不可控广播

Clash Engine的事件系统叫GameEventBus，它不是Unity原生的UnityEvent，也不是第三方插件，而是基于C#Action<T>自研的轻量级总线。关键设计有三点：

强类型约束：GameEventBus.Trigger(new ResourceChangedEvent(ResourceType.Gold, -100))，编译期就能捕获类型错误，避免SendMessage("OnGoldChange", -100)这种字符串魔法；
分层订阅：支持全局订阅（GameEventBus.Subscribe<ResourceChangedEvent>(handler)）和局部订阅（localBus.Subscribe<BuildingUpgradedEvent>(handler)），后者在场景卸载时自动解绑，杜绝内存泄漏；
事件生命周期管理：每个事件类型可配置IsPersistent（如GameStartedEvent需持久化）和MaxListeners（如CombatResultEvent限制最多3个监听器，防误注册）。

我曾遇到一个坑：在战斗结算时，多个系统（成就、邮件、联盟贡献）同时监听CombatResultEvent，但其中一个成就系统因未处理空引用导致崩溃，结果整个事件链中断，邮件没发、联盟贡献没加。Clash Engine的解决方案是——事件处理器必须实现IEventProcessor接口，并声明ExecutionPriority（0~100）。高优先级处理器（如数据持久化）先执行，失败时记录日志但不中断后续；低优先级处理器（如UI动画）失败则静默忽略。这个设计让系统健壮性提升了一个量级。

2.3 配置中心：ScriptableObject + CSV双源驱动，热更不重启

Clash Engine的配置不是写死在C#类里，也不是全靠JSON解析，而是采用“ScriptableObject为主、CSV为辅”的混合模式：

核心规则配置（如建筑升级所需资源、兵种攻击力）存为BuildingConfigSO、TroopConfigSO等ScriptableObject资产，直接拖入Inspector编辑，打包时序列化进AssetBundle；
海量数值表（如100级兵种的每级属性成长）用CSV文件管理，运行时通过CsvLoader.Load<T>("troop_levels.csv")解析为List<T>，再注入到对应SO的LevelData字段中。

这种设计的好处是：策划改一个建筑的升级时间，只需在Inspector里调参数，按Ctrl+S保存，真机上点“热更配置”按钮，3秒内生效，无需重新打包APK。而CSV则解决SO无法高效编辑大量行数据的问题——你总不能在Unity里拉100个滑块调兵种等级吧？我们项目实测，1000行CSV加载耗时仅8ms（iPhone XR），比纯SO方案快4倍。

3. 资源与建筑系统：为什么“自动采集”不是协程，而是TickableSystem的精准调度

说到SLG的资源系统，多数人第一反应是“写个协程每秒加10金币”。Clash Engine彻底抛弃了这种粗放模型，它用一套名为TickableSystem的帧级调度器，把资源增长、建筑升级、部队训练全部纳入统一的时间刻度。这不是为了炫技，而是解决三个真实痛点：浮点精度丢失导致资源累积误差、多线程下资源扣减竞态、跨设备时间不同步引发的作弊漏洞。下面以“村民自动采集木材”为例，拆解其完整链路。

3.1 TickableSystem：用固定帧率替代Time.deltaTime的底层逻辑

Clash Engine的TickableSystem不依赖Update()或FixedUpdate()，而是自己维护一个_currentTick计数器，每帧调用AdvanceTick()方法递增。关键参数如下：

参数	默认值	说明
`TickDurationMs`	100	每tick持续100毫秒（即10 tick/秒）
`MaxSkippedTicks`	3	允许最大跳过3个tick（防卡顿）
`TickPrecision`	`TimeSpan.FromMilliseconds(1)`	tick时间精度，避免浮点累加误差

为什么不用Time.deltaTime？举个例子：假设村民每5秒采集1单位木材，若用Time.deltaTime，在低端机上Update()帧率波动大，5秒内实际累加的deltaTime可能为4.998s或5.003s，长期运行会导致每小时误差0.2单位木材。而TickableSystem强制每100ms执行一次OnTick()，5秒=50次tick，误差被控制在±0.1ms内，彻底消除累积漂移。

3.2 采集流程：从“村民寻路”到“资源入仓”的七步原子操作

村民采集不是单一线程任务，而是由7个可中断、可回滚的原子步骤组成，每步都在一个tick内完成：

CheckTargetValid：验证目标木材堆是否还存在（防止被敌方摧毁）；
StartPathfinding：提交A*寻路Job，返回JobHandle供后续等待；
WaitForPath：在下一个tick检查Job是否完成，未完成则继续等待；
MoveToTarget：根据寻路结果移动村民Entity，使用TransformAccessArray批量更新；
CheckInRange：检测是否进入采集半径（2.5单位），否则跳回步骤2；
CollectResource：从木材堆ResourceNode组件中扣减1单位，触发ResourceChangedEvent；
ReturnToStorage：将采集的资源送回仓库，更新PlayerResourcePool。

注意：步骤3和5的“等待”不是yield return null，而是将村民Entity标记为PendingState，放入PendingQueue，由TickableSystem在下一tick统一处理。这样既保证逻辑清晰，又避免协程栈爆炸。我们项目曾有200村民同时采集，协程方案峰值内存达120MB，而此方案稳定在45MB。

3.3 建筑升级：可中断、可回滚、带进度条的异步状态机

建筑升级是SLG最易出Bug的功能之一。Clash Engine的BuildingUpgradeStateMachine完美解决了三大难题：

可中断：玩家点击“取消升级”时，不直接销毁升级数据，而是将状态切为UpgradingCancelled，保留已消耗的50%资源，下次升级可续费；
可回滚：若升级中途服务器掉线，客户端本地保存UpgradeSnapshot（含起始时间、已耗时、剩余资源），重连后自动校验并恢复；
进度条精准：进度值=(CurrentTime - StartTime) / TotalDuration，但CurrentTime取自TickableSystem._currentTick，而非Time.time，确保跨设备进度一致。

实测对比：某款竞品用Time.time计算进度，iOS和Android设备时间差200ms，导致同一建筑在两台设备上显示进度相差12%。Clash Engine通过TickableSystem同步tick计数，误差控制在±1tick（100ms）内，进度条偏差<0.5%。

4. 战斗系统：预演-执行分离、伤害公式可插拔、战报可追溯的工业级设计

SLG战斗常被简化为“A打B，B掉血”，但《部落冲突》的真实逻辑远不止于此：兵种阵型影响AOE范围、地形高低差改变命中率、援军加入时机决定战局走向。Clash Engine的战斗系统（CombatResolver）用“预演-执行分离”架构，把战斗拆成策略层（预演）和执行层（执行）两个完全解耦的阶段，让复杂战斗逻辑变得可测试、可调试、可复盘。

4.1 预演阶段：在内存中跑1000次战斗，只为选最优解

预演（Simulation）不是模拟真实战斗过程，而是用概率模型快速推演结果。CombatResolver.Simulate()接收CombatContext（含双方兵种配置、阵型、地形），返回CombatResult（胜率、预期损失、关键事件）。其核心是三层抽象：

UnitTemplate：定义兵种基础属性（HP、ATK、Speed）、技能（如弓箭手的RangedAttack）、抗性（对火系伤害减50%）；
CombatRuleSet：可插拔的伤害公式，如默认LinearDamageRule（ATK - DEF）、高级DiceRollRule（掷骰子决定暴击）；
TacticEvaluator：评估不同阵型得分，例如“将巨人放前排吸收伤害”得85分，“分散站位防AOE”得72分。

我的经验：预演阶段必须禁用任何副作用（如不修改真实HP、不触发事件）。我们曾因在预演中调用ApplyDamage()导致玩家真实血量被清零，排查了三天才发现是预演代码污染了实体状态。Clash Engine强制要求预演使用Clone()后的副本数据，从根源杜绝此类问题。

4.2 执行阶段：帧级同步、伤害可视化、战报生成三位一体

执行（Execution）才是真正改变游戏状态的阶段。CombatResolver.Execute()的精妙之处在于：

帧级同步：所有伤害计算、状态变更（如“眩晕3秒”）都在TickableSystem的同一tick内完成，避免“A打B，B在中间帧死亡，C的连携技能失效”这类时序Bug；
伤害可视化：每个伤害数字都是DamagePopupEntity，由DamagePopupSystem管理，支持自定义字体、颜色、飞行动画；
战报可追溯：每场战斗生成唯一CombatLogId，记录[tick:120] Archer-001 fired at Giant-003, dealt 24 damage等明细，存入CombatLogDatabase，支持后台查询、数据分析、玩家申诉。

我们上线后接到大量“战报显示我赢了，但资源没到账”的投诉。用Clash Engine的战报系统，5分钟内定位到问题：ResourceTransferSystem在处理战利品时，未正确处理跨联盟资源转移的权限校验。没有这套可追溯日志，这种问题至少要2天才能复现。

4.3 战斗扩展：如何30分钟接入“天气系统”影响战斗？

Clash Engine的扩展性体现在其CombatModifier接口。要加天气系统，只需三步：

创建WeatherModifier : ICombatModifier，实现ModifyDamage()（雨天降低弓箭手射程30%）、ModifyAccuracy()（雾天降低命中率）；
在CombatContext中添加ActiveModifiers列表，战斗开始时注入new WeatherModifier(WeatherType.Rain)；
修改CombatRuleSet，在计算伤害前调用foreach (var mod in context.ActiveModifiers) damage = mod.ModifyDamage(damage, attacker, defender)。

我们实测，从设计文档到真机验证，整个天气系统接入仅用27分钟。而传统方案需要修改12个脚本、重写3个伤害计算函数，耗时两天且极易引入回归Bug。

5. 联盟与社交系统：用“分布式状态同步”替代中心化服务器的轻量化方案

SLG的联盟功能（聊天、捐兵、联合进攻）常被做成重度服务端逻辑，导致小团队运维成本飙升。Clash Engine另辟蹊径，用“分布式状态同步”（Distributed State Sync）实现联盟功能，核心思想是：不追求强一致性，而用最终一致性+冲突解决策略保障体验。它把联盟状态拆成三类数据，分别用不同策略同步：

数据类型	同步策略	示例	冲突解决
只读配置	全量广播	联盟等级、科技树解锁条件	以服务器下发为准，客户端强制覆盖
弱一致性状态	差分广播	成员在线状态、捐兵次数	客户端本地缓存+心跳保活，离线期间操作暂存，上线后合并
强一致性操作	事务广播	联盟战争报名、资源捐献	每个操作带`OperationId`和`Timestamp`，服务器校验时序，拒绝乱序请求

5.1 捐兵系统：本地预提交+服务端终审的双保险

捐兵是联盟高频操作，Clash Engine的TroopDonationSystem流程如下：

玩家点击“捐兵”，客户端立即执行LocalDonationPreview()：扣减本地兵种库存，生成DonationPreview（含兵种ID、数量、时间戳）；
将DonationPreview发送至服务器，服务器校验：
- 玩家是否有足够兵种（查数据库）；
- 联盟当日捐兵配额是否超限（查Redis缓存）；
- 时间戳是否在合理窗口内（防重放攻击）；
校验通过，服务器广播DonationConfirmedEvent，所有成员收到后更新本地联盟兵营库存。

关键细节：客户端预提交时，库存扣减是“乐观锁”——显示库存为0，但实际数据仍保留，若服务器校验失败（如被抢光），则触发DonationFailedEvent，库存瞬间回滚。这种设计让玩家感知“秒捐”，而服务端压力降低70%。

5.2 联盟战争：用“时间锚点”解决跨时区同步难题

联盟战争要求全球玩家在同一窗口开战，但时区差异导致“北京时间20:00”在纽约是早上8:00。Clash Engine用TimeAnchor机制解决：

服务器下发战争开始时间为UnixTimestamp（如1735689600）；
客户端启动时，调用TimeSyncService.SyncWithServer()获取本地时间与服务器时间的偏移量（如+123ms）；
所有倒计时、状态切换均基于ServerTime.Now = LocalTime.Now + offset计算。

我们实测，在印度（UTC+5:30）和巴西（UTC-3）设备上，战争倒计时误差<200ms，玩家几乎无感知。而某竞品用本地DateTime.Now硬算，时区错乱导致印度玩家提前30分钟开战，直接被判违规。

5.3 社交关系：用“关系图谱”替代扁平化好友列表

Clash Engine的SocialGraphSystem把玩家关系建模为有向加权图：

节点：玩家Entity；
边：关系类型（Friend、Ally、Rival）、强度（互动频次）、时效（30天未互动自动降权）；
查询：graph.GetFriendsWithinDistance(player, maxHops:2)可查“朋友的朋友”，用于联盟推荐。

这个设计让“联盟招新”功能从“随机推送10个玩家”升级为“推荐你好友的活跃联盟”，转化率提升3.2倍。而传统方案要查10张数据库表，响应时间超800ms，Clash Engine用内存图谱，查询<15ms。

6. 实战避坑指南：我在集成Clash Engine时踩过的7个深坑及填坑方案

Clash Engine文档写得极简，但真实集成过程远比想象中复杂。我带着团队在3个项目中落地该模板，总结出7个高频深坑，每个都附带可直接复制的填坑代码。这些不是理论推测，而是真金白银烧出来的教训。

6.1 坑1：DOTS Job System与MonoBehaviour生命周期冲突

现象：在BuildingSystem中启动IJobEntity处理200个建筑升级，App在iOS后台挂起后闪退，Xcode日志显示EXC_BAD_ACCESS (code=1, address=0x0)。

根因：IJobEntity的JobHandle未在MonoBehaviour.OnDisable()中完成等待，后台挂起时Job仍在访问已销毁的EntityManager。

填坑方案：所有使用Job的System必须继承JobManagedSystem，重写OnDisable()：

public class BuildingSystem : JobManagedSystem { protected override void OnDisable() { // 强制等待所有Job完成，避免悬空引用 if (m_BuildJobHandle.IsCompleted == false) m_BuildJobHandle.Complete(); base.OnDisable(); } }

经验：Clash Engine默认未做此防护，必须手动补全。我们因此在App Store审核被拒2次，第三次才加上这段代码。

6.2 坑2：ScriptableObject配置热更后，Inspector不刷新

现象：修改BuildingConfigSO的升级时间，保存后点击“热更”，游戏内数值已变，但Inspector面板仍显示旧值，策划无法确认修改是否生效。

根因：Unity的SO热更会创建新实例，但Inspector仍绑定旧引用，需手动调用EditorUtility.SetDirty()。

填坑方案：在热更工具中添加强制刷新：

public static void HotReloadConfig<T>(string assetPath) where T : ScriptableObject { var newSO = AssetDatabase.LoadAssetAtPath<T>(assetPath); EditorUtility.SetDirty(newSO); // 关键！触发Inspector重绘 AssetDatabase.SaveAssets(); }

6.3 坑3：TickableSystem在低端机上tick堆积导致卡顿

现象：红米Note 7上，TickableSystem的AdvanceTick()单帧耗时超16ms，造成明显卡顿。

根因：MaxSkippedTicks=3设置过高，低端机每帧需处理4个tick，计算量翻倍。

填坑方案：动态调节MaxSkippedTicks，根据设备性能分级：

public class TickPerformanceTuner : MonoBehaviour { void Start() { var fps = Application.targetFrameRate; if (fps <= 30) TickableSystem.Instance.MaxSkippedTicks = 1; else if (fps <= 45) TickableSystem.Instance.MaxSkippedTicks = 2; else TickableSystem.Instance.MaxSkippedTicks = 3; } }

6.4 坑4：CombatResolver预演时，克隆对象内存暴涨

现象：预演1000次战斗，内存峰值达500MB，GC频繁触发。

根因：CombatContext.Clone()深度克隆了所有Entity，包括Mesh、Texture等大资源。

填坑方案：预演专用克隆，只复制逻辑数据：

public CombatContext CloneForSimulation() { var clone = new CombatContext(); clone.Attackers = attackers.Select(x => new TroopSnapshot(x)).ToList(); // 只存ID/HP/ATK clone.Defenders = defenders.Select(x => new TroopSnapshot(x)).ToList(); return clone; }

6.5 坑5：联盟聊天消息乱序，用户看到“你好”在“再见”之后

现象：玩家A连续发两条消息，玩家B收到顺序颠倒。

根因：WebSocket消息无序到达，Clash Engine未做消息排序。

填坑方案：为每条消息添加SequenceNumber，客户端按序号缓冲：

public class ChatMessage { public long SequenceNumber; // 服务端生成，严格递增 public string Content; } // 客户端接收时 private readonly SortedList<long, ChatMessage> _messageBuffer = new(); void OnMessageReceived(ChatMessage msg) { _messageBuffer.Add(msg.SequenceNumber, msg); // 每次检查是否能按序输出 while (_messageBuffer.Count > 0 && _messageBuffer.Keys[0] == _nextExpectedSeq) { Display(_messageBuffer.Values[0]); _messageBuffer.RemoveAt(0); _nextExpectedSeq++; } }

6.6 坑6：资源采集时，村民Entity被意外销毁导致NullReferenceException

现象：村民在采集途中被敌方炮塔击杀，CollectResource步骤访问已销毁的ResourceNode，崩溃。

根因：TickableSystem的OnTick()未做Entity有效性检查。

填坑方案：所有tick操作前加EntityManager.Exists()校验：

public void OnTick() { foreach (var entity in m_CollectingEntities) { if (!m_EntityManager.Exists(entity)) continue; // 关键防护 // ... 执行采集逻辑 } }

6.7 坑7：iOS平台IL2CPP下，泛型事件总线编译失败

现象：Xcode构建时报错error CS0656: Missing compiler required member 'System.Collections.Generic.IEnumerable'1.GetEnumerator'。

根因：IL2CPP对泛型反射支持不全，GameEventBus.Subscribe<T>()的T类型未被正确链接。

填坑方案：在link.xml中强制保留泛型类型：

<linker> <assembly fullname="Assembly-CSharp"> <type fullname="GameEventBus" /> <type fullname="System.Action`1[[MyGame.Events.ResourceChangedEvent, Assembly-CSharp]]" /> </assembly> </linker>

7. 从Clash Engine到你的项目：一份可立即执行的迁移路线图

Clash Engine不是拿来即用的黑盒，而是需要根据项目需求裁剪、增强的骨架。我为你梳理了一份分阶段迁移路线图，每一步都标注了工时预估和风险提示，团队可直接按此执行。

7.1 阶段一：核心骨架剥离（耗时2人日）

目标：从Clash Engine中提取TickableSystem、StateMachine、GameEventBus、ConfigHub四大核心，剥离所有SLG业务逻辑（建筑、兵种、战斗）。

操作清单：

删除Assets/ClashEngine/Features/下所有业务模块；
保留Assets/ClashEngine/Core/，重命名为Assets/Framework/Core/；
修改所有using ClashEngine.Core为using Framework.Core；
运行TestCoreSystems单元测试，确保100%通过。

风险提示：务必先备份原工程。我们曾因误删Core/Utils/下的MathHelper.cs，导致所有浮点计算异常，回滚耗时3小时。

7.2 阶段二：配置体系对接（耗时1人日）

目标：将现有项目的数值表（Excel/CSV）导入Clash Engine的ConfigHub。

操作清单：

用CsvToSOConverter工具，将buildings.csv转换为BuildingConfigSO资产；
编写MigrationScript，将旧版BuildingData类的字段映射到新SO的UpgradeCosts、BuildTime等属性；
在GameBootstrapper.Awake()中调用ConfigHub.LoadAll()。

技巧：用Unity的MultiColumnHeader定制Inspector，让策划能直接在表格里编辑100行数据，比CSV高效10倍。

7.3 阶段三：状态机重构（耗时3人日）

目标：将现有PlayerController、BuildingController等脚本，重构为StateMachine<PlayerState>驱动。

操作清单：

为Player创建PlayerState枚举（Idle、Building、Attacking）；
将PlayerController.StartBuilding()逻辑移到Building.OnEnter()；
用GameEventBus.Trigger(new PlayerStateChangedEvent(oldState, newState))通知UI更新。

经验：不要试图一步到位。先重构1个建筑类型（如TownHall），验证流程后再批量处理。我们首批重构TownHall，发现OnExit_Building需释放BuildingManager的引用，否则内存泄漏。

7.4 阶段四：战斗系统渐进式接入（耗时5人日）

目标：用CombatResolver替代现有战斗逻辑，分三步灰度上线。

灰度策略：

Step 1（1天）：仅启用预演，CombatResolver.Simulate()返回胜率，UI显示“预计胜率85%”，但真实战斗仍走旧逻辑；
Step 2（2天）：50%战斗走新逻辑，用Random.value < 0.5f分流，埋点统计胜率、耗时、崩溃率；
Step 3（2天）：100%切换，关闭旧逻辑，用CombatLogDatabase做全量审计。

关键指标：新旧逻辑胜率偏差<1%，单场战斗耗时<8ms（iPhone 8），崩溃率0。未达标则回滚至Step 2。

7.5 阶段五：性能压测与调优（耗时2人日）

目标：在目标设备（如Android中端机）上，确保200实体并发时帧率≥30FPS。

压测清单：

启动StressTestScene，加载200个VillageEntity（含建筑、村民、资源）；
运行Profiler，重点关注TickableSystem.AdvanceTick、CombatResolver.Execute、GameEventBus.Trigger耗时；
若AdvanceTick> 5ms，启用JobManagedSystem的ScheduleParallel()优化；
若Trigger> 2ms，检查事件监听器数量，移除未使用的Subscribe。