我正在考虑将我的内存饥饿，cpu绑定程序从Windows窗体移植到Blazor。这是非常资源密集型的，并且经常消耗资源。4gb内存。这使得它不能在32位地址空间中运行。
然而，GUI组件可以清楚地使用视图模型，从而向调用者隐藏大量内存消耗。Windows窗体代码已经被划分为一个"引擎"。"用户界面"部分部分。该引擎几乎没有UI，但cpu有限。
在Windows窗体程序中，我可以生成一个64位进程来承载引擎。这个过程可以公开一个视图模型，Windows窗体程序可以通过一些合适的IPC协议使用该视图模型。Windows窗体程序可以是64位进程的32位客户端。
我想让Blazor应用程序感觉像一个传统的桌面应用程序:SPA和无服务器。理想情况下，用户可以访问一个网页，下载Blazor应用程序，然后开始使用它，而无需与某些"计算服务器"通信。——引擎应该在用户的机器上运行。但是，我不确定如何从Blazor程序中生成64位引擎进程。
你将如何设计它来绕过wasm(32位地址空间)的限制?
我不认为这是一个合格的答案，但至少它可以给你一些起点，也许在这个领域更有经验的人可以补充一个更好的答案。
让我们从这样一个假设开始:由于基于web的技术无法有意义地满足您的性能需求，因此您将把所拥有的内容分成UI和引擎流程。所以这是关于"如何使一个具有本地功能的Blazor UI"。请注意，这对你的发行/部署有影响:我希望最终用户在启动引擎进程和UI之前安装它们。
有很多spa实际上是作为本机应用程序发布的。这通常是通过包装器外壳完成的，包装器外壳是一个本机应用程序，它引导并运行SPA，类似于web浏览器的方式(这也被称为混合应用程序)。开发人员通常有能力修改shell，包括集成本地功能。然而，由于这些shell通常是跨平台的，因此它们的功能往往受到最小公分母的限制。不过也有例外——Xamarin。例如，窗体允许您创建具有低级功能的特定于平台的程序集。
然而，这样的包装器在用户体验或性能方面通常会有一些奇怪的地方——如果你曾经长时间使用Slack或Postman，或者在屏幕之间移动它们，你就会明白我的意思。这些应用程序给人的感觉不是原生的，有时会占用你100%的CPU，直到你重新启动它们。我相信您将花费大量时间使包装器集成正确工作，特别是如果您希望包装器为您执行IPC。
In that light:
您将如何设计它来绕过Wasm(32位地址空间)?
我不会。WinForms和WPF仍然被支持是有原因的。
如果你仍然有兴趣研究它们(冒着被标记为跑题的风险)，这些是我想到的一些包装器技术:
- Blazor移动绑定(Xamarin。Forms, experimental, Microsoft)
- 电子。净(。. NET包装器(electronic .js) 离子Apache科尔多瓦
编辑:从。net 6预览3开始，WinForms和WPF也有BlazorWebView控件，你可能想尝试一下。这个概念与其他包装器类似，但是可以直接从WinForms中使用它，您可以尝试使用Blazor并优雅地将您的应用程序移植到它，而不会中断任何业务连续性。