Mike：使用 Skia，我们可以实现在每个平台上看起来都一样的“像素完美”应用程序。您无需学习或深入研究特定于平台的 API 即可调整应用程序的 UI 或创建自定义控件！我们发现这种级别的定制对我们的许多用户来说是必不可少的。

Avalonia UI 的另一个主要优势是我们拥有最广泛的支持平台，同时不影响性能。您可以为功能强大的台式机、低功耗嵌入式设备、手机、平板电脑和 WebAssembly 开发应用程序。

我们的 API 旨在跨平台，我们花时间确保添加的功能在跨平台 UI 应用程序开发的上下文中有意义。虽然 WPF 和 WinUI 会影响我们的 API，但我们不会简单地复制它们；我们改变我们可以改进的地方。我们一直认为盲目复制 Windows API 是一种有缺陷的策略。

InfoQ：Avalonia UI 在 .NET 用户界面领域的现状如何？

Mike：当我在 2012 年开始探索 .NET 的跨平台 UI 时，唯一的选择是 Xamarin。今天的情况大不相同。我们有更多选择，各有优缺点。我们的优势在于我们能够跨平台提供高性能、一致的用户体验，同时为开发人员提供熟悉、稳定且经过验证的 SDK。

我们经常与 MAUI 进行比较，这让我很感兴趣，因为我们不将 MAUI 视为竞争对手。当我在 Xamarin 工作时，最大的好处是 Xamarin 应用程序是本机应用程序；也就是说，他们使用了原生 UI 工具包。在 2013 年，这非常重要，但在选择 UI 技术时，它不再是一个如此重要的组成部分。如果我们看看 Flutter 或 Web 技术的日益普及，我们就会发现无需使用本机 UI 工具包就可以提供高质量的体验。

我们非常尊重 MAUI，但我们将 Flutter 和 Qt 视为未来的主要竞争对手。这并不是不尊重他们，但我们相信 .NET 生态系统之外的技术正在做一些令人兴奋的事情。

就我们目前的状态而言，我们为 .NET 开发人员提供了性能最高的跨平台 UI 工具包。如果开发人员优先考虑性能，那么他们使用 Avalonia UI 就很有意义。我们通过管理应用程序中显示的每个像素来实现这一点。我们的依赖性非常小，在 Windows 上仅使用 Win32 作为 Window。

我们之前有一个依赖于 MonoMac 的 Avalonia UI 版本，它是 Xamarin.Mac 的前身，但发现它的性能不可接受，因此创建了我们自己的绑定方法，称为 MicroCOM。

在 Linux 上，我们只需要 X11，而 iOS 和 Android 只需要 NET.iOS 和 NET.Android。一旦我们有了一个本机窗口，我们就可以开始推送像素和接收用户输入事件。

InfoQ：与微软最近的努力相比，Avalonia UI 的定位如何？

Mike：我们倾向于不将自己与 MAUI 进行比较，MAUI 为移动设备提供了可观的支持，但在其他平台上却步履蹒跚。从技术角度来看，Avalonia 的做法与 MAUI 截然不同。MAUI 与其说是一个 UI 工具包，不如说是一个 UI 抽象。它依赖底层原生 UI 工具包工作，而我们使用自己绘制整个 UI。我们的大多数用户都在使用 SkiaSharp 来实现这一点，但我们的架构使渲染器可插入，我们正在寻找替代方案，因为 SkiaSharp 可能因缺乏 Microsoft 的维护而成为负担。

绘制的方法产生了相当大的好处，特别是在性能、易于开发和平台支持方面。真正说明这一点的是我们轻松支持任何平台的能力。我们唯一的要求是能够推送像素和接收交互事件。举一个具体的例子，你只需要看看我们的 VNC 支持，它只需要 ~200 LOC。MAUI 不可能以我们的速度添加新平台，这仅仅是因为它们的架构和对抽象本机 UI 工具包的依赖。

我们的最终目标是成为每个需要客户端应用程序的新项目的首选，无论目标平台如何。我们已经为桌面应用程序提供了最佳体验，但我们必须继续改进我们的移动产品以与 Flutter 竞争。我们将通过继续投资发展 Avalonia UI 团队来实现这一目标。

InfoQ：Avalonia UI 未来发展的路线图是什么？我们可以期待在即将发布的版本中看到哪些新功能？

Mike：在短期内，我们的路线图侧重于发布 v11 和彻底改造文档门户。

v11 提供了巨大的改进，包括新的合成渲染器、可访问性、额外的平台支持等等。在 v11 发布之后，我们制定了一些计划来帮助我们继续推动采用并改善开发人员体验。我们将改进我们的 Visual Studio 扩展并研究其他渲染器以消除我们对 SkiaSharp 的依赖。