百度推广是否做网站,wordpress怎么放图片不显示,做量化投资网站,北京超市网站建设在软件开发领域#xff0c;优化性能和简化效率仍然至关重要。.NET 平台二十年来不断创新#xff0c;为开发人员提供了构建弹性且高效的软件解决方案的基础架构。 与本机 AOT#xff08;提前#xff09;编译相结合#xff0c;取得了显着的进步。本文深入研究.NET Native AO… 在软件开发领域优化性能和简化效率仍然至关重要。.NET 平台二十年来不断创新为开发人员提供了构建弹性且高效的软件解决方案的基础架构。 与本机 AOT提前编译相结合取得了显着的进步。本文深入研究.NET Native AOT揭示它的工作原理、优点以及它的各种应用场景。
什么是 .NET 本机 AOT .NET 本机提前 (AOT) 编译是 .NET 平台中的一项前沿进步。通过 AOTC# 代码将在开发人员计算机上编译为本机代码。这与在运行时将代码编译为本机代码的传统方法形成鲜明对比。
下面的架构说明了这一点。.NET 传统编译涉及两个步骤 1、C# 编译生成包含中间语言 (IL)代码的 DLL 文件。这样的 DLL 称为.NET 程序集。 2、执行 .NET 程序时.NET 运行时CLR 公共语言运行时会加载 .NET 程序集。CLR 的子系统负责将 IL 代码编译为由 CPU 直接执行的本机代码。这个子系统被命名为JITJust-In-Time编译器。它之所以得名是因为它仅在首次调用某个方法时才编译该方法的 IL 代码。 另一方面.NET Native AOT 编译由一个步骤组成。在开发人员的机器上将 C# 源代码编译为本机代码。此过程涉及将 C# 代码转换为 IL 代码然后转换为 Native 代码形成两步编译过程。但这是一个实现细节。这就是下面架构中 AOT .NET 程序集框呈灰色的原因。 .NET 本机 AOT 的优点 .NET 本机提前 (AOT) 编译带来了一系列优势 增强的性能通过将代码预编译为本机机器指令.NET Native AOT 显着缩短了启动时间并提高了应用程序的整体性能。运行时期间没有 JIT 编译开销意味着执行速度更快从而提供更流畅的用户体验。 简化部署 AOT 编译的应用程序通常会生成具有零或更少依赖项的独立可执行文件。这简化了部署过程使您可以更轻松地跨各种平台和设备分发应用程序而无需额外安装或运行时组件。 更小的应用程序大小通过修剪掉不必要的代码AOT 可以大大减小应用程序的大小。这不仅节省了存储空间还优化了应用程序的内存占用这在移动设备或物联网设备等资源受限的环境中尤其重要。 增强的知识产权保护 AOT 编译将源代码转换为优化的机器代码使逆向工程尝试更具挑战性。与可以轻松反编译为原始 C# 代码的 IL 代码相比生成的本机代码更加混乱且难以破译。这增强了应用程序中嵌入的敏感算法、业务逻辑和专有方法的安全性。
.NET Native AOT 的缺点 AOT 带来的好处不可避免地伴随着某些缺点。他们来了 特定于平台的编译 .NET Native AOT 生成特定于平台的本机代码针对特定的体系结构或操作系统进行定制。例如与常规 .NET 程序集不同使用 AOT 在 Windows 上生成的可执行文件无法在 Linux 上运行。 不支持跨操作系统编译例如您无法从 Windows 机器编译 Linux 本机版本反之亦然。 部分支持Reflection Reflection依赖于动态代码生成和运行时类型发现这与AOT编译代码的预编译和静态性质相冲突。然而我们将在本文末尾看到通常的反射用法与 AOT 配合得很好。 需要 AOT 兼容的依赖项 AOT 编译要求项目中使用的所有库和依赖项都与 AOT 兼容。依赖反射、运行时代码生成或其他动态行为的库可能与 AOT 不兼容从而可能导致冲突或运行时错误。 增加构建时间 AOT 编译涉及在构建过程中预先生成本机代码。此附加步骤可以显着增加构建时间特别是对于具有大量代码库的大型项目或应用程序。 需要 C 桌面开发工具 AOT 只能在安装了这些工具的情况下进行编译这些工具在您的硬盘上最多可达 7GB。 .NET 本机 AOT 实际应用 使用 Visual Studio 创建 .NET 本机 AOT Web 应用程序启动 Visual Studio 2022 v17.8或更高版本并选择从模板ASP.NET Core Web API本机 AOT创建项目。 该模板为我们生成一个 .NET 8 ASP.NET Core Web API 应用程序我们可以看到 .csproj 文件包含PublishAottrue/PublishAot。 编译 .NET Web 应用程序 如果我们编译应用程序我们可以看到在 .dll 下生成了一个 DLL 文件.\bin\debug\net8.0。此 DLL 是包含 IL 代码的常规 .NET 程序集。我们可以使用 ILSpy 对其进行反编译如下图所示 执行.NET Web应用程序 此时没有发生AOT编译。C# 代码在不到一秒的时间内就被编译为 IL 代码。.NET Web 应用程序可以按原样执行 使用 .NET Native AOT 编译 Web 应用程序 要使用 .NET Native AOT 编译 Web 应用程序您必须dotnet publish 在包管理器控制台中键入 这次这个小应用程序的编译花费了 11 秒。我们获得一个大小为 9MB 的可执行文件。该文件无法使用 ILSpy 反编译因为它不是 .NET 程序集。该文件仅包含本机代码。还生成一个 70MB PDB 文件将本机代码与源代码链接起来以进行调试。 可执行文件可以在任何 Windows x64 系统上按原样部署和执行。部署可以更简单吗我不这么认为 .NET 本机 AOT 权衡 现在是评估选项的时候了 1、一方面我们在不到一秒的时间内生成了一个可在所有平台上运行的 40KB DLL。但它需要预安装.NET 8.0。 2、另一方面我们在 11 秒内编译出一个 9MB 的可执行文件。它可以在任何 Windows x64 系统上运行无需任何先决条件。此外这个本机版本的启动速度更快。对于任何足够复杂的 Web 应用程序我们都可以期待更多的性能提升。 人们可能会认为 9MB 比 40KB 大得多但安装 .NET 8.0 需要的磁盘空间远多于 9MB。仅目录C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.0 就有 70MB而且还有更多东西需要安装。因此 AOT 导致
3、紧凑的容器镜像在容器化部署设置中特别有用 4、由于图像尺寸较小部署时间缩短 以下是本文中值得引用的评论 这是怎样的前沿进步在 .NET 平台引入之前的半个世纪里这种软件的生产方式已经存在。 这是我的答案因为你同时拥有了两个世界。 1、一方面与 C/C 相比现代语言和平台通过运行时带来了许多便利 2、另一方面原始的本机可执行文件无需在生产计算机上安装平台。 暂停一下你就会意识到这个单一可执行文件有多酷。这 9MB 不仅包含 Web 应用程序代码。但它包含一些 CLR 代码垃圾收集、库加载……、常用的 .NET 类型字符串、整数……和 API 代码如WebApplication.CreateSlimBuilder()【WebApplication.CreateSlimBuilder Method (Microsoft.AspNetCore.Builder) | Microsoft Learn】和 JSON 序列化器代码。 下面的依赖关系图通过 NDepend 获得【Visual Studio - Explore existing .net code architecture】显示了此 Web 应用程序代码及其依赖关系全部打包在 9MB 位中 用反射破坏.NET Native AOT 我努力尝试用 Reflection 来破坏 .NET Native AOT但失败了。这是一个好消息AOT 支持很多 Reflection API。以下是与 AOT 配合使用的代码
// Reflection usage A
System.Type type new object().GetType();
System.Reflection.MethodInfo methodInfo type.GetMethod(ToString);
string str (string)methodInfo.Invoke(Walk the dog, BindingFlags.Default, null, new object?[0], null);
Console.WriteLine(Reflection usage A: str);// Reflection usage B
var listOfString typeof(List).MakeGenericType(new Type[] { typeof(string) });
var list Activator.CreateInstance(listOfString) as Liststring;
list.Add(hello);
PropertyInfo prop listOfString.GetProperty(Count);
int count (int)prop.GetMethod.Invoke(list, new object?[0]);
Console.WriteLine(Reflection usage B: count);// Reflection usage C
Assembly assembly Assembly.GetExecutingAssembly();
Type[] types assembly.GetTypes();
foreach (Type type1 in types.Take(5)) {Console.WriteLine(Reflection usage C: type1.FullName);
}// Reflection usage D
Type unknownType Type.GetType(System.String);
ParameterExpression param Expression.Parameter(unknownType, x);
MethodInfo method unknownType.GetMethod(ToLower, Type.EmptyTypes);
Expression call Expression.Call(param, method);
var lambda Expression.Lambda(call, param).Compile();
var result lambda.DynamicInvoke(HELLO);
Console.WriteLine(Reflection usage D: result); 我们dotnet publish有时会收到一些警告但它确实有效 .NET 8 对本机 AOT 的支持支持这些
1、Middleware 中间件 2、Minimal APIs 最小 API 3、gRPC 远程过程调用 4、Kestrel HTTP Server 5、Authorization 授权 6、JWT Authentication 认证 7、CORS 跨域资源共享 8、HealthChecks 健康检查 9、OutputCaching 输出缓存 10、RequestDecompression 请求解压 11、ResponseCaching 响应缓存 12、ResponseCompression 响应压缩 13、StaticFiles 静态文件 14、WebSockets 15、ADO.NET 16、PostgreSQL 17、Dapper AOT 18、SQLite
尚不支持这些
1、ASP.NET Core MVC 2、WebAPI 3、SignalR 4、Blazor Server, 5、Razor Pages, 6、Session, Spa 7、Entity Framework Core
结论 .NET Native AOT 代表了优化 .NET 应用程序的关键一步。这种编译为本机代码的过程可以最大限度地减少运行时对即时 (JIT) 编译的依赖从而提高性能。由此带来的好处包括更快的执行速度、减少的部署开销以及提高可扩展性的潜力使其成为提高 .NET 开发领域效率和性能的绝佳选择。 借助 .NET 8Native AOT 已经相当成熟可以在生产中使用。我们当然可以希望微软能够继续改进AOT支持。
