.NET 的 Native AOT 现在是什么样的？

今天要写的这篇文章源自昨天在朋友圈发的文章《UWP 通过 .NET 9 和Native AOT 的支持实现 UWP 应用的现代化》[1],一位小伙伴的对话让我想全面梳理下Native AOT的现在的进展。

.NET 9 的 Native AOT（Ahead-of-Time Compilation）是微软在.NET 9版本中重点发展的一项技术，旨在提升应用程序的性能。Native AOT 技术可以将.NET 代码预先编译为本地代码，从而实现更快的启动时间和更高的执行效率。

在.NET 9中，微软已经将Native AOT作为提升性能的关键点之一[2]。此外，微软还宣布了对通用Windows平台（UWP）的初步支持，允许开发者使用.NET 9和Native AOT技术来现代化改造现有的UWP应用。这一举措为UWP开发者提供了一条升级路径，使他们能够利用最新的.NET和Native AOT技术来改进其应用程序。 .NET 9的Native AOT不仅限于UWP平台，它还支持老旧的Windows 7和XP环境，这标志着AOT技术在兼容性方面的突破。然而，对于Android平台的Native AOT支持，目前尚未完成，尤其是JNI（Java Native Interface）支持，这被认为是一个较大的功能需求，还有WPF/Winform 的Native AOT支持也需要在.NET 10 才能够完成。

.NET 的Native AOT技术通过在编译阶段对代码进行优化，使得生成的可执行文件更小且启动速度更快。这一突破性功能不仅实现了对老旧Windows 7和Windows XP环境的支持，还为性能要求高且依赖旧版系统的开发者提供了新的可能性。具体来说，.NET 9版本中，为了确保向下兼容性，X86架构下的AOT（Ahead-of-Time）编译器的支持扩展，.NET 9采用了精心设计的编译策略，确保了对Win7及XP API的兼容性，使代码能够无缝运行，允许开发人员将应用程序在编译阶段就优化为能够在老旧的Windows系统上运行。LoongArch架构和Risc-V架构下的AOT 编译器支持，社区也在继续完善之中。

在.NET 9中，对Native AOT（按需编译）支持和JNI（Java Native Interface）的支持有以下具体进展：

在.NET 9中，引入了两个新的属性，允许开发者设计功能开关。这些功能开关可以在.NET库（以及你自己）中使用来切换某些功能区域。如果一个功能不被支持，在裁剪或使用Native AOT进行编译时，将移除那些不受支持且不必要的功能，从而减小应用程序的大小。
在.NET MAUI的测试中，通过调用JNI来获取Java数组元素的性能比使用string.Split和新的Span方法更差。这表明开发者正在考虑如何在未来版本中优化这一过程。
.NET 9在Android平台上对Native AOT的支持主要体现在通过新属性实现的功能开关，以及通过Native AOT减少应用大小的能力。

对于开发者而言，学习和采用.NET 9的Native AOT技术需要具备以下前置知识或技能：

对.NET平台的理解：首先，开发者需要对.NET平台有基本的了解，包括其架构、运行时环境以及如何在不同平台上部署应用。这有助于理解Native AOT技术如何与现有.NET生态系统集成。
熟悉C#或F#编程语言：由于.NET 9支持通过C#或F#进行开发，因此掌握这些编程语言是必要的。此外，了解这些语言的高级特性将有助于更有效地利用Native AOT带来的性能优势。
了解编译器原理 ：Native AOT（Native Application Optimized Translation）是一种预编译技术，它允许开发者直接生成机器码而不是依赖JIT（即时编译）。因此，对编译器的工作原理有一定的了解可以帮助开发者更好地理解和使用Native AOT技术[3]。
性能优化经验：由于Native AOT旨在提供可预测的性能并减少资源消耗，因此具备一定的性能优化经验是有益的。这包括对内存管理、代码优化等方面的深入了解。
云原生和微服务架构知识 ：虽然不是必须的，但了解云原生应用和微服务架构的相关知识可以增强开发者在使用.NET 9时构建高效、可扩展的应用的能力。这是因为.NET 9特别强调了在这些架构中的性能表现，参见.NET 9 RC1发布[4]。