背景16.6ms 里没有 GC 的位置AAA 手游和端游的帧预算是死线不是建议。60fps 意味着每帧 16.6ms其中渲染、物理、逻辑、音频都在争这块蛋糕。托管 GC哪怕是 Unity 的增量式 GC一旦触发轻则 0.5ms重则几十毫秒帧率曲线直接出现刺峰。问题是GC 压力往往不来自大对象而来自主循环里一行看起来无害的代码// 战斗系统 Update()每帧调用voidUpdate(){_enemies.RemoveAll(ee.HP0);// ← 每帧分配闭包}这一行在手机端每秒产生 60 个短命对象。量不大但不停地戳 Gen0配合 Unity 的分代 GC迟早在战斗高峰触发一次你不想要的回收。为什么匿名委托会分配编译器的真相把上面那行代码扔进 SharpLab你会看到// 原始代码_enemies.RemoveAll(ee.HP0);// 编译器实际生成没有捕获外部变量时// ✅ 无捕获 编译器生成静态缓存字段只分配一次privatestaticPredicateEnemy9__1_0;if(9__1_0null)9__1_0newPredicateEnemy(Updateb__1_0);_enemies.RemoveAll(9__1_0);纯无捕获的 lambda编译器会帮你缓存只分配一次。真正的麻烦在捕获了外部变量的场景floatdamageThreshold_player.AttackPower*0.5f;// 局部变量_enemies.RemoveAll(ee.HPdamageThreshold);// ← 捕获了// 编译器生成varclosurenewc__DisplayClass3_0();// 每帧 new堆分配closure.damageThresholddamageThreshold;_enemies.RemoveAll(newPredicateEnemy(closure.Updateb__0));只要捕获了局部变量编译器就必须在堆上分配闭包对象。没有任何绕过方式除非你改变代码结构。定量用 Unity Profiler 看见它先建基线// 测试场景1000 个敌人60fps战斗持续 10 秒[MemoryDiagnoser]publicclassEnemySystemBenchmark{privateListEnemy_enemies;privatefloat_threshold;// 方案 A捕获局部变量[Benchmark(Baselinetrue)]publicvoidCapturingLambda(){floatt_threshold;_enemies.RemoveAll(ee.HPt);// 每次调用分配闭包}// 方案 B无捕获 static lambdaC# 9[Benchmark]publicvoidStaticLambda(){_enemies.RemoveAll(staticee.HP0);// 0 分配}// 方案 C缓存委托到字段privatestaticreadonlyPredicateEnemy_isDeadstaticee.HP0;[Benchmark]publicvoidCachedDelegate(){_enemies.RemoveAll(_isDead);// 0 分配}}BenchmarkDotNet 结果Mono on AndroidPixel 7 Pro方案MeanAlloc/帧10s 总分配CapturingLambda312 ns32 B~19 KBStaticLambda278 ns00CachedDelegate275 ns0019KB 看着不多但这只是一个系统的一个调用点。战斗系统里有十几处类似模式加起来轻松超过 1MB/s 的 Gen0 压力。C# 9staticlambda最低成本的意图锁定// static 修饰符在编译期禁止捕获// 捕获任何外部状态直接报编译错误CI 就能拦截_enemies.RemoveAll(staticee.HP0);// ❌ 编译错误CS8821 — 静态匿名函数中不能使用局部变量floatthreshold0;_enemies.RemoveAll(staticee.HPthreshold);static lambda不改变运行时行为但把我不想引入捕获变成了编译期约束。对于大型团队来说这是代码审查的替代品——接手代码的初级工程师加一行捕获CI 直接打回不需要等 Profiler 告警。需要传入外部状态时让状态流动而不是被捕获游戏逻辑里状态无处不在大多数情况不可能用无捕获 lambda。正确的做法是把状态变成显式参数而不是隐式捕获。模式一委托缓存到实例字段publicsealedclassEnemySystem:ISystem{// 实例级委托构造时分配一次之后每帧复用privatereadonlyPredicateEnemy_isDeadPredicate;// 状态通过 this 访问不是通过闭包捕获局部变量privatefloat_damageThreshold;publicEnemySystem(){_isDeadPredicateIsEnemyDead;// 方法组绑定到 this分配一次}// 实例方法通过字段读状态不是通过闭包privateboolIsEnemyDead(Enemye)e.HP0;publicvoidUpdate(floatthreshold){_damageThresholdthreshold;_enemies.RemoveAll(_isDeadPredicate);// 0 分配复用字段}}关键点委托生命周期和状态生命周期一致。_isDeadPredicate活得和EnemySystem一样长只在系统创建时分配一次。模式二带 state 参数的 API.NET 6 / Unity 2022很多高性能 API 提供带 state 参数的重载专门为了避免闭包而设计// 自定义高性能遍历接口state 参数模式publicstaticclassSpanExtensions{publicstaticintRemoveAllT,TState(thisSpanTspan,TStatestate,FuncT,TState,boolpredicate)// state 作为参数传入不是捕获{intwriteIdx0;for(inti0;ispan.Length;i){if(!predicate(span[i],state))span[writeIdx]span[i];}returnwriteIdx;}}// 调用static lambda state完全零分配floatthresholdplayer.AttackPower*0.5f;intremainingenemySpan.RemoveAll(threshold,static(e,t)e.HPt);Unity 自带的很多 APIArray.FindAll、List.FindAll没有 state 参数这是历史包袱。但如果你在写内部工具库设计新接口时应该默认带 state 参数。进阶DOTS / Burst Compiler 场景如果你们在用 Unity DOTS委托本身就是个反模式——Burst Compiler 不支持托管委托需要用函数指针// Burst 兼容非托管函数指针[BurstCompile]publicunsafestructEnemyFilterJob:IJobParallelFor{[ReadOnly]publicNativeArrayEnemyDataEnemies;publicNativeArrayboolResults;// 函数指针完全绕开委托机制无堆分配无虚表查找Burst 可内联[NativeDisableUnsafePtrRestriction]publicFunctionPointerEnemyFilterDelegateFilterFn;publicvoidExecute(intindex){Results[index]FilterFn.Invoke(Enemies[index]);}}// 调用侧unsafevoidScheduleFilter(){varfnBurstCompiler.CompileFunctionPointerEnemyFilterDelegate(FilterByHP);varjobnewEnemyFilterJob{Enemies_enemyData,Results_results,FilterFnfn// 编译时绑定运行时零开销};job.Schedule(_enemyData.Length,64);}[BurstCompile]staticboolFilterByHP(EnemyDatae)e.HP0;DOTS 场景下这不只是减少 GC而是让 Burst 真正介入——只有静态方法 函数指针Burst 才能 SIMD 化你的逻辑。事件系统最容易被忽视的分配源游戏事件系统是匿名委托重灾区因为订阅通常写得很随意// ❌ 常见写法每次都分配新委托对象voidOnEnable(){EventBus.OnEnemyDied(enemy)UpdateKillCount(enemy);// 新对象EventBus.OnEnemyDied(enemy){/* 另一个闭包 */};}两个问题一是每次OnEnable都在堆上新建委托对象二是无法正确Unsubscribe新 lambda 和-新 lambda 是不同对象取消订阅无效内存泄漏。正确写法publicsealedclassUIKillCounter:MonoBehaviour{// 委托作为字段明确生命周期可以正确取消订阅privateActionEnemy_onEnemyDiedHandler;privatevoidAwake(){// 只分配一次_onEnemyDiedHandlerOnEnemyDied;}privatevoidOnEnable()EventBus.OnEnemyDied_onEnemyDiedHandler;privatevoidOnDisable()EventBus.OnEnemyDied-_onEnemyDiedHandler;// 正确取消privatevoidOnEnemyDied(Enemyenemy){_killCount;RefreshUI();}}这个模式同时解决了三个问题零重复分配、正确取消订阅、可测试方法可以被单独单测。全局决策树这个委托/lambda 会在高频路径Update/FixedUpdate/热循环里调用吗 │ ├─ 否一次性初始化、低频事件 │ └─ 随便写可读性优先 │ └─ 是 │ ├─ 需要捕获外部状态吗 │ │ │ ├─ 否 → static lambda 或静态方法组 │ │ 编译器缓存0 分配 │ │ │ └─ 是 → 状态是否与对象生命周期一致 │ │ │ ├─ 是 → 委托缓存为实例字段构造时一次分配 │ │ │ └─ 否每帧不同值 │ │ │ ├─ API 支持 state 参数→ static lambda state │ │ │ └─ 否 → 重构 API 加 state 参数 │ 极限性能DOTS/Burst→ 函数指针 │ └─ 是 Unity DOTS/Burst 路径 └─ FunctionPointerTBurstCompile 静态方法落地检查清单生产项目里推行这套模式可以从以下几点入手开启 Roslyn Analyzer 检测捕获可以用社区的Meziantou.Analyzer或自写规则在 CI 阶段对高频路径的捕获 lambda 报警。Unity Memory Profiler 建基线在战斗开始后 30 秒截一次托管堆快照找c__DisplayClass开头的类型排序 by count前五名优先处理。新接口规范内部工具库的所有接受委托参数的 API一律提供带TState state的重载版本这是架构层面的零成本预防。事件系统规范订阅写入Awake/构造函数取消写入OnDisable/Dispose委托字段化代码审查 checklist 里加这一条。GC 优化不是非常规手段是大厂手游的标准工程实践。帧率平滑不靠运气靠的是每一个 allocation site 都有人盯。