Maui 踩坑记

Maui 踩坑记总结

在正式开始 iOS 下的 app 开发过程中，我深入体验了 Maui 框架，并遇到了一系列挑战。以下是我对这次开发经历的总结与反思。

一、技术方案选择

1. Avalonia Hybrid 路线

   优势：Avalonia Hybrid 路线的一大好处在于能够确保各个平台的 UI 保持一致。这对于追求跨平台一致性的开发者来说，无疑是一个巨大的吸引力。

   问题：然而，在实际操作中，我遇到了不少问题。首先，如果目标平台是 Windows，由于 Maui 在 Windows 下是基于 WinUI 的，而 Avalonia 是基于 Win32 的，两者无法兼容，导致我无法在 Windows 下运行 Avalonia 应用。其次，当目标平台为 iOS 时，我遇到了 clang 编译未通过的问题，经过一段时间的折腾后，最终选择了放弃这条路线。

2. Maui Blazor Hybrid 路线

   考虑：由于我的应用涉及图像和视频处理，因此直接放弃了基于 web 技术栈的 Blazor Hybrid 路线。图像和视频处理通常需要较高的性能和较低的延迟，而 web 技术栈可能无法满足这些要求。

3. 纯 Maui 技术路线

   选择理由：在尝试了上述两种路线后，我最终选择了纯 Maui 的技术路线。这主要是因为 Maui 提供了对多个平台的原生支持，并且与 .NET 生态系统紧密集成，使得开发过程更加顺畅。

二、开发过程中的问题与挑战

1. VS 对 Maui 的 XAML 支持

   体验：Visual Studio 对 Maui 的 XAML 支持相对较好，与 Avalonia 相比有明显的优势。这使得我在开发过程中能够更高效地编写和调试 XAML 代码。

2. Maui 对 Windows 的支持

   问题：虽然 Maui 声称支持多个平台，但在实际使用中，我发现它对 Windows 的支持相对较差。例如，官方的 ControlGallery 示范项目在 Windows 下表现不佳，界面丑陋且存在功能缺陷。相比之下，在 iOS 下则一切正常。

3. 开发模式的选择

   尝试：我尝试了多种开发模式，包括在 macbook 下使用 Rider 开发、在 Windows 下开发并通过 Mac 进行真机调试或虚拟机调试等。然而，这些方式都存在一些问题，如发热严重、连接速度慢、编译速度慢等。

   最终选择：经过多次尝试后，我找到了一个相对高效的开发模式：在 Windows 下进行开发，并在 Windows 下进行调试。为了模拟移动设备的界面效果，我自定义了一个 Bar，并在启动时修改 Windows 窗口的尺寸。这种方式使得我在 Windows 下就能够获得类似移动设备的视觉效果，从而提高了开发效率。

三、其他待尝试的技术方案

1. Flutter + NativeAOT 开发

   思路：利用 NativeAOT 开发底层库，以提高性能；同时利用 Flutter 开发界面，以保持跨平台的一致性。

   展望：随着 dotnet9 的发布，我将有机会将 Flutter 应用发布为 iOS 下的 library，届时我将进一步评估这种方案的可行性。

2. Swift + NativeAOT 开发

   思路：与 Flutter + NativeAOT 类似，这种方案也利用 NativeAOT 开发底层库，但界面部分则使用 Swift UI。

   展望：同样地，我也将关注 dotnet9 后的发布情况，以评估这种方案在 iOS 平台上的表现。

四、感慨与展望

回顾这次开发经历，我深刻体会到了跨平台开发的复杂性和挑战性。尽管 Maui 提供了对多个平台的支持，但在实际使用中仍然存在不少问题和挑战。未来，我将继续探索和实践不同的技术方案，以找到最适合我的开发需求和目标平台的技术路线。同时，我也期待 .NET 生态系统能够不断完善和发展，为开发者提供更加高效、稳定和可靠的跨平台开发工具和环境。