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

長年にわたり、XAMLベースのUIフレームワークは大きく進化してきました。以下の図がその最良の説明です。これらのフレームワークには主に、クロスプラットフォームアプリをサポートするAvalonia UI、Uno Platform、.NET MAUIが含まれます。実際、Avalonia UIを除けば、クロスプラットフォームXAMLへの需要がその発展の主な推進力でした。もしマイクロソフトがFlutterのようなクロスプラットフォームUIフレームワークを早期にリリースしていたら、これほど多くの選択肢はなかったかもしれません。これには長所と短所があります。多くのクロスプラットフォームソリューションから選べるという利点がある一方、フレームワークごとに異なるオブジェクトモデルと独自のXAML文法（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やCometを備えた従来のMVUパターンに対して最も完全なサポートを提供しています。これは活発に実験的開発が行われている分野であり、将来的にはMVVMと同等のサポートが期待されています。Uno Platformは独自のMVUバリアントであるMVU-Xを開発しました。これは他のものとは大きく異なり、学習曲線が高めですが、XAMLデータバインディングとの統合は向上しています。この新しいアプローチのMVUパターンの長期的な実行可能性はまだ不明であり、実験的なソリューションが安定するまでは慎重に選択するのが良いでしょう。AvaloniaはMVUパターンを直接サポートしていません。ただし、宣言型構文を使用してXAMLの代わりにUIを記述するための2つのライブラリを提供しています。Avalonia.Markup.Declarativeは、Avalonia上でヘルパーメソッドと拡張機能を提供することで、多くのC#マークアップ概念をサポートしています。これにより、XAMLを使わずにMVUパターンに従ったC#でのUI記述が可能になります。F#開発者向けの別の選択肢としてAvalonia.FuncUIがあり、F#言語向けに同様のサポートを提供します。特筆すべきは、すべてのフレームワークの中でAvaloniaがF#へのサポートが最も優れていることです（コミュニティ提供）。

• ピクセルパーフェクトレンダリング

  これら3つのフレームワークの中で、真の「ピクセルパーフェクト」レンダリングをサポートしているのはAvaloniaだけです。これは、Avaloniaのみがユーザーインターフェイスとコントロールを完全に自己描画するというアーキテクチャによるものです。Uno Platformは「ピクセルパーフェクト」を目指していますが、ネイティブの基本コントロールを使用するため、プラットフォーム間で差異が生じることがよくあります。Uno Platform（Skiaを除く）はコントロールを完全に自己描画することはないため、「ピクセルパーフェクト」に近づくことはあっても完全ではありません。

• ルックレスコントロール、スタイル＆テーマ

  開発者がXAMLを考えるとき、通常はルックレスコントロール（lookless controls）を思い浮かべます。コントロールのスタイルやデフォルトテンプレートを完全に変更して、まったく別のものに変換できる機能は、WPFの主要な機能の1つでした。AvaloniaとUno Platformはどちらも、独自のバージョンのルックレスコントロールとテンプレートの再定義を完全にサポートしています。ただし、MAUIにはこの機能がなく、いくつかの一般的なプロパティの変更のみをサポートしています。この点では、MAUIはWindows Formsのような古いUIツールキットと考えてよいでしょう。例えば、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アプリケーション内にネイティブコントロールを埋め込むための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は今後も（サードパーティのコントロールに依存せずに）高度なテキストをサポートする唯一のフレームワークであり続ける可能性が高いです。これには、Avaloniaでは実装可能だがUno Platformでは非常に困難で、.NET MAUIではほぼ不可能なRichTextBoxなどのコントロールが含まれます。

• 非UI機能

  Avalonia UIの主な欠点は、単なるUIフレームワークに過ぎないことです。.NET MAUIには必須のパッケージが含まれており、Uno PlatformはUWPに続く完全なアプリ開発プラットフォームです。.NET MAUIとUno Platformはどちらも単なるUIフレームワークではなく、設定の永続化、ファイル処理、認証、ローカライゼーション、デバイス許可などの機能が即座に利用可能ですが、Avaloniaではそうではありません。Uno Platformには、UWPにしか見られないオーディオ関連の高度なAPIもあり、クロスプラットフォームで動作します。Uno PlatformはUWPの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とコンパイル時バインディングに大きく切り替えており、これら2つの問題も解決しています。これら3つのフレームワークは理論上、WPFよりもパフォーマンスが優れています。パフォーマンスに関連するMVUパターンも無視できません。UIはXAMLマークアップから構築されるのではなく、通常はコード内でコードビハインドのビジネスロジックと一緒に構築されます。デフォルトでは、これはコントロールとユーザーインターフェイス要素が、コードによって参照され、表示が必要になった場合にのみ構築されることを意味します。この方法により、MVUパターンを使用したアプリケーションのパフォーマンスはMVVMパターンのアプリケーションを上回ると期待されます。MAUIとUno PlatformはどちらもMVUパターンをサポートしています。Avaloniaも、XAMLを使用せずにコード内でUIを作成することを完全にサポートしており、同じパフォーマンス上の利点を得られます。MAUIのパフォーマンス評価がAvaloniaの三つ星に対して意図的に二つ星とされているわけではありません。その理由は、MAUIはネイティブコントロールを使用するため、相互運用が必要だからです。ネイティブコンパイルはこの問題を大幅に緩和しますが、C#とAndroidコントロールの統合はどちらもパフォーマンスを低下させます。一方、Avaloniaは完全に自己レンダリングし、Androidネイティブコントロールとは（ネイティブビューをホストしない限り）相互作用しません。つまり、Avaloniaは基本的にビデオゲームのようなパフォーマンスを実現できます。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ライセンスではなく、Apache 2.0を採用しています。ApacheライセンスはMITほど寛容ではありません。他の点に加えて、これはMITライセンスの他のフレームワークへのコード共有を妨げます。Uno PlatformはMITライセンスのプロジェクト（WinUI、WPF、Avaloniaなど）のソースコードを使用できますが、これらのプロジェクトは基本的にUno Platformのコードを使用できません。これが、Uno Platformの評価がここで低い理由です。Avalonia UIは当初完全にMITライセンスであり、三星評価を得ていました。しかし、コンポジションレンダラーの再ライセンスにより、元のバイナリ形式以外での修正や配布が禁止されたため、評価が下がりました。コンポジションレンダラーはAvaloniaバージョン11+で唯一サポートされているレンダラーであり、他のレンダラーは削除されました。これにより、Avaloniaを修正して自身のアプリケーション内で配布することが禁止されました。チームは、このライセンスは「v11がGAになる際にMITに戻される」と明言しています（この部分は2023年7月時点では無効となり、次の段落に差し替えられています）。Avalonia UIは完全にMITライセンスであり、ほとんどの.NET FoundationやWinUIプロジェクト間でコードを自由に共有できます。UIフレームワークを完全に掌握して迅速な修正のプッシュや特定のアプリケーションの安定性を確保したり、カスタム内部コンポーネントを置き換えたい企業にとって、Avalonia UIは理想的な選択肢です。

• サポート

  MAUIはMicrosoftによって開発されていますが、AvaloniaとUno Platformは有料サポートの面でどちらもMAUIよりも高い評価を得ています。これは主に小規模企業の機動性によるものです。Microsoftは現在高度に官僚化しており、どんなフィードバックや変更も、たとえ小さなものであっても、実行には広範な議論が必要です。これは、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統合のセクションを参照してください。

• エンタープライズサポート

  一見すると、Microsoftが開発した.NET MAUIが最も強力なエンタープライズサポートを持っているように見えます。しかし、Microsoftはこのプロジェクトに多くのリソースを投入しておらず、MicrosoftがUIフレームワークを放棄してきた歴史を考えると、MAUIのサポートには不確実性があります。Avaloniaは当初完全にオープンソースでしたが、現在はコアチームメンバーの一部の会社によってサポートされています。これにより、プロジェクトを維持するための良好な安定性と収入の尺度が提供されています。ただし、企業の影響力の増大やコードベースのクローズドソース化の進展には注意が必要です。例えば、合成レンダリングエンジンは現在、修正可能なフリーライセンスではありません（残りのコードはMITライセンスですが）。これはV11の正式リリース後に元に戻される予定です。Uno Platformは、革新性と信じられないほどのコミュニケーションと応答性により、エンタープライズスポンサーシップの面でも独自の地位を確立しています。注目すべきは、Microsoftとの協力関係と緊密なコミュニケーションがあることです。

• Visual Studio 統合

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

• Visual Studio Code 統合

  Uno Platformチームは、Visual Studio Code用の拡張機能を開発し、開発、そして重要なことにモバイルおよびWebアプリケーションのデバッグをサポートしています。これは、C#/.NETアプリケーションのIDEとして歴史的に開発者に優しくなかったVS Codeツールにとって大きな前進です。驚くべきことに、この拡張機能は.NET MAUIアプリケーションもサポートしています。Uno Platformチームは確かにこの点で一歩を踏み出し、C#/.NETアプリケーションのVS Codeサポートにおける長年のギャップを埋めたため、このIDE統合でUno Platformは三つ星の評価を得ています。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 PlatformもXAMLのライブ編集をサポートしています。

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

  Uno Platformはほとんどのプラットフォームをサポートしており、さまざまな成功度合いでほぼすべてのデバイスで動作します（最も強力な分野はモバイルとWebです）。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キャンバスとしてレンダリングされます。これは、Uno Platformのように完全にHTML要素として統合されるアーキテクチャには決して及びません。.NET MAUIはLinuxやWebをまったくサポートしていません。プラットフォームカバレッジの点で他の2つのフレームワークに明らかに劣ります。

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

各プラットフォームで、最適なフレームワークが存在します。これも主観的ですが、全体として評価は正しく、すべての要素を考慮しているはずです。

プラットフォーム	最適なフレームワーク
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にうまく変換できますが、それでも3つの異なるXAMLバリアントが必要です。このため、通常はWinUIを使用するのが最善です。これはUno Platformとコードを100%共有できるからです。これにより、2つのXAMLバリアントのみが必要になります。

さらに注意：

• Web/WasmはUno Platformの明確な優位性です。アーキテクチャの違い（完全にSkiaを使用したレンダリング）により、Avaloniaはこの分野で競争するのは困難です。
• Avalonia UIはFlutterのライバルに近いです。Skia（またはWindowsではDirect2Dを選択可能）を使用して、各プラットフォームで完全に自己レンダリングします。これにより、特にmacOSやAndroid上でUnoPlatformよりも大きなパフォーマンス上の利点があります。このようにして、Avaloniaはすべてのフレームワークの中で最も純粋なアーキテクチャと、コミュニティ参加への最低の敷居を持っています。
• Avalonia UIは次世代WPFとして位置付けられており、その機能の大部分を再実装しています。AvaloniaはWPF（Grid、テキストフォーマット）やWinUI（ItemsRepeater、タッチ入力API）からアイデアやコードを取り入れつつ、他の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ベースのソリューションがありますが、機能、安定性、完全性の面で大きく遅れをとっています。
• 上表のように、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フレームワークがいくつか登場しました。興味深いことに、これらのフレームワークはそれぞれ独自の、ほぼ補完的な機能を発展させてきました。試したいであろうすべての要素が、いずれかのアプローチに含まれています。今日、私たちはうまく動作するクロスプラットフォームのXAML/C#アプリケーションを作成できます。この技術の大部分（UIレイヤーを除く）はMonoに基づいているため、その功績の多くはXamarinに帰属します。

各フレームワークの成果は素晴らしいものです。しかし、どのフレームワークもすべてのプラットフォームで支配的ではなく、それぞれに長所と短所があります。Uno PlatformはAndroid/iOSに由来し、モバイルプラットフォームとWebで最も強力です。Avaloniaはデスクトップアプリケーションに由来し、Windows/Linux/macOSで最高のパフォーマンスを発揮しますが、モバイルデバイスのサポートは急速に発展しています。2023年現在、Uno PlatformのmacOSサポートはせいぜい実験的であり、単純なアプリケーションの開発にしか使用できません。2023年現在、Avaloniaは当初はモバイルのみをサポートしていましたが、実際にはすべてのプラットフォームではるかに安定しています。ただし、現在のところ、XAMLベースのクロスプラットフォームUIを実現するには、2つの異なるUIフレームワークを使用する必要があるかもしれません。

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

著者：czwy

出典：https://www.cnblogs.com/czwy/p/17572226.html

著作権：本作品は「表示-継承 4.0 国際」ライセンスの下で提供されています。