在最近的版本性能专项里我顺手把团队内部维护的 FUI 框架启动阶段的装配链路重写了一遍。重写之前FUI 的装配还是典型的反射注册程序集扫描、特性解析、构造函数调用全在启动时发生重写之后这一切被挪到了编译期通过 Source Generator 生成注册代码。整个过程走下来启动装配耗时从 600ms 掉到了 20ms。这篇文章不是讲某个现成框架的用法而是完整记录我自己做编译期装配的技术选型、生成器实现、迁移踩坑和实测数据。C# 项目里被 DI 容器或 UI 注册性能折磨过的同学应该会有些收获。1. 启动热力图上那 600ms 的反射注册到底花在哪了先说清楚背景FUI 是团队内部维护的、基于 C# 的轻量 UI 框架负责界面路由、视图绑定和模块装配。所谓装配就是框架启动时把界面视图、依赖关系、路由信息注册进容器的过程。过去很长一段时间这部分逻辑都跑在运行时结果就是每次冷启动都要白白忙活一阵。1.1 FUI 装配最初的样子特性声明加启动扫描FUI 的设计目标很朴素业务方新加一个界面时只要给类打上一个特性框架就能自动完成注册。开发期的体验确实舒服视图类大概长这样[AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct)] public sealed class FUIViewAttribute : Attribute { public FUIViewAttribute(string alias) { Alias alias; } public string Alias { get; } public string Path { get; set; } default; public int Lifetime { get; set; } } [FUIView(login)] public class LoginView : FUIView { // 登录界面逻辑 }启动时由框架统一扫描程序集var assembly typeof(LoginView).Assembly; foreach (var type in assembly.GetTypes()) { var attribute type.GetCustomAttributeFUIViewAttribute(); if (attribute null) { continue; } var descriptor new FUIViewDescriptor( attribute.Alias, type, attribute.Path, attribute.Lifetime); container.RegisterView(descriptor); }这个模型在模块少、界面少的阶段完全够用启动阶段几十毫秒的消耗根本没人会在意。而且新加一个 View 只需要拖一个类文件进来不用碰任何注册表。也正是这个“零配置”体验让团队迭代速度一直很舒服直到界面数量涨到上百个启动耗时彻底藏不住了。1.2 六百毫秒的去向元数据遍历、特性解析、构造函数调用我对启动链路做了细分计时数据大致如下环节耗时产生原因程序集 GetTypes 遍历约 90ms加载并枚举程序集内全部类型元数据GetCustomAttribute 解析约 180ms每个类型都要实例化特性对象并且走整条反射管线Activator/构造函数调用约 250ms注册时需要拿类型实例或 Type 句柄反射调用开销大注册表构建、别名去重约 80ms字典写入、字符串哈希、描述对象分配同时GC 分配接近 15MB主要来自临时产生的 Type[]、特性实例和大量字符串。这里面最亏的是 GetCustomAttribute 和构造函数调用这两块FUIViewAttribute 里的 Alias、Path、Lifetime 全都是代码里写死的字面量类型之间的引用关系也是编译期就确定的但程序一直到启动那一刻才通过反射把这些明明白白的信息又“重新读了一遍”。1.3 一个关键判断注册清单在编译期就是完整可枚举的决定动手前我先逼自己回答一个问题FUI 的装配到底是不是必须发生在运行时结论是否定的。组装一份注册清单需要的信息无非三类视图类型有哪些、每个类型的元数据是什么、注册的先后顺序是什么。这三类信息在项目编译完成时就已经全部确定了运行时扫描只是把编译期已知的声明再读一遍本质上是在为“开发期少写几行注册代码”买单。这个判断很关键因为它把问题从“怎么优化反射”变成了“怎么把运行时重复劳动挪到编译期”。后者才是更根本的解法。2. 为什么把目标锁定在 Source Generator同赛道方案横评确定“编译期解决”之后我并没有直接冲上去写生成器。先把候选方案都过了一遍包括运行时缓存、T4 模板、手写注册表最后才是 Roslyn 的 Source Generator。每个方案的取舍点值得先展开聊聊。2.1 运行时缓存只解决一半问题当时团队里有人提议把扫描结果静态缓存第二次启动直接读缓存。这个方案实现最简单性能上也能提升不少但它有两个绕不开的问题。第一第一次启动仍然要完整扫描。而客户端冷启动本身就包含大量首次操作用户感知最强的恰恰就是第一次跑起来的耗时第二游戏客户端这类场景里AOT 和代码裁剪非常普遍。反射调用在裁剪后经常拿不到类型缓存也救不回来。这属于只治标不治本直接被我排除了。2.2 T4 和手写注册表维护成本会失控T4 模板虽然也是“生成代码”但它运行在 IDE 或构建脚本里对项目里的类型变动完全无感知。新增一个带 FUIView 特性的类如果不记得跑一遍 T4生成的注册表就是过期的运行时就会报“视图未注册”。刚开始项目里可能只有一两天手动跑一次但一旦模块多了总有人会忘记最终还是会退化成“又慢又错”的状态。手写注册表就更不用提了。上百个 View 来回维护新增时忘写注册、删除时忘删注册都是迟早的事。这类方案不光没有把问题编译期化反而把开发期的维护成本又加了回去。2.3 Source Generator 不可替代的点编译期感知类型变动Source Generator 是 Roslyn 编译管线的一部分它能直接读取语法树和语义模型。新增一个带特性的 View 类下一次编译时生成器就会自动把注册代码补上删除一个类注册代码也会对应减少。它把“类型清单”和“注册代码”始终锁定在同一次编译里从机制上杜绝了注册表过期的问题。还有一点容易被忽略Source Generator 生成的是普通 C# 代码天然参与编译优化。类型是可裁剪的调用是强类型的最终落地到 AOT 环境也没有障碍。正是这两个特性让它成为这次改造的核心方案。3. 动手实现 FUI 装配生成器从收集 FUIView 到产出注册代码这里进入正题。我会按一个最小可用的增量生成器来讲代码都做过简化但结构是真实项目里能跑的。3.1 用 IIncrementalGenerator 搭起骨架生成器需要单独放在一个类库里目标框架建议 netstandard2.0并引用 Microsoft.CodeAnalysis.CSharp 包。入口类长这样[Generator] public sealed class FUIViewRegistryGenerator : IIncrementalGenerator { public void Initialize(IncrementalGeneratorInitializationContext context) { var viewTypes context.SyntaxProvider .ForAttributeWithMetadataName( Fui.Attributes.FUIViewAttribute, predicate: static (node, _) node is TypeDeclarationSyntax, transform: static (ctx, _) GetViewInfo(ctx)) .Where(static info info is not null) .Select(static (info, _) info!); context.RegisterSourceOutput( viewTypes.Collect(), static (spc, infos) GenerateRegistry(spc, infos)); } }在 Roslyn 4.0 之前老接口是 ISourceGenerator。如果项目还停留在旧版本可以用它实现但增量编译效果会差不少。有条件建议直接上 IIncrementalGenerator。3.2 收集视图类型并保留元数据ForAttributeWithMetadataName 是增量生成器里非常顺手的 API它会自动帮我们做语法节点匹配和语义模型解析。transform 阶段拿到的 GeneratorAttributeSyntaxContext 已经带好了特性参数和目标类型符号可以在这里把最终需要的信息一次性抽出来private sealed record ViewToRegister( string FullName, string Alias, string Path, int Lifetime); private static ViewToRegister? GetViewInfo(GeneratorAttributeSyntaxContext context) { if (context.TargetSymbol is not INamedTypeSymbol typeSymbol) { return null; } var attr context.Attributes[0]; var alias attr.ConstructorArguments[0].Value as string; var path attr.NamedArguments.FirstOrDefault(x x.Key Path).Value.Value as string; var lifetime attr.NamedArguments.FirstOrDefault(x x.Key Lifetime).Value.Value as int?; return new ViewToRegister( typeSymbol.ToDisplayString(SymbolDisplayFormat.FullyQualifiedFormat), alias ?? string.Empty, path ?? default, lifetime ?? 0); }注意这里拿到的类型全名要长成global::Fui.Sample.LoginView这样不能只取 typeSymbol.Name因为不同命名空间下完全可能重名。还有一个容易被忽略的细节增量生成器里参与缓存的数据必须实现值相等性否则没法正确判断“这次编译有哪些输入没变”。所以我特意把 ViewToRegister 定义成了 record值相等是默认行为如果定义成普通 class 而不重写 Equals/GetHashCode生成器会退化成每次全量执行增量优化就白做了。3.3 生成 partial FUICompositionRoot 注册代码收集完信息就可以把注册代码拼出来。生成代码的原则是只生成容器注册调用不覆盖任何用户手写的逻辑。因此我选择生成一个 partial 静态类用户可以在另一个同名的 partial 类里写自己的扩展注册。private static void GenerateRegistry( SourceProductionContext spc, ImmutableArrayViewToRegister infos) { var writer new StringBuilder(); writer.AppendLine(// auto-generated /); writer.AppendLine(namespace Fui.Generated); writer.AppendLine({); writer.AppendLine( public static partial class FUICompositionRoot); writer.AppendLine( {); writer.AppendLine( public static void RegisterViews(FUIContainer container)); writer.AppendLine( {); foreach (var view in infos) { writer.AppendLine( container.RegisterView(new FUIViewDescriptor(); writer.AppendLine($ \{view.Alias}\,); writer.AppendLine($ typeof({view.FullName}),); writer.AppendLine($ \{view.Path}\,); writer.AppendLine($ (ViewLifetime){view.Lifetime}));); } writer.AppendLine( }); writer.AppendLine( }); writer.AppendLine(}); spc.AddSource(FUIViewRegistry.g.cs, writer.ToString()); }生成结果大致是// auto-generated / namespace Fui.Generated { public static partial class FUICompositionRoot { public static void RegisterViews(FUIContainer container) { container.RegisterView(new FUIViewDescriptor( login, typeof(global::Fui.Sample.LoginView), default, (ViewLifetime)0)); } } }这段代码放到客户端启动流程里在最前面调用一次即可。因为全部是显式类型引用和直接方法调用编译器可以做正常裁剪运行期也彻底没有了反射调用。3.4 给生成器加编译期诊断把错误提前暴露既然已经能拿到语义模型就不要只闷头生成代码。我在生成器里加了几个 Diagnostic把过去运行时才暴露的问题提前到编译期FUIViewAttribute 用在接口或抽象类上直接报编译错误。视图别名重复报编译错误并列出两个类型的完整名称。特性参数是 null报编译警告提示检查别名是否漏填。这些诊断的成本几乎为零但能省掉后面大量联调时间。运行时崩溃变成编译期报错这件事越早做越值。4. 生成代码和容器对接兼容旧逻辑的过渡方案替换装配链路不能上来就一刀切。反射版本跑了那么久里面可能藏着一些隐性的顺序依赖和行为细节直接删掉风险太高。我采用了双轨并行确保任何时刻可以一键回退。4.1 统一注册入口按程序集做命名空间隔离FUICompositionRoot 本身是 partial 类用户侧可以在另一个同名 partial 类里写手动扩展注册生成文件里的内容不会覆盖这些手写逻辑。多程序集场景下每个程序集分别生成一个 RegisterViews 方法放在各自程序集专属的命名空间里模块初始化时自行调用自己的根。这个设计解决了一个很实际的问题生成器不知道用户想在注册前后做什么。有的人需要先订阅某个事件再注册视图有的人需要注册后追加路由规则。保留 partial 入口就是保留和现有容器逻辑的对接空间。4.2 条件编译开关控制反射逻辑的去留迁移的前几个版本我保留了旧的反射装配方法但用一个编译常量控制走哪条路#if !DONT_USE_SOURCE_GENERATED_REGISTRY Fui.Generated.FUICompositionRoot.RegisterViews(container); #else AssemblyReflectionRegistrar.RegisterAllViews(container); #endif这样回归测试时可以随时切回旧逻辑对比行为。万一新逻辑漏了某个注册也能快速定位是不是反射顺序导致的。等线上跑过两三个版本确认没有差异后再把反射相关代码整体删掉。4.3 更进一步连视图工厂也编译期生成反射注册里开销最大的其实是 Activator.CreateInstance。很多框架注册完类型之后运行期加载界面时还会再反射一次创建实例。迁移期我把这块也一起处理了生成器为每个 View 生成一个静态工厂方法private static global::Fui.Sample.LoginView CreateLoginView() new global::Fui.Sample.LoginView();注册时直接把方法组传给容器container.RegisterView(new FUIViewDescriptor( login, typeof(global::Fui.Sample.LoginView), default, (ViewLifetime)0, new ViewFactoryFUIView(CreateLoginView)));这样一来连创建实例都不走反射了AOT 和代码裁剪环境下也彻底放心。5. 迁移路上翻过的车五个值得记下来的细节这一节才是真正的实战部分。理论讲得再好落地时照样会遇到一堆莫名其妙的问题。我把这次迁移过程中踩过的坑按价值从高到低列一下。5.1 注册顺序依赖丢了被两个页面替身坑了一次旧反射实现依赖 Assembly.GetTypes() 的返回顺序。团队里有些模块是靠“后注册覆盖先注册”来实现默认视图替换的。生成器并行收集之后顺序完全不确定迁移第一天就有两个页面被替换错了线上数据直接异常。解决办法是给特性加一个显式的排序字段并让生成器在输出前按这个字段统一排序[FUIView(home, Order 10)]收集阶段把 Order 读出来生成时按 Order、命名空间、类型名排序后再输出。这是所有从反射迁移到编译期的项目最容易忽略的问题强烈建议一开始就给特性预留排序键。5.2 类型全名不能漏 global:: 前缀最开始生成代码里直接写 typeSymbol.Name遇到嵌套类、不同命名空间同名类很快翻车。后来全部改成SymbolDisplayFormat.FullyQualifiedFormat它输出的形式是global::Fui.Sample.LoginView。加上这个前缀能避开一切歧义无论是嵌套类型还是跟 using 引入的同名类型冲突都不会再有问题。5.3 增量生成器加载失败时错误指向非常迷第一次接入时生成器引用没配对编译报“FUICompositionRoot 不存在”。这个报错其实是正常的因为项目根本没有生成任何代码。排查方向有这么几个确认生成器项目引用了 Microsoft.CodeAnalysis.CSharp 包并且版本和主项目的 Roslyn 版本匹配在生成器项目里写一个临时 flag 文件通过环境变量控制是否把生成内容额外输出一份到磁盘方便检查开发阶段可以用 Debugger.Launch() 挂调试器但是提交前一定要删掉否则 CI 构建会卡住。5.4 多程序集重复注册FUI 允许把 View 拆分到多个程序集生成器会分别收集。如果同一个类型被多个特性标注生成代码里就可能出现重复注册。我在生成器里按类型全名做了去重并在发现重复时生成一个编译期错误诊断提示开发者检查是否贴了多个特性。这件事越早知道越好否则运行时容器会一脸茫然地接受两个描述符等到使用时才暴露出别名指向问题。5.5 老框架版本兼容问题IIncrementalGenerator 需要 Roslyn 4.0 配合。如果合作项目还在旧版 IDE 或者老 .NET 版本时代建议留一个基于 ISourceGenerator 的兼容实现。旧接口 API 简陋一些但核心功能都能做只是增量编译的性能差不少。实际做法是用条件编译符号在不同项目里各取所需保证老项目也能享受到编译期装配的好处。6. 迁移后的实测性能提升之外还捡到了什么数据是迁移最有说服力的部分。我拿同一份 UI 模块分别跑反射注册版本和编译期装配版本结果如下指标反射注册编译期装配启动装配耗时约 600ms约 22msGC Alloc约 15MB0MB注册表自身少量对象除外首次打开页面耗时约 120ms约 35ms错误发现时机启动或运行时编译期6.1 性能对比为什么差距能拉得这么大生成版本里剩下的 22ms主要是容器注册表构建本身的开销包括字典写入、哈希计算这些没法再省的基础操作。而反射版本多出来的那些毫秒几乎全部消耗在元数据遍历、特性实例创建和反射方法调用上。这两类开销在编译期方案里根本不存在的。6.2 构建时长增加多少值不值迁移后全新编译大约增加了 400ms增量编译因为增量缓存的存在只增加了 30ms 左右。对 CI 来说完全可接受。这里要特别提醒生成器自身如果收集逻辑写得不好比如在 transform 阶段做复杂度很高的语义分析会让 IDE 的 IntelliSense 明显变卡。优先使用 ForAttributeWithMetadataName少手动遍历 SyntaxTree是保住编辑器流畅度的关键。6.3 运行时崩溃变成编译期报错收益最实在生成器里那几条编译期诊断上线后帮我们逮住了不少问题。过去最容易犯的两类错误把 FUIView 特性写到接口上、别名重复。这些在反射时代都要等到启动装配那一刻才会崩溃现在写错代码直接编译不过测试反馈链路缩短了一大截。6.4 给生成代码加一道 CI 兜底检查建议在 CI 构建脚本里加一步生成代码变更检查正常执行一次构建然后 git diff 生成目录如果发现 .g.cs 文件有未提交的变动就直接失败。这能防止有人改了特性定义或者生成器逻辑却忘了提交对应的生成结果。看起来是个笨办法但对团队协作场景特别管用。7. 编译期装配的思路其实不局限于 UI 框架FUI 迁移做完后我复盘了一下这套方法本质上是一个通用模式任何“运行期扫描 反射调用”的注册工作都可以尝试编译期化。而且判断标准非常清晰——注册信息在编译期是不是已经完全确定了。7.1 可复用的场景清单我顺手梳理了团队里其他可以套用同样思路的地方消息处理器注册EventBus 启动时扫描 IMessageHandler 实现类完全可以生成显式注册表模块启动器排序模块之间的依赖关系是静态的排序逻辑放到编译期生成启动时少做一堆反射读取特性API 端点自动发现类似 ASP.NET Core 的 Controller 发现机制控制器类型和路由特性在编译期都是确定的数据迁移脚本扫描数据库迁移版本列表完全可以在编译期确定根本不需要运行时去读程序集配置文件绑定模型注册一个 POCO 对应一个配置节编译期直接生成绑定代码省掉一堆属性反射。这些场景的共同点和我前面判断 FUI 时一模一样运行时扫描只是在重复劳动而编译期已经把答案写好了。7.2 下一步把依赖注入解析也搬进编译期FUI 目前还残留了一块反射在构建阶段容器解析构造函数参数时仍然通过反射读取参数列表。我正打算把构造参数提取也挪进生成器为每个类型生成一个强类型的解析方法让整个装配链路彻底告别反射。做完这一步启动链路和首次页面打开链路里就再也找不到 Type.GetMethods 或 Activator.CreateInstance 了。从我个人的实际体会来看改到这一步最重要的收获还不是省出的那几百毫秒而是整个装配过程变得可理解、可调试、可裁剪了。现在团队里每次讨论要不要再加一个运行时特性我都会先问一句这个信息编译器是不是已经知道了如果答案是肯定的那它就不该等到运行时再去翻兜。7.3 不是所有反射都要消灭知道什么时候停手编译期装配也不是银弹。插件系统、热更新模块、用户自定义类型的加载这些动态场景在编译期确实拿不到类型清单强行生成代码只会把架构搞复杂。我的经验是判断标准不是“性能差就编译期化”而是“这段信息在编译期是否已经确定且有穷尽”。如果是就值得搬如果不是保留反射反而是正确设计。把握好这个边界Source Generator 才能用在刀刃上。