XAMLベースのクロスプラットフォームフレームワークの比較分析

XAMLベースのUIフレームワークは長年にわたって大きく進化してきました。以下の図はその最良の例です。これらのフレームワークには、クロスプラットフォームアプリケーションをサポートするAvalonia UI、Uno Platform、. NET MAUIなどがあります。実際、Avalonia UIに加えて、クロスプラットフォームのXAMLの必要性が開発の主な原動力となっています。マイクロソフトがFlutterのようなクロスプラットフォームUIフレームワークをもっと早く導入していれば、選択肢はそれほど多くなかったかもしれません。長所と短所：多くのクロスプラットフォームオプションがあることが利点です。短所は、フレームワークによって異なるオブジェクトモデルと独自のXAML構文があることです。

さまざまな. NET UIフレームワークを見ているとき、同じ質問があります。アプリケーションの開発に使用するXAML UIフレームワークは何ですか？これは正当で重要な質問です。今のところ明確な答えはありません。しかし、各フレームワークの長所と短所は、特定のアプリケーション要件に対して比較分析できるため、特定のアプリケーションごとに簡単に答えることができます。XAMLベースの主要なUIフレームワークの長所と短所を概説することで、企業や開発者が以下の質問に答えるのに役立ちます。

クロスプラットフォームアプリケーションを開発するには、どのXAMLフレームワークを選択すればいいですか？

これらのXAMLベースのクロスプラットフォームUIフレームワークの違いは、階層的に説明することができます。これらのフレームワークはすべて同じ. NET（以前はMono）ツールに基づいています。Xamarinの. NETへの貢献がこれらのフレームワークの存在を可能にしたことは無視できない。さらに、. NET 6+では、これらのフレームワークはすべてのプラットフォームで同じランタイムとコアライブラリを使用します。

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

因为 WPF 和 UWP/WinUI 这些基于 XAML 的微软框架不是跨平台的，所以这里不进行详细比较。但是 WPF 可以通过Wine Mono 或者 Avalonia XPF跨平台运行。WinUI/UWP 已通过接下来讨论的 Uno Platform 支持跨平台运行。

** プロジェクトリンク **

** その他の枠組み **

NETクロスプラットフォーム開発で利用可能な他のソリューションは、この記事では詳しく説明しません。この記事では詳細な比較は行われませんが、以下のフレームワークやソリューションを検討する価値があります。

1. WPF : 正如上文所讲，WPF 可以通过Wine Mono 或者 Avalonia XPF跨平台运行。对于 WPF 代码量较大的现有应用，可以考虑这种跨平台解决方案。
2. Eto.Forms : 一个类似于 .NET MAUI 的 UI 框架，使用平台原生控件构建 UI，XAML 也可以用于序列化和构造 UI。
3. Noesis GUI : 用于游戏开发, Noesis GUI 重新创建 WPF，用于游戏引擎（如 Unity）以构建用户界面。Noesis GUI 对 XAML 的支持非常广泛，可以和 Microsoft Blend 一起使用。 如果它可以在游戏引擎之外工作，并且对较小的应用程序有更好的许可，那么它将是一项早于其他跨平台 XAML 实现的有趣技术。
4. .NET MAUI + Blazor Hybrid : .NET MAUI 可以托管 Blazor Web 应用（在 BlazorWebView 控件内），使其更像是应用程序和服务容器。对于那些希望将现有 Web 应用程序重新打包并分发为移动应用程序的人来说，这是一个非常有吸引力的选择。
5. .NET MAUI + Avalonia UI Hybrid : .NET MAUI 还可以托管 Avalonia UI(在 AvaloniaView 控件里)，使其更像是一个应用程序和服务的容器。 由于 Avalonia 只是一个 UI 框架，要轻松获取 .NET MAUI 的所有附加平台抽象功能 （Essentials） 以及更轻松地打包和部署移动应用时，这是一个非常有吸引力的选择。

アプリケーションとサービスのコンテナとして. NET MAUIを使用し、BlazorやAvalonia UIなどの他のUIフレームワークをホストすることは魅力的な選択肢です。このアーキテクチャは、今後さらに注目される可能性があり、間違いなく注目すべき領域です。

フレームワークの比較

それぞれのフレームワークには異なるパフォーマンスがあり、いくつかの場所では明らかです。以下の表では、インパクトの高い領域と特徴に焦点を当てます。すべてのフレームで同じように見えるものは、以下の表には表示されません（違いのみ）。

この比較は様々な枠組みに対する大量の研究と経験に基づいている;結果は主観的である。NET MAUIの使用経験は3つのオプションの中で最も少なく、ランキングの精度に影響する可能性があります。

• ✔️この機能をサポートしますサポートしません
• ⭐⭐⭐ 是最高/最好的评分, ⭐ 是最低/最差的

このフォームの最後の更新は2023 年 7 月です。

備考：コメント

• MVUモード

  .NET MAUI 对传统上认为的带有 C# Markup and Comet的 MVU 模式具有最完整的支持. 这是一个活跃的试验性和开发领域，预计未来将得到和 MVVM 的相同级别的支持。Uno Platform 开发了自己的 MVU 变体，称为 MVU-X。这与其他产品有很大不同，并且具有更高的学习曲线，但确实与 XAML 数据绑定集成得更好。MVU 模式这一全新方法的长期可行性还有待观察，在这实验性的方案稳定之前，最好谨慎选择。Avalonia 没有直接的支持 MVU 模式。但是，它提供了两个类库支持使用声明性语法替代 XAML 编写 UI 界面。Avalonia.Markup.Declarative通过在 Avalonia 上提供帮助方法和扩展来支持许多 C#标记概念。这提供了一种用 C#编写 UI 界面的好方法，该方法可以遵循 MVU 模式而不需要使用 XAML。F# 开发人员的另一个选择是Avalonia.FuncUI，它专门为 F#语言提供了类似的支持。值得注意的是，在所有框架中，Avalonia 对 F# 的支持最好（由社区提供）。

• Pixel-Perfect Rendering

  これら3つのフレームワークのうち、Avaloniaだけが真の“ピクセル完璧”レンダリングをサポートしています。これは、Avaloniaだけが独自のユーザーインターフェイスとコントロールを完全に描画したアーキテクチャ上の理由によるものです。Uno Platformは“ピクセル完璧”を実現しようとしていますが、ネイティブの基本コントロールを使用しているため、プラットフォーム間ではしばしば違いがあります。Uno Platform（Skiaを除く）は、独自のコントロールを完全に描画することはなく、“ピクセル完璧”に近づいています。

• 固定スキンコントロールなしLookless Controls、スタイル&テーマ

  当开发人员想到 XAML 时，他们通常会想到无固定外观控件（lookless controls）。能够完全更改控件的样式和默认模板以将其转换为完全不同的内容是 WPF 的一个主要功能。Avalonia 和 Uno Platform 都完整支持自己版本的无固定外观控件（lookless controls）和模板重定义。但是，MAUI 不具备此功能，仅支持更改一些常见的属性。在这方面，可以把 MAUI 看作是 Windows Forms 这类较旧的界面工具包。例如，这意味着在 MAUI 中不支持在按钮内放置图标或图形，而在其他的 XAML 框架中则很容易实现。什么是Lookless Controls WPF 控件的行为是固定的。例如，按钮有一组固定的事件，包括单击事件。不管你用按钮控件做什么操作，它仍然会有一个点击事件。 WPF 控件没有固定的“外观”。Lookless 这个词恰好可以简洁的表达这个意思。 按钮的默认外观是由默认的 XAML 模板定义的，可以替换一个完全不同的模板，从而完全改变按钮控件的外观。

• プラットフォームの一貫性

  クロスプラットフォームフレームワークを使用して開発する場合、アプリケーションとコードの一貫性は非常に重要です。あるプラットフォームで開発して検証したくない機能を、別のプラットフォームでは動作が異なることがわかりません。この点で、. NET MAUIはすべてのプラットフォームのネイティブコントロールにリンクされているため、非常に貧弱です。これには、すべての場所で検証するだけでなく、カスタムコントロールを複数回記述し、一貫した外観にするためにコンテンツを調整するのに多くの時間を費やします（すべてのブラウザでWebページを正しくレンダリングするように）。ほとんどの場合、Uno PlatformはMAUIよりも優れています。しかし、いくつかの機能がすべてのプラットフォームでサポートされていない深刻な問題もあります。これらすべてのプラットフォームで利用可能な機能は通常一貫して動作しますが、修正が難しい微妙な違いがあります。アーキテクチャの違いにより、Avalonia UIはプラットフォームの一貫性の問題で他のフレームワークを容易に凌駕します。Avaloniaは完全に独自にレンダリングされるため、どのプラットフォームでも常にまったく同じように見えます（フォント、入力の違い、ポップアップなどを除く）。

• ネイティブコントロールの統合

  NET MAUIとUno PlatformはXamarin Native上に構築され、完全に統合されています。つまり、両方のフレームワークはC#バインディングを介してプラットフォーム固有のネイティブコントロールにアクセスできます。これは、ほとんど妥協なしにネイティブプラットフォームの機能やコントロールにアクセスするのに非常に強力です。ネイティブコントロールは、フレームワーク自体に組み込まれている他のコントロールと同様に、XAMLとコード隠蔽に直接追加できます。対照的に、Avalonia UIは独自のUIレイヤであり、Xamarin Nativeとそのプラットフォーム固有のコントロールとは直接統合されていません。代わりに、AvaloniaはAvaloniaアプリケーションにローカルコントロールを埋め込むことができるNative Control Hostを提供しています。しかし、MAUIやUnoプラットフォームほど簡潔ではありません。WPFのWindows FormsHostに似ていますが、Avalonia UIは3 D要素を使用して“空の問題”を解決し、さまざまな表面に直接UIを描画することができます。これにより、Avaloniaは他のフレームワークでは不可能なゲームエンジンやDirect X上で動作することができる。

• XAML構文とコード共有

  コード共有に関しては、Uno Platformが最も高い評価を得ています。UWP/Win UIと同じXAML 方言とオブジェクトモデルを使用しているため、XAMLとC#の両方で100%互換性があります。AvaloniaとMAUIはどちらも過去のXAMLバージョンから逸脱しており、WPFやUWP/Win UIと互換性がない。それにもかかわらず、Avaloniaはオブジェクトモデルの面でWPFに似ているように努力しており、MAUIはいくつかの理由（Height/Width、TextBlockなど）で逸脱している。Avaloniaは、より強力な次世代WPF構文とオブジェクトモデルになることにも成功した。XAMLへのいくつかの変更（スタイル、bool型のIsVisible、単純化されたグリッド行/列構文など）により、Avaloniaでの操作の一部が簡単になりました。AvaloniaはMAUIと比較して既存のWPFコードとの互換性とコード共有が優れているため、総合的な評価も高くなります。

• 高度なテキストフォーマット

  オリジナルのXAMLフレームワークであるWPFは非常に高度なテキストフォーマットAPI FlowDocumentを持っていた。これは、Win UI 3以前のUWPで今日見られるものよりもまだ高度です。実際、Avalonia UIバージョン1 1.0以前は、他のクロスプラットフォームXAMLフレームワークは高度なテキスト機能をサポートしていませんでした。Avalonia UIにはWPFとほぼ同じAPIがあり、. NET MAUIやUno Platformでは不可能だったテキストのフォーマットや測定が可能になりました。アーキテクチャの違いにより、Avalonia UIは、サードパーティ製コントロールに依存せずに高度なテキストをサポートする唯一のフレームワークであり続ける可能性が高いです。これには、Avaloniaで実装できるRichText Boxのようなコントロールが含まれますが、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サーフェス）全体をカバーしようとしており、これには膨大な数のAPIが含まれている。API全体は自動的に生成され、多くの機能はスタブを実装していません。つまり、ほとんどの非 UI APIは利用できず、アプリケーションで使用すると例外がスローされます。これは開発中にいくつかの問題を引き起こしますが、コンパイラーは未実装のAPIを使用していることを示します。それでも、Uno Platformは他のフレームワークよりもUI以外の機能が多い。

• パフォーマンス

  XAMLはデスクトップアプリケーションから始まり、それ自体がかなりリソースを消費します。WPFオリジナルのXAMLフレームワークは、通常、実行時にXAMLタグからビュー全体を構築します。これは、最初のロード時にパフォーマンスに深刻な影響を与える可能性があります。さらに、MVVMを使用すると、リフレクションバインディングを使用してビューモデルにコントロールをバインドしますが、リフレクションバインディングはコンパイルされたコードよりも遅いです。さらに、従来のXAMLコントロールはパフォーマンスとシステム要件が高く、モバイルプラットフォームやクラウドプラットフォームでは考慮すべき問題となる可能性があります。UWPおよびUno Platformは、x Loadが怠惰なロードを可能にすることでこれを改善しています。いずれも、x Bindを使用したコンパイル·バインディングをサポートしています。MAUIのアーキテクチャは、ネイティブコントロールを使用することで最初の問題を完全に回避します。Avalonia UIはコンパイル済みのXAMLとコンパイル済みバインディングに大きく切り替えられ、両方の問題も解決されました。3つのフレームワークは理論的にはWPFより優れている。パフォーマンスに関連するMVUパターンは無視すべきではない。UIはXAMLタグによって構築されるのではなく、通常、コード内に、ビジネスロジックとともに構築される。デフォルトでは、コントロール要素とUI要素はコードによって参照され、表示する必要がある場合にのみ構築されます。このようにして、MVUモードを使用したパフォーマンスは、MVVMモードアプリケーションのパフォーマンスを上回ることが期待されます。MAUIとUno PlatformはMVUモードをサポートしている。AvaloniaはXAMLを使用せずにコード内でUIを作成することも完全にサポートしており、同じパフォーマンス上の利点が得られます。MAUIのパフォーマンスは、Avaloniaの3つ星よりも低い2つ星を与えられました。その理由は、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には、開発プロセスを通じて発生する多くの未解決のケースやバグがあります。これは、正確さと安定性よりも迅速な開発スピードを重視する戦略の結果です。対照的に、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 授权的，并获得了三星评级。但是，随着 re-licensing of the composition renderer，禁止以原始二进制形式以外的任何形式进行修改和分发，这降低了分数。合成渲染器（composition renderer）是 Avalonia 版本 11+中唯一支持的渲染器，其他渲染器已被删除。这使得修改 Avalonia 并在您自己的应用程序中分发它被禁止。该团队已经澄清，该许可证将“在 v11 进入 GA 时恢复到 MIT”。（此部分于 2023 年 7 月废弃，有下一段内容替代。） Avalonia UI 完全是 MIT 授权的，可以在大多数.NET 基金会和 WinUI 项目之间免费共享代码。对于需要完全掌控 UI 框架以达到快速推送修复，确保特定应用稳定性的目的，甚至是想替换自定义的内部组件的公司来说，Avalonia UI 是一个理想的选择。

• サポートする。

  MAUIはマイクロソフトによって開発されていますが、AvaloniaとUno Platformは有料サポートでMAUIを上回っています。これは主に中小企業の機敏さによるものです。マイクロソフトは現在非常に官僚主義的であり、フィードバックや変更は、たとえ小さなものであっても、行動を起こす前に広範な議論が必要です。これは、新機能を非常に迅速に採用できるAvaloniaとは対照的であり、Uno Platformは非常に迅速に通信できます。無料サポートに関しては、Uno Platformコミュニティはより大きなMAUIコミュニティと同等の反応を示しました。しかし、Uno Platformは通常、バグを解決し、機能を実装するのがはるかに高速です。

• コードベースの読みやすさと貢献の容易さ

  Avalonia UIは最もクリーンなコードベースを備えており、パブリック貢献の障壁を大幅に下げます。Uno Platformと. NET MAUIは、コードからわかるように、はるかに複雑です。長期的には、複雑さの増大は、通常、メンテナンスと安定性の面でコストがかかります。Uno Platformでは、アーキテクチャの目標を満たし、ネイティブ制御統合をサポートするためにこの複雑さが必要です。

• 開発体験の開発

  Avalonia UIは最高の全体的な開発体験を提供する。コードベースは読みやすく、Riderを使用した開発·デバッグエクスペリエンスは優れています他のIDEでは劣っています。NET MAUIは、他のすべてのフレームワークよりもVisual Studioとの統合が進んでいるため、これに続きます。. NET MAUIは、プラットフォームごとに各機能/ビューを個別に検証/調整する必要があるため、全体的な開発エクスペリエンスの面で不十分です。Uno Platformの開発経験は悪く、Visual Studioとの統合が少なく、コンパイルに時間がかかり、デバッグが困難です。開発エクスペリエンスの詳細については、IDE統合のセクションを参照してください。

• ビジネスサポート

  一見すると、マイクロソフトが開発した. NET MAUIは、最も強力なエンタープライズサポートを持っているように見えます。しかし、マイクロソフトはこのプロジェクトに多くのリソースを投資しておらず、マイクロソフトがUIフレームワークを放棄した歴史を考えると、MAUIのサポートについては不確実性があります。Avaloniaは当初完全にオープンソースであったが、現在はコアチームメンバーの一部の企業によってサポートされている。これは、プロジェクトを維持するための安定性と収益の良い指標を提供する。しかし、注意が必要なのは、企業の影響力の増大とコードベースのクローズドソース化の進展です。例えば、合成レンダリングエンジンは現在変更可能なフリーライセンスではありません（残りのコードはMITライセンスです）。これはV 11がリリースされたときに変更されます。Uno Platformは、革新的で信じられないほどのコミュニケーションと応答性により、企業スポンサーシップの中でもユニークです。特に、彼らはマイクロソフトと協力し、緊密なコミュニケーションを取っています。

• Visual Studioの

  Visual Studio統合に関して3つ星を持つフレームワークはありません。これは、Visual Studioが歴史的にWin Forms、WPF、UWP、Win UIなどのWindowsプラットフォームフレームワークに焦点を当て、拡張不可能な方法でこれらのフレームワークをハードコードしてサポートしてきたためです。しかし、. NET MAUIのサポートは大幅に改善されています（リリース時にはほとんど利用できなかったものから）。Uno PlatformとのVisual Studio統合には改善すべき点がたくさんあり、3つの中では明らかに開発エクスペリエンスが悪いものです。マイクロソフトは.xamlファイルを使用する他のプロジェクトタイプを不当にサポートしているため、これは彼らのせいではない。Visual StudioのAvaloniaサポートは信頼性の高いプレビューラーサポートを提供し、特別な.axaml拡張子を使用してほとんどの機能が動作しますが、XAMLはRiderのような他のIDEほどスムーズではありません。

• Visual Studio Codeとの統合

  Uno Platform 团队为Visual Studio Code 开发了一个扩展，支持开发，更重要的是，可以调试移动和 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 预览和代码补全的Visual Studio Code 插件预览版。这使得 Avalonia UI 在 Visual Studio Code 中更易于开发，并将使其成为一个可选的 IDE。

• 設計ツールの統合

  現在、UIを構築するためのデザインツールFigmaはUno Platformのみでサポートされています。このサポートはクローズドソースのXAMLジェネレータで提供されます。過去にはMicrosoft BlendがWPFで同じ役割をサポートしていた。生成されるXAMLの品質と効率は不十分かもしれませんが、設計チームと開発チームの間に明確な線引きがある企業にとっては、設計者から開発者への移行に役立ちます。NET MAUIは設計ツールをサポートしておらず、そのアーキテクチャのために決してサポートしないかもしれない。しかし、XAMLのライブ編集をすぐにサポートしているため、デザイナーはコードを追加する前にアプリケーションに直接UI要素を調整して追加することができます。UnoプラットフォームはXAMLのリアルタイム編集もサポートしている。

• プラットフォームのサポート

  Uno Platformは、ほとんどのプラットフォームをサポートし、ほぼすべてのデバイスで動作し、さまざまな成功を収めています（最も強力な分野はモバイルとWebです）。Uno PlatformはWinUI/UWPを通じてWindowsデスクトップアプリを直接サポートしているため、Windowsデスクトップネイティブアプリの中では最高のランクを獲得していますが、Uno Platformには他のバックエンドやプラットフォームが持つ機能が欠けているバックエンドやプラットフォームがあることに注意する必要があります。これにより、LinuxではできないことをiOS/Androidで実行できるようになる可能性もあります。プラットフォームサポートは一貫性がなく、慎重に検討する必要があります。これは特にmacOSに当てはまり、Uno Platformは前回のテスト（2021 年）では非常に動作が悪くなりました。Uno PlatformのiOSサポートは大幅に優れているため、macOSアプリをmacOS Catalystで構築する方が一般的に優れています。Skiaバックエンドは、古いバージョンのWindowsでも、すべてのデスクトッププラットフォームで動作します。パフォーマンスの項で説明しているように、Uno PlatformはAndroidではiOSよりもパフォーマンスが低いことに注意してください。Avalonia UIは、macOSやLinuxデスクトッププラットフォームの他のフレームワークをはるかにリードしています。AvaloniaはWindowsデスクトップでも高いスコアを獲得しましたが、ネイティブUIツールキットを使用していないため、Uno Platformよりもわずかに低いスコアを獲得しました。モバイルとウェブのサポートはバージョン1 1.0で新しくリリースされたもので、安定するのに時間がかかる可能性があり、現時点ではスコアが低いです。Avaloniaのウェブ実装はHTML 5 canvasでレンダリングされます。これは、HTML要素として完全に統合されたUno Platformsアーキテクチャほど優れたものではありません。NET MAUIはLinuxやWebを全くサポートしていません。プラットフォームカバレッジは他の2つのフレームワークよりも著しく劣っています。

プラットフォーム別の推奨フレームワーク

どのプラットフォームでも、最高のパフォーマンスを発揮するフレームワークがあります。これも主観的ですが、全体として、評価は正しく、すべての要因を考慮する必要があります。

プラットフォームプラットフォーム	ベスト·フレームワーク
Windows	WPF/WinUI
macOS		Avalonia UI
Linux
Android
iOS
Web/Wasm

アプリケーションがデスクトッププラットフォームでのみ使用する必要がある場合、Avaloniaは非常に良い選択です。Windowsのサポートはファーストクラスですが、ネイティブUIではないため、Win UIやWPFの後にランクされます。しかし、Avaloniaはデスクトップアプリケーションには明らかな欠点がなく、多くのデスクトップアプリケーションですでに使用されています。実際、AvaloniaはDirect XサーフェスにXAMLコントロールをオーバーレイするなど、WPFではできないことをサポートしています。

アプリケーションがクロスプラットフォームである必要がある場合は、まずWin UIまたはWPFで記述できます。Windows 上のWPFコードベースを使用するとAvaloniaに変換できますが、3つの異なるXAMLバリアントが必要です。このため、Uno Platformのコードと100%共有できるWin UIを使用するのが一般的に最善です。必要なのはXAMLの2種類だけです。

ご注意ください：

• Web/Wasmは、Uno Platformの明確な利点です。アーキテクチャの違い（完全にSkiaレンダリング）のため、Avaloniaはこの分野で競争するのが難しいです。
• Avalonia UIはFlutterの競争相手のようなものです。Skia（またはWindowsではDirect 2 D）を使用して、各プラットフォームで完全にレンダリングします。これは、特にmacOSとAndroidでは、UnoPlatformよりも大きなパフォーマンス上の利点があります。このようにして、Avaloniaはすべてのフレームワークの中で最も純粋なアーキテクチャとコミュニティ参加のしきい値を持っています。
• Avalonia UIは、ほとんどの機能を再実装した次世代WPFと位置づけられています。AvaloniaはWPF GridテキストフォーマットとWinUI Items Repeaterタッチ入力APIからアイデアとコードを抽出していますが、他のXAMLフレームワークにはないユニークなアイデアもありますいくつかの点ではCSSの高度なスタイルシステムに近い。デスクトップアプリケーション開発者、特にすでにWPFコードを持っている開発者が利用できるようになった。この移行はUWP/Win UI開発者にとってスムーズではありませんが、移行を改善するためにバージョン11でUWP/Win UIの最新機能が追加されました。既存のWPFコードを変更したくないエンタープライズアプリケーション向けに、AvaloniaはAvaloniaレンダリングエンジン上にオープンソースのWPFコードベースを実装したAvalonia XPFも提供しています。
• NET MAUIはどのプラットフォームにも最適なソリューションとしてリストされていません。複雑なUIのない小さなアプリケーションに最適です。中程度の複雑さのアプリケーションでも、プラットフォーム間でコードを共有する有用性と機能は、他のフレームワークに急速に遅れを取るでしょう。しかし、一部の基幹業務やより単純なアプリケーションでは、MAUIの方が良い選択肢かもしれません。MAUIは最近、Blazor UIとAvalonia UIの両方をホストすることもでき、特定のシナリオで興味深いオプションを提供します。
• Windows 10以前のバージョンに最適なオプションはAvaloniaです。Uno PlatformにはSkiaベースのソリューションもありますが、機能性、安定性、完全性の面でははるかに遅れています。
• 上の表に示すように、2つのXAML 方言dialects of XAMLを使用すると、すべてのプラットフォームをうまくサポートできます。WinUI/UWPはWindows用（Uno Platformはモバイル向け）、残りはAvaloniaを使用している。

リファレンスとリンク

1. Question: XAML Flavor, Architecture & Roadmap
2. The New .NET Multi-platform App UI
3. Goodbye Xamarin.Forms
4. Putting “Universal” back into UWP
5. Evolution of Client Development: Richard Campbell
6. [Spec] Slim Renderer Architecture
7. Discussion: Compatibility with WPF, UWP and WinUI
8. Project Reunion: An End to Microsoft’s UI Madness?

結論：結論

ここまで来るのに何年もかかりましたが、ついにすべての目的をカバーする強力な. NET UIフレームワークが手に入りました。興味深いことに、これらのフレームワークはそれぞれ独自の補完的な機能を開発している。あなたが試したいすべては、これらの方法の1つに含まれています。今日では、うまく動作するクロスプラットフォームXAML/C#アプリケーションを書くことができます。この技術のほとんど（UIレイヤーを除く）はMonoに基づいているため、クレジットのほとんどはXamarinにあります。

それぞれのフレームワークの成果は素晴らしいものです。しかし、すべてのプラットフォームで支配的なものはなく、それぞれに長所と短所があります。Android/iOSから派生したUno Platformは、モバイルプラットフォームとウェブプラットフォームで最も強力です。Avaloniaはデスクトップアプリケーションから始まり、Windows/Linux/macOSで最もよく動作しますが、モバイルデバイスのサポートは急速に進化しています。2023 年現在、Uno PlatformのmacOSサポートはせいぜい実験的なものであり、単純なアプリケーションの開発にのみ使用されている。Avaloniaは2023 年までモバイルデバイスのみをサポートしていますが、実際にはすべてのプラットフォームでより安定します。しかし、現時点では、XAMLベースのクロスプラットフォームUIを実装するには2つの異なるUIフレームワークが必要です。

原文へのリンク：https//github.com/robloo/PublicDocs/blob/master/XAMLFrameworkComparison.md

アーティスト：Czwy

出典www.cnblogs.com/czwy/p/17572226.html

版权：本作品采用「署名-相同方式共享 4.0 国际」许可协议进行许可。