Uno Platform AOT 编译支持全景研究：跨平台原生性能优化指南

1. AOT 编译技术架构总览

1.1 Uno Platform 运行时执行模式

Uno Platform 作为跨平台 .NET UI 框架，针对不同目标平台的特性与约束，设计了四种互补的运行时执行模式。这些模式在启动速度、运行时性能与包体积之间呈现显著的权衡特征，开发者需根据具体场景选择最优配置。

1.1.1 解释器模式（Interpreter）

解释器模式是 Uno Platform 的默认执行模式，尤其在 WebAssembly 平台上作为开发阶段的基础配置。该模式下，.NET 中间语言（IL）通过基于 WebAssembly 实现的 Mono 解释器逐条执行，无需预先将 IL 编译为原生机器码。这一设计的核心优势在于极快的构建速度与最小的包体积——仅需传输 .NET 运行时与原始程序集，无需额外的原生代码生成。然而，性能代价同样显著：根据 Uno Platform 官方基准测试，解释器模式的执行速度通常比 WebAssembly 编译代码慢约 30 倍 。这一差距在计算密集型场景（如复杂数据绑定、实时图像处理、大规模集合操作）中尤为明显。解释器模式适用于快速原型开发、内网工具应用，或作为 AOT 编译失败时的降级方案。在移动平台上，解释器模式通常不作为生产环境的推荐配置，但在特定调试场景或动态代码加载需求下仍有其价值。

1.1.2 混合模式（Mixed Mode / InterpreterAndAOT）

混合模式（InterpreterAndAOT）代表了 Uno Platform 在性能与包体积之间的工程平衡，是当前 WebAssembly 生产部署的推荐配置。该模式通过选择性编译策略，将应用程序的热路径代码（高频执行的核心代码）预编译为原生 WebAssembly 字节码，而冷路径代码（低频或边缘功能）保留 IL 由解释器执行。这种分层设计使得包体积相比完整 AOT 减少约 50%，同时确保关键性能场景的响应速度接近原生水平 。混合模式的启用通过 WasmShellMonoRuntimeExecutionMode 属性配置，且仅在 dotnet publish 或 dotnet build -c Release 时激活——常规 Debug 构建保持解释器模式以保障开发迭代效率 。现代 Uno Platform 版本已支持方法级别的精细混合编译，这得益于 Profile-Guided AOT 技术的引入，允许开发者通过实际运行数据精确指导 AOT 编译范围。

1.1.3 完整 AOT 模式（Full AOT）

完整 AOT 模式将应用程序的所有托管代码彻底编译为目标平台的原生机器码，完全消除运行时的 IL 解释开销。在 iOS 平台上，完整 AOT 并非可选优化，而是 Apple 平台政策的强制性要求——iOS 的安全架构禁止动态代码生成，所有 .NET 代码必须在构建阶段静态化 。完整 AOT 的构建产物包含完全剥离 IL 方法体的原生二进制文件，这不仅带来最优的运行时性能，还提供了额外的代码保护（反编译难度显著增加）。然而，代价同样明显：构建时间大幅延长（大型项目可达数十分钟），包体积急剧膨胀（因原生代码密度通常高于 IL），以及某些动态特性（如 System.Reflection.Emit）的兼容性限制。在 Android 平台，完整 AOT 可通过显式禁用 Profile-Guided AOT 实现（-p:AndroidEnableProfiledAot=false），但需充分评估包体积与编译时间的代价 。

1.1.4 Jiterpreter 混合编译模式（.NET 9+）

Jiterpreter 是 .NET 9 引入的革命性执行技术，为 WebAssembly 平台提供了 AOT 与解释器之外的第三条路径。该模式在解释器执行框架内嵌入了轻量级 JIT 引擎，能够在运行时动态生成部分 WebAssembly 代码——解释器负责初始执行并收集热点信息，Jiterpreter 则识别频繁执行的方法并即时编译为优化代码缓存。与完整 AOT 相比，Jiterpreter 避免了全量预编译的开销，同时获得接近 AOT 的热路径性能；与纯解释器相比，则实现了数量级的执行速度提升。启用配置极为简洁：<WasmShellEnableJiterpreter>true</WasmShellEnableJiterpreter> 。高级调优可通过 WasmShellRuntimeOptions 属性实现，如启用热度估计（--jiterpreter-estimate-heat）或统计输出（--jiterpreter-stats-enable），运行时数据可通过浏览器开发者控制台的 INTERNAL.jiterpreter_dump_stats() 获取。Uno Platform 5.6 及后续版本中，Jiterpreter 与 Profiled AOT 的结合可带来最高 10 倍的执行速度提升 。

1.2 底层技术栈映射

Uno Platform 的 AOT 实现并非单一技术方案，而是针对不同目标平台调用最优的底层编译工具链与运行时架构，形成多元化的技术矩阵。

1.2.1 Mono AOT 编译器（iOS、Android、macOS、WebAssembly）

Mono AOT 编译器是 Uno Platform 移动端与 Web 平台的核心编译基础设施，其历史可追溯至 Xamarin 技术栈，经过十余年生产环境验证。该编译器将 C# IL 代码转换为各平台的原生代码：在 iOS/Android 上生成 ARM/ARM64 机器码，在 WebAssembly 上生成符合 WASM MVP 规范的字节码。Mono AOT 的关键特征在于保留部分运行时元数据以支持反射等动态特性，这与 .NET Native AOT 的激进静态链接形成对比 。在 WebAssembly 场景中，Mono AOT 输出需通过 Emscripten 工具链进一步处理，形成完整的浏览器可执行模块。

1.2.2 .NET Native AOT（CoreCLR 桌面目标）

.NET Native AOT（又称 CoreCLR Native AOT）是微软自 .NET 7 起正式推出的静态编译技术，代表了 .NET 运行时架构的重大演进。与 Mono AOT 不同，Native AOT 基于 CoreCLR 的 RyuJIT 编译器，在发布时执行全程序分析，生成完全自包含的原生可执行文件，无需任何 .NET 运行时安装。其核心优势包括：启动速度极快（无运行时初始化开销）、内存占用更低（无 JIT 编译器内存消耗）、部署极度简化（单文件可执行）、以及固有的反编译保护。Uno Platform 对 Native AOT 的支持始于 4.7 版本，最初针对 Skia+GTK 后端，要求 GtkSharp 3.24.24.38 或更高版本 。随着版本演进，Native AOT 的支持范围扩展至所有 Skia 桌面目标以及 Windows WinUI 3 的特定配置。

1.2.3 LLVM 后端优化（Android 特定）

LLVM（Low Level Virtual Machine）作为模块化编译器基础设施，为 Android 平台的 AOT 编译提供了强大的优化后端。启用 LLVM 优化（通过 -p:EnableLLVM=true）后，Mono AOT 编译器将 IL 代码转换为 LLVM 中间表示（IR），再由 LLVM 工具链执行目标特定的优化与机器码生成。优化流水线包括：指令选择（IR 映射到 ARM/ARM64 指令集）、循环优化（向量化、展开、不变量外提）、寄存器分配（图着色算法最大化利用率）、以及代码布局（基本块重排优化指令缓存）。实测表明，LLVM 优化可带来 20-40% 的运行时性能提升（计算密集型场景），但代价是构建时间显著延长（可能翻倍）以及 Android NDK 的额外依赖 。

1.2.4 Emscripten 工具链（WebAssembly 特定）

Emscripten 是将 C/C++ 代码编译为 WebAssembly 的完整工具链，也是 Mono WebAssembly 运行时的构建基础。Uno Platform 的 WebAssembly AOT 编译流程中，Emscripten 承担关键角色：Mono AOT 编译器生成 LLVM IR，Emscripten 将其转换为 WebAssembly 字节码，并提供 JavaScript 胶水代码以实现浏览器 API 互操作。历史版本（Uno 3.x-4.x）要求开发者手动安装配置 Emscripten SDK，常因版本不匹配导致构建失败 。.NET 9 的重大改进在于：Emscripten 工具链由 .NET SDK 自动管理，无需手动安装，ninja-build 等外部依赖也被移除，同时支持 Windows ARM64、macOS ARM64 与 Linux ARM64 上的 AOT 构建 。

1.3 平台支持矩阵与版本要求

1.3.1 .NET 版本兼容性（.NET 7/8/9+）

.NET 9 的发布标志着 WebAssembly AOT 构建体验的质变：增量构建显著缩短重复编译时间，WebCIL 格式缓解反病毒软件误报，卫星程序集与 ICU 数据的部分下载优化本地化场景 。对于新启动的项目，强烈建议采用 .NET 9 以获取最优的 AOT 开发体验。

1.3.2 Uno Platform 版本要求（4.7+、5.x、6.0+）

Uno Platform 6.0（2025 年 5 月发布）是 AOT 技术的集大成者：统一的 Skia 渲染引擎覆盖所有平台，Win32 后端替代 WPF 实现完整 IL 修剪，空白应用包体积在 Windows 上减少 74%、iOS 上减少 21%，AOT 编译构建时间提升 35% 。

1.3.3 各平台 AOT 成熟度分级

---

2. iOS 平台 AOT 编译深度解析

2.1 iOS AOT 技术实现原理

2.1.1 Apple 平台强制 AOT 政策背景

iOS 平台的 AOT 编译并非技术选择，而是 Apple 生态系统的强制性安全要求。Apple 的 App Store 审核指南明确禁止应用程序在运行时生成可执行代码，这一政策直接封杀了 JIT 编译在 iOS 上的应用可能性。技术层面，iOS 设备的硬件内存保护机制（W^X，Write XOR Execute）确保内存页不可同时具有写权限与执行权限，从根本上阻止了动态代码生成 。因此，所有基于托管语言（C#、Java、JavaScript 等）的 iOS 应用必须通过 AOT 编译将代码静态化，方能在 App Store 分发。

Uno Platform 的 iOS 实现继承自 Xamarin.iOS（现 .NET for iOS），采用 Mono 完整 AOT（Full AOT） 作为唯一支持的编译模式。与 Android 的可选 AOT 不同，iOS 的 AOT 是构建流程的固有环节，开发者无需（也无法）显式禁用。这一设计决策确保了 Uno Platform 应用与原生 Swift/Objective-C 应用在技术合规性上的等效性，同时继承了 Xamarin 生态十余年的 iOS 适配经验。

2.1.2 Mono 完整 AOT 与部分 AOT 差异

Mono AOT 编译器在技术上支持多种编译粒度，但 iOS 平台实际仅启用 完整 AOT 模式。完整 AOT 的核心特征包括：所有托管方法在构建阶段编译为 ARM64 机器码；IL 方法体可选择性剥离以减小包体积；运行时元数据保留以支持反射与序列化。与之相对的部分 AOT（或 "JIT-less" 模式）允许保留部分 IL 由解释器执行，这在 Android 的 Profile-Guided AOT 中有应用，但 iOS 平台因政策限制不予支持。

完整 AOT 的性能特征呈现双刃剑效应：启动速度极快（无运行时编译延迟），执行效率接近原生代码，但二进制体积显著增大，且某些动态特性（如 System.Reflection.Emit）完全不可用。Uno Platform 通过托管链接器（Managed Linker）缓解体积问题，默认启用 "Link Framework SDKs Only" 模式，移除未使用的 BCL（Base Class Library）成员。

2.1.3 与 Xamarin.iOS 运行时兼容性

Uno Platform 的 iOS 实现与 Xamarin.iOS 运行时深度共享基础设施，这一架构决策带来显著的兼容性优势。开发者可将现有的 Xamarin.iOS 绑定库、自定义渲染器与平台特定代码近乎无缝地迁移至 Uno Platform。运行时层面，两者共享相同的垃圾回收器（SGen 或 .NET 6+ 的 CoreCLR GC）、线程调度模型与 Objective-C 互操作层。

然而，兼容性边界仍需关注：Uno Platform 的 UI 渲染层完全独立实现，不依赖 Xamarin.Forms 的渲染器体系，这意味着 Xamarin.Forms 的自定义渲染器需重写为 Uno Platform 的样式或附加属性系统。此外，Uno Platform 的 WinUI 3 API 表面与 Xamarin.iOS 的 UIKit 直接访问并存，开发者需在跨平台抽象与平台特定优化之间做出权衡。

2.2 iOS AOT 配置步骤

2.2.1 项目文件基础配置

iOS 项目的 AOT 配置相对简洁，主要依赖 .NET SDK 的默认行为。标准 Uno Platform iOS 项目的 Release 配置已隐含 AOT 启用，关键配置片段如下：

<PropertyGroup Condition="'$(Configuration)'=='Release'">
    <!-- iOS 强制 AOT，无需显式设置 PublishAot -->
    <RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
    <PublishTrimmed>true</PublishTrimmed>
    <TrimMode>partial</TrimMode>
    
    <!-- Uno 6.0+：启用 XAML 修剪 -->
    <UnoXamlTrimming>true</UnoXamlTrimming>
</PropertyGroup>

值得注意的是，iOS 项目通常不显式设置 <PublishAot>true</PublishAot>，因为 .NET for iOS 的 SDK 已默认启用 AOT。这一行为与 Android 形成对比，后者需显式配置以启用 AOT 优化。

2.2.2 命令行发布参数

iOS 应用的发布构建通过 dotnet publish 命令执行，典型参数组合如下：

# 物理设备发布（ARM64，现代 iPhone）
dotnet publish -f net9.0-ios -c Release -r ios-arm64 -p:ArchiveOnBuild=true

# 模拟器发布（Apple Silicon Mac）
dotnet publish -f net9.0-ios -c Release -r iossimulator-arm64

关键参数解析：

• -f net9.0-ios：指定目标框架为 .NET 9 iOS
• -r ios-arm64：限定运行时标识符为 ARM64（iPhone XS 及后续机型）
• -p:ArchiveOnBuild=true：触发 .ipa 归档生成，用于 App Store 分发
• 历史版本（.NET 6-7）可能需显式指定 -p:PublishAot=true，.NET 8+ 已简化

2.2.3 与 Native Rendering 后端的协同

Uno Platform 6.0 引入了对 iOS 的 Skia 渲染后端支持，此前版本仅支持 Native Rendering（UIKit 直接映射）。这一扩展带来了 AOT 配置的微妙差异：

选择 Skia 后端的 iOS 项目需确保 SkiaSharp 的 AOT 兼容性，推荐配置：

<!-- LinkerConfig.xml -->
<linker>
  <assembly fullname="SkiaSharp" preserve="all" />
  <assembly fullname="SkiaSharp.Views.Uno" preserve="all" />
</linker>

2.3 iOS 优化策略

2.3.1 启动跟踪分析（Startup Tracing）

iOS 平台的启动性能优化可借鉴 Android 的 Startup Tracing 方法论，尽管实现细节有所差异。核心思路是：通过仪器化构建采集应用启动阶段的实际执行路径，生成自定义 AOT 配置文件，指导编译器优先优化热路径代码。

Uno Platform 6.0 的 统一 Skia 引擎带来了显著的启动性能提升：官方测试显示 iPhone 13 上的启动时间从 1.5 秒降至 0.49 秒，改善幅度达 67% 。这一提升源于渲染架构的简化与更高效的资源加载管道，AOT 编译的代码布局优化也贡献显著。

2.3.2 托管链接器调优

托管链接器（IL Linker）是控制 iOS 包体积的核心工具。Uno Platform iOS 项目支持三种链接模式：

完全链接模式可通过以下配置启用：

<PropertyGroup>
    <MtouchLink>Full</MtouchLink>
    <!-- 或 MSBuild 属性 -->
    <PublishTrimmed>true</PublishTrimmed>
    <TrimMode>full</TrimMode>
</PropertyGroup>

完全链接的潜在风险在于过度修剪：反射依赖的类型、动态实例化的类、XAML 中引用的资源可能被错误移除。缓解策略包括：使用 [DynamicDependency] 属性标记、配置 LinkerConfig.xml 保留规则、以及启用 <TrimmerSingleWarn>false</TrimmerSingleWarn> 获取详细警告。

2.3.3 内存管理与 GC 配置优化

iOS 设备的内存约束比桌面平台更为严苛，AOT 编译后的应用需特别关注垃圾回收器配置。Mono SGen GC 的关键调优参数包括：

<PropertyGroup>
    <!-- 启用并发 GC 减少暂停 -->
    <MtouchEnableSGenConc>true</MtouchEnableSGenConc>
    
    <!-- 调整 nursery 大小（年轻代） -->
    <MtouchNurserySize>2m</MtouchNurserySize>
    
    <!-- 设置堆扩展策略 -->
    <MtouchHeapSize>256m</MtouchHeapSize>
</PropertyGroup>

或通过代码动态配置：

// Main.iOS.cs 中的 GC 配置
public static void Main(string[] args)
{
    Environment.SetEnvironmentVariable(
        "MONO_GC_PARAMS", 
        "soft-heap-limit=256m,nursery-size=8m,major=marksweep-conc");
    UIApplication.Main(args, null, typeof(App));
}

参数调优需考虑 iOS 设备的内存约束——低端设备可能需要更保守的配置以避免 OOM（Out of Memory）。

2.4 iOS 兼容性注意事项

2.4.1 动态代码生成限制

iOS 的 AOT 强制政策彻底禁用了动态代码生成技术，以下 API 与模式在 iOS 上不可用或行为受限：

Uno Platform 的源生成器（Source Generators）基础设施是应对这一限制的关键——在构建时生成原本需要动态创建的代码，如 XAML 代码后置、依赖属性实现等。开发者应避免在 iOS 代码路径中使用 dynamic，对必要的反射操作使用预缓存模式。

2.4.2 反射与序列化兼容性

AOT 编译对反射的影响主要体现在元数据修剪：完整 AOT 模式下，IL 方法体可被剥离，但反射所需的类型、成员、属性信息需显式保留。System.Text.Json 与 Newtonsoft.Json 的 AOT 兼容性对比：

推荐迁移至 System.Text.Json 的源生成模式，从根本上消除反射依赖：

[JsonSerializable(typeof(MyViewModel))]
[JsonSerializable(typeof(List<MenuItem>))]
internal partial class AppJsonContext : JsonSerializerContext { }

// 使用：JsonSerializer.Deserialize(json, AppJsonContext.Default.MyViewModel)

2.4.3 第三方库 AOT 兼容性验证

引入第三方 NuGet 包前，务必验证其 AOT 兼容性。评估维度包括：

1. 修剪友好性：库是否标记 [AssemblyMetadata("IsTrimmable", "True")]
2. 反射使用：是否依赖运行时类型扫描、动态代理
3. P/Invoke 依赖：原生库是否提供 iOS ARM64 构建
4. 已知问题：GitHub Issues 中是否报告 AOT 相关缺陷

验证工具链：dotnet publish 的修剪警告、ILCompiler 的 AOT 分析、以及实际设备测试。

---

3. Android 平台 AOT 编译深度解析

3.1 Android AOT 技术实现原理

3.1.1 Mono AOT + LLVM 后端架构

Android 平台的 AOT 编译采用 Mono AOT 编译器与 LLVM 优化后端的组合架构，这一设计在性能与灵活性之间取得了工程平衡。与 iOS 的强制完整 AOT 不同，Android 提供了更灵活的配置空间：开发者可在解释器、混合 AOT、Profile-Guided AOT 和完整 AOT 之间选择，根据应用的性能-包体积-构建时间优先级进行权衡。

基础 AOT 编译流程与 iOS 类似——Mono AOT 编译器将 IL 转换为 ARM64/ARMv7 机器码。关键差异在于 Android 允许运行时回退：AOT 编译失败或缺失的方法可回退至解释器执行，这一容错机制在 iOS 上不存在。LLVM 后端通过 -p:EnableLLVM=true 启用 ，将代码生成委托给 LLVM 的优化管道，带来 10%-30% 的性能提升，但增加构建时间和 NDK 依赖。

3.1.2 Profile-Guided AOT 机制

Profile-Guided AOT（PG-AOT） 是 Android 平台平衡包体积与运行时性能的关键技术。其核心机制是：通过运行时分析收集应用实际执行的方法调用数据，生成自定义 AOT 配置文件；后续构建仅对配置文件中标记的"热方法"进行 AOT 编译，其余代码保留在解释器中执行。

PG-AOT 的工作流程分为三个阶段：

PG-AOT 的典型效果：包体积增加 20-40%（对比完整 AOT 的 100-200%），热路径性能接近完整 AOT 的 95%，是大多数 Android 应用的推荐配置。

3.1.3 Marshal Methods 优化（.NET 8+）

Marshal Methods 是 .NET 8 引入的 Android 特定优化，旨在减少托管代码与 Java/Kotlin 互操作的开销。传统 JNI（Java Native Interface）调用涉及复杂的参数封送与线程上下文切换，Marshal Methods 通过预生成优化的封送存根（stubs）显著降低这一成本。

启用配置：

<PropertyGroup>
    <AndroidEnableMarshalMethods>true</AndroidEnableMarshalMethods>
</PropertyGroup>

技术实现上，Marshal Methods 在构建阶段分析托管代码中的 [Java.Interop.Export] 与 [Java.Interop.JniMethodSignature] 标记，生成对应的 JNI 注册表与优化封送代码。这一优化对大量使用 Android SDK API 的 Uno Platform 应用尤为有益，实测可减少 15-25% 的 JNI 调用开销。

3.2 Android AOT 配置步骤

3.2.1 基础 AOT 启用配置

Android 项目的 AOT 配置需显式启用，与 iOS 的强制 AOT 形成对比。标准配置如下：

<!-- YourApp.Android.csproj -->
<PropertyGroup Condition="'$(Configuration)'=='Release'">
    <!-- 启用 AOT 编译 -->
    <RunAOTCompilation>true</RunAOTCompilation>
    
    <!-- 启用 LLVM 优化后端（推荐生产环境） -->
    <EnableLLVM>true</EnableLLVM>
    
    <!-- 启用 Marshal Methods（.NET 8+） -->
    <AndroidEnableMarshalMethods>true</AndroidEnableMarshalMethods>
    
    <!-- 启用托管链接器 -->
    <PublishTrimmed>true</PublishTrimmed>
    <TrimMode>partial</TrimMode>
    
    <!-- 启用 Profile-Guided AOT -->
    <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

命令行发布验证：

dotnet publish \
  -f net9.0-android \
  -c Release \
  -p:AndroidPackageFormat=aab \
  -o ./publish/android

3.2.2 LLVM 优化后端启用（-p:EnableLLVM=true）

LLVM 后端的启用已在 3.2.1 节展示，此处补充故障排查要点。LLVM 构建失败的常见原因：

3.2.3 Marshal Methods 启用（-p:AndroidEnableMarshalMethods=true）

Marshal Methods 的完整配置（.NET 8+）：

<PropertyGroup>
    <AndroidEnableMarshalMethods>true</AndroidEnableMarshalMethods>
    <!-- 可选：启用实验性快速部署 -->
    <AndroidFastDeploymentType>Assemblies</AndroidFastDeploymentType>
</PropertyGroup>

已知限制：Marshal Methods 与某些动态代码模式不兼容，如遇 TypeInitializationException，可尝试禁用以隔离问题。

3.2.4 Startup Tracing 完整流程

3.2.4.1 Mono.AotProfiler.Android 包集成

Startup Tracing 的首要步骤是集成 AOT 分析器包：

dotnet add package Mono.AotProfiler.Android --version 7.0.0

包集成后，项目文件自动注入必要的 MSBuild 目标与属性。

3.2.4.2 分析数据采集命令序列

分析数据采集的标准工作流：

# 步骤 1：构建并启动分析版本（禁用 AOT 以确保完整覆盖）
dotnet build -t:BuildAndStartAotProfiling \
  -f net9.0-android \
  -c Release \
  -p:AndroidEnableProfiledAot=false

# 步骤 2：在设备/模拟器上执行典型用户场景
# - 冷启动应用
# - 导航至主要功能页面  
# - 执行核心交互操作
# 建议执行时间：30-60 秒以覆盖足够代码路径

# 步骤 3：完成分析并提取配置文件
dotnet build -t:FinishAotProfiling -f net9.0-android -c Release

成功执行后，项目目录下生成 custom.aprof 文件，此即 Startup Tracing 的核心产出。

3.2.4.3 自定义 Profile 文件集成

将生成的 Profile 文件集成至发布构建：

# 移动 Profile 至标准位置
mv custom.aprof Android/custom.aprof

<!-- 在 .csproj 中引用 -->
<ItemGroup>
    <AndroidAotProfile Include="Android/custom.aprof" />
</ItemGroup>

多环境配置策略：可为不同设备类别（高端/低端）或应用变体（免费/专业版）维护独立的 Profile 文件，通过 MSBuild 条件选择。

3.2.5 Full AOT 模式切换（-p:AndroidEnableProfiledAot=false）

特定场景（高性能计算应用、游戏引擎集成）可能需要完整 AOT 编译：

dotnet publish \
  -f net9.0-android \
  -c Release \
  -p:AndroidEnableProfiledAot=false \
  -p:RunAOTCompilation=true \
  -p:EnableLLVM=true \
  -p:AndroidEnableMarshalMethods=true

代价评估：包体积增加 40-80%，构建时间延长 2-3 倍，启动速度提升 10-20%。建议通过 A/B 测试验证实际收益。

3.3 Android 优化策略

3.3.1 包体积与运行时性能权衡

Android 应用的包体积直接影响用户获取成本（下载转化率）与分发渠道限制（Google Play 的 150MB AAB 阈值）。AOT 配置的权衡矩阵：

3.3.2 编译时间优化策略

AOT 构建的时间成本是开发效率的关键瓶颈。优化策略包括：

3.3.3 字符串资源修剪

字符串资源是 Android 包体积的隐性贡献者。启用字符串资源修剪：

<PropertyGroup>
    <AndroidLinkResources>true</AndroidLinkResources>
</PropertyGroup>

该选项移除未使用的本地化字符串，对多语言应用效果显著，可减少 10-30% 的资源体积。

3.3.4 GC 配置调优（environment.conf）

Android 特定的 GC 配置通过 environment.conf 文件注入，置于 Android/Assets/ 目录：

MONO_GC_PARAMS=soft-heap-limit=512m,nursery-size=64m,evacuation-threshold=66,major=marksweep
MONO_LOG_LEVEL=error

关键参数解析：

• soft-heap-limit=512m：建议堆大小上限，非硬性限制，触发更积极的回收
• nursery-size=64m：新生代大小，影响短生命周期对象分配效率
• major=marksweep：老年代收集器选择
• evacuation-threshold=66：触发堆整理的阈值

3.4 Android 兼容性注意事项

3.4.1 JNI 调用兼容性

JNI 互操作是 Android 平台特定的复杂性来源。AOT 编译对 JNI 的影响包括：

• 方法签名必须在构建时确定：动态签名查找失败
• RegisterNatives 调用的时机与 AOT 初始化顺序交互

最佳实践：使用 [DllImport("__Internal")] 显式声明 JNI 函数，避免运行时反射查找。

3.4.2 设备架构特定优化（arm64-v8a, armeabi-v7a）

Google Play 的 64 位强制政策（2019 年 8 月起）要求所有新应用支持 arm64-v8a。Uno Platform 的 AOT 配置需明确目标 ABI：

<PropertyGroup>
    <!-- 推荐：仅 arm64-v8a，减小包体积 -->
    <RuntimeIdentifiers>android-arm64</RuntimeIdentifiers>
    
    <!-- 兼容性：多 ABI 支持（如必需） -->
    <!-- <RuntimeIdentifiers>android-arm64;android-arm;android-x86;android-x64</RuntimeIdentifiers> -->
</PropertyGroup>

多 ABI 构建的 AOT 时间线性增长，建议 CI/CD 中并行化各 ABI 构建。

3.4.3 Google Play 商店包格式要求（AAB/APK）

Google Play 强制要求 AAB（Android App Bundle） 格式分发，其动态交付机制与 AOT 的交互：

构建 AAB：

dotnet publish -f net9.0-android -p:AndroidPackageFormat=aab

---

4. WebAssembly 平台 AOT 编译深度解析

4.1 WebAssembly AOT 技术实现原理

4.1.1 Mono WebAssembly 运行时架构

Mono WebAssembly 运行时是 Uno Platform Web 目标的核心执行引擎，其架构演进经历了三个主要阶段：早期解释器独占阶段（Uno 1.x-2.x）、AOT 编译引入阶段（3.x-4.x）、以及现代混合执行阶段（5.x+）。当前架构的核心组件包括：

4.1.2 Emscripten 编译工具链集成

Emscripten 是将 C/C++（及 Mono 运行时）编译为 WebAssembly 的完整工具链，其复杂性曾是 Uno Platform WebAssembly AOT 的主要门槛。历史版本（Uno 3.x-4.x）要求开发者手动安装配置：

# 历史配置（已过时）
git clone https://github.com/emscripten-core/emsdk.git
./emsdk install 3.1.12
./emsdk activate 3.1.12
source ./emsdk_env.sh  # 每终端执行

.NET 9 的重大改进：Emscripten 工具链由 .NET SDK 自动管理，无需手动安装，ninja-build 等外部依赖也被移除 。这一改进显著降低了新开发者的入门门槛，同时确保了工具链版本的一致性。

4.1.3 静态链接与动态链接差异

Uno Platform 默认采用静态链接以简化部署，动态链接支持仍在积极开发中。

4.2 WebAssembly AOT 配置步骤

4.2.1 基础 Mixed AOT 模式启用

4.2.1.1 WasmShellMonoRuntimeExecutionMode 配置

混合 AOT 模式的启用是 WebAssembly 生产部署的基础配置：

<!-- YourApp.Wasm.csproj -->
<PropertyGroup Condition="'$(Configuration)'=='Release'">
    <!-- 混合解释器/AOT 模式 -->
    <WasmShellMonoRuntimeExecutionMode>InterpreterAndAOT</WasmShellMonoRuntimeExecutionMode>
</PropertyGroup>

可选值：

• Interpreter：纯解释器（默认，开发用）
• InterpreterAndAOT：混合 AOT（推荐生产）
• AOT：完整 AOT（较少使用，体积大）

4.2.1.2 RunAOTCompilationAfterBuild 开发时启用

特殊场景（AOT 行为调试、性能回归测试）需在开发构建中启用 AOT：

<PropertyGroup>
    <RunAOTCompilationAfterBuild>true</RunAOTCompilationAfterBuild>
</PropertyGroup>

警告：此配置显著延长构建时间（每次构建增加 2-10 分钟），建议仅在必要时临时启用。

4.2.2 Profile-Guided AOT 完整配置

4.2.2.1 WasmShellGenerateAOTProfile 启用

PG-AOT 的配置流程始于分析模式构建：

<PropertyGroup>
    <WasmShellGenerateAOTProfile>true</WasmShellGenerateAOTProfile>
</PropertyGroup>

4.2.2.2 运行时 Profile 数据采集（Alt+Shift+P）

Uno Platform 提供浏览器内的 Profile 采集快捷键：Alt+Shift+P 触发 Profile 数据序列化与下载。采集流程：

1. 以分析模式启动应用（无调试器，Ctrl+F5）
2. 执行典型用户场景（建议覆盖 80% 常用功能）
3. 按下 Alt+Shift+P，浏览器自动下载 .aotprofile 文件
4. 将文件移至项目目录，重命名为描述性名称（如 production.aotprofile）

历史版本中，Profile 采集依赖特定的 LinkerConfig.xml 配置，现代版本已简化。

4.2.2.3 WasmShellEnableAotProfile 集成

将采集的 Profile 集成至生产构建：

<!-- 使用 Uno.Sdk 时，放置于 Platforms/WebAssembly/ 文件夹即可自动识别 -->
<!-- 非 Uno.Sdk 项目，显式引用： -->
<ItemGroup>
    <WasmShellEnableAotProfile Include="production.aotprofile" />
</ItemGroup>

重新执行 dotnet publish，AOT 编译器将仅对 Profile 标记的方法进行原生编译。

4.2.3 Jiterpreter 模式配置（.NET 9+）

4.2.3.1 WasmShellEnableJiterpreter 启用

Jiterpreter 的启用极为简洁：

<PropertyGroup>
    <WasmShellEnableJiterpreter>true</WasmShellEnableJiterpreter>
</PropertyGroup>

Jiterpreter 与 AOT 的协同：Jiterpreter 优化解释器执行的热路径，AOT 编译预识别的关键方法，两者互补而非互斥。推荐配置为同时启用混合 AOT 与 Jiterpreter。

4.2.3.2 运行时统计与调优选项

高级调优配置：

<PropertyGroup>
    <WasmShellEnableJiterpreter>true</WasmShellEnableJiterpreter>
    <WasmShellRuntimeOptions>
        --jiterpreter-stats-enable
        --jiterpreter-estimate-heat
        --jiterpreter-wasm-bytes-limit=50000
    </WasmShellRuntimeOptions>
</PropertyGroup>

运行时统计查看：浏览器开发者控制台执行 INTERNAL.jiterpreter_dump_stats()，输出各方法的热度估计与 JIT 生成决策。

4.3 WebAssembly 优化策略

4.3.1 包体积优化（50%+ 缩减实践）

Uno Platform 官方文档记载的 PG-AOT 包体积优化成果：相比完整 AOT，PG-AOT 可实现 50% 的包体积缩减 。现代版本（5.6+）结合 XAML 修剪、资源优化与改进的 PG-AOT，缩减幅度可达 60-70%。

4.3.2 执行性能优化（10x 速度提升路径）

Uno Platform 5.6 的官方发布说明宣称：WebAssembly AOT 编译场景下可实现最高 10 倍的执行速度提升 。这一数字需结合基准测试背景理解——对比基准为纯解释器模式，实际应用中的提升幅度因代码特征而异。

关键性能突破：Uno Platform 5.6 修复了 WebAssembly AOT 编译器的关键 bug——某些包含 catch 和 finally 的方法未被正确 AOT 编译，导致 10 倍性能回退至解释器 。修复后的优化路径：

1. 确保 AOT 编译覆盖：检查构建日志的 AOT 方法统计
2. 启用 Jiterpreter：.NET 9+ 的额外加速层
3. 优化 JavaScript Interop：减少跨边界调用频率，批量 DOM 操作
4. 使用 unsafe 代码：WASM 支持指针操作，关键路径可获显著加速

4.3.3 增量构建优化（.NET 9+）

.NET 9 引入了 WebAssembly 的增量 AOT 编译，Uno Platform 5.5+ 自动利用：

• 方法级增量：仅重新编译变更的方法
• 缓存重用：跨构建会话保留 AOT 产物
• 并行编译：利用多核加速

配置确认：

<PropertyGroup>
    <WasmShellEnableIncrementalAOT>true</WasmShellEnableIncrementalAOT>
</PropertyGroup>

4.3.4 浏览器缓存策略（WebCIL, 缓存破坏器）

生产部署的缓存优化：

• 文件名哈希（content hashing）：确保变更文件缓存失效
• CDN 的 Cache-Control 头：静态资源长期缓存
• Service Worker：离线能力和智能缓存

.NET 9 的 WebCIL 格式：将程序集打包为浏览器友好的格式，减少反病毒软件误报，优化缓存效率 。

4.4 WebAssembly 兼容性注意事项

4.4.1 浏览器兼容性矩阵（Safari iOS 限制）

Safari iOS 的历史限制对 WebAssembly 应用影响深远：早期版本对 WebAssembly 模块大小设有硬性上限（约 50MB 解压后），超过此限制将导致应用无法加载 。虽然 iOS 16+ 有所放宽，但仍建议对 iOS 用户进行专项测试。

4.4.2 单文件大小限制应对

针对 Safari iOS 的大小限制，推荐策略：

• 启用 PG-AOT：减少代码体积
• 使用延迟加载（lazy loading）：拆分非关键代码
• 监控 mono.wasm 和 dotnet.wasm 的合并大小

4.4.3 调试与发布模式差异

4.4.4 反病毒软件干扰缓解

Windows Defender 等反病毒软件可能误报 WebAssembly 构建产物，导致构建失败或运行时加载异常。缓解措施：

• 将项目 obj 和 bin 目录加入排除列表
• CI/CD 环境中使用 Linux 构建代理
• 对发布产物进行代码签名

---

5. 桌面端 AOT 编译深度解析（Skia/GTK/WPF）

5.1 Skia 桌面端 AOT 技术实现原理

5.1.1 .NET Native AOT（CoreCLR）架构

Skia 桌面端是 Uno Platform 中率先全面支持 .NET Native AOT 的目标类别，标志着框架向现代原生编译技术的战略迁移。.NET Native AOT 基于 CoreCLR 的 RyuJIT 编译器，在发布时执行全程序分析，生成完全自包含的原生可执行文件，无需任何 .NET 运行时安装。

与 Mono AOT 的关键差异：

Uno Platform 对 Native AOT 的支持始于 4.7 版本，最初针对 Skia+GTK 后端 。随着版本演进，支持范围扩展至所有 Skia 桌面目标（Linux、macOS、Windows）。

5.1.2 SkiaSharp 渲染引擎集成

SkiaSharp 作为跨平台 2D 图形引擎，在 Native AOT 环境下需要特殊处理：

• 原生 Skia 库：作为动态库或静态链接
• GPU 后端：OpenGL（Linux/Windows）、Vulkan（实验性）、Metal（macOS）
• 字体和文本渲染：系统集成与嵌入字体

Uno Platform 自动处理 SkiaSharp 的 AOT 兼容性，但自定义 Skia 互操作代码需验证修剪安全性。

5.1.3 平台特定后端（GTK3/GTK4/GLFW/X11）

5.2 Skia 桌面端 AOT 配置步骤

5.2.1 基础 <PublishAot>true</PublishAot> 配置

启用 Native AOT 的核心配置极为简洁：

<PropertyGroup>
    <PublishAot>true</PublishAot>
    <!-- 可选：单文件发布 -->
    <PublishSingleFile>true</PublishSingleFile>
    <!-- 可选：自包含 -->
    <SelfContained>true</SelfContained>
</PropertyGroup>

5.2.2 多目标框架条件配置

对于同时包含 WebAssembly 等不支持 Native AOT 目标的项目，需要条件化配置以避免构建错误 ：

<PropertyGroup Condition="'$(TargetFramework)' == 'net9.0-desktop'">
    <PublishAot>true</PublishAot>
    <PublishTrimmed>true</PublishTrimmed>
    <PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

关键注意事项：PublishAot 不能无条件应用于所有目标框架，WebAssembly（browser-wasm）等目标会报告 NETSDK1203 错误 。

5.2.3 自包含部署与单文件发布

推荐的生产部署配置：

# Linux x64
dotnet publish -c Release -r linux-x64 -p:PublishAot=true -p:PublishSingleFile=true

# macOS Apple Silicon
dotnet publish -c Release -r osx-arm64 -p:PublishAot=true -p:PublishSingleFile=true

# Windows x64
dotnet publish -c Release -r win-x64 -p:PublishAot=true -p:PublishSingleFile=true

生成的可执行文件包含所有依赖，无需目标机器预装 .NET 运行时。

5.2.4 平台特定运行时标识符（-r linux-x64, -r osx-arm64, -r win-x64）

重要限制：Native AOT 不支持跨平台编译，必须在目标平台或兼容的容器环境中执行发布 。

5.3 GTK 特定配置

5.3.1 GtkSharp 版本要求（3.24.24.38+）

Native AOT 支持要求 GtkSharp 3.24.24.38 或更高版本 。Uno Platform 4.7+ 的模板已包含兼容版本，升级现有项目时需显式更新：

dotnet list package --include-transitive | grep GtkSharp
# 如需更新：dotnet add package GtkSharp --version 3.24.24.38

5.3.2 Linux 运行时依赖安装

目标 Linux 系统需安装 GTK3 运行时：

# Ubuntu/Debian
sudo apt-get install libgtk-3-0 libgdk-pixbuf2.0-0 libfontconfig1

# Fedora
sudo dnf install gtk3

# Arch
sudo pacman -S gtk3

静态链接选项（实验性）可将 GTK 依赖打包，但增加体积约 20MB。

5.3.3 Windows GTK3 运行时部署

Windows 上 GTK3 运行时可通过 MSYS2 安装或随应用分发。Uno Platform 的打包工具支持自动包含必要的 DLL。

5.4 WPF 平台 AOT 现状

5.4.1 WPF 不支持 .NET Native AOT 的技术限制

WPF（Windows Presentation Foundation）当前不支持 .NET Native AOT，核心障碍包括：

• 重度依赖 COM 互操作和动态激活
• 广泛的反射使用（资源字典、样式系统）
• 与 PresentationCore/PresentationFramework 的紧密耦合

Microsoft 官方路线图未承诺 WPF 的 Native AOT 支持，建议新项目避免 WPF 目标。

5.4.2 替代方案：Skia+WPF 宿主或 WinUI 3 迁移

5.5 桌面端优化策略

5.5.1 启动时间优化

Native AOT 的核心优势之一是消除 JIT 预热延迟。进一步优化杠杆：

• 延迟初始化非关键服务：使用 Lazy<T> 和异步初始化
• 预编译 XAML 绑定：x:Bind 模式
• 配置文件引导的优化（PGO）：.NET 9+ 预览支持

实测数据：Native AOT 相比传统 CoreCLR JIT 运行时，启动时间从 3,398ms 降低至 1,925ms（约 43% 改进） 。

5.5.2 包体积优化（IL 修剪与资源优化）

Uno Platform 6.0 的体积优化成果：空白应用包体积在 Windows 上减少 74%，iOS 上减少 21% 。

5.5.3 原生依赖静态链接

实验性静态链接减少部署依赖：

<PropertyGroup>
    <StaticallyLinked>true</StaticallyLinked>
</PropertyGroup>

限制：某些系统库（如图形驱动相关）无法静态链接。

5.6 桌面端兼容性注意事项

5.6.1 P/Invoke 库兼容性

Native AOT 要求 P/Invoke 签名在编译时完全解析：

• 避免运行时构造 DllImport 路径
• 使用 [LibraryImport] 和源生成（.NET 7+）
• 确保原生库在目标平台可用

5.6.2 COM 互操作限制

COM 互操作在 Native AOT 中受限：

• 避免 dynamic 和 Type.GetTypeFromCLSID
• 使用 ComWrappers 源生成兼容模式
• Windows 特定的 COM 功能需显式启用

5.6.3 反射代码修剪安全

修剪分析器标记的警告需处理：

// 不安全：可能被修剪
var props = typeof(MyType).GetProperties();

// 安全：显式保留
[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicProperties)]
public class MyType { }

或配置修剪描述文件保留整个程序集或类型层次结构。

---

6. Windows WinUI 3 平台 AOT 编译深度解析

6.1 WinUI 3 AOT 技术实现原理

6.1.1 Windows App SDK 与 Native AOT 集成

WinUI 3 作为 Windows 的现代原生 UI 框架，与 Windows App SDK 紧密集成。Uno Platform 提供两种 WinUI 3 目标实现：

• WPF 宿主实现（Uno 5.x 及更早）：基于 WPF 的 WinUI 3 兼容层，不支持 Native AOT
• Win32 实现（Uno 6.0+）：直接基于 Windows App SDK，支持完整 Native AOT

Uno Platform 6.0 的重大架构变更将 Windows 目标从 WPF 迁移到 Win32 实现，核心动机之一就是启用 Native AOT 和完整 IL 修剪 。

6.1.2 Win32 实现与 WPF 实现的架构差异

6.1.3 完整 IL 修剪支持（Uno Platform 6.0+）

Win32 实现的完整 IL 修剪通过 <TrimMode>full</TrimMode> 和 <TrimmerRemoveSymbols>true</TrimmerRemoveSymbols> 启用，自动分析 XAML 绑定和依赖属性使用，安全移除未引用代码。

6.2 WinUI 3 AOT 配置步骤

6.2.1 Skia 后端 AOT 配置（推荐路径）

Uno Platform 6.0 的 WinUI 3 目标默认使用 Skia 渲染后端，配置与 Skia 桌面端一致：

<PropertyGroup>
    <TargetFrameworks>net9.0-windows10.0.19041</TargetFrameworks>
    <PublishAot>true</PublishAot>
    <PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

6.2.2 命令行发布参数（-p:PublishAot=true）

dotnet publish -c Release -r win-x64 -p:PublishAot=true -p:PublishSingleFile=true -p:SelfContained=true

6.2.3 MSIX 打包与 Native AOT 协同

MSIX 是 Windows 应用的首选打包格式，与 Native AOT 协同：

dotnet publish -p:PublishAot=true -p:WindowsPackageType=MSIX

Uno Platform 的打包工具自动处理 MSIX 清单、资源打包和签名准备。

6.3 WinUI 3 优化策略

6.3.1 空白应用包体积优化（74% 缩减实践）

Uno Platform 6.0 的优化成果：空白应用包体积从 ~150MB（WPF + 自包含）降至 ~40MB（Win32 + Native AOT + 完整 IL 修剪），缩减 74% 。

关键技术杠杆：

• Win32 后端替代 WPF：消除 WPF 运行时依赖
• 完整 IL 修剪：移除未使用的 BCL 与框架代码
• XAML 与资源修剪：分析绑定表达式，移除未引用资源

6.3.2 构建时间优化（35% 提升）

Uno Platform 6.0 通过以下改进实现 AOT 构建时间 35% 提升 ：

• 并行化 AOT 编译任务
• 改进的增量构建跟踪
• 缓存优化减少重复工作
• 修剪器与 AOT 编译器的管道优化

6.3.3 XAML 与资源修剪

XAML 修剪配置：

<PropertyGroup>
    <UnoXamlResourcesTrimming>true</UnoXamlResourcesTrimming>
    <UnoXamlResourcesTrimmingVerbosity>Detailed</UnoXamlResourcesTrimmingVerbosity>
</PropertyGroup>

详细日志帮助识别未被修剪的 XAML 资源，指导进一步优化。

6.4 WinUI 3 兼容性注意事项

6.4.1 WinRT API 兼容性边界

Native AOT 对 WinRT API 的调用需通过 CsWinRT 投影。限制包括：

• 动态接口查询（as 运算符）可能失败，需使用显式接口实现
• 泛型接口的 COM 互操作需预注册
• 异步操作的模式匹配需小心处理

6.4.2 CoreDispatcher/CoreWindow 替代方案

WinUI 3 移除了 UWP 的 CoreDispatcher 和 CoreWindow API。Uno Platform 应用需迁移至：

• DispatcherQueue：线程调度
• Microsoft.UI.Xaml.Window：窗口管理
• AppWindow：高级窗口控制

6.4.3 第三方 WinUI 控件库兼容性

第三方控件库的 Native AOT 兼容性需单独验证。Windows Community Toolkit 8.2+ 已正式支持 Native AOT，是兼容性良好的参考实现。评估维度：

• 是否使用 DynamicallyAccessedMembers 标注
• 是否提供修剪描述符（trimming descriptors）
• 是否依赖动态代码生成

---

7. 跨平台 AOT 统一配置与高级主题

7.1 多目标框架项目配置模式

7.1.1 条件化 MSBuild 属性

现代 Uno Platform 项目采用 Single Project 结构，通过条件化 MSBuild 属性管理多平台 AOT 配置：

<Project Sdk="Uno.Sdk">
  <PropertyGroup>
    <TargetFrameworks>
      net9.0-desktop;
      net9.0-browserwasm;
      net9.0-ios;
      net9.0-android
    </TargetFrameworks>
  </PropertyGroup>
  
  <!-- 共享 AOT 配置 -->
  <PropertyGroup>
    <PublishAot Condition="'$(TargetFramework)'!='net9.0-browserwasm'">true</PublishAot>
  </PropertyGroup>
  
  <!-- WebAssembly 特定 -->
  <PropertyGroup Condition="'$(TargetFramework)'=='net9.0-browserwasm'">
    <WasmShellMonoRuntimeExecutionMode>InterpreterAndAOT</WasmShellMonoRuntimeExecutionMode>
  </PropertyGroup>
  
  <!-- iOS 特定 -->
  <PropertyGroup Condition="'$(TargetFramework)'=='net9.0-ios'">
    <MtouchUseLlvm>true</MtouchUseLlvm>
    <UnoXamlTrimming>true</UnoXamlTrimming>
  </PropertyGroup>
  
  <!-- Android 特定 -->
  <PropertyGroup Condition="'$(TargetFramework)'=='net9.0-android'">
    <EnableLLVM>true</EnableLLVM>
    <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
    <AndroidEnableMarshalMethods>true</AndroidEnableMarshalMethods>
  </PropertyGroup>
</Project>

7.1.2 平台特定属性组隔离

使用 Choose/When 结构实现更复杂的条件逻辑：

<Choose>
  <When Condition="'$(TargetFramework)'=='net9.0-desktop'">
    <PropertyGroup>
      <PublishAot>true</PublishAot>
      <PublishSingleFile>true</PublishSingleFile>
    </PropertyGroup>
  </When>
  <When Condition="'$(TargetFramework)'=='net9.0-browserwasm'">
    <PropertyGroup>
      <WasmShellEnableJiterpreter>true</WasmShellEnableJiterpreter>
    </PropertyGroup>
  </When>
</Choose>

7.1.3 共享项目与平台头项目结构

大型解决方案可采用 共享项目（Shared Project） 模式，将平台无关代码集中于 .shproj，平台特定配置分散于各头项目。

7.2 CI/CD 集成最佳实践

7.2.1 GitHub Actions 工作流配置

# .github/workflows/build.yml
name: Build and Publish

on:
  push:
    branches: [main]

jobs:
  build:
    strategy:
      matrix:
        include:
          - os: ubuntu-latest
            target: net9.0-desktop
            rid: linux-x64
          - os: macos-latest
            target: net9.0-desktop
            rid: osx-arm64
          - os: windows-latest
            target: net9.0-windows10.0.19041
            rid: win-x64
    
    runs-on: ${{ matrix.os }}
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '9.0.x'
      
      - name: Restore workloads
        run: dotnet workload restore
      
      - name: Build and publish
        run: |
          dotnet publish \
            -f ${{ matrix.target }} \
            -r ${{ matrix.rid }} \
            -c Release \
            -p:PublishAot=true \
            -p:PublishSingleFile=true
      
      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: ${{ matrix.rid }}
          path: bin/Release/${{ matrix.target }}/${{ matrix.rid }}/publish/

7.2.2 Azure DevOps 管道配置

# azure-pipelines.yml
trigger:
  - main

strategy:
  matrix:
    linux:
      imageName: 'ubuntu-latest'
      rid: 'linux-x64'
    macos:
      imageName: 'macos-latest'
      rid: 'osx-arm64'
    windows:
      imageName: 'windows-latest'
      rid: 'win-x64'

pool:
  vmImage: $(imageName)

steps:
  - task: UseDotNet@2
    inputs:
      version: '9.0.x'
  
  - script: dotnet workload restore
    displayName: 'Restore workloads'
  
  - script: |
      dotnet publish \
        -f net9.0-desktop \
        -r $(rid) \
        -c Release \
        -p:PublishAot=true
    displayName: 'Build and publish'
  
  - task: PublishBuildArtifacts@1
    inputs:
      pathToPublish: 'bin/Release/net9.0-desktop/$(rid)/publish/'
      artifactName: '$(rid)'

7.2.3 跨平台构建代理要求

WebAssembly AOT 的特殊需求：构建过程内存密集，建议 16GB+ RAM，或启用交换空间。

7.3 AOT 兼容性诊断与故障排除

7.3.1 修剪警告分析与抑制

修剪警告（IL2xxx 系列）是 AOT 兼容性的关键指标：

抑制非关键警告：

<ItemGroup>
  <TrimmerRootAssembly Include="MyAssembly" />
</ItemGroup>

7.3.2 运行时异常诊断

常见 AOT 运行时异常：

7.3.3 原生依赖缺失排查

原生依赖诊断流程：

1. 使用 ldd（Linux）、otool -L（macOS）或 Dependencies（Windows）检查可执行文件依赖
2. 确认原生库存在于输出目录或系统路径
3. 验证库架构与目标 RID 匹配（ARM64 vs x64）
4. 对于静态链接尝试，检查链接器日志中的未解析符号

7.4 未来演进路线图

7.4.1 .NET 9+ Native AOT 扩展支持

.NET 9 及后续版本的 Native AOT 演进方向：

• 改进的泛型代码处理：减少泛型膨胀，优化包体积
• 扩展的反射兼容性：更多反射模式在修剪后可用
• P/Invoke 源生成器：[LibraryImport] 的全面推广
• 配置绑定源生成器：替代运行时配置反射

7.4.2 统一运行时愿景

微软与 Uno Platform 社区的长期目标：统一 Mono 与 CoreCLR 运行时，最终形成单一的 .NET 运行时支持所有 AOT 场景。这一愿景的实现将：

• 消除 Mono AOT 与 Native AOT 的行为差异
• 简化跨平台 AOT 配置
• 提升 WebAssembly 与移动平台的性能一致性

7.4.3 新兴平台支持（Flatpak, 嵌入式）

---

8. 平台对比与选型决策框架

8.1 各平台 AOT 特性对比矩阵

8.2 性能-包体积-编译时间三角权衡

                    性能最优
                       ▲
                      / \
                     /   \
                    /     \
                   /   ◆   \    ← 理想平衡点（因场景而异）
                  /  PG-AOT  \
                 /  + Jiterp   \
                /________________\
        包体积最优 ◄─────────────► 编译时间最优
        （解释器/    （增量构建/
         激进修剪）    缓存重用）

选型决策树：

1. 目标平台是 iOS？ → 强制 Full AOT，优化链接器配置
2. 目标平台是 Android？ → 默认 PG-AOT + LLVM，极致性能选 Full AOT
3. 目标平台是 Web？ → 推荐 PG-AOT + Jiterpreter，关注 Safari 兼容性
4. 目标平台是桌面？ → 推荐 Native AOT，单文件部署
5. 需要极致启动速度？ → Native AOT（桌面）或 Full AOT（iOS）
6. 包体积极度敏感？ → PG-AOT 或 Jiterpreter，配合激进修剪

8.3 目标场景推荐配置速查