AOT项目在发布时,可以通过项目文件中的OptimizationPreference选项来生成理论上最快的可执行文件(Speed)和更小的可执行文件(Size), 默认情况下,编译器选择混合方法:生成快速代码,大小又适中。通过在<PropertyGroup>中增加如下节点即可:
<PropertyGroup>
……
<OptimizationPreference>Size</OptimizationPreference>
</PropertyGroup>
下面是优化完后的结果,并且做了性能测试,从结果来看,Seep的不一定比默认的快,当然,快和慢与测试的接口和使用的库有很大关系,不能一概而论,所以那种方式发布,一定要通过自己的性能测试来决定,不盲信,不育从。
AOT项目在发布时要选择对应平台,因为AOT项目只支持编译出当前平台上的Native代码,并且在发布时,要选择独立发布,这将会把AOT项目本身的代码和经过裁剪的库打成一个执行文件,否则会报错。这块我有一篇文章详细介绍过:
AOT发布相关
桂素伟,公众号:桂迹.net8下发布AOT报错避坑
另一方面,AOT项目发布真叫慢,因为他不但分析项目与AOT要求有没有错误,警告,还要用源生成器把特定代码转换成AOT的适配合代码,然后裁剪,提取依赖包,然后用对应平台的编译器编译成Native代码,所以整个过程要比普通的.NET慢的多,基本是以分钟为单位。希望未来这块能加速。
AOT项目其实更适合云原生,体积小,占内存少,启动快,首次请求也快等特点,几乎就是为了容器中的服务而生。所以在发布镜像时,我们可以针对性地选择镜像的基层。目前,通过Visual Studio创建的docker化的AOT项目,运行时基础镜像用的是mcr.microsoft.com/dotnet/runtime-deps:8.0 ,这个镜像发布出来有240多M,如果有镜像尺寸优化,可以用ubuntu,就会到200M,如果要求更小,就只能基于alpine自己进行裁剪来测试服务的可用性了。
AOT项目上生产,我个人感觉处于开始阶段,技术本身的成熟度,配套工具的完善化,三方库的适配度,都需要一些时间,所以谨慎使用,即使用,也要尽可能进行性能测试,确保业务万无一失。同时也期待AOT技术更快更好地发展。