再见 Xamarin 表单

TL，DR：Uno 平台是我希望 Xamarin.Forms 的一切。鉴于此，请告诉我为什么要为 .NET Maui 烦恼。 2012 年，我听说了这个名为 Xamarin 的新平台。当时，它被宣传为 Mono（大众的 C#）的品牌重塑，重点是 iOS 和 Android。作为一名小型开发人员，维护多个冗余代码库是（现在仍然是）我最大的痛点——所以我很感兴趣。 2013年，我花钱请了我的一个好朋友来深入了解一下。他为应用程序创建了一些基准（启动时间、渲染时间等），这些应用程序比 Xamarin 营销中的任何东西都更加真实。 iOS 的表现很棒。 Android - 不是很多，但可以忍受。有希望使 Android 变得更好，所以我们决定采取飞跃并构建一些应用程序。然后，在 2015 年，Xamarin.Forms 制造了足够多的噪音，我想我会尝试一下。尽管 Xamarin 允许我们编写一次业务逻辑，但这只是构建应用程序工作的一小部分。 Xamarin.Forms 电梯宣传是“适用于所有设备的一个代码库”。首先，Xamarin.Forms 当时的理念是“让 iOS 应用看起来像 iOS 应用，让 Android 应用看起来像 Android 应用”。换句话说，他们知道需要大量的工作来规范 UI，所以他们不会打扰。如果您想要平台之间的一致性，您将不得不为此付出汗水。接下来，我在 Android 和 iOS 中习惯的很多东西都没有出现在 Xamarin.Forms 的抽象 UI 中。一些例子。上面的清单消耗了我三年的大部分时间。与此同时，Xamarin 的 UWP 支持和 Tizen 也上线了（仍然没有客户询问 Tizen）。完成上述列表并移植我的 UI 代码后，我就有了一些很棒的 iOS 和 UWP 应用程序。但是，Xamirin.Forms Android 应用程序很糟糕（现在仍然如此）。启动时间很糟糕，更重要的是，视图渲染比没有表单的 Xamarin 慢一个数量级。

AOT 编译和启动分析缓解了这个问题，但即使到今天，Android 性能仍然很糟糕。即使在高端设备上，Android 操作系统也会经常终止这些应用程序，因为它们的响应速度不够快。除了上述内容之外，我和我的客户还想要我们应用程序的 WASM 版本。从一开始就有将 Xamarin.Forms 移植到 WASM 的传言，但从来没有官方声明。然后，在 2017 年 6 月，Frank Krueger 发布了 Ooui — Xamarin.Forms for WASM！弗兰克打造了一件杰作——优雅而高效。让我说清楚。 Frank 给了我对 Xamarin.Forms 的希望。如果不是 Ooui，我会放弃 Xamarin.Forms 并放弃跨平台开发。但是，缺点从未消失，Xamarin 的重点始终放在别处。 Android 更新继续发生，但性能并没有变得更好。 Frank 退出了 Ooui 的工作（这只是一个概念证明，对吧？）。我花了三个月的时间试图提高 Android 性能，但徒劳无功。 Xamarin 似乎对 Blazor 比 Ooui 更感兴趣，因为它是一种网络方法。同时，在 2018 年 10 月，Uno 平台宣布他们拥有 WASM。很快，他们就有了复杂的、真实世界的演示应用程序来证明这一点。因此，在 2020 年春季，我（实际上）参加了 Uno Conf。我的第一要务是：Uno 的 Android 性能如何。在花了几个小时听了关于构建工具和工具包的讨论后，会议结束了。我没有答案，越来越怀疑。然而，有一个虚拟的会后社交活动，我可以在那里会见其他与会者。一旦经过供应商，我遇到了卡尔德比利。我与 Carl 分享了我使用 Xamarin.Forms Android 的经验，并询问 Uno 是否会有所不同。卡尔非常专业，但他也给了我足够的信息，让我知道该戳哪里。在接下来的一周中，我进行了许多实验，并且对我所学到的东西感到非常震惊——如果不进行重大重写，Xamarin.Forms 将永远无法构建高性能的 Android 应用程序。为什么？因为 Android 中托管 (C#) 和本机代码 (Java) 之间的切换比其他平台差约 10 倍。 Xamarin.Android 应用不是问题，因为它们使用 Android 布局引擎。但是，Android 版 Xamarin.Forms 是为使用 Xamarin.Forms 的托管代码进行视图实例化和布局而构建的（就像 Xamarin.Forms 在其他平台上所做的那样）——这会导致托管和本机之间的切换时间增加 10 秒、100 秒、1000 秒、10,000 秒.这在 Xamarin 的演示应用程序中并不是什么大问题，但是，在更真实的列表视图应用程序中，这个纸牌屋会在其自身的重量下倒塌。这就是为什么我的 Android 应用程序很烂的原因。八月份开始迁移我的工程分析代码库，其中78k行是UI代码。我不是 UWP 开发人员，所以有一个上升曲线。 12 周后，一个完成的应用程序，在 beta 测试中——在 WASM 中运行！当它超出测试版时，我会在这里放一个链接。一路上我学到的东西：

UWP 调试是可耻的。如果 UWP 采用失败的原因只有一个，那就是它。但是，Uno 允许您针对许多其他平台，这不是问题，从而为您提供了机会。 Windows。不支持绘图。然而，Uno 的 SkiaSharp 支持足以弥补这一差距。拥有非常清晰和有形的规范是 Uno 最大的资产。 “正确的方式”是毋庸置疑的。不幸的是，出于务实的原因，Uno 有时确实不得不偏离 UWP。一旦您了解这些偏差的位置，您很快就会意识到 Uno 的架构与 UWP 一样好（或者可能更好）。性能：毫无疑问，Uno 更好。我的 Android 应用程序的 Uno 版本没有卡顿！需要做更多的工作来允许资产一次性放置在共享项目中，并且可供所有平台项目访问。例如，设置自定义字体会导致许多特定于平台的工作可以自动化。我对 Xamarin 对这个问题的解决方案并不疯狂，我希望 Uno 可以想出一种方法，从开发人员的 POV 来看，感觉就像他们在构建 UWP 应用程序一样。与 Xamarin.Forms / Xamarin.Essentials 相比，仍在开发中的 Uno 框架本质上具有更多的功能。 Uno 的 Web 解决方案很大程度上受到 Ooui 的启发——这意味着非常精简和精简的实现。

还有一个意外发现：我的 UI 代码从 78k 行 Xamarin.Forms 代码变成了 19k 行 Uno 代码！引用 Todd Wiley 的话：“我最喜欢的键是 [delete] 键”。总结：我从 2015 年年中开始开发 Xamarin.Forms 应用程序，这几乎是 Xamarin.Forms 的开始。从根本上说，它有两个对除最简单的应用程序之外的所有应用程序来说都过于严重和根本的问题： WASM 过于复杂的方法：使用 BlazorMobile 或 Uno.Wasm，而不是像 Ooui 这样更直接的方法。 .NET Maui 是 Xamarin.Forms 的未来。除非我遗漏了什么（如果有请告诉我），.NET Maui 没有解决这些基本问题。如果没有修复它们，我就无法看到 Xamarin.Forms / .NET Maui 在 Uno 平台上的任何价值。