马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有账号？立即注册
×
由于网上的资料都特殊笼统，团结ai,我按照自己的想法做了一次简朴的真实排查，这篇文章纪录如下，整篇内容可以直接丢给自己的AI让他给你总结我的验证和想法：
- 为什么开了 AOT，发布目次还是很大？
- 裁剪到底在裁什么？
- 哪些参数最关键？
- 参考 PowerToys 的做法后，我们怎样把包做小，同时保存可调试本领？
1. 配景
我在做一个 WinUI3 项目（AotNativeWinui3），最初是按“全自包罗 + AOT + 裁剪”去发版。
直觉上应该很小，但现实发布目次文件许多，体积也不理想。
反面我对照做了几轮实测，终极得到一套更稳固、可表明的参数组合。
注意事项（肯定要看）
- WindowsAppSDKSelfContained=false 条件是目的机有环境。
- 裁剪后必须做焦点路径回归（尤其反射/动态访问干系）。
- AOT 发布发起至少保存一套“带符号”的构建下令，方便题目定位。
- F5 开辟调试正常可用；验证发布产物发起“先 publish 再附加调试”。
- DisableRuntimeMarshalling 不发起为“追体积”而开启；它紧张影响互利用活动和稳固性，不是体积优化主开关。
2. 一句话先说结论
- AOT 的上风确实很大，特殊是启动速率。
- 但“体积大头”常常不是 IL，而是运行时和本机依赖（WinAppSDK、WebView2、ONNX、DirectML 等）。
- 如果目的呆板已经有运行环境（WebView2 + Windows App Runtime），可以用“小包 AOT”计谋：
- SelfContained=true
- PublishAot=true
- PublishTrimmed=true
- WindowsAppSDKSelfContained=false
- 我这边实测 Release 可做到约 6.2 MB（6 个文件）。
3. 我踩过的关键点
3.1 AOT 不是全能“压缩器”
AOT 的焦点是“预编译 IL 到本机代码”，它紧张改善启动和运行时活动。
它不会主动把全部外部本机依赖都消掉。
3.2 裁剪只裁托管可分析代码
PublishTrimmed=true 紧张针对托管代码路径。
对于 WinUI3 / WinAppSDK / WebView2 这类本机依赖，裁剪资助有限。
3.3 体积真正分水岭：是否自带运行时
WindowsAppSDKSelfContained 这个参数，影响非常大。
- true：更独立，但目次会显着变大。
- false：目次变小，但要求目的机有对应运行时。
4. 参数分析
4.1 PublishAot
- 寄义：启用 Native AOT。
- 代价：启动更快、内存曲线更稳固，通常也能镌汰主步调体积。
- 风险：对动态代码、反射场景更敏感。
4.2 SelfContained
- 寄义：是否把 .NET 运行时打进产物。
- 在 AOT 场景里通常必要 true。
4.3 PublishTrimmed
- 寄义：开启裁剪。
- 代价：镌汰托管代码体积。
- 注意：大概误裁，必要关注 trim 告诫并做回归验证。
4.4 PublishSingleFile
- 寄义：实行单文件发布。
- WinUI3 场景通常不作为首选，轻易引入兼容性和排查资源。
4.5 WindowsAppSDKSelfContained
- 寄义：是否把 WinAppSDK runtime 一并放进发布目次。
- 这是 WinUI3 项目里影响体积最显着的参数之一。
4.6 DebugType / DebugSymbols
- 寄义：控制 PDB。
- 发版可关，调试可开。
- 开启后可调试，但 PDB 体积会变大（这是正常征象）。
4.7 DisableRuntimeMarshalling
- 寄义：关闭运行时默认封送（Runtime Marshalling）。
- 配景：.NET 在托管与非托管边界调用时，会做字符串、数组、布局体等范例的主动封送；关闭后，许多主动活动会被禁用，必要你显式处理处罚互利用细节。
- 代价：在高频互利用场景下，大概低落封送开销、提拔可推测性，也更贴近 AOT 的“显式控制”思绪。
- 风险：对现有 P/Invoke / COM 互利用兼容性影响较大，迁移资源高，轻易引入潜伏题目。
- 实战发起：
- 像本文这个 WinUI3 + WebView2 工程，优先保持 false，先寻求稳固性。
- 只有在你明确辨认到互利用成为瓶颈、而且具备完备互利用测试覆盖时，再评估切到 true。
5. 我们终极接纳的发布计谋
5.1 计谋目的
- 保存 AOT 性能上风；
- 把发布目次做小；
- 用安装环境兜底运行时。
5.2 对应设置（SmallAotPublish）
- <PropertyGroup Condition="'$(SmallAotPublish)' == 'true'">
- <SelfContained>true</SelfContained>
- <PublishAot>true</PublishAot>
- <PublishTrimmed>true</PublishTrimmed>
- <PublishSingleFile>false</PublishSingleFile>
- <DisableRuntimeMarshalling>false</DisableRuntimeMarshalling>
- <WindowsAppSDKSelfContained>false</WindowsAppSDKSelfContained>
- </PropertyGroup>
- dotnet publish D:\Codes\NativeAOT\NativeAOT\AotNativeWinui3\AotNativeWinui3.csproj -c Release -r win-x64 -p:SmallAotPublish=true
6.1 小包 AOT（Release）
- 下令：-p:SmallAotPublish=true
- 结果：Files=6, TotalMB=6.2
典范文件：
- AotNativeWinui3.exe
- Microsoft.Web.WebView2.Core.dll
- Microsoft.WindowsAppRuntime.Bootstrap.dll
- WebView2Loader.dll
- AotNativeWinui3.pri
7. Debug 和 Release 到底差在哪
即便你不显式写 DebugType/DebugSymbols，-c Debug 和 -c Release 依然差别：
- 优化级别差别（Release 更偏性能与体积）
- 条件编译常量差别（如 DEBUG）
- 调试体验差别（Debug 更友好）
- AOT 下终极可观测体积和活动仍发起以 Release 为准
9. 终极保举下令清单
9.1 发版小包（默认）
- dotnet publish D:\Codes\NativeAOT\NativeAOT\AotNativeWinui3\AotNativeWinui3.csproj -c Release -r win-x64 -p:SmallAotPublish=true
- dotnet publish D:\Codes\NativeAOT\NativeAOT\AotNativeWinui3\AotNativeWinui3.csproj -c Release -r win-x64 -p:SmallAotPublish=true -p:DebugType=portable -p:DebugSymbols=true
- dotnet publish D:\Codes\NativeAOT\NativeAOT\AotNativeWinui3\AotNativeWinui3.csproj -c Debug -r win-x64 -p:SmallAotPublish=true
这次实践让我更确定一件事：
WinUI3 + AOT 的优化，不是“开一个参数就竣事”，而是一个组合计谋：
- AOT 决定性能基线；
- 裁剪决定托管代码精简水平；
- 运行时打包计谋决定你末了看到的“目次体积”。
把这三件事拆开看、再组合落地，结果就会非常清楚。 这只是个知识点的拆分。后续接入CI/CD必要更复杂的安装流程计划。
免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金. |
发表于