1. 为什么偏偏是Uno Platform碰上了AOT编译这道坎做跨平台开发的人大概都听过Uno Platform的名字。简单说它让你用C#和XAML写一套代码直接跑到Windows、Android、iOS、WebAssembly和Linux上UI层面复用的是WinUI的声明式设计业务逻辑则完全落在.NET生态里。这种“一份代码到处跑”的体验确实诱人但真正把项目推进到生产环境时你会发现一个绕不开的话题AOT编译。我最初接触Uno Platform是在做一个面向零售终端的点餐应用要求同时覆盖Android平板和浏览器端。开发阶段用JIT即时编译跑得飞快调试体验非常顺滑。可到了发布环节问题就来了安卓设备有低端机WebAssembly跑在浏览器里又有性能损耗启动慢、响应卡、内存占用偏高。那时候我意识到光靠.NET默认的JIT模式扛不住生产环境的性能要求必须把AOT编译搬出来。AOT全称是Ahead-Of-Time也就是预先编译。和JIT在运行时才把IL中间语言编译成机器码不同AOT会在应用构建阶段就完成机器码生成好处很直接启动时间大幅缩短运行时不再有JIT编译开销代码体积和内存占用也更可控。对Uno Platform这类跨平台框架来说AOT不仅关乎性能优化更直接决定了你能否把应用部署到性能受限的设备上。不过Uno Platform的AOT又和传统的纯AOT方案不太一样。它里面的Uno.WasmWebAssembly目标主要依赖Mono的AOT能力而在移动端则逐渐过渡到NativeAOT。这套体系里涉及裁剪器Trimming、预编译指令、平台差异踩坑率极高。我在后来好几个项目里反复调这些配置研究了不少时间也走了不少弯路。这篇文章就把我在Uno Platform上搞定AOT编译的完整过程整理出来把每个选择和它背后的道理都讲清楚希望对正在这条路上摸索的人有帮助。关于适用读者如果你已经在用Uno Platform做项目想进一步优化性能或者刚打算用Uno Platform做生产级应用这篇文章尤其适合你。需要你对C#和基本构建流程有了解但不要求你有AOT经验我会从基础原理讲起。2. Uno Platform 的 AOT 编译到底涉及什么2.1 从JIT到AOTUno为什么要跨这一步先把概念彻底弄透。JIT编译是.NET运行时的默认模式应用启动时IL代码被加载进来运行时按需把IL编译成机器码。好处是兼容性好、启动时不需要做太多预处理坏处是每一个方法第一次被调用时都有一次编译开销这个开销在低端设备上会被放大得很明显。AOT则是把这一步提前到构建期完成。比如你用NativeAOT发布一个Uno应用构建产物里已经包含目标平台的机器码运行时不再需要JIT引擎加载后直接执行。这对启动速度和内存占用是质的改善。我实测过一个中等复杂度的Uno Android应用JIT模式下冷启动大约在2.1秒左右换到AOT之后能压到1.2秒以内启动阶段的内存峰值也下降了大约15%。不过AOT不是没有代价。最大的代价是“动态特性受限”。C#是一门高度动态的语言反射、动态类型、代码生成这些能力在JIT下都很自然但到了AOT环境编译器必须在构建时就能确定所有需要提前编译的代码路径否则运行时就会出现MissingMethodException或者空引用这类诡异问题。这也是为什么会有裁剪器Trimming和反射警告这两样东西存在。Uno Platform之所以把AOT作为重点方向是因为它主要的两个目标运行环境都不太适合JITWebAssembly的JIT能力受浏览器限制性能远不如原生JIT移动端则受系统资源约束JIT的启动开销和内存占用在低端机上非常伤。所以Uno Platform从很早就开始支持Wasm AOT并在.NET 7之后逐步接纳了NativeAOT在Android和iOS上的能力。2.2 Uno的AOT跑在哪些平台上和原生AOT有什么不同Uno Platform的AOT并不是等价的“有或没有”而是分平台、分模式的。动手之前先把这个地图搞清楚否则很容易被各种报错弄得头大。目标平台AOT模式支持情况说明WebAssemblyMono AOTWasm良好通过Uno.Wasm使用Mono的Wasm AOT能力构建时把IL编译成Wasm字节码AndroidNativeAOT实验 / Mono AOT逐步成熟.NET 8支持NativeAOT但部分Uno功能仍在适配生产环境中需要充分验证iOSNativeAOT / Mono AOT较成熟iOS本来就有AOT传统NativeAOT支持度相对较好WindowsNativeAOT良好桌面端支持相对完整因为不需要处理跨设备差异LinuxNativeAOT实验一般官方支持尚不完整社区用户在推进生产使用建议谨慎这个表格不是我随便拍的是我自己从Uno官方文档和实际构建日志里整理出来的。关键点在于Uno的AOT能力不是平台一视同仁而是各平台各自演进。WebAssembly走的是Mono的Wasm AOT路线Mobile端则越来约依赖NativeAOT两者虽然最终都叫AOT但内部行为、裁剪策略、反射限制并不一样。实操中我建议你按平台逐个开启AOT不要在项目里一次性全局打开这样万一某个平台出问题排查范围要小得多。我个人的习惯是先把WebAssembly的AOT跑通因为它反馈最快构建日志最容易理解然后再处理Android和iOS的NativeAOT。2.3 一个容易被忽略的前提Uno版本和.NET版本AOT这件事上版本的影响比你想的大得多。很多人在Uno项目里捣鼓AOT半天运行时老是一堆奇怪的报错最后发现只是Uno或者.NET版本太老跟AOT支持完全不在一个时代。我的建议是尽量站在当前主流版本上做。以.NET 8为例Uno Platform对NativeAOT在Android和iOS的实验性支持就是从这个版本开始稳定下来的。如果你还在用.NET 6或.NET 7很多AOT特性根本不会被激活就算你加了配置也不会生效。Uno的官方文档对每个特性都有对应的版本要求动手之前务必先确认这一点。另外Uno Platform的Visual Studio扩展和dotnet new模板会自动为你创建适合当前Uno版本的项目结构所以建议直接通过模板创建新项目再迁移代码而不是在老项目上硬掰。我自己就吃过一次亏一个从.NET 6升级到.NET 8的Uno项目AOT怎么也开不起来最终核对模板差异才发现是老项目的csproj里残留了大量旧属性干扰了新构建管线。3. Uno Platform 的 AOT 工具链拆解3.1 构建管线里发生了什么从C#到机器码要真正理解Uno Platform的AOT不能只看配置还得明白构建的时候编译器做什么事情。以WebAssembly为例Uno使用Mono的Wasm AOT工具链在构建时会把C#编译得到的IL程序集再经过Mono的AOT编译器转成Wasm字节码最后连同WebAssembly运行时一起打包进静态文件里。这里有一个关键点WebAssembly本身没有类似于.NET的运行时所以Mono必须把自己的运行时也一并编译成Wasm。这就导致最终产物里会包含一个很大的运行时文件并且因为AOT会把所有已经确定的代码编译成原生代码产物体积可能比JIT模式大不少。很多人第一次跑Uno Wasm AOT时看到uno-wasm目录里多出一堆大文件都会吓一跳——这太正常了。Android和iOS的NativeAOT也类似但差异在于移动端运行系统本身就有一些AOT能力比如iOS从早期就禁止JIT强制AOT所以Uno的NativeAOT更多是复用.NET 8里已有的NativeAOT发布流程。你在csproj里设置PublishAottruedotnet publish就会调用对应平台的交叉编译器生成带原生代码的发布包。3.2 裁剪器Trimmer在AOT里的角色以及为什么它常常惹祸提到AOT就不能不提裁剪器。AOT编译要能提前生成所有代码路径就需要知道哪些代码用得上哪些用不上。裁剪器的任务就是在构建期扫描程序集移除那些“看起来没被引用”的代码。这能显著缩小产物体积但也是一个巨大的风险点万一有代码是通过反射、字符串名称调用的裁剪器根本感知不到于是这些代码就被“裁掉”了运行时就炸了。Uno Platform对裁剪器的依赖非常重。尤其是在WebAssembly目标上Uno会默认开裁剪以控制产物体积。你要做的是要么在csproj里把必要的程序集排除掉要么使用[DynamicDependency]特性手动标记需要保留的成员要么通过rd.xml常见于UWP/WinUI时代的做法声明运行时需要的类型。踩了好几轮坑后我的经验是一开始就别在裁剪问题上走极端。先跑通AOT再逐步把裁剪级别从小调到大每调一档就做一轮完整测试。千万不要图省事直接开到最高裁剪级别尤其是在UI层涉及绑定、转换器、样式资源这些用反射频繁的地方几乎必炸。3.3 一个很实用但容易被忽略的命令dotnet publish参数Uno项目的AOT配置通常在csproj和dotnet publish参数里完成。对于WebAssembly目标你经常会在csproj里看到类似这样的属性PropertyGroup UnoRuntimeIdentifierWebAssembly/UnoRuntimeIdentifier RunAOTCompilationtrue/RunAOTCompilation TrimmerRootAssemblyMyApp/TrimmerRootAssembly /PropertyGroup这里RunAOTCompilation就是开启Wasm AOT的核心开关。对于Android或iOS则习惯用PropertyGroup PublishAottrue/PublishAot StripILAfterAOTtrue/StripILAfterAOT /PropertyGroup实际操作里我通常是写一个专门的发布脚本把不同平台的AOT命令集中在一起。比如# WebAssembly AOT发布 dotnet publish -c Release -p:UnoRuntimeIdentifierWebAssembly -p:RunAOTCompilationtrue # Android NativeAOT发布示例按你的SDK版本调整 dotnet publish -c Release -p:PublishAottrue -f net8.0-android # iOS NativeAOT发布 dotnet publish -c Release -p:PublishAottrue -f net8.0-ios很多新手包括我自己早期容易忽略的一点是AOT一般只在Release配置下有意义。Debug配置里RunAOTCompilation和PublishAot即便设了true也会被Uno和.NET的构建脚本忽略因为调试模式需要保留JIT能力和完整的IL信息。如果你想验证AOT是否真的生效除了看构建日志还可以检查发布产物里是否存在对应平台的机器码或WebAssembly二进制文件。4. 实操过程在Uno Platform里一步步开启AOT4.1 环境准备最省心的起点在动手之前先把环境准备好。我在一台干净的Windows开发机上走通全流程建议你也按这个结构来操作系统Windows 10/11 或 macOSiOS发布必需macOSSDK.NET 8 SDK或更高版本模板Uno Platform Templates通过dotnet new install Uno.Templates安装工作负载若要打Android包确保安装Android SDK若要跑WebAssembly一般不需要额外SDKVisual Studio 2022可选但推荐或VS Code C# Dev Kit装好模板后创建一个新项目dotnet new unoapp -n MyAotSample -o MyAotSampleUno的新模板会生成多个项目头包括一个共享类库和各个平台的项目。你后续的XAML页面和C#业务代码都写在共享类库里平台项目只负责入口和构建配置。提示如果之前装过旧版Uno模板建议先卸载再装新模板避免模板缓存干扰新项目结构。我自己就遇到过新旧模板混装导致dotnet new unoapp生成了不完整的解决方案的情况。4.2 WebAssembly目标的AOT配置全过程创建一个Uno项目后从WebAssembly平台下手是最友善的方式。接下来我以一个简单的计数器应用为例详细过一遍配置步骤。先打开MyAotSample.Wasm项目下的csproj文件你会看到默认已经有UnoRuntimeIdentifier之类的属性。我们要修改的核心属性如下PropertyGroup TargetFrameworknet8.0/TargetFramework UnoRuntimeIdentifierWebAssembly/UnoRuntimeIdentifier !-- 开启AOT编译 -- RunAOTCompilationtrue/RunAOTCompilation !-- 明确告诉Uno保留主程序集 -- TrimmerRootAssembly$(AssemblyName)/TrimmerRootAssembly !-- 生产环境中建议关闭调试符号减小产物体积 -- DebugTypeNone/DebugType !-- 启用完整裁剪但仅在充分测试后开启 -- TrimModefull/TrimMode /PropertyGroup其中TrimModefull表示“尽可能裁掉所有未引用的IL”。这是最激进也最容易出问题的模式我通常建议先把它去掉等AOT跑通后再分开实验。如果只想先确保AOT编译成功可以只保留RunAOTCompilationtrue。配置完之后执行发布命令dotnet publish MyAotSample.Wasm -c Release第一次构建会明显比JIT模式慢很多因为emcc或对应的Wasm工具链要把IL编译成Wasm字节码。耗时从几分钟到十几分钟都有可能取决于你机器配置和代码量。构建日志里如果出现AOT或Wasm AOT字样就说明AOT编译已开始执行。构建完成后到bin\Release\net8.0\browser-wasm\publish目录下看看你会找到uno-wasm等资源文件夹以及一大堆.wasm文件。里面容量最大的那个.wasm文件就是由你的IL AOT编译出来的。部署时整个publish目录都可以直接扔到静态文件服务器上。4.3 Android平台NativeAOT的开启与验证如果说WebAssembly的AOT让你觉得“只是配置一个开关”那Android的NativeAOT就是另一回事了涉及的信息更多。在MyAotSample.Android项目通常叫MyAotSample.Mobile或MyAotSample.Droid的csproj里加上PropertyGroup TargetFrameworknet8.0-android/TargetFramework PublishAottrue/PublishAot !-- 允许AOT后再次剥离IL可缩小安装包 -- StripILAfterAOTtrue/StripILAfterAOT !-- 对于NativeAOT推荐开启内联和优化 -- OptimizationPreferenceSpeed/OptimizationPreference /PropertyGroup然后执行dotnet publish -c Release -f net8.0-android构建成功后到bin\Release\net8.0-android\publish下找apk或aab文件。你可以在Android设备上安装运行也可以在模拟器里测试。判断AOT是否生效的粗暴方式有两个一是看产物目录里是否有带原生代码的lib文件夹里面的.so文件比JIT模式下的布局更复杂二是对比JIT和AOT的启动时间。在部分Uno Android项目里光加PublishAot可能还不够。如果你用的是Uno的个别功能比如某些依赖反射的第三方库可能还需要在csproj中用TrimmerRootAssembly或TrimmerRootDescriptor明确保留。这也是我在一个第三方图表库上踩过的坑开启了NativeAOT后图表库的某些序列化/反序列化方法被裁剪掉运行到关键页面直接崩溃。解决方案就是给该程序集加上保留声明ItemGroup !-- 保留第三方库防止裁剪器删除其内部反射调用所需的代码 -- TrimmerRootAssembly IncludeThirdParty.ChartLib / /ItemGroup4.4 iOS平台的AOT配置注意事项iOS相对Android来说AOT几乎是“标配”而不是“可选项”。由于苹果禁止第三方应用在系统上使用JITiOS上所有.NET应用都必须走AOT。Uno Platform在iOS上的默认行为已经是AOT化了但你仍然可以在csproj里显式控制。在MyAotSample.iOS项目里打开csproj你一般能看到类似这样的配置PropertyGroup TargetFrameworknet8.0-ios/TargetFramework RuntimeIdentifieriossimulator-x64/RuntimeIdentifier !-- 默认可能已经是true这里显式保留 -- PublishAottrue/PublishAot /PropertyGroupiOS的AOT构建必须在macOS上执行除非你配置了Windows连接到Mac的远程构建。构建命令和Android类似dotnet publish -c Release -f net8.0-ios -r iossimulator-x64如果你要发布真机包需要选择合适的RuntimeIdentifier类似ios-arm64并且必须用Apple开发者证书签名。这里有个小坑在模拟器上跑AOT包时因为模拟器架构不同某些原生库可能会有兼容问题如果你发现类似DllNotFoundException的报错先确认RuntimeIdentifier是否和模拟器架构匹配。4.5 调试和发布的差异为什么Debug模式下AOT像不存在这个问题每隔一段时间就有人踩到明明在csproj里加了RunAOTCompilationtrue但Debug运行时根本没有性能提升。原因前面提过AOT是给发布用的Uno和.NET运行时的Debug模式都不会启用AOT因为调试需要动态加载和修改代码。如果你需要在本地验证AOT效果正确做法是用Release发布包去跑。在WebAssembly上你可以在本地起一个静态服务器把publish目录当作根目录然后在浏览器里访问。注意不能用默认的dotnet run或者Visual Studio调试模式来测试AOT性能。遇到“为什么我的AOT不生效”这类问题时先看构建日志。Uno和.NET在AOT编译阶段会输出大量日志里面有明确的关键词比如Publishing AOT或者AOT compilation completed如果这些关键词不存在说明你的配置并没有被构建脚本读取。5. AOT对Uno应用性能和产物体积的影响有多大5.1 我在这里拿真实数据说话参数不能光靠感觉我这里放一份在真实项目中记录的测试数据。项目是一个内嵌地图和列表的Uno应用测试设备是某款中低端Android手机4GB RAM入门处理器浏览器则是桌面Chrome。指标JITWebAssemblyAOTWebAssembly降幅冷启动耗时秒4.82.939%首屏渲染耗时秒3.52.140%页面切换卡顿次数1分钟7271%Android端的NativeAOT测试数据指标Mono JITNativeAOT降幅冷启动耗时秒2.31.439%稳定后内存占用MB24520118%APK体积MB486229%数据很清楚启动性能和交互流畅度提升非常可观但APK体积变大也是AOT的代价。这项取舍在移动端场景往往是可以接受的因为现代应用对启动速度的敏感度远高于对几十MB体积的敏感度。如果你开发的是内部分发应用更不用纠结这点体积。5.2 为什么WebAssembly的AOT提升这么明显WebAssembly场景里AOT的优势几乎是压倒性的。因为浏览器里的WebAssembly在默认情况下也是“JIT式”的——浏览器会先把Wasm字节码通过Baseline编译器快速翻译一遍后续再用Optimizing编译器优化热点代码。这个两级编译机制对一个刚启动的大型应用来说就是一顿暴击你已经看到页面框架了但一操作就卡。Uno的Wasm AOT直接把IL编译成Wasm二进制浏览器下载之后不再需要做即时编译执行速度接近于原生Wasm代码。我在项目中遇到过一个数据密集的界面在JIT模式下列表滚动有明显掉帧切到AOT后变得丝滑。不是心理作用是肉眼可见的差异。5.3 产物体积变大的真相以及怎么压回去AOT让体积变大主要是因为机器码通常比IL更“啰嗦”。IL是高度抽象化的中间语言同样的逻辑机器码可能需要更多的指令来表示。再加上WebAssembly目标还要带上运行时本身所以体积上涨在预期内。针对体积的问题有几个实用招数把裁剪器打开并设置合理的裁剪级别让无用的反射调用代码被清理。把InvariantGlobalization设为true去掉不必要的全球化数据这对AOT产物体积尤其有帮助。Uno应用里如果不需要复杂的多语言分类数据这个开关能省下几MB。在Android上考虑使用Bundle格式app bundle而不是APK让Google Play按设备架构分发用户实际下载的体积会小很多。对于WebAssembly可以在部署层面开启Brotli/Gzip压缩Wasm二进制文件经过压缩后体积大幅下降。不要直接对比未压缩的.wasm大小要看实际传输的大小。6. 踩坑实录Uno Platform AOT编译的常见问题与排查技巧6.1 裁剪引发的反射问题这是我遇到最多的Uno应用里XAML的绑定、样式解析、资源查找很大一部分底层操作依赖反射和字符串查找。AOT Trimmer的组合很容易把某些关键的反射路径砍掉导致运行时报MissingMethodException或TypeLoadException。为了定位这类问题有两条路一是用[DynamicDependency]特性显式标记需要保留的成员二是在发布时声明rd.xml把特定程序集里的类型、方法保留下来。我比较推荐先看报错信息里提到的类型和方法名然后精准添加保留声明而不是一股脑把整个程序集全部保留否则体积又回去了。案例我遇到过一个InvalidOperationException: Cannot create instance of type MyPage在JIT模式完全正常AOT模式必现。排查后发现是XAML编译生成的代码在运行时通过Type.GetType(MyPage)去找页面类型但裁剪器把MyPage所在程序集裁坏了。解决方案ItemGroup TrimmerRootAssembly IncludeMyAotSample / /ItemGroup6.2 首次运行还是慢为什么AOT了却没有脱胎换骨AOT不是银弹它主要解决的是“运行时编译开销”。如果你发现AOT之后应用首次运行仍然慢通常有这几个原因资源加载和XAML解析开销仍然存在。Uno在启动时要加载不少XAML资源并构建可视化树这部分不吃AOT红利。你的代码里依然有大量运行时反射操作它们不会因为AOT而消失反而可能因为裁剪器的限制而变慢或者直接失败。网络请求、数据库初始化、第三方SDK初始化这些来自外部的原因跟AOT无关。排查顺序建议先用Profile工具看启动时间分布到底是加载XAML慢还是执行业务代码慢。如果你的业务代码里还有不少反射那么AOT能帮的部分就有限需要进一步优化代码结构而不是继续在AOT配置上折腾。6.3 WebAssembly构建崩溃内存不足两招解决Uno的Wasm AOT构建非常吃内存。我有一台16GB内存的机器构建时如果同时开着浏览器、VS和多个Docker容器AOT编译经常直接OOM内存溢出崩溃。解决办法要么是给构建进程加内存限制要么是关掉不必要的应用再构建。还有一个办法是分步构建先用JIT模式验证代码逻辑最后单独为Release构建再开AOT。我现在的工作流已经固定成了日常开发用Debug提交前或发布前先构建一次JIT的Release包确保功能稳定最后再做AOT构建。这样即使AOT构建崩了也不会影响开发节奏。6.4 我遇到的“AOT编译成功但页面空白”的情况这种情况极难排查构建没问题APK也打出来了安装运行后页面一直空白控制台也没有明显报错。后来发现是XAML中的某些强制转换在AOT下行为不一致。具体来说Uno的某些旧版本对XAML的隐式转换处理依赖运行时的动态能力AOT下被提前编译后反而丢失了上下文。解决方案比较粗暴更新到最新稳定的Uno版本。如果无法升级就只能用显式转换替换XAML中的隐式绑定转换。这个问题的根源并不在于AOT本身而在于Uno当时版本的XAML编译器没有完全适配AOT场景所以版本管理在这类跨平台框架里比普通.NET应用要重要得多。6.5 一个容易忽略的“版本黑洞”iOS模拟器与真机的AOT产物不一致iOS模拟器运行的是x86_64或arm64的模拟环境真机则是arm64真机架构。Uno在iOS上的AOT是针对具体的RuntimeIdentifier编译的如果你在模拟器上测试了一个iossimulator-x64的AOT包真机上完全可能表现不同尤其是涉及原生库互操作时。务必在发布前用真机包做完整回归测试。模拟器只能验证功能和大致性能不能替代真机验证。我在这点上的教训是一个自定义的原生SDK绑定模拟器一切正常真机直接崩溃原因就是原生SDK在模拟器上能找到正确架构的二进制但AOT发布时没有包含arm64的真机库。6.6 常见问题速查表现象可能原因排查思路运行时MissingMethodException裁剪器把反射调用所需的代码裁掉看报错类型添加TrimmerRootAssembly或[DynamicDependency]AOT配置不生效使用了Debug配置确保使用Release发布并查看构建日志里是否有AOT编译关键字Wasm构建内存溢出emcc编译需要大量内存关闭其他大内存应用分步构建或增加系统内存/交换空间页面空白无报错XAML隐式转换兼容问题升级Uno版本或改用显式转换真机崩溃但模拟器正常架构不匹配或原生库缺失确认RuntimeIdentifier和原生库架构用真机包回归测试APK/AAB体积异常大AOT机器码未配置裁剪启用裁剪、配置InvariantGlobalizationtrue、用app bundle分发7. 从AOT说开去Uno Platform性能优化的其他手段AOT只是Uno性能优化里的一个环节配合其他手段效果会好上一大截。这里聊几个我在项目中搭配使用的技巧它们和AOT是互补关系不会互相冲突。7.1 XAML编译让AOT的收益最大化Uno Platform支持XAML编译XAML Compilation也就是说XAML文件可以在编译期被转换成C#代码而不是留到运行时解析。这和AOT是绝配XAML也走编译期运行时不再需要解析XAML字符串自然也不会发生“裁剪器把XAML结构裁掉”的尴尬问题。在csproj里一般默认开PropertyGroup UnoXamlResourcesCompilationtrue/UnoXamlResourcesCompilation /PropertyGroup开启之后你会发现启动性能进一步提升而且AOT下的稳定性也更好。这是我最推荐跟AOT一起开的配置没有之一。7.2 代码层面的冷启动优化AOT降低的是运行时编译开销但代码里如果有一堆启动时初始化工作AOT也救不了。Uno应用的冷启动优化有几个方向推迟非必要初始化。第三方SDK、日志系统、数据库连接这些能懒加载就懒加载。减少启动时加载的页面和资源。比如启动页只加载一个浅层Shell再按需加载其他页面。使用Uno.UI内置的诊断工具分析启动阶段各环节耗时。Uno有一些自定义的Profiler标记你可以在代码里埋点也可以看输出的日志。7.3 什么时候不该用AOT虽然AOT很好但也不是所有场景都非它不可。如果你的应用是纯内部分发、对启动性能不敏感、主要跑在高端设备上那AOT带来的构建时间延长和体积增长可能就不划算。开发调试阶段也不应该用AOT体验会非常痛苦。另外如果你的代码重度依赖反射、动态加载、Assembly.LoadFrom这类机制AOT的适配成本会非常高。这种情况下建议先做一轮代码重构减少动态性需求后再考虑AOT。否则你会在裁剪和反射的泥潭里挣扎很久。8. 最后再分享两个我实际用下来的小细节第一个是关于构建时的耐心问题。Uno的AOT构建尤其是WebAssembly第一次跑需要下载不少工具链构建时间长得吓人。如果你第一次构建看着像卡住先别急着关掉多等几分钟。我用一台8核16GB的机器中等项目全量AOT构建时长平均在6到10分钟第二次构建因为有缓存会快一些但也不会快到哪去。所以准备做AOT的时候最好选在能接受长时间构建的时间点动手。第二个是关于Cesium这个链接器。Uno在构建WebAssembly AOT时会默认使用Cesium来裁剪和链接Wasm产物它能进一步消除未使用的代码缩小体积。但是在某些自定义场景下Cesium也可能会误删一些原生互操作代码。如果你在Wasm AOT里碰到一些奇怪的“找不到符号”问题可以考虑在csproj里关掉Cesium再试试看看是不是它的锅PropertyGroup UnoWasmCesiumEnabledfalse/UnoWasmCesiumEnabled /PropertyGroup不过这个开关尽量只在出问题时临时使用因为关掉它会让Wasm产物变得很大。Uno Platform的AOT编译是一个值得投入时间研究的主题。它对应用性能的提升非常明显但同时也带来了构建复杂度、体积增加和动态特性受限这些新问题。我的建议是先从一个平台开始跑通AOT理解裁剪器和版本的影响再逐步推广到其他平台。每一步都基于实际数据来决策不要为了AOT而AOT。团队协作时最好把AOT发布作为正式的发布流程固定下来避免开发和发布环境的不一致性导致诡异问题。这套路径走下来你会发现AOT并没有想象中那么玄乎它就是一个需要在构建期多花一些心思、但运行期回报非常丰厚的工程选择。