把 Unity 的程序集DLL想象成一本即将出版的小说。你在编辑器里写的 C# 源码是作家的手稿Unity 编译之后生成的Assembly-CSharp.dll、各个asmdef的 DLL是排版好的“铅字版”而 ILIntermediate Language中间语言就是铅字的“字模”——已经不是你写的中文句子但仍然保留完整语义能被 Mono 或 IL2CPP 翻译执行。所谓IL 层程序集改写Assembly Rewriting就像你在小说印刷前或印刷后给每章开头自动加一句“本章导读”方法入口注入在每章结尾自动加“本章总结”return 前注入遇到任何意外都补一个“事故记录”异常路径 try/finally甚至把某些句子替换成修订版热修复、补丁而作者本人业务开发者可能只写了[AutoProfile]voidOpenPanel(){...}真正出版的书里却变成voidOpenPanel(){vartokenProfilerRuntime.Begin(OpenPanel);try{...}finally{ProfilerRuntime.End(token);}}这就是 IL 注入最迷人的地方它把“横切关注点”计时、埋点、日志、防护、权限校验从人肉劳动变成流水线作业。下面我们用“印刷厂改稿”的方式把构建前/构建后改 DLL 的 IL这套最常见注入思路讲透它是什么、能干什么、怎么设计、怎么集成、有哪些坑以及如何工程化。一、先搞清楚“你动的是什么”C# → IL →Mono 执行 或 IL2CPP 转 C1.1 Unity 的编译产物是什么在 Unity 项目里脚本编译后形成若干程序集Assembly-CSharp.dll传统项目Assembly-CSharp-Editor.dll编辑器脚本使用 asmdef 时每个 asmdef 一个 DLL以及一些第三方 DLLPlugins这些 DLL 里装的是IL 元数据类型、方法、字段信息。Mono 运行时可以直接执行 ILJIT/AOT 视平台。IL2CPP 会把 IL 翻译成 C 再编译成原生代码但翻译的源头仍是 IL。所以——只要你的发布链路仍以 IL 为输入即便最后走 IL2CPPIL 改写就依然有效。1.2 IL 改写到底改变了什么它改变的是“铅字排版”不是作者手稿。你改的是方法体里的 IL 指令序列Instruction局部变量表Variables异常处理块ExceptionHandlers引用的类型/方法MemberReference它不需要你改 C# 源码也不需要你用反射在运行时绕来绕去它是在编译后的确定形态上动刀注入后的代码就像你本来就这么写的一样执行。二、为什么 IL 注入是“最常见的注入”——因为它像装配线稳定、强力、便宜如果把三种注入方式比作施工运行时 Hook像演出当天找人临时加戏灵活但不可控原生层插桩像改大楼钢结构专业但昂贵IL 改写像印刷厂流水线加页脚——稳定、批量、成本可控IL 注入常见优势性能好注入后是普通调用不依赖反射/动态代理覆盖广几乎任何方法都能改同步、异步、协程生成的 MoveNext 也能不改业务源码业务只需标记或遵循规范可工程化构建管线固定执行产物稳定一致对 IL2CPP 友好比运行时反射更稳但要处理裁剪适用典型场景自动性能统计方法耗时、热点检测自动埋点UI 打开/关闭、按钮点击自动异常保护SDK 回调、网络解析自动权限/状态校验例如必须登录、必须在主线程自动生成注册表减少反射提升 IL2CPP 兼容性三、IL 注入的“基本动作”找目标 → 选插入点 → 插入 call → 修复控制流IL 注入看似神秘其实可以拆成四步像给文章批量插页脚3.1 找目标Targeting你要明确改哪个程序集、哪个类型、哪个方法。常见选择规则具有某个 Attribute 的方法[AutoProfile]、[AutoTrack]实现某接口的类ITrackable名称匹配OnClick*、Open*Panel配置列表json/yaml 记录要注入的签名工程上最推荐Attribute 白名单配置原因可控、安全、可审计。3.2 选插入点Weaving Points最常见三类入口方法第一条有效指令之前出口每个ret前注意可能有多个 return异常用try/finally包住方法体保证 End 必执行你会发现“出口”比你想象复杂一个方法可能有多个 return、多个分支甚至尾部并不显式retIL 会生成。所以很多统计类注入更喜欢用try/finally一次性兜住所有退出路径。3.3 插入指令Inject IL Instructions注入常用方式插入对某个静态方法的调用ProfilerRuntime.Begin(int methodId)ProfilerRuntime.End(int token)TrackRuntime.Event(int eventId)为什么用int因为它比 string 更快更省内存string 常带分配风险。3.4 修复控制流与元数据Fix-up插入 IL 不是把文本塞进去那么简单它牵涉分支跳转目标是否偏移了异常处理块的范围要重算局部变量索引变化调试符号PDB/MDB映射是否更新这一步做不好就像你把小说的章节插页插乱了读到一半跳到另一个故事。四、工具选择Mono.Cecil 是 IL 改写界的“瑞士军刀”在 Unity 生态里IL 改写最常用的库是Mono.Cecil。它能读取 DLLModuleDefinition枚举类型/方法/字段读取并修改方法体 ILMethodBody、Instruction修改引用import reference写回 DLL并处理符号文件你可以把 Cecil 想象成“铅字排版软件”它让你用较高层的 API 操作 IL而不是手撸字节流。Unity 的某些编译管线也使用 Cecil 或类似机制。五、两种集成时机构建前改 vs 构建后改像在印刷前改稿 vs 印刷后贴修正贴纸5.1 构建前改Pre-build / Compile pipeline 中改流程像Unity 编译脚本 → 产出 DLL注入工具立刻改写 DLLUnity 接着打包优点注入后的 DLL 会进入后续所有流程比如 IL2CPP 转换、代码裁剪分析与最终包一致性好难点要和 Unity 编译管线对齐避免多次注入、避免编译死循环Domain Reload、增量编译要处理5.2 构建后改Post-build / 输出产物后改比如你打 PC 包输出Game_Data/Managed/*.dll后再去改那个目录里的 DLL。优点对 Unity 编译管线侵入小适合某些平台特定处理、或者仅用于测试包缺点不一定适用于 IL2CPP因为 IL2CPP 可能已经把 IL 转成 C 了你再改 Managed DLL 没意义对 iOS/Android IL2CPP 包通常不可行容易和平台签名、打包完整性冲突工程结论通常是如果你的目标是通用包括 IL2CPP 平台并且稳定上线优先构建前注入。构建后注入更像“临时补丁贴纸”适合 PC Mono、测试与内部工具。六、注入工程的“黄金结构”Weaver织入器 Runtime运行库 Config配置成熟的 IL 注入体系通常拆成三块像三个部门6.1 Weaver织入器负责改 DLL职责扫描程序集、找目标读取 IL插入指令写回 DLL/符号防重复注入幂等它应该尽量“无业务逻辑”只做织入工作。6.2 Runtime运行库注入代码真正调用的工具函数职责Begin/End、Track、Guard 等实现采样、开关、过滤低分配、线程安全输出到日志/文件/网络这部分运行在游戏里必须极其谨慎别为了统计性能在 runtime 里疯狂分配字符串反而制造 GC。6.3 Config配置/规则职责白名单/黑名单注入策略只注入 public只注入某 namespace不同构建目标Debug/Release的开关把“规则”外置才能让注入工具适应项目迭代而不是每次改工具代码。七、一个典型完整案例方法耗时统计注入从业务标记到 IL 改写结果我们用最典型的需求自动耗时统计来串起整个链路。7.1 业务侧只写标记[AutoProfile]publicvoidLoadBattle(){// 大量逻辑...}7.2 注入目标让它等价于publicvoidLoadBattle(){inttokenProfilerRuntime.Begin(/* methodId */);try{// 原始逻辑}finally{ProfilerRuntime.End(token);}}7.3 为什么 methodId 不用字符串如果你在注入点传nameof(LoadBattle)或拼接type.FullName method.Name你会增加字符串常量/或运行时字符串拼接可能产生 GC Alloc运行时查表更慢更工程化的做法是注入时为每个方法生成一个稳定的 int id同时生成一个 mapid → 可读名称用于离线解析或调试 UI 展示这就像给每个游乐设施发一个编号报表上用编号展示层再把编号翻译成人话。7.4 try/finally 的价值覆盖所有 return 与异常若只在每个ret前插 End你需要处理多个 returnthrowyield状态机async状态机复杂度会迅速上升。try/finally 像给走廊装一扇自动门无论从哪个出口离开都必须刷一次卡。八、绕不开的“高级关卡”async/await 与 coroutine协程怎么注入Unity 项目里最想统计的往往是async网络请求IEnumerator协程加载流程但它们在 IL 层面并不是普通方法体而是被编译器改造成“状态机”。8.1 async 方法真正执行的逻辑在 MoveNextasync Task Foo()编译后会生成一个结构体/类状态机核心逻辑在MoveNext()。如果你对Foo()入口注入 Begin/End你得到的是“启动耗时”不是异步执行耗时。要统计完整耗时需要注入状态机的 MoveNext或注入 await 关键点更复杂工程上常见折中统计Foo()的启动与第一个 await 前的同步部分简单或专门对状态机 MoveNext 做注入复杂但准确8.2 IEnumerator 协程同样有状态机 MoveNextIEnumerator Load()也会生成状态机逻辑在MoveNext()中分帧执行。你要统计“总耗时”还是“每帧耗时”两者注入点不同总耗时从第一次 MoveNext 到结束每帧耗时每次 MoveNext 的执行时间这类注入更像给长跑运动员装计步器你想看全程时间还是每公里配速结论IL 注入能做但必须理解编译器状态机的生成模式并制定一致的统计口径。九、幂等与防重复注入别让同一段走廊被装两次门禁在 Unity 编辑器里脚本会频繁重编译。若你的注入器每次都无脑插入会出现Begin/End 变成 Begin/Begin/Begin…堆栈越来越深性能和逻辑都崩所以必须做“幂等设计”常见策略注入后在方法体插入一个可识别的 IL 标记例如调用一个特殊空方法InjectionMarker.Mark()或给方法加自定义 Attribute但写回程序集会改变元数据需谨慎或在方法体开头检查是否已存在对 runtime 的调用模式匹配幂等就像施工验收看到门口已经有门禁就不要再装一套。十、符号文件与调试别让 bug 定位变成“地图对不上”一旦你改写 DLL行号映射PDB/MDB可能错位崩溃堆栈出现 runtime 方法断点位置可能偏移解决建议注入时同时读写符号文件Cecil 的 SymbolReader/SymbolWriterruntime 方法尽量短小、可过滤为注入逻辑提供开关必要时关闭注入复现问题工程经验注入体系必须可回滚。当线上出现诡异问题第一步往往是“关掉注入验证是否相关”。十一、与裁剪Stripping/link.xml 的关系你插进去的调用别被打包时剪掉在 IL2CPP 或较高 Stripping Level 下Unity 会裁剪“看似未使用”的代码。如果你的注入 runtime 位于某个程序集但裁剪器认为它未被引用可能会剪掉导致运行时报MissingMethodException或注入调用变成无效严重时崩溃解决保证 runtime 方法在注入后确实被引用通常会对反射相关类型/方法写link.xml保留在构建配置中验证注入 runtime 的保留情况十二、性能与安全注入不是免费午餐要像“城市改造”一样做预算12.1 注入会增加什么开销多一次/多几次方法调用可能增加 try/finally会略影响 JIT/优化可能增加局部变量、栈操作所以你必须做“注入范围控制”不要对所有方法注入不要对属性 getter/setter 注入太频繁不要对极热路径如每帧调用上万次的 math 函数注入用采样Sample Rate减少统计开销12.2 运行库必须“低分配”注入的初衷常是性能与稳定性如果 runtime 里每次拼字符串、分配对象你会把项目带进“为了省油装了个更耗油的引擎”的尴尬局面。十三、实用落地建议一套“可上线”的 IL 注入实施清单明确目标性能/埋点/防护/生成代码设计标记Attribute 白名单建 runtime稳定 API、低分配、可开关实现 weaver扫描→注入→幂等→写符号集成到构建前流程优先加验证注入前后跑自动化测试/关键场景回归加监控注入版本号写入 build report便于追溯为 Release 配采样与降级开关与 IL2CPP/Stripping 联调必要时加 link.xml文档化与规范化哪些方法允许注入、哪些禁止结语IL 改写像“给城市加基础设施”好用但必须工程化IL 层程序集改写之所以最常见是因为它符合软件工程的现实一次投入长期受益把重复劳动交给机器把一致性和可控性拉满对最终性能影响可预算、可管理用一句形象的话收尾IL 注入不是在代码上“贴膏药”而是在编译产物里“修路装门禁”。修得好整座城市更通畅修得乱地图会变成迷宫。关键在于规划、幂等、开关、测试、以及对成本的敬畏。