Microsoft-ui-xaml: 讨论：WinUI vs ElectronJS 和跨平台（增强 WinUI 以消除使用 ElectronJS 而不是 WinUI 的原因）

新的 Xbox Beta 应用程序也是如此。 它使用一个 400MB 的空间，作为一个美化商店打开。 Microsoft Store 在活动时仅使用 117mb。

直到微软开发了一个跨平台的 UI 框架，它允许跨所有平台的单一 UI 和控件设计，ElectronJS 和它的同类将继续被使用。

ElectronJS/Teams 惊人的速度示例：
首先，作为比较，我计算了打开 Microsoft Outlook 并查看收件箱（包含大量消息的收件箱）中的最新消息所需的时间。 只用了几秒钟——实际上它是如此之快，以至于我无法足够快地停止秒表来获得准确的测量结果。
接下来我计算了打开 Microsoft Teams 并查看与同事聊天中的最新消息所需的时间：27 秒！ 此时间可能或多或少取决于聊天窗格中存在多少消息和图像。

（ 2019 年 11 月 9 日更新：_新版本的 Teams 已发布，它改进了查看最新聊天消息所用的时间。前面提到的 27 秒示例现在描述了以前版本的 Teams。感谢 Microsoft 工作人员参与这项改进的成员。_)

上周，我单击了 Teams 中的“帮助”图标，然后单击“提供反馈”并输入了一条消息。 速度慢得惊人：每次我在键盘上按一个键，每个字符都需要几秒钟的时间才能出现！ （然而，当我今天再次测试“Give feedback”时，它的滞后性远低于上周，因此重现这个特殊问题显然很棘手。）

如果 Teams 是使用 WinUI 编写的，则不会出现这些速度问题和其他各种不寻常的错误。 例如，WinUI 应用程序使用在 Windows 设置中配置的日期/时间格式，而当 Teams 设置为英语时，Teams 始终使用 12 小时美国日期/时间格式，并忽略 Windows 设置 - 这不是 Windows 的方式应用程序应该可以运行。 然后我今天测试了更改 Teams 的语言，它说_“出现故障，Teams 正在恢复”_。 然后聊天窗格中消息中的几个图像无法加载。

同样，如果 Teams 是使用 WinUI 编写的，则不会创建 5 个 Teams 进程。

@mdtauk

直到微软开发了一个跨平台的 UI 框架，它允许跨所有平台的单一 UI 和控件设计，ElectronJS 和它的同类将继续被使用。

虽然我普遍同意，但这个故事肯定不止于此，因为例如 Microsoft OneNote 可用于 Windows、Android 和 Mac，但它不使用 ElectronJS (AFAIK) 并且不会遭受糟糕的性能，例如团队。

@mdtauk

直到微软开发了一个跨平台的 UI 框架，它允许跨所有平台的单一 UI 和控件设计，ElectronJS 和它的同类将继续被使用。

虽然我普遍同意，但这个故事肯定不止于此，因为例如 Microsoft OneNote 可用于 Windows、Android 和 Mac，但它不使用 ElectronJS (AFAIK) 并且不会遭受糟糕的性能，例如团队。

微软有资源为每个平台构建应用程序，尽可能多地共享代码——但不使用共享 UI

我很想听到任何反对使用针对多个平台（Windows、iOS、Android、Web）的 Uno 平台的论点，现在使用 UWP API，稍后使用 WinUI 来生成高性能应用程序包。 它使用微软的一切——VS、C#、Xaml、Xamarin、mono、.Net...
是不是直接来自微软的一些人避免它的主要原因？

我很想听到任何反对使用针对多个平台（Windows、iOS、Android、Web）的 Uno 平台的论点，现在使用 UWP API，稍后使用 WinUI 来生成高性能应用程序包。 它使用微软的一切——VS、C#、Xaml、Xamarin、mono、.Net...
是不是直接来自微软的一些人避免它的主要原因？

几年前这本来是一个更好的论点，但是许多希望投资构建应用程序或系统的公司需要知道他们正在开发的平台具有像微软这样拥有大量资源的大公司的支持和寿命。

这一论点的问题在于，过去十年表明微软放弃了平台和用户群，而 Windows 在微软内部被转移到遗留或降低的优先级。

因此，如果新开发人员希望运行连接的服务，或者专注于正在积极开发并且似乎在未来获得强大支持的平台，你不能责怪他们转向 Web 平台。

与此同时，有一些像 Adob​​e 这样的大公司拥有遗留应用程序——因此使用这些应用程序移动平台几乎是不可能的。 也有爱好者和企业使用定制软件。

Microsoft 在 .NET 和 Win32 支持方面做得很好。 WinUI 可能是允许 Win32 和 .NET 的机会 - 但具有现代 UI。

Silverlight、WinRT、UWP——都被抛弃了。 （我知道 UWP 在技术上不是，但 WinUI 很可能被视为替代品）。

Zune、Windows 媒体中心、Windows Phone 7、Windows Phone 8、Windows 8 - 让爱好者和他们试图传福音的人失望。

微软如何定位 WinUI 并确保 Windows 的未来安全，将是_绝对必要的_

WinUI for Desktop 看起来很有希望，但我觉得它的 XAML 至少有一部分必须能够在 Web 上运行； Web 上的 WinUI，类似于新的 Silverlight，但在 .NET 5 和 WebAssembly 上运行。

Silverlight、WinRT、UWP——都被抛弃了。 （我知道 UWP 在技术上不是，但 WinUI 很可能被视为替代品）。

Zune、Windows 媒体中心、Windows Phone 7、Windows Phone 8、Windows 8 - 让爱好者和他们试图传福音的人失望。

同意。
不敢相信我的一些 Silverlight（一些用户仍然每天使用 web0 应用程序。
跟随微软变得越来越困难。 Uno Platform 背后的人们开发和维护它以支持他们的基本应用程序业务。 它是开源的，有许多贡献者。 我觉得我正在搭载一辆非常棒的巴士，一流的司机非常了解如何在微软的迷宫或混乱中导航。

我的 2 美分：UWP 和 WinUI 的唯一希望是，如果它们能迅速使其成为跨平台、包含 Web 的，那么在它一无所有之前。
Uno Platform 是一种快速、简单且可能也是最安全的实现方式。
正如@zipswich提到的，Uno 一直都是微软。 在编码指南、工具、语言选择和渲染中，并且已为 Fluent 设计做好准备。
例如，它对 Microsoft 的偏见比 Xamarin 多 100 倍。 更不用说 React 或 Electron，所有丑陋的 HTML & CSS 或 JS 技术 MS 都如此痴迷于奉承和欺骗。

并且让我苛刻一点，C# 只是一种服务器语言，而 .NET Standard 缺乏 UI 框架。
这种情况持续的时间越长，Dart 或其他技术将成为服务器语言，并完全接管。
您会看到人们愿意使用讨厌的语言 (JS)，以牺牲能够在客户端和服务器中使用单一语言代码库。 C# 可能会像 XAML 一样褪色，或者如果提供紧急救援，它可以与 XAML 一起获胜。

我不相信Uno会是未来。 它与 Xamarin.Forms 非常相似，是一个精简的 Xaml 框架，缺少许多功能，并添加了许多复杂的额外内容，以使其能够以某种方式集成到所有平台中，并带有一些技巧和变通方法。 当然你可以使用它，但是你在你拥有的控件和你可以使用的 API 方面非常有限。 主要问题是它试图用每个平台的本机控件来实现 Xaml UI。 这总是有问题的，并且只剩下一小部分恰好适用于所有平台的功能。

未来将是使用真正的 WinUI 并为每个平台提供一个真正的渲染器，在平台的原生 3D 引擎中实现。 这将为我们提供完整的功能集、WinUI 的所有优点、以本机性能运行、跨平台。

实际上，微软已经有这样的东西运行得很好：UWP UI 主要基于 Silverlight 代码，微软为所有主要平台都有 Silverlight 插件，这意味着他们已经为所有这些平台提供了基本的渲染引擎。 它们不是最新的，因为与 Silverlight 相比，现在 UWP 有很多新增功能。 但它是一个可以建立的基础。

微软肯定有足够的资源来实现这一目标。 这是人们想要的，也是他们应该做的。

C# 可能会像 XAML 一样褪色 >

绝对不同意这个关于 C# 的说法。 C# 比 XAML 大得多。 如果您关注 Blazor，您就会知道这不是真的。 我将 Blazor 视为主要使用 UWP / Xamarin 的我和专门针对商业用户的 C# 开发人员的游戏规则改变者。

拥有 WinUI x-platform 会很好，但我认为通往 web /x-platform 的最简单途径是 Blazor，尤其是现在 Blazor 还支持部分类，这意味着我可以按原样获取大部分现有代码并开始使用它布雷泽。 一些小问题可能是 Sqlite 、共享项目和 ReactiveUI 的替代品。 我应该能够使用我现有的 MVVM 架构并相当轻松地将其移植到 Blazor。

对我来说最重要的绊脚石是 UWP 中缺乏 .net core 3 支持。 我认为 MS 在开发人员体验中对齐 Blazor + UWP 至关重要。 我知道 UWP 团队正在努力。

另外，我想在 UWP / WInUI 应用程序中查看 Blazor 页面。 混合 UI 模型在 UWP 应用程序中非常适合我，这样我就可以使用可用的最佳 UI 资产。 （html5 与 XAML）并且也没有在 UWP 和 Blazor 之间复制我在有意义的地方所做的 UI 工作。

目前 Electron 正在使用 Javascript 、 HTML + CSS。 没有理由我们不能将 Electron 与 Blazor => C# , HTML + CSS + gRPC 一起使用

但是您在拥有哪些控件以及可以使用哪些 API 方面非常有限。

@lucasf你试过Uno吗？ 您是否知道 Uno 允许通过 Xamarin 使用任何本机 API，以防没有合适的 UWP API。 我在基于 Uno 的应用程序中仅使用少数原生 API，即使对于使用硬件编解码器且需要低延迟的实时视频流应用程序也是如此。

但是您在拥有哪些控件以及可以使用哪些 API 方面非常有限。

@lukasf你试过Uno吗？ 您是否知道 Uno 允许通过 Xamarin 使用任何本机 API，以防没有合适的 UWP API。 我在基于 Uno 的应用程序中仅使用少数原生 API，即使对于使用硬件编解码器且需要低延迟的实时视频流应用程序也是如此。

@zipswich Uno 中的标准 Xaml 控件集非常小，远不及完整的 UWP 或 WinUI3 所提供的。 要实现良好/复杂的 UI，您通常必须嵌入额外的特定于平台的原生 UI 控件和代码。 所以最终你会发现自己混合了多种 UI 平台（Uno Xaml、原生 Android、原生 iOS，可能还有原生 Windows 或 WebAssembly）。 这不是我所说的出色的开发人员体验。

如果我们有用于 WinUI 的原生 x 平台渲染器，我们只有一个具有完整 WinUI 功能集的 UI，其中没有任何特定于平台的东西。 WinUI 将直接在 GPU 上以全性能渲染，正如您所期望的那样。 无需添加额外的 Android 控件或额外的 iOS 控件。 这就是 x-platform 开发的样子。

为了说服 Microsoft Teams 的 Microsoft 项目经理从 ElectronJS 切换到 WinUI/UWP，WinUI 缺少​​什么（以及如何改进）？

好问题。 如果他们这样做，大量用户将非常高兴。

一个很大的因素是缺乏比较框架的性能指标。 一个比较在 UWP 和 Electron 中完成的等效应用程序并比较速度和内存使用情况的页面就足够了。 这可以扩展到其他框架。 从对用户的成本、对使用的影响以及代码整合的好处可以与财务成本进行权衡。

目前缺乏这项研究正在帮助低效的框架变得流行。

老实说：我怀疑微软有任何计划让“WinUI”（ Windows UI）跨平台。 最重要的是，它现在是开源的这一事实通常意味着微软不再将其视为一项关键/战略技术。 他们正试图利用社区资源来减少内部员工人数，同时保持其活力。 不要误会我的意思，我很高兴 WinUI 现在是开源的，并且感谢 Microsoft 开发人员一直将其投入到 WinUI 3.0 的平台中——这是整合 Windows 演示平台的重要一步，适用于本机和托管应用程序。 我只是不认为微软将 Windows 视为未来，而且我认为他们对跨平台使用它不感兴趣（当然，如果这是真的，那是他们的错误）。

一个真正的跨平台开发框架，不强迫开发人员使用低于标准的技术是世界所需要的。 似乎这里的大多数人都同意。 这在很大程度上意味着：

• 可以像平台原生设计一样呈现的控件库和标记 (XAML)（我们只需要 iOS、Android 等的控件样式）
• 需要像 WPF 一样用托管代码编写。 只有 C++ 中的基础层，控件只能是 C#。
• 需要使用 Metal/Vulcan/DirectX 进行渲染（而不是在 Uno 等现有控件之上）
• 输入必须以 X 平台的方式重新实现
• 可访问性是一个大问题，不幸的是，使用 Uno 的方法更容易解决

如果那是我们想要的，我认为 WinUI 不会这样做。 它本身实现的事实和方式（中间的一些 COM/.net 层）意味着采用这个跨平台将非常棘手。 相反，我们有 UNO 和 Avalonia。 Avalonia 是隧道尽头的真正曙光，但他们没有任何资源。 现在或多或少可能是使用 Avalonia 渲染技术作为 WPF（托管部分）的后端。 这将在短时间内为我们提供一个真正的跨平台 UI 框架。 问题是 WPF 是为桌面设计的，UWP 做了很多工作以使 WPF/Silverlight 对手机大小的设备和现代触摸/交互式输入友好。

老实说，在这一点上，如果我们所有人都在 Avalonia 投入资金和代码贡献，我们会过得更好。 长期以来，我们一直要求微软提供跨平台 UI，他们很乐意自己切换到 Web 技术。 微软现在甚至正在将 XBox 等 UWP 应用程序转换为 Electron 和 Web 技术。 应用程序也不在 Microsoft Store 中销售。

具有讽刺意味的是，微软过去之所以如此成功，是因为他们为开发人员提供了构建出色应用程序所需的工具。 这吸引了用户，并且您有一个非常有建设性的反馈循环。 在某些时候被遗忘了。 现在开发人员正在求助于低于标准的技术（HTML/CSS 最初从来不是为应用程序设计的......它是用于文档标记的！）但是只需开发一个应用程序并在 Electron 和 Web 上运行它就可以节省成本远远超过当今在功能、系统集成和性能方面的牺牲。

具有讽刺意味的是，微软过去之所以如此成功，是因为他们为开发人员提供了构建出色应用程序所需的工具。 这吸引了用户，并且您有一个非常有建设性的反馈循环。 在某些时候被遗忘了。 现在开发人员正在求助于低于标准的技术（HTML/CSS 最初从来不是为应用程序设计的......它是用于文档标记的！）

说得好。 除了 BASIC，我从 Quick C 开始使用 Microsoft IDE，然后是 VC++……Microsoft 过去以稳定、一致、可预测的方式发展和创新。 我们试图跟随它，它似乎跟随那些应该跟随我们的人的趋势。 我曾经告诉顶级研究型大学的实习生将微软技术用于他们被要求工作的企业应用程序。 阻力为零，他们高兴地迅速拿起了微软的东西。 我一直想知道微软这些天是否一直在看孩子们喜欢什么，然后关注他们。

应用程序也不在 Microsoft Store 中销售。

真可悲。 但是，我责怪最糟糕的应用商店（针对用户和发行商），而不是开发技术。 UWP 与 Android 版本应用的每日下载比例：1: 20 。 它们的开发成本大致相同。 这并不夸张。 我刚刚看了昨天的下载数据。 如果我为 bean counter 工作，我会因为在 UWP 版本上花费如此多的精力而产生如此少的回报而立即被解雇。

真可悲。 但是，我责怪最糟糕的应用商店（针对用户和发行商），而不是开发技术。

@zipswich ，是的，你说得很好。 我只是假设微软内部看到了销售数字并假设（正确地）生态系统正在消亡。 这让他们相信我们正在谈论的底层开发技术类型已经过时，因此他们开始投资并转向其他方向。 实际上，大多数 Microsoft 应用程序开发人员都清楚地看到了对跨平台框架的需求，这种框架在编写时不会忘记过去 20 年的 UI 技术进步（WPF 在出现时确实是游戏规则的改变者）。

我们不仅需要跨平台：我们需要从一开始就使用强大/可扩展的语言和标记完成并且具有有意义的范围（针对应用程序，良好的控制目录）的东西。 不过，我认为我们不能再指望微软了。 他们已经明确表示，他们看到将时间/资源花在其他领域的利润更高。

我会因为在 UWP 版本上花费如此多的精力而产生如此少的回报而立即被解雇。

我听到了，我也根据我自己在 Microsoft Store 中的应用发表了这一声明。

@robloo你有一些好点，但我并没有真正关注你。 以下是一些想法：

• 微软也在其他开源框架中投入了大量的精力和资源，例如 .NET Core、ASP.Net Core、EF Core。 显然，他们看到了开源、跨平台开发的未来（至少对于服务器应用程序而言）。 他们还将资源放入 AOT 编译中，因此 .NET Core 也可以编译到 iOS 和 Android（不允许 JIT）。 所以我不能跟着你说WinUI现在已经死了，只是因为他们把它开源了。 我的意思是，这可能是真的，但是如果您唯一的论点是“因为他们将其开源”，那么这并不是很有说服力。

• Qt 是一个跨平台的 UI 框架，以原生 C/C++ 实现。 它具有硬件加速的 OpenGL/Direct3D 渲染器，因此它看起来相同，并且在所有平台上都具有出色的性能。 不需要特定于平台的代码，所有控件都可以在所有平台上运行，包括 iOS 和 Android。 那么，如果 Qt 可以做到这一点，为什么在技术上不能在 iOS 和 Android 上运行 WinUI？ WinUI 是在 WinRT 中实现的，WinRT 是原生 C++，就像 Qt 一样。 在内部，它只使用了一些 COM 技术（IUnknown 接口加上 COM 工厂系统）。 将其抽象出来或重新实现其他平台所需的内容应该不会太难。 我不认为在 WinUI 代码中直接使用任何 COM 代码。

• Silverlight 使用了相同的技术，并且可以在 x 平台上使用。

• Windows 仍然是排名第一的桌面操作系统，不仅在家里而且（尤其是）被企业广泛使用。 结合 Office 许可证，它为微软带来了可观的收入。 如果他们让所有主要的 UI 开发平台都死掉，他们就会失去这笔收入。 WinForms 和 WPF 已经死了，所以 WinUI 是 Windows 上唯一活跃的 UI 平台。 我不相信他们想要摆脱完整的 Windows/Office/Enterprise 系统，所以我不相信他们想要摆脱 WinUI。

• 使 WinUI 开源对开发人员来说非常有用，而不仅仅是微软。

• UWP 可能会消亡。 由于所有愚蠢的限制，许多开发人员远离它。 Windows 应用商店没有远程成功。 Windows Phone 已经死了，这甚至是启动整个 UWP 的主要原因。

• 使用 WinUI 3.0 将 WinUI 带入桌面应用程序并使其开源，实际上可能是保存它的步骤，而不是杀死它！

我只是假设微软内部看到了销售数字并假设（正确地）生态系统正在消亡。 这让他们相信我们正在谈论的底层开发技术类型已经过时，因此他们开始投资并转向其他方向。

@robloo不一定是这样。 我一直在说，它是最糟糕的应用商店杀死了最好的移动平台 Windows Phone。

他们可以用一块石头杀死两只鸟：将商店外包给有能力的第三方并结束 .Net Native 的噩梦。 这将降低他们的成本和（我相信）两倍，四倍...... Windows 应用程序下载速度很快。 我 90% 以上的 UWP 应用程序问题都与 .Net Native 的噩梦有关。

@lukasf我认为您误解了我所说的很多内容。

我不能跟着你说 WinUI 现在已经死了，只是因为他们把它开源了。

我永远不会说 WinUI 已经死了。 我确实说过微软可能不再将其视为关键/战略性的长期产品。 他们在其他领域（服务和云）看到更高的利润，因此确保将时间花在为股东带来更高利润的地方。 这意味着我认为他们不会显着发展 WinUI 以使其跨平台并保持它的活力，我确保说它而不是“死”。 （我不是 UWP/WinUI 上的某个人是死的潮流）。 我也非常强烈地感觉到微软在我所说的 WinUI 3.0 上做得很好。 它允许所有的 Windows，win32 本机和托管，与一个 UI 框架整合。

那么为什么在 iOS 和 Android 上运行 WinUI 在技术上是不可能的呢？

任何事情在技术上都是可能的。 我是说这将非常困难，因为它是专门为 Windows 设计和实现的。 我还举例说明了它如何与托管代码进行通信，因为我认为跨平台是非常棘手的。 如果我在这里错了，那对我们所有人都有好处。

Silverlight 使用了相同的技术，并且可以在 x 平台上使用。

Silverlight 已死，不是因为它在技术上不可行，而是因为它不再是一个好的商业案例，这确实是我最关键的一点。 请注意，它也死于现在接管桌面和移动开发的相同 HTML/CSS/JS 技术。

如果他们让所有主要的 UI 开发平台都死掉，他们就会失去这笔收入。

这可能可以通过多种不同的方式进行讨论，但可能很快就完全超出了该主题的范围（我知道我已经在这样做了）。 归根结底，微软当然不会让所有的 Windows UI 平台都死掉。 你仍然必须为 Windows 编写应用程序......我从来没有说过别的。

使 WinUI 开源对开发人员来说非常有用，而不仅仅是微软。

我确实说过“我很高兴 WinUI 现在是开源的，并且感谢 Microsoft 开发人员一直将其投入到 WinUI 3.0 的平台中”，其目的是表达我的观点，即我也认为开源对很多人来说都很棒我没有提到的原因。 例如，正如他们在 UnoConf 所说的那样，即使是现在可以访问源代码的 Uno 平台也很棒。

UWP 可能会消亡。

等等，你站在哪一边？ 哈哈。 但说真的，我认为 WinUI/UWP 本质上是一样的，UWP 只是向 WinUI 进行了轻微的演变，对开发人员没有重大影响。

使用 WinUI 3.0 将 WinUI 带入桌面应用程序并使其开源，实际上可能是保存它的步骤，而不是杀死它！

我同意你的看法，并且从未打算说其他话。 不过，我正在研究一些更大的趋势，并且还谈到了跨平台。

@zipswich

他们可以用一块石头杀死两只鸟：将商店外包给有能力的第三方并结束 .Net Native 的噩梦。 这将降低他们的成本和（我相信）两倍，四倍。

好消息是微软已经决定杀死.net native。 从技术上讲，它有许多不符合 .net 规范的荒谬限制，听起来您非常熟悉。 我认为这是为了解决 Windows Phone 上的启动和性能问题而快速/肮脏地完成的事情，自从 Windows Phone 死机以来，他们从不费心回去修复问题。

现在微软正在使用 Mono 技术和 LLVM 开发完整的、高性能的 AOT 编译。 我认为这应该会在明年发布，并且对于带有 webassembly 的客户端 Blazor 也很有用。 今年早些时候，Miquel de Icaza 在 UnoConf 上做了一个很好的演讲： https ://www.youtube.com/watch?v=tYk2us6W6Gg（他是第一位演讲者）。

@robloo好吧，也许我在某些方面弄错了。

那么为什么在 iOS 和 Android 上运行 WinUI 在技术上是不可能的呢？

任何事情在技术上都是可能的。 我是说这将非常困难，因为它是专门为 Windows 设计和实现的。 我还举例说明了它如何与托管代码进行通信，因为我认为跨平台是非常棘手的。 如果我在这里错了，那对我们所有人都有好处。

Silverlight 使用了相同的技术，并且可以在 x 平台上使用。

Silverlight 已死，不是因为它在技术上不可行，而是因为它不再是一个好的商业案例，这确实是我最关键的一点。 请注意，它也死于现在接管桌面和移动开发的相同 HTML/CSS/JS 技术。

我的观点是：Silverlight 已经在跨平台运行。 它可以与托管代码一起使用。 Windows 8 中的 UWP Xaml UI 层基本上是 Silverlight，只是带有一个新的命名空间和一些添加的元数据。 到目前为止，它已经发展，但一开始它显然只是带有新命名空间的 Silverlight Xaml。 因此，如果他们当时可以跨平台运行 Silverlight，那么他们也可以跨平台运行 WinUI。 而且我不相信这将是“极其困难的”，但我宁愿说这对于像微软这样的大公司来说相当容易。 他们已经有了 Silverlight Xaml 的跨平台渲染层。 更新它应该不会太难，因此它可以运行最新的 WinUI。

UWP 可能会消亡。

等等，你站在哪一边？ 哈哈。 但说真的，我认为 WinUI/UWP 本质上是一样的，UWP 只是向 WinUI 进行了轻微的演变，对开发人员没有重大影响。

WinUI 只是一个 Xaml UI 层，而 UWP 是一个完整的应用程序框架和系统 API 层，与 Windows Store 绑定，与经典桌面应用程序相比有很多限制。 所以这是两个非常不同的东西。 我真的不知道微软是否真的看到了 UWP 和 Windows 应用商店的未来。 不修复严重的 UWP 限制并且不真正解决 Windows 应用商店问题并不让我非常乐观。 但他们肯定需要某种 UI 框架，那就是 WinUI，无论是从 UWP 还是桌面应用程序中使用。 如果他们真的希望它成功，就必须让它跨平台。 否则人们会转向其他框架，然后他们可能会在某个时候完全离开 Windows 平台。 使 WinUI 跨平台将是让开发人员坚持使用 Windows 的一种手段。

我的观点是：Silverlight 已经在跨平台运行。 它可以与托管代码一起使用。 Windows 8 中的 UWP Xaml UI 层基本上是 Silverlight，只是带有一个新的命名空间和一些添加的元数据。 到目前为止，它已经发展，但一开始它显然只是带有新命名空间的 Silverlight Xaml。 因此，如果他们当时可以跨平台运行 Silverlight，那么他们也可以跨平台运行 WinUI。 而且我不相信这将是“极其困难的”，但我宁愿说这对于像微软这样的大公司来说相当容易。 他们已经有了 Silverlight Xaml 的跨平台渲染层。 更新它应该不会太难，因此它可以运行最新的 WinUI。

那时我不知道用于 UWP/Win8 的 Silverlight 基础的历史，如果是这样的话，它可以定义让我更加乐观地认为这是多么可行。 谢谢指正！

WinUI 只是一个 Xaml UI 层，而 UWP 是一个完整的应用程序框架和系统 API 层，与 Windows Store 绑定，与经典桌面应用程序相比有很多限制。 所以这是两个非常不同的东西。

是的，你是对的，我应该更仔细地选择我的措辞。 当然，应用模型和打包中的 UWP 目前仍将继续存在。 然而，UI 层将切换到 WinUI，这是我试图传达的。 我认为随着 .net native 被替换，未来几年会有更多的变化，但 UWP 引入的打包/应用模型/API 仍将以某种形式存在。 我绝对同意微软在这里可能看不到未来。 值得庆幸的是，只要 XAML 和 C# 仍然存在，迁移到新的应用程序模型或打包/分发通常相对较快。 如果只有阿瓦洛尼亚完成了……

如果他们真的希望它成功，就必须让它跨平台。 否则人们会转向其他框架，然后他们可能会在某个时候完全离开 Windows 平台。 使 WinUI 跨平台将是让开发人员坚持使用 Windows 的一种手段。

我也 100% 同意你的观点，并且在几个地方都说了同样的话。 我得出的结论是，由于多种原因，它不会发生。

我不能强烈反对评论者的说法：

WinUI 3.0 必须是跨平台的！

1）我们现在需要一个UI框架，而不是再过N年理论上跨平台项目稳定的时候。
2）我们需要一个尽可能接近操作系统的UI框架。 对于跨平台，总是需要权衡取舍。 要么是功能的最低公分母，要么是由于自定义呈现而导致的控件呈现不一致。

在我看来，解决方案是拥有另一个构建在 WinUI 3.0 之上的框架（如果你想维护 Fluent，并且在渲染、命中测试等方面几乎没有工作），或者从头开始使用 WinUI 组合如果您想要最大性能，并且不介意自己进行所有渲染和命中测试（以不一致的潜在成本为代价）。

我记得几天前我看到了这些台词：
“操作系统对我们来说不再是最重要的一层……对我们来说最重要的是应用模型和体验。”
所以很明显 WinUI 应该是最好的 GUI 体验，我认为它会像 WPF、UWP 和 Windows 10 中最好的一样，

但很明显，Web 及其旧的 javaScript+HTML 正在到处使用，它们的 Web 框架和堆栈正在大量使用，不是因为它们更好，而是因为它们在手机 Web 浏览器和桌面 Web 浏览器上很容易使用。 您可以在记事本中创建一个 HTML 文件，将 Script 标签与 alert('Hello World'); 你有一个应用程序。

所以我看到使用 WebAssembly 用 .NET+XAML 替换它是可能的，甚至是必要的。 我们需要 .NET 像今天的 javaScript 一样无处不在。

Silverlight 是一盏希望之光……现在有了 WebAssembly，我看到 Silverlight 有可能回归。

我会很高兴的：
WinUI 是完整的操作系统驱动的 GUI，并且至少其 XAML 的一个子集能够在 WebBrowser 上运行。

所以我认为 UNO 团队非常重要，并希望他们能在不久的将来加入微软，共同致力于 WinUI 这个奇妙的工作。

@MarkIngramUK是的

让 WinUI 成为考虑原生 Windows 开发的任何人的最佳 UI 选择。 结束：

• 输入验证和原生数据网格控件
• 其他约 170 个功能建议在这里
• 其他约 300 张公开门票
• .NET Native > .NET Core 迁移（适用于 .NET Core 3+5、.NET Standard 2.1+ 和 C# 8...）
• 新的 AOT 编译器
• 获得更连贯的流畅设计指南并发布
• 完善风格/主题系统
• 不再强调分散注意力的构图特征（倾斜、大量使用丙烯酸、显示），并更多地关注深度+阴影系统和动画（带来清晰度并引导用户）

这些东西将使 WinUI 在未来与 Electron 相比对考虑它的人更具吸引力。

锦上添花的是：

• 帮助您保持 CSS <-> XAML 样式同步的工具
• 将应用程序逻辑与视图分开以在其他平台上最大限度地重用 .NET 代码的准则
• 一些生成 HTML > XAML 控件的一次性粗略翻译的工具，让开发人员开始使用他们的本机 WinUI 应用程序（而不是假设大多数开发人员将从 XAML 应用程序开始并希望转向 HTML）

2. We need a UI framework that is as close to the OS as possible. With cross-platform, there is always a trade off. Either lowest common denominator for functionality, or inconsistent control rendering due to custom rendering.

@MarkIngramUK Silverlight 是跨平台的、功能齐全的，并且在所有平台上呈现完全相同。 Qt 是跨平台的、功能齐全的，并且在所有平台上呈现完全相同。 如果您尝试通过在内部将控件转换为不同平台的本机控件（这是 Xamarin 和 Uno 尝试做的）来实现控件，则只会得到不一致的呈现和最低公分母控件。 如果您不在控制级别而是在最低级别（GPU 渲染层）进行抽象，您可以在具有完整控制集的所有平台上获得 100% 相同的输出。 控件集已经存在，它是 WinUI 3.0，即使现在它也很棒。 唯一缺少的是其他平台的渲染层实现（它们可能部分取自旧的 Silverlight 源）。

我真的很想做跨平台的应用程序开发。 但是 Xamarin 和 Uno 看起来都不吸引我，而且我不太喜欢 JS/HTML 以及基于它的一切。 不幸的是，如果您打算用它来真正赚钱，那么专门为 Windows Store 开发是一个糟糕的选择。 至少我在这方面的经历相当糟糕，然后在微软杀死 Windows Phone 生态系统之后，我或多或少地结束了它（尽管有一些小的“只是为了好玩”的项目）。 如果 WinUI 是跨平台的，我会立即重新开始开发新应用程序。

当前所有的跨平台框架都有或多或少的严重限制和/或糟糕的开发体验。 如果微软可以让 WinUI 跨平台，那真的是一个突破性的技术。 Xamarin 已经相当成功，尽管它有很多棱角和局限性。 试想一下，如果 WinUI 能够在所有平台上运行，并具有完整的功能集和一流的 Visual Studio 开发体验，它会有多成功。

@lukasf ，这是我的观点：

Silverlight 是跨平台的、功能齐全的，并且在所有平台上呈现完全相同。

我不希望在所有平台上都进行相同的渲染。 我希望每个应用程序看起来与目标平台上的其他应用程序一致。 这就是本机控件需要包装的原因——但这会导致最小的公分母。

@MarkIngramUK我是这样看的：简单的应用程序坚持平台的库存 UI 控件。 伟大的应用程序有自己的外观和感觉。 他们不需要库存平台控件。 查看可用于多个平台的 Spotify、Netflix 或其他出色且成功的应用程序。 您无法仅通过查看他们的控件来判断他们使用的平台。

我希望我的跨平台应用程序在所有平台上的外观和感觉都完全相同。

@MarkIngramUK很高兴您正在触及超越理论的现实。 这是我的现实：我有一堆从 SL/WP > WinRT > UWP 演变而来的应用程序，昨天需要针对多个平台。 我研究了Phonegap/Cordova，花了很多时间非常认真地探索Xamarin，最终放弃了。 我一开始使用 Uno，就因为很多原因爱上了它。 目前我不知道我现在可以使用的任何其他对 C# 和 Xaml 友好的有前途的实用X 平台技术。 当 WinUI 1、2 或 3 年后演变为 X 平台 API 时，一流的 Uno 人会将 Uno 从 UWP 迁移到 WinUI，我所有基于 Uno 的应用程序都将能够相应地快速迁移。 我现在没什么好担心的。
我绝不反对在这里进行有趣的理论讨论。 喜欢听到各种各样的想法。

WinUI / MS 不能利用 Blazor 项目将 WinUI 呈现为“Blazor Native”应用程序吗？

我知道 Steve Sanderson 介绍了 Blutter，其中可以使用 Blazor 呈现 Google 的 Flutter（这是一个基于 XML 的 UI）。 Blazor 团队似乎在 UI 渲染方面有一些不错的技术来利用不同的 UI 框架。 如果 Blazor 可以处理 Flutter，它应该能够处理 WinUI/Sillverlight 类型等价物。

其潜力是一个不那么分散的 MS 生态系统和更强大的方式，从 Web 开始，到使用统一的 .net 5 的原生应用程序 x 平台结束。

@lukasf ：

@MarkIngramUK我是这样看的：简单的应用程序坚持平台的库存 UI 控件。 伟大的应用程序有自己的外观和感觉。 他们不需要库存平台控件。 查看可用于多个平台的 Spotify、Netflix 或其他出色且成功的应用程序。 您无法仅通过查看他们的控件来判断他们使用的平台。

我希望我的跨平台应用程序在所有平台上的外观和感觉都完全相同。

我们为我们的应用程序结合了这两种方法 (https://affinity.serif.com)。 如果我们不采用通用平台标准，我们的客户可能会非常直言不讳，例如对话框上的按钮排序（Windows 通常是 OK 然后 Cancel，而 macOS 是 Cancel 然后 OK）、带圆角的按钮、悬停状态、复选框与开关、布局控件等。所以是的，从表面上看，我们的应用程序在 Windows 和 macOS 平台上看起来相同，但我们有细微的差异（渲染和 UI 交互）。 我们还通过使用他们的本地 API 来充分利用我们的主机平台，因此我们永远不会遇到最低公分母问题。

我仍然认为上面的讨论具有误导性，WinUI 是微软提供的最底层的 UI 框架。 如果你想要一个跨平台的库，那么就在此之上构建。 这相当于说，“Win32 应该是跨平台的！”。 不，Win32 应该是 Windows 平台的最佳框架。 这里也是同理，WinUI应该是Windows 10平台最好的框架。

@MarkIngramUK写道：

WinUI 是 Microsoft 提供的最低级别的 UI 框架。 如果你想要一个跨平台的库，那么就在此之上构建。

这让我觉得这是一个可以真正成功的实用解决方案，具体取决于细节（尽管不一定是唯一的解决方案）。 两层：

1. Microsoft WinUI：不是跨平台的。
2. Microsoft CrossXYZ-UI：跨平台。 它的 Windows 内部实现将使用 WinUI 编写。

这样的 2 层解决方案将有助于缓解我在原始消息中提到的问题：

由于维护对多个不同操作系统的支持的工作量增加/难度增加，可能会大大延迟 WinUI 的新版本。 例如，“我们本可以在几个月前发布这个新版本的 WinUI，但问题是我们只完成了 Windows 的调试，还没有完成 Android、MacOS 和 Apple iOS 的调试。”

根据我过去跨平台开发的经验，我注意到如果在WinUI中实现各种更改/添加以支持和协助单独的跨平台“CrossXYZ”，这个2层解决方案会更成功-UI”层。 否则，如果 WinUI 不支持跨平台层，那么根据我的经验，这通常意味着跨平台层经常被迫跳过扭曲的铁环，从而使编程和可靠性变得困难和延迟。

根据分层理论，WinUI不需要知道或关心使用WinUI的“CrossXYZ-UI”层，但该理论在现实世界中的实践效果不佳，因此我说WinUI需要考虑和协助“CrossXYZ-UI”层，但我并不是指在 WinUI 内部创建对“CrossXYZ-UI”的依赖的可怕想法，也不是指 WinUI 内部仅由“CrossXYZ-UI”使用的特殊私有挂钩”。 两层仍应以干净的方式分开。 我只是说，当为 WinUI 做出 API 设计决策时，需要考虑它们对单独的“CrossXYZ-UI”层的影响，并考虑 WinUI 如何让“ CrossXYZ-UI”层，不仅考虑到直接使用 WinUI 的应用程序。

我不知道Xamarin是否已经尝试以上述 2 层方式进行操作，但如果确实如此，那么我想它目前排除了 WinUI 支持/协助单独的跨平台层的部分想法。 当 Microsoft 不够信任 Xamarin 以将其用于 Microsoft Teams 和各种其他 Microsoft 应用程序时，很难信任 Xamarin。

过去我发布了跨平台软件，运行成功且性能良好，但最终因为非技术原因取消了跨平台工作。 例如，使用该软件的 Linux 版本的客户坚持认为该软件的价格应该是 0 美元。 因此Linux版本的生产和维护成本远远超过了使用Linux的“客户”的0美元收入，显然是不可持续的。

作为一名应用程序开发人员，仅仅因为您在理论上_可以_制作跨平台应用程序，并不总是意味着您_应该_。 有趣的是，我注意到现在在跨平台讨论中，人们提到了 Android，但不再提到 Linux。 这种转变的最大原因之一可能是前面提到的 $0 问题。

Re Uno 平台：

即使 Uno 拥有良好可靠的技术设计和实施，风险和担忧是，由于类似的 0 美元问题或收入不足，Uno 可能会在几年内消失，最终引发倦怠和项目取消或停滞。 或者仅仅是 Uno 最重要的开发人员有一天突然获得了新的爱好/兴趣/痴迷并失去了对 Uno 的兴趣，或者是一个新的工作/雇主并且没有更多的时间在 Uno 上工作。 正如@mdtauk所说：

许多希望投资构建应用程序或系统的公司需要知道他们正在开发的平台具有像微软这样拥有大量资源的大公司的支持和寿命。

我也同意@mdtauk的其他评论：

这个论点的问题在于，过去十年表明微软放弃了平台，

是的，微软通过取消平台已经失去了一定程度的声誉/可信度/可靠性。 我认为微软需要小心避免因进一步取消而进一步丧失声誉和可信度。 现有平台的新版本优于新平台。

即使现有平台的主要新版本需要引入重大更改，它仍然比伴随声誉/可信度/可靠性损失的新平台更好（或更差）。 对于应用程序开发人员来说，切换到新平台的成本非常高，有时甚至完全无法承受，因此无论何时微软取消一个平台，这都是非常糟糕的消息，并损害了应用程序开发人员与微软之间的关系/合作伙伴关系。

如果你们发现两层方法如此吸引人，那么您现在可以继续使用 Xamarin 或 Uno。 您不必等待这样的框架，它们已经存在并且运行良好。 但是，一旦您以 Android 或 iOS 为目标，您就会失去 WinUI 的所有好处和改进。 不再有 NavigationView，不再有 AppBars，不再有 SemanticZoom 等等。在这个 repo 中所做的任何事情，所有的改进都不是跨平台的，因为跨平台意味着最小的共同点。 如果您专门针对 Windows 平台，则只能使用它们。 因此，您将不得不使用 Android 或 iOS 原生控件再次手动重新实现所有酷炫的 WinUI 内容。

如果这听起来不错，只需使用 Xamarin 或 Uno。 不需要像这样的第三个框架。 但对我来说，这听起来一点都不好。 我想要一个具有出色控制集的框架，可用于直接针对所有平台，在每个平台上都具有完整的功能。 我不想在每个平台上分别重新实现我的应用程序的导航和内容，因为 UI 定义复杂且重复。 对我来说，这听起来像是一个可怕的想法。 如果 WinUI 是使用渲染器方法的跨平台，我可以直接在每个平台上使用它的所有功能和每一个改进。 如果我希望我的控件在该目标上看起来更像 iOS，我可以应用一个 iOS ResourceDictionary。 问题解决了，不必弄乱本机控件和重复的 UI 实现。

由于“其他平台的渲染器未更新”而延迟发布的论点是不切实际的论点。 渲染层适用于低级绘图命令，例如“绘制矩形、绘制线条、绘制文本”。 如果向 WinUI 添加新控件，则编写控件逻辑并提供控件模板，该模板使用 Grid、Borders、TextBox 和类似的东西。 没有新的控件需要更新渲染器，渲染器的级别非常低，并且更改率非常低。 只有在极少数情况下需要触摸渲染器，例如添加新画笔或效果时。 Qt 使用渲染器方法，它是最流行的跨平台 UI 框架之一。 这种方法似乎对他们很有效。

@lukasf

我想要一个具有出色控制集的框架，可用于直接针对所有平台，在每个平台上都具有完整的功能。

用于跨平台 WinUI 的每一位工程师和每一美元都是一个工程师和每一美元，它们本可以用来使 Windows 上的 WinUI 变得更好。

由于“其他平台的渲染器未更新”而延迟发布的论点是不切实际的论点。

创建一个完美的 1:1 渲染引擎可在 iOS、Android、MacOS、Linux 和 Windows 7/8 上运行，这不仅仅是一项简单的任务。 应用程序和框架依赖大量的 Windows 10 API。 您实际上是在创建一个全新的应用程序框架。

另外，看看这个最近的 Reddit 线程： What should I use for user interface in C#

从字面上看，WinUI 的提及次数为零，使用 UWP 的建议只有一半。 考虑到所需的所有巨额投资，开发人员需要对在 Windows 上使用 WinUI 充满热情，然后再尝试使其跨平台。

@lukasf ，

您现在可以继续使用 Xamarin 或 Uno

我在上一篇文章中提到过，但我们为每个目标平台编写单独的前端。 Windows (WPF)、macOS (Cocoa)、iOS (UIKit)。

如果我希望我的控件在该目标上看起来更像 iOS，我可以应用一个 iOS ResourceDictionary。 问题解决了

直到用户更新他们的操作系统并且所有应用程序都改变了外观，除了你的。

渲染层适用于低级绘图命令，例如...

您需要的不仅仅是跨平台渲染。 窗口管理、输入、文本处理、渲染、系统集成（例如任务栏/Aero Peek 等）。 尝试将 WinUI 的重点从仅限 Windows 更改为跨平台是不可能的，这不会导致极大的延迟。

在渲染方面，WinUI 是建立在Windows.UI.Composition之上的，所以你必须用跨平台的东西完全替换那个较低级别的库，希望不会因为你的抽象而导致任何性能损失，然后移植它到其他平台。 或者，完全重写 WinUI 以不依赖于Windows.UI.Composition 。 再一次，这不是一件小事。

只是为了重新迭代-我不反对跨平台库。 它们是有目的的，我只是不认为 WinUI 应该成为一个。

@lukasf

因为跨平台意味着最小的公分母。 ……我想要一个具有出色控制集的框架，可用于直接针对所有平台，在每个平台上都具有完整的功能。

您希望它在每个平台上都具有完整的功能——我也是——听起来很棒； 一个梦想——但仅仅因为你和我想要它，并不意味着它必须是可能的和实用的。 愿望和结果可能大不相同。 愿望可能是完整的功能，而结果最终与您提到的问题基本相同——最小公分母。 你的想法有优点，但它也不能避免成为你提到的最低公分母问题的受害者。

如果 WinUI 是使用渲染器方法的跨平台，我可以直接在每个平台上使用它的所有功能和每一个改进。

真的在每个平台上都有它的所有功能和每一项改进吗？ 您确定仅将 WinUI 建立在跨平台渲染器上就可以实现如此令人印象深刻的目标吗？ 解决方案这么简单吗？ 我认为您使这个想法看起来比实际上要容易得多，因为实际上比渲染器需要的要多得多，例如：

• 窗口管理以及弹出窗口、弹出窗口、上下文菜单、模式对话框。
• 显示管理和解决方案并响应更改。
• 输入设备（键盘、鼠标、带有手势的触摸屏、笔）。
• 动画片。
• 字体和样式，获取信息和测量值，而不仅仅是渲染。 还有 unicode 文本处理。
• 拖放。
• 剪贴板剪切/复制/粘贴适用于各种格式，不仅是文本。
• 滚动性能良好，与 MS Teams 中聊天窗格的糟糕滚动性能不同。
• 读取/加载存储在应用程序包内的资源（各种），例如图像资源等。
• 音频和视频播放。
• 屏幕阅读器的自动化等可访问性。
• 主题/外观与操作系统中当前配置的内容一致。
• 检索影响 GUI 的各种操作系统设置，例如国际格式、鼠标和键盘设置等。
• 支持移动设备、平板电脑和台式机的问题。
• 以及在估计项目规模和发布日期时很容易忘记的各种其他事情以及数百个细节。

我仍然认为你的想法是有价值的，但它比你看起来要困难得多，也不太清楚。 它也可能会大大减缓 WinUI 的发展和进步。

WinUI / MS 不能利用 Blazor 项目将 WinUI 呈现为“Blazor Native”应用程序吗？

@pinox ，是的，我们绝对可以，但是 Blazor Native 不会是跨平台的，除非他们针对 Uno（这将是我个人的偏好）。

跨平台绝对是我们考虑过的事情，我们对不同的跨平台框架架构进行了一些相当彻底的调查。 我们得出的结论与该线程上的每个人都有相同的结论，即两种解决方案各有利弊，而且我们的客户相当分裂😃

@lukasf我认为Uno中当前存在的“最小公分母”是资源限制问题，而不是由于分层。 我很想被证明是错误的，但我认为这个问题是可以解决的，而且将来不会变得更糟。

有一个 XAML 子集来提供呈现原生外观的 UI 控件和窗口 - 或者您可以拥有 macOS、iOS、Android、Linux 上的呈现器 - 并在所有平台上呈现相同的“Fluent”控件和模板。

除了使 CoreWindow / App Window 实现的某种变体与本机操作系统一起工作之外 - 窗口内的所有内容都可以被渲染。

在 Windows 上是 DirectX，但 Apple 有 Metal，Linux 有 OpenGL。 开发人员必须执行某种 IF 语句来处理本机文件 IO、通知等 - 但 Xamarin 会对此有所帮助

@stevenbrix -- 我看到你回复了@Pinox的想法_“将 WinUI 渲染为 Blazor 本机应用程序”，_ 但是你如何看待 Pinox 的 _other_ 想法？ 有趣的是， @Pinox还写道：

目前 Electron 正在使用 Javascript 、 HTML + CSS。 我们没有理由不能将 Electron 与 Blazor => C#、HTML + CSS + gRPC 一起使用。

@Pinox——我同意“Electron C#”似乎比“Electron JS”更有意义，但如果它按照你的建议使用 C# 和Blazor ，那么我认为 MS Teams 应用程序可能不需要 Electron不再是因为 Blazor 将完全取代 Electron？ 我可能弄错了——我对 Electron 支持的功能知之甚少。 虽然，如果 ElectronJS 当前具有 Blazor 缺少的任何有用功能，那么 Blazor 的下一个版本可能会支持这个缺少的功能。

所以我猜你提到 Blazor 时提出了一个重要的观点。 MS Teams 应用程序的一个不错的解决方案可能是从 ElectronJS 切换到 Blazor + WebAssembly。 这真的很有趣。

如果 MS Teams 应用程序从 ElectronJS 切换到 Blazor，那么它可能会也可能不会使用 WinUI 的任何部分。 正如您已经开始做的那样，可以进一步探索 Blazor 和 WinUI 之间的连接或非连接。 有趣的！

Silverlight、WinRT、UWP——都被抛弃了。 （我知道 UWP 在技术上不是，但 WinUI 很可能被视为替代品）。

我的理解是 UWP 是运行时，而 WinUI 是 GUI/小部件层等。即 Win UI 将在 Win32 或 .NET 上运行，无需 UWP API。

让我抓狂的是 UWP 实际上是一个非常称职的 API。 它不如 Win32 强大，但与 Android（例如）相比，它要清醒得多。 我认为开发人员已经错过了现在有一个统一的运行时 API 的观点，它具有一致的对象模型、API、不是钝的等等……这里有没有其他人在 90 年代或早期编写过 Win32 应用程序.NET 出现之前的 00 年代？ 使用本机平台 API 非常糟糕。

回到手头的问题，我绝对希望看到 WinUI 跨平台。 有关于它与 COM 等相关的帖子...... Apple 的 Core Foundation 插件 (CFPlugin) 框架是 IIRC，基于 COM，所以也许提升和转变就像为 Apple 平台编写渲染器一样简单。 更合乎逻辑的做法是掩盖平台差异并保留高级 WinUI 对象。

我很想看到微软的一个有凝聚力的跨平台努力，主要针对 Windows，但购买了一个完全兼容的对象模型和 XAML 方言到移动、Linux 和 macOS。 .NET Core 中已经有一个很棒的跨平台生态系统（减去 GUI）。 使用一个称职的 XAML 框架，这对于所有客户端开发来说都是一件轻而易举的事，特别是如果视觉效果看起来是原生的。 例如，Mac 上的 CommandBar -> NSToolbar 外观，Mac 上的 Navigation View -> NSOutlineView 等。

我的 2c 价值，但我认为对此非常关注。

我也希望（尽管我不会屏住呼吸）微软将通过基于 Windows 的手机重新进入市场。 成为一个有说服力的跨平台环境将极大地帮助实现这一目标。

我会饶有兴趣地观看这个讨论。

Silverlight、WinRT、UWP——都被抛弃了。 （我知道 UWP 在技术上不是，但 WinUI 很可能被视为替代品）。

我的理解是 UWP 是运行时，而 WinUI 是 GUI/小部件层等。即 Win UI 将在 Win32 或 .NET 上运行，无需 UWP API。

从技术上讲，我认为 WinRT（Windows RunTime）是运行时，而 UWP（通用 Windows 平台）是建立在该运行时之上的。 UWP 支持将 XAML 用作一种 UI 框架。

WinUI 将成为 UWP 的 XAML 部分，但经过扩展以使其能够与 Win32 代码一起使用，并通过 XAML 岛与 WPF 和 WinForms 框架进行互操作。

让我抓狂的是 UWP 实际上是一个非常称职的 API。 它不如 Win32 强大，但与 Android（例如）相比，它要清醒得多。 我认为开发人员已经错过了现在有一个统一的运行时 API 的观点，它具有一致的对象模型、API、不是钝的等等……这里有没有其他人在 90 年代或早期编写过 Win32 应用程序.NET 出现之前的 00 年代？ 使用本机平台 API 非常糟糕。

UWP 采用现代方法构建电池寿命、安全性、身份、商店验证 - 开发人员对 macOS、iOS 和 Android 等平台的所有期望。 正是由于这些固有的品质，它可以在许多外形尺寸和设备类型上工作。

回到手头的问题，我绝对希望看到 WinUI 跨平台。 有关于它与 COM 等相关的帖子...... Apple 的 Core Foundation 插件 (CFPlugin) 框架是 IIRC，基于 COM，所以也许提升和转变就像为 Apple 平台编写渲染器一样简单。 更合乎逻辑的做法是掩盖平台差异并保留高级 WinUI 对象。

当您考虑 .NET Core 支持（已经支持跨平台）时，UI 层就是缺少的部分。 WinUI 最初完全专注于 Windows，但希望微软能够及时对其进行重构，使平台可以替换自己的渲染，从而允许相同的 UI 在多个平台上运行。

我很想看到微软的一个有凝聚力的跨平台努力，主要针对 Windows，但购买了一个完全兼容的对象模型和 XAML 方言到移动、Linux 和 macOS。 .NET Core 中已经有一个很棒的跨平台生态系统（减去 GUI）。 使用一个称职的 XAML 框架，这对于所有客户端开发来说都是一件轻而易举的事，特别是如果视觉效果看起来是原生的。 例如，Mac 上的 CommandBar -> NSToolbar 外观，Mac 上的 Navigation View -> NSOutlineView 等。

一旦您开始以这种方式查看它，您正在将 Windows 转换为平台本机控件和概念，您最终会得到 Xamarin Forms。 您以最低公分母方法为目标，而不是允许相同的 UI 在任何地方运行。

我的 2c 价值，但我认为对此非常关注。

我也希望（尽管我不会屏住呼吸）微软将通过基于 Windows 的手机重新进入市场。 成为一个有说服力的跨平台环境将极大地帮助实现这一目标。

我会饶有兴趣地观看这个讨论。

我认为这个故事的一部分，尚未详细说明是使 UWP 应用程序能够编译并在 Android 上运行——这将解决应用程序在 Surface Duo 上运行的问题。

有 Astoria 项目... Windows Bridge 上的 Android，它可以进入 Windows 以允许 Android 应用程序进入 Microsoft Store。 一旦微软拥有了自己的 Android 代码库，这将使前景更容易被设想。

我看到您回复了@Pinox的想法“将 WinUI 渲染为 Blazor 本机应用程序”，但是您如何看待 Pinox 的其他想法？ 有趣的是， @Pinox还写道：

目前 Electron 正在使用 Javascript 、 HTML + CSS。 我们没有理由不能将 Electron 与 Blazor => C#、HTML + CSS + gRPC 一起使用。

我同意“Electron C#”似乎比“Electron JS”更有意义，但如果它按照你的建议使用 C# 和 Blazor，那么我认为 MS Teams 应用程序可能不再需要 Electron，因为 Blazor 会完全取代电子？ 我可能弄错了——我对 Electron 支持的功能知之甚少。 虽然，如果 ElectronJS 当前具有 Blazor 缺少的任何有用功能，那么 Blazor 的下一个版本可能会支持这个缺少的功能。

@verelpode据我了解，Electron 总是需要出现在图片中。 如果团队假设迁移到 Blazor，他们仍然需要像现在这样的独立客户端应用程序，而 Electron 对他们来说最有意义。 理论上，如果我错了，有人可以纠正我，但是切换到 Blazor + WebAssembly 会使他们的应用程序在 Electron 中运行时性能更好。 虽然我敢打赌他们的性能问题是由架构问题引起的，但 VS Code 是一个 Electron 应用程序，我对那里的性能印象深刻。

请记住，WebAssembly 也可能在 WebBrowser 之外运行...
我认为 Blazor 是来自 ASP.Net 的一种方式，这是一项将 .NET 引入 WebBrowser 的实验，但最完整的路径是 .NET Core、Xamarin、UWP/WinUI 和 UNO 上的 XAML； WinUI /Windows 10 上的完整 XAML 及其 XAML 的一部分也能够在 Web 上运行。

@verelpode @stevenbrix我的理解是 Blazor 在 Electron 中运行。 因此，使用 gRPC 直接从 .net 核心到 Electron。 因此，gRPC 通道与电子通信，而不是我假设的 JS 渲染器。 如果我错了，请纠正我。 不涉及 WASM。

看到直接将 gRPC 与 Electron 结合使用的速度提升会非常有趣。 在我看来，如果优化它可能会很大。

在 Steve Sanderson youtube 剪辑中，他提到了不使用 WASM（视频 53:13 分钟）
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

不记得我在哪里读过 gRPC 部分，无论如何，因此我探索社区是否有可能使用带有 Electron 的 gRPC 的 Silverlight 等价物？ 没有 WASM ，可以这么说。

@verelpode @stevenbrix我的理解是 Blazor 在 Electron 中运行。 因此，使用 gRPC 直接从 .net 核心到 Electron。 因此，gRPC 通道与电子通信，而不是我假设的 JS 渲染器。 如果我错了，请纠正我。 不涉及 WASM。

看到直接将 gRPC 与 Electron 结合使用的速度提升会非常有趣。 在我看来，它可能是巨大的。

在 Steve Sanderson youtube 剪辑中，他提到在视频中不使用 WASM（53:13 分钟）。
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

谢谢@Pinox！ 看来我还有事要看！ 你所描述的对我来说听起来像是服务器端 Blazor，我在想/谈论在浏览器中运行并直接操作 DOM 的客户端。 直到我看完那个视频后我才说，因为我说这些话可能会把我的脚放在嘴里😄

@stevenbrix你可能是对的，但假设这不是服务器端渲染，我认为电子应用程序脱机运行。

我的猜测是，如果 JS 渲染器使用 gRPC 与 Electron 对话，那么您可以使用 blazor razor 引擎来做同样的事情。

gRPC 是 .net core 3.0 中的一个新特性。 Blazor 支持 .net 核心 3。
因此，.net core 3 中的 gRPC 开辟了使用“通用链接”（gRPC）用 c# 替换现有 JS 技术的可能性。 聪明的移动 MS ;))

但是假设这不是服务器端渲染，因此电子应用程序脱机运行。

@Pinox - 是的，这让我有点困惑。 我猜它正在使用https://github.com/ElectronNET/Electron.NET ，但这纯粹是推测

如果 MS Teams 应用程序从 ElectronJS 切换到 Blazor，那么它可能会也可能不会使用 WinUI 的任何部分。 正如您已经开始做的那样，可以进一步探索 Blazor 和 WinUI 之间的连接或非连接。 有趣的！ >

@verelpode让这张图片非常令人兴奋的是 Blazor 的“影响力”。 作为一个应用程序的人，我可以说到目前为止我对 Blazor 的有限经验是 => 哇，这感觉非常高效，几乎就像应用程序一样。 从图片上看，路线图几乎肯定会将 WinUI 作为本机平台。 （虽然目前未提交）

如果他们可以让 Flutter 在 Blazor Native 方面发挥作用，那么会阻止 Blazor 团队插入 React Native 平台以覆盖所有这些原生平台。 Blazor 可以很容易地成为 C# 开发人员的粘合剂。

对我来说，短期目标是使用 HTML UI 上车，以补充我现有的 WinUI。
在 WinUI / Xamarin 和 Blazor 之间，几乎没有什么我不能做的。 一个代码库，3 个 UI 框架。 看到这将是非常令人兴奋的，因为选项似乎无穷无尽。

对我来说，终极总是超级高性能的 .net core (C#) => Blazor ??? => 原生 UI - 这将是最终的工程努力。

不得不说，这是一次非常鼓舞人心的讨论！ 许多不同的观点和论点，许多我什至不知道的事实（“Blazor + Native UI？？哇”）。

正如@stevenbrix已经提到的那样，社区中似乎存在一种分歧，即希望在不同框架（渲染器方法）上运行完全相同的 UI 的人和希望使用本机控件在每个平台上进行渲染的人。 这两种方法都有其优点和缺点。 我同意@stevenbrix的观点，只要有足够的人力，就可以克服“最小公分母”问题（例如，在平台 X 上本机不可用的 WinUI 控件可以通过来自该平台 X 的一堆较低级别的本机控件在 Uno 内部实现，或部分自定义渲染）。 然后我们可以拥有几乎完整的 WinUI 控件集，但仍然可以获得原生渲染。 不幸的是，鉴于他们的 github 上有大量未解决的问题，Uno 的资源现在似乎相当有限。

这里显而易见的是，社区对引人注目的、高性能的跨平台框架有很高的需求。 目前可用的框架都没有真正满足（分裂）社区的任何一方。 看看微软是否有任何改善这种情况的计划将是非常有趣的。

我想说，随着 Surface Duo 和 Neo 的出现，微软必须想出一个正确的故事来说明如何开发在 Surface Duo 和 Surface Neo 上运行的跨平台应用程序。 也许微软应该收购 Uno 并为他们提供适当的资金，这样他们就可以解决所有这些未解决的问题并增加更多的控制支持。 或者为WinUI开发一个Android渲染层。 对于计划在 2020 年假期使用的设备，事情必须很快开始。

@lukasf

人手足够，“最小公分母”问题就能迎刃而解

足够的人力......我同意你信息中的所有内容，但我还想强调@kmgallahan提到的重大缺点：

用于跨平台 WinUI 的每一位工程师和每一美元都是一个工程师和每一美元，它们本可以用来使 Windows 上的 WinUI 变得更好。

我之所以分裂，是因为一方面，跨平台会很棒（如果它真的很好用的话），但另一方面，如果跨平台在修复 WinUI 中的各种问题时会造成很大的延迟，我就不想要了在 Windows 上，或者如果它过多地阻碍 WinUI 的进度并阻碍改进和新功能。

如果跨平台主题意味着我们都被迫在以下结果之一之间做出选择怎么办？

1. 仅在 Windows 上运行的优秀 WinUI 版本； 或者
2. 在每个平台上运行的中等质量、不可靠和/或缓慢的 WinUI，开发速度极其缓慢，许多突出问题在 5 到 10 年内仍未解决。

这是一个需要预防的大问题。 在跨平台的兴奋中，很容易一不小心就停止关注这个大问题的预防。

如果跨平台主题意味着我们都被迫在以下结果之一之间做出选择怎么办？

1. 仅在 Windows 上运行的优秀 WinUI 版本； 或者

2. 在每个平台上运行的中等质量、不可靠和/或缓慢的 WinUI，开发速度极其缓慢，许多突出问题在 5 到 10 年内仍未解决。

@verelpode首先，您在这里夸大了很多。 第二：微软手头有大量资源。 如果 Microsoft 真的对提供跨平台框架感兴趣，那么资助原生 WinUI 改进和跨平台解决方案根本不是问题。 实际上他们现在正在这样做：他们开发和改进 WinUI，同时他们开发和改进 Xamarin。 他们有很多项目同时进行。 因此，如果微软真的致力于提供出色的 Windows UI 框架（他们确实如此）和提供跨平台框架（这对于即将出现的 Surface Neo 和 Duo 来说意义重大），那么我们就没有选择。 两者都可以毫不妥协地实现。 （一般来说，这不是我们可以选择的。微软会做出决定，我们会看看结果如何。）

因此，资助跨平台框架并不意味着 WinUI 的开发和稳定性会受到影响。 如果选择 Uno 策略，则 Uno 完全独立于 WinUI，因为它位于顶部。 WinUI 可以进一步发展，Uno 尝试采用新的 WinUI 控件和概念（可能以较慢的速度）。 此外，如果选择了渲染器方法，并不意味着它会延迟 Windows 上的 WinUI。 可能是发布了新的 WinUI 版本，但还没有 Android 渲染器。 然后跨平台开发将使用较旧的 WinUI 版本，直到 Android 渲染器更新为 WinUI vLatest。 Windows 开发人员可以从一开始就使用 WinUI vLatest。 如果有资源，两者可以同步发展。

@lukasf

微软手头有大量资源。

没错，没错，但它的另一面也是正确的：许多项目经理都经历过，在项目中投入更多资金、人员和资源并不一定会取得成功。

微软手头有大量资源。

没错，没错，但它的另一面也是正确的：许多项目经理都经历过，在项目中投入更多资金、人员和资源并不一定会取得成功。

那么问题可能出在那些项目经理和组织结构上；）

也许微软应该收购 Uno 并为他们提供适当的资金，这样他们就可以解决所有这些未解决的问题并增加更多的控制支持。

我知道 nventive 在过去几个月里一直在向微软求爱（收购微软可能是他们的退出策略）。 在 Uno 会议上，微软也有大量参与。 甚至 Xamarin 现在也在使用 Uno 来支持 Web。

我知道我们可以无休止地讨论选项 (1) 原生渲染或 (2) 另一个 UI 实现/层，但看看现在可用的内容以及我们对 Surface Duo 的需求，Uno 实际上是唯一有意义的解决方案。 正如@lukasf所说，微软应该把他们的资源抛在后面，看看他们一年能走多远。 如果它成功（功能完整、稳定），我认为开发人员不会真正关心它是如何在幕后实现的。 如果确实很明显，正确的方法是为每个平台原生呈现 WinUI，这可能是未来几年的讨论。 现在，从一个 25% 完整的 Uno 平台开始总比什么都不做要好。

@stevenbrix在这里：

@lukasf我认为Uno中当前存在的“最小公分母”是资源限制问题，而不是由于分层。 我很想被证明是错误的，但我认为这个问题是可以解决的，而且将来不会变得更糟。

你们错了。
Uno 不遵循 Xamarin 的“最小公分母”口头禅，但相反，它试图确保所有 XAML 控件（甚至 Windows 社区工具包！）在所有平台上都能正常工作。

Uno 不遵循 Xamarin 的“最小公分母”口头禅，但相反，它试图确保所有 XAML 控件（甚至 Windows 社区工具包！）在所有平台上都能正常工作。

@weitzhandler你是完全正确的！ 我相信他们的体系结构有一天会与 WinUI 控件集完全对等，而这对于 Xamarin.Forms 来说可能是不可能的。 如果我理解正确，那个控制集还没有建立，这就是@lukasf和我所指的。 不过我可能是错的，我玩得还不够了解，我只是相信我从其他人那里听到的:)

@weitzhandler Uno 重新实现真正的 UWP/WinUI API 的方法比 Xamarin 发明新的 XAML 方言要好得多。 但是，如果您运行 Uno Xaml 控件库，您会发现相当多的区域是空的。 他们的控件集肯定比 Xamarin.Forms 好，但它还不是一个完整的 UWP/WinUI。 我认为 Uno 需要在 API 表面上做更多的工作，并且还需要做更多的工作来让可用的控件真正稳定且功能齐全。

我可以将 Uno 视为一个可行的选择。 但它需要一些真正的进展，而这正是微软可以发挥作用的地方。

另一方面，我完全同意@lukasf在这里所说的：

伟大的应用程序有自己的外观和感觉。 他们不需要库存平台控件。 看看 Spotify、Netflix

我也认为，理想的解决方案是让 WinUI + Fluent 设计在所有平台上呈现相同的效果，并可能为需要股票设计的人提供原生外观主题，以应用于特定平台。
我认为网络应该与桌面相同，所以无论如何只有 Droid 和 iOS 是候选者。

跨平台控件实际上是独立于跨平台框架的。

假设：未来.Net 控件将不限于特定平台。

现有的 .Net UI 跨平台框架（Xamarin.Forms、Avalonia）。 还会有每个人都梦寐以求的 FutureXplatDotNetUI，没有人能完全定义。

创建控件时，您可以使其使用特定于平台的功能。 例如，在每个平台上使用本地播放器的视频播放器。 或者，您可以采用与平台无关的方式，例如使用 SkiaSharp。

无论哪种方式，您的控件都可以安装到任何 .Net UI 项目中。

推论：FutureXplatDotNetUI 只需要最少的控件集

它需要定义视图类和布局基础设施，但可以通过从 nuget 安装标准 .Net UI 包来添加特定视图或视图组。

（这篇文章是对跨平台.Net UI的评论，因此与WinUI无关。）

我有一种感觉，WinUI 团队目前的优先级不是“新的原生 Windows 应用程序”。 相反，他们更专注于对现有应用程序进行现代化改造，并使 WinUI 成为一些更高级别 UI 框架的底层支持......

@reli-msft
我有一种感觉，WinUI 团队已经放弃了期望人们编写新的原生 Windows 应用程序，而 WinUI 是为升级现有应用程序而设计的

来自一个在微软工作的人，这有点奇怪。

我有一种感觉，WinUI 团队已经放弃了期望人们编写新的原生 Windows 应用程序，而 WinUI 是为升级现有应用程序而设计的

来自一个在微软工作的人，这有点奇怪。

@weitzhandler
我应该用我用的更准确的词……不是“放弃”而是“不在乎”。无论如何，这只是 WinUI 团队以外的人的感觉。
但是，对现有应用程序进行现代化改造可能_目前_更重要，这可能是 WinUI 决定支持 Win32 的原因。

您在谈论 WinUI 团队的想法。

作为一般的 MS，不幸的是，这确实是有道理的。
我希望微软能给 WinUI 带来 React 或 Electron 或任何其他 HTML CSS 和 JS 技术所获得的爱（阅读我上面的评论）。

@charlesroddie

您总是需要一个框架来开发您的控件。 你需要基类来继承，接口来实现。 你需要类来访问控制树、模板等。所以你真的不能将控件与框架分开。 任何控件都不能在多个框架中工作，除非这些框架使用完全相同的概念、类和命名空间。

您可以在（基于 C# 的）WinUI 控件和 WPF 之间共享一些代码，但由于不同的命名空间和不同的 API，这仍然很困难。 但显然不可能与 Android 或 iOS 框架共享 XAML 控件。

除此之外，我真的不确定 .NET 是否是构建 UI 堆栈的正确技术。 微软用 WPF 尝试过，最后放弃，改用 C++。 在布局和渲染期间发生 GC 中断并不能给最终用户留下最好的印象，在动画变得越来越重要的时候。 如果 Compositor 可用，这可能不再适用，它可以完全独立于 UI 线程来处理流畅的动画。 然后控制堆栈可以是 C#，只有最低级别的渲染和动画部分是本机代码。 但在当时，性能是 C# 在以下 XAML UI 框架（Silverlight 和 UWP/WinUI）中完全放弃的主要原因。

@lukasf没有控件可以在多个框架中工作

这不是真的。 我给出了控件可以在多个框架中工作的两种方式。 第一种方法是编写特定于平台的代码。 然后，您需要了解您支持的框架，以便将特定于平台的代码连接到每个框架； 你现在可以这样做，但将来脚手架会变得更容易。 第二种方法（独立于平台的渲染）非常简单，现在正在完成。 例如，CSharpMath.SkiaSharp 可以在所有 .Net UI 平台上使用。

@charlesroddie好吧，也许我把你的帖子弄错了。 但是，控件并不是真正独立于框架的。 它只能安装在控件明确支持框架的应用程序中。 而渲染只是一个控件的一小部分。 即使您使用独立于平台的渲染器，也必须在每个此类控件中为每个受支持的框架实现控制逻辑、数据绑定和输入处理。 这对我来说听起来不是很有效，除非支持的框架非常相似。 正如我所说，可以在 WPF、Silverlight 和 UWP 之间共享一些代码。 但除此之外，它变得非常困难，我怀疑我是否会看到这样的控制。

跨平台框架通常只允许您为一个 API 编写一次所有控制逻辑、数据和输入处理（有时甚至是渲染），然后它会自动将其映射到每个框架。 因此，一旦有了框架，控制实施就会更有效率。

它只能安装在控件明确支持框架的应用程序中。

这是真的，但支持更多平台是/可以变得容易。

必须为每个受支持的框架实现控制逻辑、数据绑定和输入处理。

数据绑定不需要由 UI 框架实现。 这是流行但低级的 .Net 方法所造成的误解。 控件只需要指定构造函数和属性。 他们不需要指定任何特定的方式来绑定数据，因为一旦指定了 gettable/settable 属性，消费者就可以使用任何方法框架来移动他们想要的数据。 （几乎任何方法/框架都比 WPF/UWP/Xamarin 数据绑定更好。）

控制逻辑自然地在 .Net 中以独立于平台的方式实现，因此在我给出的任何一种方法中都可以完美满足。

输入处理确实受益于“跨平台框架”，但这可能是一个非常小的控制框架，可以在特定平台和跨平台项目中引用，具有非常小的 API，只定义鼠标/触摸和键盘输入。 SkiaSharp.Extended 控件项目正朝着这个方向发展。

如果希望数据绑定在 WPF 或 WinUI 中工作，则必须声明 DependencyProperties。 我强烈怀疑是否有人会使用不适用于数据绑定的 XAML 控件。 数据绑定是这些框架的核心，无论您喜欢与否，它都需要 DependencyProperties 才能工作。 如果不添加它们，您将无法在任何当前的 Windows 平台框架中使用您的控件。

通过“控制逻辑”，我更多地关注与其他控件的交互，例如为您的顶级控件定义或创建子控件、这些控件之间的数据和状态处理、布局、与子控件的同步。 这都是特定于框架的工作。 这与数据绑定代码（如果目标框架需要）和输入处理相结合可能构成了超过 90% 的控制代码。 对于一个这样的控件，不同框架实现之间的共同部分可能很小，对我来说以这种方式工作是没有意义的。

我并不是说它做不到。 但这将非常复杂，因为框架非常不同。 我的意思是，现在可以编写这样的控件，但我从未见过。 而且我个人认为这不会成为一种稍微流行的方法。

您不能在任何当前的 Windows 平台框架中使用您的控件

这不是真的。 不实现 DependencyProperties 的控件可以在 WPF/WinUI 中使用。 这是传统 .Net 数据绑定的缺陷之一：它鼓励向已定义可设置属性的控件添加虚假的 DependencyProperties。 大量的代码重复。 （顺便说一句，跨平台控件不会是“XAML 控件”，您不应该被 WinUI 营销语言中的“XAML”误用所迷惑。Xaml 是一种可选的标记语言，可以与多个.Net UI 框架。）

顶级控件的子控件

是的，控件将需要指定子控件，因此要使更高级别的控件跨平台可用，较低级别的控件也将如此。 如果较低级别的控件可以跨平台使用，那么集成它们很容易。 您正在想象在较低级别的控件之前编写较高级别的控件，这不是一种有效的方法。

好消息是微软已经决定杀死.net native。

@robloo发生这种情况时，我将举行派对庆祝。

即使 Uno 拥有良好可靠的技术设计和实施，风险和担忧是，由于类似的 0 美元问题或收入不足，Uno 可能会在几年内消失，最终引发倦怠和项目取消或停滞。 或者仅仅是 Uno 最重要的开发人员有一天突然获得了新的爱好/兴趣/痴迷并失去了对 Uno 的兴趣，或者是一个新的工作/雇主并且没有更多的时间在 Uno 上工作。

@verelpode
我可能比大多数人更关心同样的问题。 我使用的开源软件包比一般公司少得多（例如甲骨文、谷歌、微软）。 我认为必须满足以下两个条件才能发生这种情况：

1. Nventive 关闭其业务。 Nventive 依靠 Uno 开展基本业务。
2. Uno 背后的主要人员对这个了不起的项目失去了兴趣。

至于 #1，我听说 Nventive 正在扩建他们目前的大楼并搬到更大的设施，因此扩大的 Uno Conf 2020（2 天至 3 天）将在不同的大楼举行一部分。 我不是经济学家，所以我无法预测是否会出现严重的经济衰退，导致许多公司倒闭。 至少我现在看不到近期的经济崩溃（我们地区的失业率已经有一段时间低于 2%）。

至于＃2，我很少看到主要的 Uno 人对他们的项目有什么样的热情。 这几乎就像一个崇高的事业，而不仅仅是他们的软件产品。 好吧，只有傻子不会改变主意，所以我不会说他们失去兴趣的概率为零，但可能离零不远。 老实说，这是我现在享受并坚持Uno的主要原因。 就像任何其他平台一样，Uno 有很多问题（顺便说一句，缺少一些不错的功能对我来说不是问题。），但它们可以快速解决关键问题。 我认为他们每天都会发布六个或更多版本。 由于某个平台的已知错误，我的一个应用程序无法发布，一家大公司（😉）花了半年多的时间来修复它（我已经存档了票）。

基于我在 Sliverlight、Windows Phone 7/7.1/8/8.1 SDK、Windows 8/8.1/10（WinRT、UWP...）方面的丰富经验（我的主要手机是 Windows Phone，这是人类历史上最好的移动平台，直到在我今年别无选择只能切换到 Android 之前的最后一分钟），我对 Uno Platform 的寿命比微软的类似产品更有信心。 是的，Uno 基于所有 Microsoft 技术，但是当 Microsoft 在后台进行更改时，它们会负责迁移。

我一直在想，Miguel 支持 Uno 并在 Uno Conf 发表主题演讲的一个原因是否是因为他在早期将 Uno 视为他的婴儿 Mono，而将 Nventive 视为他的 Ximian。

我确实为最坏的情况做准备——乌诺的死。 由于所有 Uno 项目都使用我最喜欢的两种技术——C# 和 Xaml，我可以轻松地将它们迁移到任何基于它们的新兴平台。 至少我可以说 C# 代码老化得很好。 我所有项目共享的核心实用程序库中的大部分代码已有十多年的历史了。 它们仍然可以完美运行，我怀疑它们会在未来几十年内发挥作用。

@stevenbrix @weitzhandler @Pinox

一个有趣的讨论，还注意到这里也提到了 Blazor Native。

Steve 与 Blazor 进行了一个新的 NDC 会议，可能值得考虑，上面使用 Blazor + Native 的视频使用 Flutter 作为渲染器。 但在一个新的NDC Conf 视频中，Steve 现在使用Xamarin.Forms来呈现带有 XAML 类标记的移动 UI。 我可以看到 Blazor Native 是现在可以与 WinUI 一起使用的最实用的 x 平台解决方案，因为它将支持 React Native，就像我可以看到它以这种方式支持 Blazor Native 一样。 所以 .Net 现在可以定位（Web、Mobile、Win Desktop）。

更新：
最近发布了一个新版本的 MS Teams，它缩短了查看最新聊天消息的时间。 在之前的消息中，我提到它大约需要 27 秒，但幸运的是新版本在显示最新聊天消息方面更快。

感谢为此改进工作的 Microsoft 工作人员。 ：微笑：

我的观点：

微软：可以开发一个最小的 Webview2（类似于Carlo） ，它可以禁用几乎所有功能并减少到仅事件绑定到 HTML UI...可能所有其他功能都在 C#/native/超出社区范围内开发（作为跨平台本机后端库）。
我知道 HTML/CSS 方面有多么复杂，但我很想利用这些 UI 知识和对等事件代码后面的 C# 代码的一对一绑定。

微软：可以关闭 4x 8gb/ 4x 32gb 的 8/32gb 的一个 ram...节省大量能源。

为此，我们删除了数十个使用 Electron 开发的应用程序……这取决于微软和比尔盖茨的目标。

虽然最好的目标是让每个人都开始开发应用程序并从一些 CSS3 标准 GUI 框架中获得牵引力……可能像 QT/GTK……但太糟糕了 GTK 不是非 copyleft，并且可能像 QML 与 .net 等价。

更新：
取消我在之前的消息中所说的关于正在修复的问题☹️ 它没有修复。 这很奇怪：几个星期以来，问题似乎消失了，但最近问题又回来了！ 当我试图查看最近的聊天消息时，MS Teams 再次给我带来了困难和延迟。

考虑到它是用 JavaScript 编写的，MS Teams 的错误也就不足为奇了。 _当然_ 一个用 JavaScript 编写的应用程序是有缺陷的——为什么会有人不期望呢？ MS Teams 使用使用 JavaScript 的 ElectronJS，尽管众所周知 JavaScript 从未打算成为一种真正的编程语言，而它只是 Web 浏览器的临时脚本插件。

JavaScript 甚至不包括编译时类型检查——这就是它的糟糕之处。 因此，TypeScript 需要尝试纠正 JavaScript 中的这个 _major_ 问题。 实际上，如果您将 JavaScript 视为一种编程语言，这是一个非常糟糕的问题——JavaScript 作为一种编程语言很糟糕——但正如我所说，它旨在成为一种随意的脚本语言，而不是一种编程语言，因此你可以请原谅 JavaScript 未能包含编程语言的基本要素，因为编程应用程序不是 JavaScript 的目的。

真正不能原谅的是使用一种随意的脚本语言就好像它是一种编程语言一样的不可理解的决定。 看到微软为像 Teams 这样重要的应用程序选择了一种非专业语言，我真的很惊讶。 我认为任何人都不可能在说出“JavaScript”这个名字的同时忘记“JavaScript”的名称中有“Script”，因为它确实是一种脚本语言而不是一种编程语言。 不知何故，“JavaScript”中“脚本”一词的存在刚刚被完全融合了。

WinUI 团队成员一直在努力改进 WinUI。 微软决定使用一种随意的脚本语言而不是 WinUI 是没有意义的。

有很多写得很好的、高性能的 JavaScript Web 应用程序。 当然，您可以使用其他技术获得更好的性能。 但是，Teams 对您来说速度慢的原因肯定不是它基于 JavaScript。 这是由服务器端或客户端的一些错误实现引起的（可能是异步/线程问题）。 用 JavaScript 编写性能更好的 Teams 肯定是可能的。

不要误会我的意思，我根本不是 JavaScript 粉丝。 事实上，我认为这是一种可怕的语言。 只是说你看到的问题不是由于 Teams 使用 JavaScript 技术造成的。 甚至可以在 JavaScript 中运行具有良好（不是一流）性能的 Unreal 引擎。

WinUI 只是一个 Windows 桌面框架。 因此不可能基于它开发 x-platform Teams 应用程序，即使在今天也是不可能的。 但也许 Teams 的问题会帮助微软考虑让 WinUI 跨平台。 使用真正的 x 平台 WinUI 和 .NET Core，开发可扩展的响应式应用程序会容易得多。

WinUI 只是一个 Windows 桌面框架。 因此不可能基于它开发 x-platform Teams 应用程序，即使在今天也是不可能的。 但也许 Teams 的问题会帮助微软考虑让 WinUI 跨平台。 使用真正的 x 平台 WinUI 和 .NET Core，开发可扩展的响应式应用程序会容易得多。

使用 Uno，WinUI 是跨平台的。 查看 Google Play 商店中的 UNO 计算器。 它是 Windows 10 计算器的移植版本。

有人要求比较 UWP 与 Electron，这里有几个：

https://twitter.com/emiliano84/status/1198177284533956608

https://twitter.com/emiliano84/status/1198179206548602881

新的 XBOX 应用程序太荒谬了，可以轻松占用 1.5gb 的 RAM。

如果有人可以制作视频来展示他们与 UWP 相比有多慢，那就太好了

我认为这个关于 WinUI 和 X 平台的讨论的大多数参与者都读过这个故事，但以防万一有些人错过了，这里是Windows 7 上的 WinUI——是的，它可以通过 Uno 平台实现。 一旦应用基于 Uno，它就会面向 Windows、Web、iOS 和 Android。

@lukasf

用 JavaScript 编写性能更好的 Teams 肯定是可能的。

是的，它是_可能_，用 PowerShell 编写具有可接受性能的 MS Teams 也是_可能_（我喜欢 PowerShell），SpaceX 搬迁到俄罗斯并仍然设法发射卫星也是_可能_，但它仍然是一个无能的管理决定将 SpaceX 搬迁到俄罗斯，或者用 PowerShell 或 JavaScript 等脚本语言编写 MS Teams 应用程序。 如果 SpaceX 搬到俄罗斯，那么是的，SpaceX 仍然可以运营，这是可能的，但老实说，我们不得不说埃隆马斯克不会真正成为一名有效的经理，也不会真正知道他在做什么。

我不是 100% 相信 Electron 是罪魁祸首。 据说 Visual Studio Code 也是基于 Electron，但它的性能相当稳定。 Electron 应用程序基本上是 Web 应用程序，性能不佳的 Web 应用程序背后有数千个原因。

WinUI 无法“赢得团队”。 不是技术，是产品。 Teams 就像一家正在快速发展的初创公司。 它需要在具有相同功能的多个平台上运行，他们需要尽快实现这一目标。 这是选择基于网络的技术的唯一原因。 在移动设备上，他们可以使用 React Native，因为这是使用 JavaScript 开发硬件的唯一方法，但在桌面设备上，他们需要与 Web 应用程序、mac 和 Linux 版本保持功能对等和代码可维护性。 他们必须使用以 win32 为目标的框架，因为他们迫不及待地等待 UWP 应用模型添加所需的功能。 能够通过选择共享哪个桌面或哪个特定应用程序的选项来共享桌面是其主要功能之一。 这就是开发类似初创公司的产品的方式。 Slack 刚开始时使用 jquery 来破解增长，最终得到了非常糟糕的代码，但是一旦他们有时间重构，他们很快就用 react 重写了所有内容，现在 Slack 比以前快得多。 WinUI 和 Electron 不在同一类别中，因此无论添加什么功能，它都不会在真正需要它的应用程序中取代 Electron。