将移动应用从 Xamarin 迁移到 .NET MAUI

将移动应用从 Xamarin 迁移到 .NET MAUI

背景

Xamarin 迎来了官方支持结束的日期，这意味着 Osunasport 的移动应用面临一个倒计时：继续留在 Xamarin 上，就意味着使用一个不再受支持的框架，不会再有安全或工具链更新，并最终与新版本操作系统不兼容。作为微软官方的继任方案，.NET MAUI 是显而易见的目标——它能复用大部分已经在使用的 .NET/C# 知识和库，而不必强行跳转到 Flutter 或 React Native 这类完全不同的技术栈。

迁移过程

团队没有把这次迁移当作简单的"替换框架"，而是涉及了整个应用：

• 项目结构：MAUI 将原本按平台拆分的 Xamarin.Forms 项目（iOS、Android、UWP）合并为一个带平台专属文件夹的共享项目，这要求重新组织各平台代码与资源的组织方式。
• 导航与生命周期：MAUI 的导航与应用生命周期 API 与 Xamarin.Forms 有足够大的差异，使得应用的大部分导航流程都需要重新审视，而不仅仅是重新编译。
• 第三方依赖：多个仅支持 Xamarin 的库没有直接对应的 MAUI 版本，因此被替换，或在没有替代方案时被封装进自定义的平台处理器（handler）中。
• UI/UX 重新设计：既然视图层的大部分内容都需要改动，这次迁移也顺势被用来重新设计应用前端、整体改善 UI/UX，而不只是原样搬运旧的界面。

在应用于 .NET MAUI 上稳定运行之后，又进行了一次规模较小的后续迁移：待 MAUI 的工具链与第三方包都跟上该运行时后，将 .NET 9 升级到 .NET 10。

发现的关键差异

• 单一项目结构相较于按平台拆分的多个项目，改变了资源、字体和平台专属代码的组织与引用方式。
• 部分 Xamarin.Forms 的自定义 renderer 与 MAUI 的 handler 并非一一对应，因此视觉表现需要在 iOS 和 Android 上重新测试，而不能假定可以直接沿用。
• 构建与打包工具链的差异足够大，CI/CD 流水线也需要随应用代码一起更新。

结果

该应用如今运行在 .NET MAUI / .NET 10 上，持续得到维护，界面焕然一新，由同一位工程师端到端开发维护，同时兼顾平台的后端与架构工作。