AvaloniaUI：使用 .NET 创建多平台应用

原文 ↗ Hacker News 讨论 ↗

AvaloniaUI 被描述为一个面向 .NET 的跨平台 UI 框架，目标包括 Windows、macOS、Linux、Web，并且越来越多地支持移动端；它使用 Skia 进行渲染、使用 XAML 进行布局，因此对有 WPF 或 Xamarin.Forms 背景的团队尤其有吸引力。评论者强调了它在桌面场景中的优势、在 MIT 许可下活跃的开源开发，以及通过商业的 WPF 兼容产品（XPF）实现的可行商业模式；已有多家知名公司将其用于生产环境。主要担忧集中在移动支持尚不成熟、外观和交互不够原生、启动时间、CPU 和内存使用等性能问题，以及与更成熟工具包相比仍在增长中的控件生态。

生态系统与控件

  • 主要担忧：与成熟的原生技术栈相比，生态更小（例如，现成的地图、图表、日期选择器等控件更少）。
  • 反方观点：Avalonia/.NET 生态中已经存在若干图表、地图库和其他控件。
  • 一些用户强调社区集合（例如“awesome”列表）和第三方库的可用性。

桌面与移动优先级

  • Avalonia 普遍被视为以桌面为先；移动支持确实存在，但被描述为“即将到来”、“尚未可用于生产”或不够完善。
  • 像 TextBox 这样的控件在移动端上可能会显得更偏桌面风格。
  • 有人认为无论如何都必须针对不同形态重新设计 UI；也有人希望有一个“移动优先、桌面次之”的跨平台工具包，并认为这一点仍未满足。

性能、渲染与用户体验

  • 使用 Skia；从概念上可与“.NET 版 Flutter”相比较。
  • 反馈不一：有人认为它很快（尤其是在 Native AOT 和编译绑定下），也有人报告：
    • 待机 CPU 占用高，尤其是在 macOS 上以及使用动画时。
    • 启动慢，内存使用相对较高。
    • 文本行为非原生（例如撤销/重做粒度）以及字体渲染“感觉不对”。
  • 更广泛的争论围绕 Skia 的 CPU 消耗、GPU 加速，以及现代 2D UI 技术栈普遍偏慢的问题，并与浏览器、游戏和替代渲染器进行比较。

生产使用与许可

  • 多家公司和产品已在生产环境中使用 Avalonia（包括一些知名名称）。
  • 该框架本身采用 MIT 许可，完全开源，没有付费“pro”层或隐藏功能限制。
  • 收入模式主要集中在：
    • 支持和咨询。
    • Avalonia XPF，一种商业 WPF 兼容平台，据称每个应用每个平台收费数千到约 2 万美元。

迁移与目标场景

  • 特别适合：
    • 将 WPF 应用迁移到跨平台桌面（Windows/macOS/Linux/Web），并尽量少改动，尤其可通过 XPF 实现。
    • 面向桌面的新应用，且可接受或希望保持一致的非原生外观。
  • 注意事项：
    • 与 WinForms/WPF 生态相比，可直接替换的控件更少。
    • 将 Xamarin.Forms 迁移到 Avalonia 被认为比迁移到 Flutter/React Native 更容易，但仍然需要大量工作。
    • 无论选择何种 UI 方案，WinForms 和 .NET Framework → .NET Core/“dotnet”的迁移都可能很痛苦。

语言与替代方案

  • 最适合已经投入 .NET/C#/XAML 的团队。
  • 通过社区项目（FuncUI、Fabulous）可以支持 F#，但被认为不是一等公民。
  • 与 Flutter（移动端更成熟）、Uno（更偏向原生控件）以及其他 GUI/嵌入式引擎进行比较。