【译】基于xaml的跨平台框架对比分析-kb88凯时官网登录

多年来，基于xaml的ui框架已经有了很大的发展。下面的图表是最好的说明。这些框架主要包含：支持跨平台应用的avalonia ui, uno platform和 .net maui。事实上，除了avalonia ui之外，对跨平台xaml的需求是其发展的主要驱动力。如果微软早点推出一个类似flutter这样的跨平台ui框架，我们可能就不会有这个么多的选择。这样有利有弊：好处在于我们选择有很多跨平台方案可以选择，坏处在于不同的框架有不同的对象模型以及各自的特有的xaml语法（dialect of xaml）。
在关注各种 .net ui 框架时，我们会提出同一个问题：应该使用哪一个xaml ui框架来开发我们的应用？这是一个合理且重要的问题。迄今为止还没有一个明确的答案。但是，对于每个具体的应用，这个问题很容易回答，因为可以针对特定的应用需求比较分析每一种框架的优点和缺点。通过概述基于 xaml 的主要 ui 框架的优点和缺点，本文档旨在帮助公司和开发人员回答以下问题：

应该选择哪一个xaml框架开发我的跨平台应用？

高屋建瓴地看，可以从架构上描述这些基于xaml的跨平台ui框架的差异。这些框架都是基于相同的 .net（以前的mono）工具。不容忽视的是，xamarin对 .net 的贡献使得这些框架存在。此外，在 .net 6 中，这些框架在每个平台上都使用相同的运行时和核心库。

• : 完全自己呈现控件和用户界面元素。这一点和flutter相同。
• : 标准化一组名称、属性、事件，并将它们应用/链接到特定平台的原生控件。如果单个平台不支持某项功能，该功能则不会出现在所有平台的maui中（不涉及特定平台的代码）
• : 使用选定的几个特定于平台的基本元素来构建和渲染控件。 对于高级控件，这提供了近乎像素完美的结果。这意味着 uno platform 像 avalonia ui 和 flutter那样完全渲染控件; 不过, 它还支持直接嵌入特定平台的原生控件，是一个混合架构。

因为 wpf 和 uwp/winui 这些基于xaml的微软框架不是跨平台的，所以这里不进行详细比较。但是 wpf 可以通过 或者 跨平台运行。winui/uwp已通过接下来讨论的 uno platform 支持跨平台运行。

项目链接

其他框架

还有一些其他可用于 .net跨平台开发的kb88凯时官网登录的解决方案在本文的不再详细描述。即便本文不会进行详细对比，这些框架或者kb88凯时官网登录的解决方案也值得了解以下

1. : 正如上文所讲，wpf 可以通过 或者 跨平台运行。对于wpf代码量较大的现有应用，可以考虑这种跨平台kb88凯时官网登录的解决方案。
2. : 一个类似于 .net maui 的ui框架，使用平台原生控件构建ui。xaml也可以用于序列化和构造ui.
3. : 用于游戏开发, noesis gui 重新创建wpf，用于游戏引擎（如unity）以构建用户界面。noesis gui 对 xaml 的支持非常广泛，可以和 microsoft blend 一起使用。 如果它可以在游戏引擎之外工作，并且对较小的应用程序有更好的许可，那么它将是一项早于其他跨平台xaml实现的有趣技术。
4. : .net maui 可以托管 blazor web 应用（在 blazorwebview 控件内），使其更像是应用程序和服务容器。对于那些希望将现有 web 应用程序重新打包并分发为移动应用程序的人来说，这是一个非常有吸引力的选择。
5. : .net maui 还可以托管 avalonia ui(在avaloniaview控件里)，使其更像是一个应用程序和服务的容器。 由于 avalonia 只是一个 ui 框架，要轻松获取 .net maui 的所有附加平台抽象功能 （essentials） 以及更轻松地打包和部署移动应用时，这是一个非常有吸引力的选择。

更多时候将 .net maui 作为应用程序加服务容器，然后托管其他 ui 框架（如 blazor 或 avalonia ui）是一个有吸引力的选择。这种架构可能会在未来获得更多的关注，绝对是一个值得密切关注的领域。

框架对比

每个框架都有不同的表现——在某些地方很明显。下表中重点关注具有较高影响力的领域和特征。对于所有框架表象相同的地方将不在下表中呈现（仅关注差异）。

这种比较是基于对各种框架的大量研究和经验；结果不免有些主观，还需要注意的是，. net maui的使用经验是三个选项中最少的，这可能会影响排名的准确性。

• ✔️ 表示支持该特性 ❌ 表示不支持
• ⭐⭐⭐ 是最高/最好的评分, ⭐ 是最低/最差的

该表格最近一次更新是在2023年7月.

备注

mvu模式

.net maui对传统上认为的带有 and 的mvu模式具有最完整的支持. 这是一个活跃的试验性和开发领域，预计未来将得到和mvvm的相同级别的支持。

uno platform开发了自己的mvu变体，称为mvu-x。这与其他产品有很大不同，并且具有更高的学习曲线，但确实与 xaml 数据绑定集成得更好。mvu模式这一全新方法的长期可行性还有待观察，在这实验性的方案稳定之前，最好谨慎选择。

avalonia没有直接的支持mvu模式。但是，它提供了两个类库支持使用声明性语法替代xaml编写ui界面。通过在avalonia上提供帮助方法和扩展来支持许多c#标记概念。这提供了一种用c#编写ui界面的好方法，该方法可以遵循mvu模式而不需要使用xaml。f# 开发人员的另一个选择是，它专门为f#语言提供了类似的支持。值得注意的是，在所有框架中，avalonia 对 f# 的支持最好（由社区提供）。

pixel-perfect rendering

在这三个框架中，只有avalonia支持真正的“pixel-perfect”渲染。这是由于架构的原因，只有avalonia完全绘制了自己的用户界面和控件。虽然uno platform试图实现“pixel-perfect”，但由于使用原生的基本控件，在不同平台之间经常存在差异。uno platform（skia除外）从未完全绘制自己的控件，因此只是趋近于“pixel-perfect”。

无固定外观控件(lookless controls), 样式 & 主题

当开发人员想到 xaml 时，他们通常会想到无固定外观控件（lookless controls）。能够完全更改控件的样式和默认模板以将其转换为完全不同的内容是 wpf 的一个主要功能。avalonia和uno platform都完整支持自己版本的无固定外观控件（lookless controls）和模板重定义。但是，maui不具备此功能，仅支持更改一些常见的属性。

在这方面，可以把maui看作是windows forms这类较旧的界面工具包。例如，这意味着在 maui 中不支持在按钮内放置图标或图形，而在其他的xaml框架中则很容易实现。

什么是
wpf控件的行为是固定的。例如，按钮有一组固定的事件，包括单击事件。不管你用按钮控件做什么操作，它仍然会有一个点击事件。
wpf控件没有固定的“外观”。lookless这个词恰好可以简洁的表达这个意思。
按钮的默认外观是由默认的xaml模板定义的，可以替换一个完全不同的模板，从而完全改变按钮控件的外观。

平台一致性

在使用跨平台框架进行开发时，应用程序和代码的一致性非常重要。您不想在一个平台上开发和验证的功能，然后发现它在另一个平台上的运行效果不同。在这方面，.net maui 非常差，因为它链接到每个平台上的原生控件。这不仅需要对所有地方进行验证，而且需要多次编写自定义控件，同时花费大量时间调整内容以使其看起来一致（类似于让网页在所有浏览器上正确呈现）

大多数情况下，uno platform比maui表现得更好。但是，它也存在一些严重的问题，一些功能并不是在所有平台上都支持。那些所有平台上都有的功能通常表现一致，但也可能存在很难修复的细微差异。

由于架构差异，avalonia ui在平台一致性的问题上很容易超越其他框架。avalonia 完全自己渲染，因此它在每个平台上看起来总是完全相同（字体、输入差异、弹出窗口等除外）。

原生控件集成

.net maui和uno platform都建立在xamarin native之上，并与之完全集成。这意味着两个框架都可以通过c#绑定访问特定于平台的原生控件。这对于访问原生平台功能和控件来说非常强大，几乎没有任何妥协。可以直接在xaml和代码隐藏中添加原生控件，就像框架本身内置的任何其他控件一样。

相比之下，avalonia ui是它自己的ui层，它不直接与xamarin native(及其特定于平台的控件)集成。作为替代，avalonia提供了一个允许在avalonia应用程序中嵌入本地控件的nativecontrolhost。但是，这并不像 maui或者uno platform中那样简洁。类似于wpf中的windowsformshost，但与之不同的是，avalonia ui 还使用 3d 元素解决了“空域问题”，可以直接在各种表面上绘制 ui。这实际上允许avalonia在游戏引擎或directx上运行，这在其他框架中是不可能的。

xaml 语法和代码共享

在代码共享方面，uno platform拥有最高的评分。它使用与 uwp/winui相同的xaml方言和对象模型，这使得它在xaml和c# 100% 兼容。avalonia和maui都偏离了过去的xaml版本，与wpf或uwp/winui都不兼容。尽管如此，avalonia努力在对象模型方面与wpf相似， maui会因为很少的原因（height/width, textblock等）而偏离。在一些情况下，avalonia还成功地成为了更强大的下一代wpf语法和对象模型。由于对xaml的一些改变（样式，bool类型的isvisible，简化的网格行/列语法等），使得一些操作在avalonia中更容易。与maui相比，avalonia与现有wpf 代码的兼容性和代码共享更好，因此总体评分也更高。

高级文本格式

最初的xaml框架wpf具有非常先进的文本格式api（flowdocument）。这仍然比今天在winui 3或之前的uwp中发现的更高级。事实上，在avalonia ui版本11.0之前，没有其他跨平台xaml框架支持高级文本特性。现在，avalonia ui具有与wpf几乎相同的api，并且可以完成在 .net maui和uno platform上根本不可能完成的文本格式化和测量。由于架构上的差异，在可预见的未来，avalonia ui很可能仍将是唯一支持高级文本(不依赖第三方控件)的框架。这包括诸如richtextbox之类的控件，这些控件可以在avalonia中实现，但在uno platform中非常困难，在 .net maui中几乎是不可能的。

非ui功能

avalonia ui的主要缺点是它只是一个ui框架。.net maui有必备的软件包，uno platform是继uwp之后的一个完整的应用开发平台。可以说.net maui和uno platform都不仅仅是一个ui框架。这意味着在.net maui和uno platform中诸如持久化设置、文件处理、身份验证、本地化和设备权限等内容都可以立即使用，但在 avalonia不行。uno platform甚至具有一些仅在uwp中才能找到的音频相关的高级api，并且可以跨平台。

uno platform试图覆盖整个uwp的对外暴露的api（api-surface），这包含大量的api。整个api 是自动生成的，其中许多功能未实现stubs。这意味着大多数非 ui的api不可用，如果在应用中使用它们，则会引发异常。这确实会在开发过程中产生一些问题，但编译器会显示正在使用哪些未实现的api。尽管如此，uno platform依然比其他框架拥有更多的非ui功能。

性能

xaml源自于桌面应用，本身也相当消耗资源。wpf(最初的xaml框架)通常在运行时从xaml标记中构建整个视图，这在首次加载时可能会严重影响性能。此外，使用mvvm是通过反射绑定把控件绑定到viewmodel上，相比于编译后的代码，反射绑定本来就慢一些。最重要的是，传统的xaml控件具有更高的性能和系统要求，这可能是移动平台或云平台需要考虑的问题。

uwp和uno platform通过x:load允许懒加载来改进这一点。它们都支持使用x:bind进行编译绑定。maui的体系结构通过使用原生控件完全避免了第一个问题。avalonia ui已在很大程度上切换到预编译的xaml和编译绑定，这也解决了这两个问题。这三种框架理论上性能都优于wpf。

与性能相关的 mvu 模式不应被忽视。ui 不是由 xaml 标记构造的,它通常是在代码中和代码隐藏中的业务逻辑一起构造。默认情况下，这意味着控件和用户界面元素只有在被代码引用并需要显示时才会构造。通过这种方式，使用mvu模式的性能有望超过mvvm模式应用程序的性能。maui和uno platform都支持mvu模式。avalonia也完全支持在代码中创建ui，而不使用xaml，从而获得同样的性能优势。

maui的性能并非故意评为两颗星，低于avalonia的三颗星。其原因是：maui使用原生控件，是互操作。本机编译在很大程度上缓解了这一问题，但c#和android控件集成都会降低性能。然而，avalonia完全渲染自己，并且不与android原生控件交互(除非托管本机视图)。这意味着avalonia基本上可以拥有视频游戏（video game）的性能。

uno platform的性能在大多数平台上通常都是足够的。但是，在android上，.net运行时和java运行时之间存在严重的互操作性能问题。这是.net和android本身的问题。然而，由于uno platform的体系结构(与本机控件集成)，这种互操作总是必需的。这意味着，在android上，uno platform的性能从根本上不如其他框架，并且android上的高性能uno platform应用程序目前是不可能实现的。

应用稳定性

maui的移动应用稳定性与uno platform排名相同;但是，在不同平台上遇到需要用大量针对特定情况的代码和标记来处理的布局问题是很常见的。uno platform还有许多没有处理的情况和一些bug，这些都会在整个开发过程中出现。这在很大程度上是快速开发速度优于正确性和稳定性的策略带来的结果。相比之下，avalonia ui从一开始就考虑到稳定性:它的功能是完整的。在实践中，avalonia ui可能是最稳定和最容易开发的。

代码的许可协议

uno platform采用的不是mit license，而是apache 2.0。apache license不像mit那样宽松。除了别的方面，这阻止了代码共享回其他mit许可的框架。uno platform可以使用mit许可项目（如 winui、wpf和avalonia）的源代码，但这些项目基本上不能使用uno platform的代码。这就是为什么uno platform在这里排名较低。

avalonia ui最初完全是mit授权的，并获得了三星评级。但是，随着 ，禁止以原始二进制形式以外的任何形式进行修改和分发，这降低了分数。合成渲染器（composition renderer）是 avalonia版本11 中唯一支持的渲染器，其他渲染器已被删除。这使得修改avalonia并在您自己的应用程序中分发它被禁止。该团队已经澄清，该许可证将“在v11进入ga时恢复到mit”。（此部分于2023年7月废弃，有下一段内容替代。）
avalonia ui完全是mit授权的，可以在大多数.net基金会和winui项目之间免费共享代码。对于需要完全掌控ui框架以达到快速推送修复，确保特定应用稳定性的目的，甚至是想替换自定义的内部组件的公司来说，avalonia ui是一个理想的选择。

支持

尽管maui是由microsoft开发的，avalonia和uno platform在付费支持方面的排名依旧都高于maui。这主要是由于小公司的敏捷性。microsoft现在高度官僚主义，任何反馈或变化，即使是微小的，都需要广泛的讨论才能采取行动。这与avalonia形成鲜明对比，avalonia可以非常快速地采用新功能，uno platform沟通速度也非常快。在免费支持方面，uno platform社区的响应次数与更为庞大的maui社区相当。但是uno platform通常可以更快的解决bugs并实现功能。

代码库的易读性和易于贡献

avalonia ui拥有最干净的代码库，大大降低了公众贡献的门槛。uno platform和 .net maui的要复杂得多，可以从代码上看出这点。从长远来看，复杂性的增加通常在维护和稳定性方面成本变得很高。在uno platform中，这种复杂性对于满足体系结构目标和支持原生控制集成是必要的。

开发体验

avalonia ui拥有最好的整体开发体验。代码库易于阅读，使用rider的开发调试体验是一流的(在其他ide上则要差一些)。.net maui紧随其后，因为它现在与visual studio的集成超过了所有其他的框架。由于需要在每个平台上分别验证/调整每个特性/视图，.net maui在整体开发体验方面存在不足。uno platform的开发体验很差，与visual studio的集成较少，编译时间长，调试也很困难。有关开发体验的更多详细信息，请参阅ide集成部分。

企业支持

乍一看，microsoft开发的 .net maui似乎拥有最强大的企业支持。然而，microsoft并没有在这个项目上投入大量资源，根据microsoft放弃ui框架的历史，对maui的支持也存在不确定性。

avalonia虽然最初是完全开源的，但现在得到了一些核心团队成员的公司的支持。这为维持项目提供了良好的稳定性和收入衡量标准。但是，需要谨慎的是企业对其影响的增加以及代码库闭源的进展。例如，合成渲染引擎现在不是可以修改的自由许可证（而其余代码是 mit 许可的），这一点会在v11正式版发布后改回来。

uno platform凭借创新和令人难以置信的沟通和响应次数，在企业赞助方面依然独树一帜。值得注意的是，它们与microsoft 有着合作以及密切的沟通。

visual studio集成

没有一个框架在visual studio集成方面有三星。这是因为visual studio历来专注于windows平台框架，如winforms、wpf、uwp和winui，并以不可扩展的方式对这些框架进行硬编码支持。但是，.net maui的支持有了很大的改进（从发布时几乎无法使用开始）。uno platform的visual studio集成还有很多需要改进的地方，显然是三者中开发体验较差的一个。这不是他们的错，因为microsoft不合理地支持使用 .xaml 文件的任何其他项目类型。visual studio中的avalonia支持提供了可靠的预览器支持，并且大多数功能都可以工作- 通过使用特殊的.axaml扩展名 - 但xaml并不像其他ide（如rider）那样流畅。

visual studio code集成

uno platform团队为，支持开发，更重要的是，可以调试移动和web应用程序。这是vs code工具向前迈出的一大步，而vs code工具作为c#/.net应用程序的ide历来对开发人员不友好。令人惊讶的是，该扩展还支持.net maui应用程序。uno platform团队确实在这方面迈出了一步，填补了vs code支持c#/.net应用程序方面长期存在的空白，因此uno platform在这款ide集成方面获得了三颗星的评价。uno platform应用程序现在在visual studio code中得到了最好的支持(除非在windows上开发winui，其中visual studio仍然是最好的)。请注意，这个扩展不是开源的。

avalonia ui 于2023年7月 了一个支持xaml预览和代码补全的。这使得avalonia ui在visual studio code中更易于开发，并将使其成为一个可选的ide。

设计工具集成

目前只有uno platform支持设计工具(figma)来构建ui。这种支持是由一个闭源xaml生成器提供的。过去microsoft blend 可供wpf支持相同的作用。生成的xaml的质量和效率可能不足，但是，对于那些在设计与开发团队之间有明确划分的公司来说，它有助于设计师到开发人员的过渡。

.net maui 不支持任何设计工具，并且由于其体系结构可能永远不会。然而，它对xaml的实时编辑提供了开箱即用的支持，这使得设计人员可以在添加代码之前直接在应用程序中调整和添加一些ui元素。uno platform也支持xaml的实时编辑。

平台支持

uno platform支持大多数平台，几乎可以在任何设备上运行，并取得不同程度的成功(它最强大的领域是移动端和网页)。uno platform通过winui/uwp直接支持windows桌面应用，因此在windows桌面原生应用中获得了最高的排名，需要注意的是，在uno platform中，某些后端和平台缺少其他后端和平台具有的功能。这可能会导致你可以在ios/android上做一些不能在linux上做的事情。因此，平台支持并不一致，应该仔细审查。在 macos 上尤其如此，uno platform在上次测试（2021 年）时运行极差。如今，使用maccatalyst构建macos应用通常会更好，因为uno platform对ios的支持明显更好、更完整。skia后端也适用于所有桌面平台(甚至是旧版本的windows)。请记住(如性能部分所述)uno platform在android上的性能不如ios。

avalonia ui远远领先于macos和linux桌面平台的其他框架。avalonia在windows桌面平台上的得分也很高，但没有使用原生ui工具包，所以得分比uno platform低一些。移动端和web支持是 11.0 版中新发布的，可能需要一些时间才能稳定下来，因此目前得分较低。avalonia的web实现呈现为html5 canvas。这永远不会像uno platforms架构那样好，在uno platforms中，它完全集成为html元素。

.net maui根本不支持linux或web。在平台覆盖面上明显不如其他两个框架。

各平台框架推荐

在每个平台上，都有性能最佳的框架。这也是主观的;但是，总体而言，评估应该是正确的，并考虑到所有的因素。

平台	最佳框架
windows	wpf/winui
macos		avalonia ui
linux
android
ios
web/wasm

如果一个应用程序只需要用于桌面平台，avalonia是一个非常好的选择。它对windows的支持是一流的，只是因为不是原生ui，所以排在winui或wpf之后。然而，avalonia在桌面应用程序中没有明显的短板，许多桌面应用程序已经在使用它了。事实上，avalonia甚至支持在wpf中无法完成的操作，例如在directx表面上覆盖 xaml控件。

如果应用程序需要跨平台，可以先用winui或wpf编写。在windows上使用wpf代码库可以很好地转换为avalonia，但仍然需要三种不同的xaml变体。出于这个原因，通常最好使用winui，因为它可以与uno platform的代码100%共享。这样就只需要两种xaml变体。

另请注意：

• web/wasm是uno platform的一个明显优势。由于架构差异（完全使用skia渲染），avalonia很难在这个方面竞争。
• avalonia ui更像是flutter的竞争对手。它使用skia（或者选用windows上的direct2d）在每个平台上完全渲染自己。这比unoplatform有很大的性能优势，尤其是在macos和android上。通过这种方式，avalonia拥有所有框架中最纯粹的架构和最低的社区参与门槛。
• avalonia ui被定位为下一代wpf，它重新实现了大部分功能。avalonia从wpf(grid, text formatting)和winui (itemsrepeater, touch input apis)中汲取思想和代码，同时仍然有一些其他xaml框架中没有的独特想法(在某些方面更接近css的高级样式系统)。它现已为桌面应用开发人员准备就绪，尤其是那些已有wpf代码的开发人员。对于uwp/winui开发人员来说，这个过渡不太平滑，但在版本11中添加了uwp/winui的最新功能以改进过渡。对于不想更改现有wpf代码的企业应用程序，avalonia还提供了avalonia xpf，它在avalonia渲染引擎之上实现了开源的wpf代码库。
• .net maui特意没有列为任何平台最佳方案。它对于没有复杂 ui 的小型应用程序最有用。即便是在中等复杂程度的应用程序中，它的实用性以及在不同平台之间共享代码的能力，很快就要落后于其他的框架。然而，在某些业务线或更简单的应用程序中，maui可能是更好的选择。maui最近还能够同时托管blazor和avalonia ui，这为某些场景提供了一个有趣的选择。
• windows 10之前的版本最合适的选择是avalonia。虽然uno platform也有依托skia的kb88凯时官网登录的解决方案，但它在功能，稳定性和完整性方面远远落后。
• 如上表所示，使用两种xaml方言（dialects of xaml）可以很好地支持所有平台。winui/uwp适用于windows（uno platform用于移动端），其余的使用avalonia。

参考和链接

结论

我们花了数年时间才走到这一步，但我们终于有了一些涵盖所有用途的强大的 .net ui框架。有趣的是，这些框架都发展了一些各自特有且几乎互补的功能。您可能想要尝试的所有内容都包含在其中一种方法中。今天，我们可以编写运行良好的跨平台xaml/c# 应用程序。大多数这项技术（除了ui层）都是基于mono的，所以大部分功劳都归功于xamarin。

每个框架所取得的成就都是了不起的。然而，没有一个在所有平台上都占主导地位，每个框架都有自己的优势和劣势。uno platform源自于android/ios，它在移动平台和web端是最强的。avalonia源自桌面应用程序，在windows/linux/macos上运行效果最好，但移动设备支持上正在迅速发展。截至 2023 年，uno platform的macos支持充其量只是实验性的，只能用于开发简单的应用程序。截至2023年，avalonia最初仅支持移动设备，但实际上在所有平台上都更加稳定。不过，目前可能还是需要使用两种不同的ui框架实现基于xaml的跨平台ui。

原文链接：