Aspnetcore: AoT编译

跟进 mono-wasm 的状态

您知道我们可以跟踪进度的问题吗？

当前的解释器模式非常慢。
https://dotnetfiddle.net/JUpsRT

.NET 300 毫秒
WASM：13155毫秒

是的，我们认为这更多是因为没有进行任何优化，而不是表明我们此时应该转向 AoT，但随着 IL 解释器和 AoT 支持的成熟，我们将了解更多。

@danroth27 据我所知，Mono IL 解释器和当前的 mono.wasm 版本之间的性能差异约为 5-10 倍。 总体而言，mono.wasm 大约比原生 .NET Core 控制台应用程序慢 50-80 倍，IL 解释器大约慢 10 倍。

所以解释器目前总体上仍然不是很快，而且 WebAssembly 增加了更多的开销。

我认为 AOT 可能仍然有更好的加快速度的机会，但你是对的，现在排除解释器很可能为时过早，因为大多数 Web 应用程序甚至没有如此高的性能要求，而且很可能会很好带有解释版本。

AOT 更高效不仅对密集型应用程序很重要。 这对于移动和其他低端平台也很重要，尤其是当您考虑电池使用情况时。

目前是否有任何可行的方法可以为 Blazor 项目启用 AoT 编译？ 我一直在阅读声称 Blazor 已经具有 AoT 模式的博客文章； 如果这是真的，有人可以指出一篇解释如何启用它的文章吗？

@TheFanatr AOT 编译依赖于支持此功能的单声道。 至于我可以告诉的话题最后一次更新是从@migueldeicaza Blazor的Gitter 。

米格尔·德·伊卡萨 (2018-06-08 19:01)：
我们正在做这件事。 事情是这样的：
解释器使用“emscripten”，它有一个我们可以依赖的相当完整的 libc。 我们的 AOT 引擎建立在纯 LLVM 之上，这需要我们编写完整的 libc。 后者是理想的地方，因为我们获得了本地链接器和即时的 llvm 支持等等。 但是这会让我们走上必须编写 libc 的道路。
所以在短期内，我们正在着手编写 AOT 编译器，确保我们保持兼容性。 但缺点是 emscripten 工具较旧，因此许多更好的部分（如 LLVM 链接器）不可用。 所以我们正在努力解决这些问题。
基本上，我们已经完成了一些事情，但是我们必须从头开始使用我们拥有的东西，而不是强迫我们自己编写和模拟所有东西。 我们本可以尝试将这两者结合起来，但这也是一项重大努力。 所以我们认为我们现在可以通过一些巧妙的技巧来实现 emscripten。

简而言之，他们正在努力，但目前的公共构建没有一个好的选择。

CoreRT 刚刚报告了一些相当大的进展！！

https://github.com/dotnet/corert/issues/4659#issuecomment -425690500

任何人都知道是什么阻止了这个？ 我可能愿意投入几万亿个工时来看到 AOT 早晚发生，因为客户端 blazor 已经被微软的权力所承诺。 如果我们想使用 Blazor 开发（优秀的）PWA，AOT 将非常重要。

@honkmother AoT 正在https://github.com/mono/mono 存储库中的 mono.wasm 人员进行工作。 我相信他们会很高兴得到你的帮助！ 一旦准备好，这个问题就会跟踪消耗他们的工作。

我想我有一个有点相关的问题，但它没有经过深思熟虑和措辞不当 - 我一直在试验 ILRepack 和 Blazor，并设法将大多数 dll 打包成一个单一的整体 blob。 你们打算在任何时候将公共库打包为单个 dll 吗？

@honkmother我们目前没有任何具体的计划，但我们很想听听您的实验结果。

我能够通过在 /dist/bin/ 输出上使用 ILRepack 并包括 System.Core.dll 将它们中的大部分合并在一起。 结合大多数库后启动时间得到改善，但它引入了许多令人头疼的错误，我不知道如何解决； 当然，您正在失去依赖缓存更新代码片段而无需再次下载整个 blob 的能力。

那么这方面或至少是 ETA 有任何进展吗？ 服务器端工作得很好，但是一旦 DOM 变得相当复杂，通过解释器的客户端 WASM 性能仍然是不可接受的。

我不这么认为，mono repo 上的 AOT 似乎仍然是 WIP； 我听说我们将在 2020 年第一季度拥有它，但我不知道这是否确定； 这很可悲，因为我在客户端设置了一个非常好的 PWA，但它有一些性能问题，AOT 可能会在不需要脏黑客的情况下缓解。

与此同时，您可以做一些事情来减轻那里的痛苦，即使用虚拟 DOM 和/或直接使用 RenderTreeBuilder，这样您就不会一次渲染所有内容并可以控制正在发生的事情。

好吧，我还想知道几个月前关于.NET 5的公告是否有任何变化。 那里有趣的报价：

Blazor 项目已经在使用 Mono AOT。 这将是过渡到 .NET 5 的首批项目之一。我们将其用作证明该计划的场景之一。

他们知道我们不知道的事情吗？

与此同时，您可以做一些事情来减轻那里的痛苦，即使用虚拟 DOM 和/或直接使用 RenderTreeBuilder，这样您就不会一次渲染所有内容并可以控制正在发生的事情。

的确。 我正在从头开始制作一个受 WPF 启发的 MVVM 框架，我做的第一件事就是覆盖ShouldRender以关闭 Blazor 的自动渲染触发器，而是依靠属性更改来告诉组件何时重新渲染。 事实上，HUUUUGGGE 的一项性能改进来自于尽可能通过 JS 互操作而不是StateHasChanged更新样式。

尽管如此，当需要预先生成大型 DOM 时，我遇到了问题 - 例如，复杂的列表或数据网格。 服务器端很好，但客户端有时需要 5-10 秒才能开始渲染。

我们真正需要的是像 WPF 中的VirtualizingPanel 。 我一直在广泛思考如何在 Blazor 和 JS 互操作中实现这一点，但我仍然没有找到完整的解决方案。 在 WPF 中，它起作用是因为该框架负责测量每个视觉元素并报告其大小。 即使使用 JS 互操作，我也不确定同样的事情是否可行，而且我还没有在任何 Web 框架中看到一个很好的通用解决方案。

SyncFusion 有一些虚拟化组件，即列表视图 - 不知道它们是如何工作的，但我正在使用它们。 可能想检查一下。

还有https://github.com/SamProf/BlazorVirtualScrolling也值得一看。

哦，是的，我看到了。 很高兴知道它对你很有效。 它确实具有需要统一项目高度和预先知道高度的重大限制。 但这可能是一个临时解决方案。

有人可以用 blazor-wasm 标签标记这个问题吗？ 在所有服务器端（或托管不可知的）Blazor 问题中很难找到这个问题。

对于那些寻找正在完成的 Mono WASM AOT 工作的概述的人，我找到了这个链接：
https://github.com/mono/mono/projects/11

你的愿望就是我的命令😆

谢谢这很有帮助！

是否有可能对我们何时能够开始使用带有 Blazor 的 AOT 编译的 WASM 进行最模糊的估计，甚至是实验性的？ 6个月？ 一年？ Blazor 团队中的任何人是否真的以临时方式成功地使其工作？

当我们仍然真的不知道最终产品会是什么样子时，开始在客户端 Blazor 上投入大量时间或计划是有点冒险的。 与服务器端一样好，我们确实需要一个可靠且高性能的客户端版本才能使其可行。

我在这里发布了这个问题https://github.com/mono/mono/issues/10222但得到的答案是它是一个错误的地方。 在此重新发布：

宣布 Blazor WASM 将于 2020 年 5 月发布。我们可以假设此时它将是本机 WASM 应用程序吗？ 正确答案是什么？

1. 是的。
2. 我们会尝试，但我们不确定。
3. 不，它将在 2020 年 11 月随 .NET 5.0 一起提供。
4. 不，我们还没有任何路线图。

对于所有 Blazor 粉丝来说，有两件事非常重要：

• 运行时速度 - 在某些用例中解释器会变慢。
• 下载大小 - 希望您能够实现与当前 .NET DLL 类似的 WASM 大小，我们将能够完全删除 mono.wasm（我相信该文件仅包含 IL 解释器 - 对吗？）。

我从一开始就是 Blazor 的忠实粉丝。 我知道 Blazor 服务器端对某些人有一些优势，但我们都在等待真正的革命——浏览器中快速可靠的 Blazor。

谢谢你们的努力！！！

@Andrzej-W 这可能会误导任何浏览此内容并假设 2020 年 11 月是规范版本的人。

我个人听说它应该在 2020 年第一季度左右正式发布。

实际上，据我所知，除了膨胀的可执行文件大小之外，目前没有什么能阻止我们将它实施到我们的构建过程中，而且微软目前还不支持它。

实际上，据我所知，除了膨胀的可执行文件大小之外，目前没有什么能阻止我们将它实施到我们的构建过程中，而且微软目前还不支持它。

有没有人试过这个？ 我认为至少有一个概念证明对我们很重要，这样我们就可以看到它与解释和服务器端相比的表现。 我知道 exe 大小是 Mono 团队正在研究的东西，这很重要，但应用程序速度是王道。 （恕我直言，编译时间真的无关紧要，因为我们将在服务器端进行调试，并且只编译到本机 WASM 以进行发布。webpack 的编译时间也可能非常糟糕）。

在 .NET Conf 上，我们宣布计划于 2020 年 5 月发布 Blazor WebAssembly 的第一个版本。对于第一个 Blazor WebAssembly 版本，我们预计运行时仍将基于我们当前使用的 IL 解释器。

.NET 运行时团队正在为直接编译为 WASM 提供提前编译支持。 这种方法具有提高运行时性能的好处，但以应用程序大小为代价。

对于 5 月的 Blazor WebAssembly 初始版本，我们正在探索以混合模式运行 IL 解释器，其中热路径已编译为 WASM，但应用程序的其余部分是 .NET 程序集。 这在运行时性能和应用程序大小之间提供了很好的折衷。 但是，目前尚不清楚这是否会在 5 月份及时降落。

从长远来看，我们希望提供一个 SDK，让应用程序开发人员可以控制他们的应用程序的哪些部分直接编译为 WASM。 对于何时可以使用此类 SDK，尚无路线图。

@lewing @richlander

谢谢@danroth27的解释。 服务器端预渲染可以部分屏蔽下载大小 - 确保此https://github.com/danroth27/ClientSideBlazorWithPrerendering将适用于所有未来的 Blazor（预）版本。

@danroth27感谢您的更新！ 一个澄清问题 - “.NET 运行时团队”是指 Mono 团队、CoreRT、.NET 5 还是其他？

@legistek他们现在都是一个团队：微笑：。 该技术虽然基于 Mono 运行时。

哦，对了我忘记了。 ;D 我得到的是mono/wasm/10222是否是有关此主题信息的正确问题/回购。

@legistek 是的，所有 .NET WASM 的工作目前都在 mono 仓库中进行。

我现在已经构建了一个运行服务器端 Blazor 的非常复杂的应用程序，并且运行良好。 （但是，通过 IL 解释器的 WASM 太慢以至于无法使用）。

我真的很想知道它如何与编译的 WASM 一起运行。

如果我们暂时忽略下载大小或编译时间，是否有任何 AOT 方法可以将 Blazor 应用程序编译为 WASM 并进行尝试？ 在 mono 存储库 (https://github.com/mono/mono/issues/10222) 上，人们发布了一些使用其他平台（如 Uno）的 AOT 示例，但我还没有看到 Blazor 示例，更不用说有关如何操作的说明了去做吧。

我意识到构建过程在这一点上是完全临时的，但即使在原则上也可能只是为了让我们能够粗略地了解性能差异吗？ 我喜欢服务器端进行调试和演示，但我不知道它是否适用于大规模生产部署。 因此，在我知道 AOT WASM 的性能会很好之前，我对在这个项目上做更多的工作犹豫不决。 我不得不想象有很多人在同一条船上。

只是为了跟进，我最终尝试使用 WSL（在此处描述）的 Uno WASM 引导程序，它确实运行良好。 这里的这个问题仍然被标记为 BLOCKED，虽然我知道他们仍在努力减少有效负载大小，但这似乎不应该阻止 Blazor 的 AOT 构建链上的工作，即使它现在只是 Linux。 是这样吗？如果不是，Blazor 团队在开始之前从 Mono 团队等待什么？

@legistek你构建了你的应用程序还是其他什么？ 性能好多少？ 你有一些指标要分享吗？ 出于好奇问道。

我构建了我的应用程序的一个子集，然后只运行了一些性能指标，因为如果没有 Blazor 引导，我就无法运行整个应用程序。

对于数学（随机数生成和简单算术），我发现 AOT 比解释的快 40 倍。

我真正感兴趣的是我知道效率低下的事情，比如反射和字符串操作。 我的应用程序有一个类似于 WPF 的自定义数据绑定框架，所以我尝试设置一个复杂的数据绑定并将值更改为随机字符串 10,000 次。 结果如下：

单声道解释 IL：2.49 秒
全 AOT（铬）：0.702s
完整的 AOT (Firefox)：0.5 秒
原生：0.067s

所以基本上我们有一个最坏的情况，AOT 大约是解释型 IL 的 4 倍，但最好的情况是 40 倍。

我认为这可能是意料之中的。

不幸的是，这仍然没有告诉我们 Blazor AOT 与解释相比的表现如何，但我有点悲观它会处于较低的一侧（4-5x），因为 Blazor 可能会进行大量的字符串操作来构建DOM 以及复杂的 SPA 将执行大量 JSON API 调用（当然，这些调用广泛使用反射和字符串）。 但实际上，我们无法确定，直到我们可以实际使用 AOT 试用真正的 Blazor 应用程序。

我想在不久的将来，随着浏览器供应商开始更加重视 WebAssembly，性能将得到显着提高。

我认为 AOT 早晚值得进行更多的调查，因为 Blazor 的生死可能取决于它在 WASM 中的客户端实现的声誉。

像https://d07riv.github.io/diabloweb/这样的项目毫无疑问地证明了 WebAssembly 不仅能够处理自己，但我还没有看到在 Mono+WASM 上运行的同样令人印象深刻的概念证明。

这个issue开放两年了。。有什么进展吗？

@partyelite是的，取得了进展。 https://github.com/mono/mono repo 中有一个 AoT 编译到 WASM 的实现，并且运行时已经更新以支持执行 .NET IL 和已编译 WASM 文件的混合。 但是，AoT 支持不会为即将到来的 5 月版本做好准备。 我们将重新考虑为 .NET 5 发布它。

我尝试了 Dan 所指的 AOT 编译选项，它与 Uno 配合得很好。

我仍然在挠头的是为什么至少还没有与 Blazor 一起使用的 PoC？ 我意识到工具链仍然是 Linux 并且输出文件比我们最终想要的要大得多，但是是什么阻止了使用 AoT 制作 Blazor 应用程序的示例，以便我们可以衡量性能和可行性？

我不确定这是否相关，但在 Syncfusion 存储库上，不久前报告了一个性能问题（https://github.com/syncfusion/blazor-samples/issues/50），据说是由于单声道的缓慢性能。

在我的分析中，性能问题深入到调用js_to_wasm ：

这会被这个团队和单声道团队解决吗？ 或者这是无关的东西？

@Herdo可能与此有关： https :

检查您的 Web 控制台日志以查看它是否过度使用 GC。 这似乎已融入 WASM Mono 运行时中，并且需要可配置 IMO。

@honkmother ，
您能否分享更多有关您如何使用 ILRepack 成功打包 Blazor DLL 的信息？ 我使用 ILRepack.MSBuild.Task 详细说明here 。 打包成功，但当我运行应用程序时，我总是收到此错误：

WASM: System.IO.FileNotFoundException: 无法加载文件或程序集“netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51”或其依赖项之一。

包装似乎破坏了某些东西，或者在列表中阻止了应用程序的正确引导。

嗯 AOT 在UNO 中。 你能 C&P 这个解决方案吗？

.Net 5 不支持 Blazor 的 AoT 编译？

它也超出了路线图。

在得出结论之前，我想听听官方评论，但如果这是真的，这是一个非常坏的消息，不仅会影响 Blazor，还会迫使我重新评估 .NET 本身作为前端平台的地位。

几个月来也没有关于 Mono 方面的活动报告：
https://github.com/mono/mono/issues/10222

也许是时候减少损失并专注于 CoreRT 了。

@ram16g @legistek我们正在努力提高.NET 5（及更高版本）中的

你好@danroth27 ，现在的整体性能不是我所关心的，但是初始启动性能呢？ 每次访问页面需要 2-3 秒，直到实际页面加载，直到运行时加载 DLL 编译等。没有 AOT 会有改进吗？ 还是我们需要依赖预渲染？

嗨@迈克尔彼得。 初始页面加载时间主要由下载应用程序和启动运行时决定。 AoT 不会真正帮助那。 AoT 旨在提高运行时性能，而不是减少应用程序下载大小。 对于基于 JIT 的运行时，AoT 可以提高启动性能，因为您无需在运行时进行 JIT，但 Blazor WebAssembly 使用基于 IL 解释器的运行时，没有任何 JIT 支持。

很有可能，AoT 实际上会使应用程序变得更大以供下载，因为 .NET IL 是一种比其本机编译表示形式更紧凑的格式。 因此，使用 AoT 可能会导致在以增加下载大小为代价加快运行时性能之间进行权衡。 目前的想法是，我们将向开发人员提供 AoT 工具链，以便您可以决定要 AoT 的应用程序的数量，然后应用程序将在混合模式下运行，其中一些应用程序仍作为 .NET IL 运行，而性能关键路径被预编译为 WebAssembly。

为了提高应用启动性能，我们正在研究对 .NET IL 链接器的进一步改进，并对核心框架库进行工作以使其更具可链接性。 我们还计划在下载后查看运行时本身的启动性能。

@danroth27关于应用程序启动性能的进展，我有什么可以关注的问题吗？ 这是目前我对 blazor 最大的担忧。

@danroth27 ：+1：非常感谢您提供的信息，我主要在 LAN 环境中使用 Blazor，其中下载时间应该几乎为零，并且认为浏览器正在缓存。 无论如何，Net DLL。 但在启动问题中，我也会非常感兴趣。

请注意，基于 WebAssembly 的应用程序（如 Blazor 解释器）的启动时间可能取决于浏览器是否正确缓存文件。 如果托管您的应用程序的 Web 服务器配置不正确或文件已更改或浏览器无法缓存应用程序，则每次启动应用程序时都必须从头开始重新编译它。 在理想情况下，浏览器能够缓存它，因此您第一次访问后的未来访问将开始得更快。

您可以查看https://v8.dev/blog/wasm-code-caching了解这方面的信息。 Firefox 有类似的机制，我相信 Safari 也有类似的机制，但我不确定。

@danroth27我真的很感谢你的解释和你在尝试让 .NET 5 和其他一切准备就绪时所处的位置。 一些评论/问题：

AoT 的第一步是将 Blazor WebAssembly 移动到使用与 .NET Core 相同的核心 .NET 库，这也应该有助于提高性能

我假设您指的是从 Mono mscorlib 切换到 CoreFX？ 考虑到许多已发布的性能基准显示 CoreFX 显着优于 Mono（以及 NetFX），我认为这是一个很好的举措。

然后我们需要研究如何使 AoT 与 IL 链接一起工作。

是的，正如这里所讨论的那样，链接一直是一个主要障碍。 尽管如此，Uno 还是设法制作了一个工具链，并在解释和编译之间取得了平衡，可以使应用程序大小在 ~10MB 或十几岁的范围内。 我原以为我们至少会在 Blazor 方面为此提供一个 PoC，只是为了开始衡量性能指标。 目前最令人担忧的是不知道哪个学位的表现会有所提高。

我们还计划在下载后查看运行时本身的启动性能。

DOM 构建部分也需要仔细查看。 在我的桌面上加载一个空的 Blazor 应用程序需要 1-2 秒，在移动设备上需要更多时间。 生活在 Angular 世界中，我习惯于每次看到“正在加载...”并发现基本启动时间很好。 更大的问题是构建复杂 DOM 的速度极其缓慢。 即使有 1000-2000 个元素的 DOM 也会为初始加载增加多达 5-10 秒的时间，并且涉及复杂项目的交互性也会显着增加延迟。 我没有看到太多人谈论这个，我担心 (1) AOT 不会解决这个问题，因为它是 WASM/JS 互操作和字符串在两者之间交换的方式所特有的； (2) Blazor 中的渲染/差异机制现在非常成熟，现在将其更改为高性能的东西为时已晚。

目前的想法是，我们将向开发人员提供 AoT 工具链，以便您可以决定要 AoT 多少应用程序，然后应用程序将在混合模式下运行，

就像 Uno 已经在做的那样，...

所以这是我对这一切的反应和分析，我希望你和其他所有人都明白，我是作为一个可能和以往一样大的 .NET 和 Microsoft 粉丝的人来到这里的。 Blazor 是作为使用 _webassembly_ 将 .NET 带回浏览器的框架引入世界的。 当我得知它时，我欣喜若狂。 但是自从它第一次被引入预览以来已经两年多了，而且由于严重的性能问题，webassembly 部分仍然没有准备好用于消费者应用程序。 与此同时，在服务器端投入了大量资金（我仍然不完全确定它的位置），现在可能通过 Xamarin 移动，但 WASM 可能会一次又一次地被淘汰。

自从 SPA 接管和 Silverlight 因 Chrome 禁止插件而消亡以来，.NET 作为前端 Web 平台已经失去了很多优势。 Blazor 可以改变这一切。 但我现在不能确定 Blazor WASM 是否真的是微软打算作为战略游戏规则改变者的，它可能只是像我这样的粉丝的好奇心。 但是无论是否狂热，作为企业主，如果我今天为新项目或旧项目的重建选择前端框架，我如何向我的支持者证明 Blazor 是要走的路，而不是 React 或 Angular？ 当我列出优点和缺点时，除了我喜欢 C# 之外，作为专家我还剩下什么？ 另一方面，缺点不断增加。

所以我很失望，也有点士气低落。 不仅要等待更长时间，而且对于这项技术是否可行，仍有很多疑问，而我一直在等待 AoT，以便我做出决定。

我不指望你们今天改变你的路线图或者真的能够减轻这些担忧中的任何一个，但我认为它们值得播出。 我非常希望它能够成功，并且希望 .NET 重新夺回其作为交互式 Web 应用程序之王的地位。 但如果我今天必须把钱押在上面，那看起来就不是一个好赌注。 请证明我错了！

我不得不说我和@legistek 的情况一样。 我正在使用 0.1 版的 Blazor，而且我是这项技术的忠实粉丝。 当然，对于我们中的一些人来说，有一个在服务器上运行 Blazor 的选项是很好的。 在移动设备上使用 Blazor 也是一个有趣的选择，但我真的相信 WebAssembly 实现应该具有最高优先级。 它是游戏规则的改变者，它是未来。

@danroth27对于 blazor，对于较大的对象列表，JSON 反序列化速度非常慢，是否有任何关于如何快速执行此操作而不是使用当前较慢的解释器方式的指导。

我发现这是 blazor 中最糟糕的性能损失，如果正在使用 rest apis 并且数据大小更大，而 javascript 不会以几乎相同的方式受到大小的影响。

如果它需要手动反序列化过程对于那些较大的列表来说很好，只是想知道是否有一些指导。 理想情况下，我们能够 AOT 反序列化器？

为了缩短启动时间，我建议延迟加载。 这意味着仅加载特定视图或页面所需的 dll。 这确实会加快启动速度

@ram16g @legistek我们正在努力提高.NET 5（及更高版本）中的

大家好， @danroth27 ，这会在多大程度上提高启动速度（假设所有东西都被缓存了）？ 我可以做些什么来帮助在 11 月之前交付 aot？ 我不再喜欢使用 angular 了。 啊哈哈哈哈我愿意提供免费编码只是为了加快速度。 我并不真正关心初始下载大小，因为它只会被缓存。 用户是常客。 当文件被缓存时，angular 可以立即启动。

@hoksource我们没有关于性能特征将如何变化的确切数字，但是如果您在 1-2 个月内尝试预览，您应该能够找到答案。

@hoksource我们没有关于性能特征将如何变化的确切数字，但是如果您在 1-2 个月内尝试预览，您应该能够找到答案。

@SteveSandersonMS好吧
贡献我的目标是能够做到以下几点：

方案一：直接处理（直接处理问题）：
[] 学习编译单声道项目
[]学习编译asp.net blazor项目
[] 学习使用 webassembly 编译 asp.net blazor
[ ] 学习将 blazor 客户端程序完全编译为 webassembly aot（mono->webassembly aot 完成了吗？它可以将所有参考二进制文件合并到 1 个 wasm 文件中吗？）
[ ] 检查 mono 是否可以将整个 webassembly 项目编译为 aot web assembly。
[] 弄清楚如何支持所有缺失的 c#/.net 语言到 webassembly
[]找出将所有dll转换为1个wasm或多个wasm文件的最佳链接结构
[] 找出权衡文件大小和性能的最佳方法
[] 学习/设计将二进制文件链接和合并到 1 个 webassembly 或允许使用部分程序集进行延迟加载
[ ] 有不同的解决方案，选择前几个最好的解决方案，将它们展示给你们。 通过当前项目的一些公共/私有存储库分支

选项2：（间接处理问题）
[ ] 我会做一些小的简单任务，比如小/简单的模块/设计/文档，相信在 11 月 .net 5 发布之前，更优秀的工程师/设计师可以将他们的资源集中/引导到选项 1 所述的直接方法上。

• 补充问题。 所有参考库都应该是开源的吗？ 我编写了很多库，但我不确定是否要公开所有这些库。

但我认为选项 1 将是最好的选择，因为我不会重做你们中的一个人正在做的其他一些事情。 请确认我是否遗漏了什么。

@hoksource感谢您的参与。 目前唯一可行的选项是选项 1，因为 ASP.NET Core 团队正忙于其他工作。 我知道您必须弄清楚很多事情，但希望这有助于解释为什么我们无法直接进入 .NET 5 里程碑:) 听起来您确实有很好的见解进入这里所需的范围。

补充问题。 所有参考库都应该是开源的吗？ 我编写了很多库，但我不确定是否要公开所有这些库。

开源和不开源完全取决于您。 ASP.NET Core 本身是开源的，但您可以根据需要在其上构建闭源代码。 我们只能在我们的 repo 中包含开源的东西。

对于基于 JIT 的运行时，AoT 可以提高启动性能，因为您无需在运行时进行 JIT，但 Blazor WebAssembly 使用基于 IL 解释器的运行时，没有任何 JIT 支持。

出于好奇：客户的 JITting 是否是解释/进行完整 AoT 的实用替代方案？

嗨伙计！ 刚刚和一些团队和事情进行了一些交谈。 似乎这对于诸如 SkiaSharp 之类的库非常重要。 SkiaSharp 的主要部分是一个本机库，输出基本上是一个需要静态链接的 .a 文件。我们可能会构建一个动态本机库，但 Blazor 甚至支持吗？

仅供参考，目前可以将本机库静态链接到运行时。 这不是我推荐的东西，因为它很重要，但是您可以这样做，然后在所有部分都存在后 p/invoke 到静态链接库中。 我不知道我们是否有任何测试用例可以做到这一点，因此它可能需要一些尚未在 Blazor 中提供的额外基础设施。 您必须编译自己的 dotnet.wasm/dotnet.js 才能与您的 Blazor 构建集成，这不适合胆小的人。

动态本机库是另一回事，我的理解是，在您甚至还没有问到 Blazor 是否支持它们之前，wasm 中的工具现在一般来说并不是很好。

我去年发现动态链接在这一点上根本不是一个可行的解决方案。 Emscripten 暗示“主要”wasm 模块包括任何动态库想要使用的系统库的所有可能组合。 这使得一个非常大的通用 wasm 模块开始。

我尝试在 Uno.SkiaSharp 上使用这种方法有一段时间，但它很粗糙并将其放在一边（此时@vargaz可能克制自己说“告诉过你”😂）。

Uno 引导程序现在能够在 Windows 上通过 WSL 使用静态链接（此处的方向）和 P/Invoke，并且由于它使用与内部 System.Native 互操作相同的执行路径，因此现在非常稳定。 您甚至可以通过这种方式

我做了一些阅读，只有 .net 运行时被转换为 wasm。 所有 dll 都会在启动时下载和解析。 看起来正在使用的 wasm 运行时是单声道。 他们现在的目标是改用 .net 核心运行时。

当前的完整 aot 编译器由 mono 完成，但我不确定带有 .net 核心的完整 aot 是否应该是路径/方式。 （不知道我在这里说什么。需要专家）

Internet 表示，对于计算密集型任务，.net core 的运行速度比 mono 快两倍。 启动与 io 相关，第 1 次下载 .dll 二进制文件和依赖项。 （多个文件）将它们解析到内存中。 然后在其上启动 blazor wasm 客户端应用程序。 下载需要一段时间（但可以缓存），解析需要一段时间。 aot 编译器也不知道哪些是 blazor 的依赖项，哪些是特定于应用程序的。 如果您总是设置要包含在 aot wasm 中的 dll，那将会很混乱。 所以一个完整的 aot 看起来不错。 （但使用 .net 核心运行时实现而不是单声道会更快？我也不确定完全 aot wasm 编译的设计/实现是使用单声道还是 .net 运行时完成的。 也不确定进度

@danroth27有什么进展吗？

它会在 .NET 5 中可用吗？
也有一些预发布版本来检查此功能会很好;)

@redradist AOT 不会被 .NET 5 支持。他们正在对 blazor wasm 进行优化。 但是从我读到的内容来看，他们正在进行组装和现场修整。 和运行时优化。 希望他们可以在手机上缓存时获得 <1 启动。 danroth27 评论

@hoksource

@redradist AOT 不会被 .NET 5 支持。他们正在对 blazor wasm 进行优化。 但是从我读到的内容来看，他们正在进行组装和现场修整。 和运行时优化。 希望他们可以在手机上缓存时获得 <1 启动。 danroth27 评论

这是可悲的 ：（

我有个问题。 使用 Blazor AOT，您正在致力于：

1. 将 C# 直接编译为 WebAssembly 字节码格式
2. 或者您是否正在将 .NET DLL 中编译的 IL 转换为 WebAssembly 字节码格式

方法 2) 将保留所有依赖标准 IL 和元数据编译的 .NET 工具（包括我们的）以及 PDB 来工作。 另外 2) 将具有额外的优势，将System DLL 也编译为 WebAssembly，可能会在运行时修剪未执行的代码（请参阅@JbEvain 的 Mono.Linker项目）。
谢谢

顺便说一句，有很多关于 Blazor 的资源，但我没有找到具有正确粒度的资源来教育自己了解Blazor Internals，所以我写了它。

2 不是 1

此外，我希望 AoT 过程能够生成适当的源映射（从 wasm 到 C#），使调试更容易。

我希望在 2021 年第一季度看到对 .Net 6 预览版的这种支持。 这是支持像 SkiaSharp 这样在 Web 浏览器中本地运行的 repo 的基础。

谢谢您联络我们。
我们正在将此问题移至Next sprint planning里程碑以供将来评估/考虑。 我们将在计划下一个里程碑的工作时评估请求。 要了解有关接下来会发生什么以及如何处理此问题的更多信息，您可以在此处阅读有关我们的分类流程的更多信息。