2026年了还在认真纠结“有没有人用 Xamarin”的我猜大概就两类人一类是手头压着老项目、想动又不敢动的 C# 工程师一类是被领导叫去“调研一下跨平台方案”的选型人。老实说这个问题放到技术圈早就快变成梗了——官方停止支持、微软全力推 .NET MAUI、Flutter 和 Kotlin Multiplatform 抢得凶怎么看都像是一门“入土”的技术。但如果你真的看过一些工业、物流、医疗、外贸行业的旧 App或者翻过外包公司的交付清单会发现 Xamarin 的真实存活率比社区热度高得多。这篇文章不打算给它招魂而是想把手电筒打亮一点Xamarin 到今天的技术底子到底是什么2026 年还在用它的人图什么以及如果你正被存量代码绑着接下来到底该怎么走。1. 先把这个问题的底账盘清楚Xamarin 到底什么状态1.1 从巅峰到“官宣退役”的时间线Xamarin 最早是 2011 年从 Mono 项目里长出来的商业跨平台方案创始人 Miguel de Icaza 在 .NET 圈子里地位很高。2016 年微软收购之后Xamarin 被并入 Visual Studio从收费变成免费一度是 Windows 生态里做 iOS/Android 的默认选项。2017 到 2019 年这阵子.NET 后端团队想顺手做 App几乎没有比 Xamarin 更顺的选择——C# 写逻辑、XAML 画界面、一套代码出双端听着就诱人。转折点在 2020 年微软在 Build 大会上宣布 Xamarin.Forms 将由 .NET MAUI 接替。这个宣布当时在社区里震动不小但大多数人没意识到“接替”的力度有多大。2022 年 .NET MAUI 正式版推出后Xamarin.Forms 就进了维护模式只修 bug 不加功能。再往后Xamarin.iOS 和 Xamarin.Android 这两个平台绑定层的官方支持也在 2024 年年中画上了句号。到 2026 年再回头看这条时间线其实很清晰微软不是“放弃”了 Xamarin而是把它拆开重组换了个名字继续走只是老壳子不再发了。这个时间点容易让人产生一个误解以为 Xamarin 一夜之间就不能用了。实际不是这样官方支持停止意味着没有新版本、没有补丁、没有官方渠道的 bug 修复。但已经装在生产环境里的 App 不会因为支持期结束就自动崩掉——它们的寿命取决于 Android/iOS 系统新版本带来的兼容压力。1.2 MAUI 接棒了但 Xamarin 没被“蒸发”这里要掰开讲一句因为很多人搞混。.NET MAUI 并不是 Xamarin.Forms 的 6.0而是一个重新设计的 UI 框架它和 Xamarin 共享的是更底层的“平台绑定层”——也就是把 iOS 的 Objective-C API 和 Android 的 Java API 暴露给 C# 的那套机制。这套机制在 .NET 时代改名为 .NET for iOS / .NET for Android但血缘清晰你在 Xamarin.Android 里写的很多平台调用迁移到新项目里改动并不大。换句话说微软做过一次“换血”“平台绑定层”这个老器官还在身体里只是换了名字UI 层这个“大脑”则是移植了新组织不兼容旧接口。所以“Xamarin 被微软抛弃了”这个说法严格说只对了一半——技术资产被继承了产品线确实停止了。这个区分很重要它决定了老项目的 C# 代码到底有多少能带走。1.3 2026 年的真实使用温度我不会给你编一个精确的百分比因为任何第三方统计都难以精确捕捉“存量工程”的全貌。但从几个侧面能看到温度社区论坛上 Xamarin 版块的新帖已经很少大多数是“如何迁移到 MAUI”“还有人维护这个库吗”GitHub 上不少知名 Xamarin 组件库停在三四年前的最后一次提交招聘平台上纯 Xamarin 岗位的绝对数量很少但薪资往往不低因为需求方是背着存量系统的公司市场上能接盘的人更少。我身边真实接触到的项目里Xamarin 并没有绝迹。有做冷链物流的App 还是 Xamarin.Forms对接一堆蓝牙温湿度计业务层全在共享类库里有做制造业设备终端的跑的是 Xamarin.Android界面朴实无华但连着串口和 USB 设备跑了好几年没动过。这类项目不会出现在技术大会的讲稿里但它们真实地活着也真实地消耗着工程师的维护时间。2. 它的技术底子凭什么还能撑到今天2.1 用 C# 写 Android 和 iOS这套逻辑至今没输要理解 Xamarin 为什么还有“留守者”先得承认一个事实用 C# 写移动端这件事在开发体验上到今天依然能打。C# 的异步模型比 Java 传统写法顺手得多async/await 处理网络请求和回调代码读起来是线性的LINQ 处理集合数据比手写循环少一大半样板可空引用类型、模式匹配、Source Generator 这些现代语言特性配合最新版 IDE 都能用。如果你是个写 ASP.NET Core 出身的人第一次用 Xamarin 写网络层会有一种“这也能行”的错觉——Service 层代码直接复制大半过去几乎是零成本。这个“零成本”不是玄学。Xamarin 项目的经典结构是.NET Standard 类库承载业务逻辑、数据模型、网络层UI 层只做界面和交互。业务规则好不好测、后端和客户端能不能共享代码直接决定一个团队的生产力。对比当时主流的 React Native 和 FlutterXamarin 在“逻辑复用”这点上是最彻底的因为共享的不是文件级别的代码片段而是整个编译单元。2.2 原生绑定机制不是套壳是翻译官很多人以为 Xamarin 是“WebView 套壳”或者“渲染引擎画界面”这是误解。Xamarin.Android 和 Xamarin.iOS 本质上是一套非常扎实的原生互操作层C# 代码通过 JNI 和 Android 的 Java/Kotlin 世界通信通过运行时绑定和 iOS 的 Objective-C 世界通信。UI 用的是 Android 原生控件和 iOS 原生控件不是 WebView 也不是自绘引擎。你写一个 Xamarin.Android 的页面最后渲染出来的是 Android 的 View 体系写 Xamarin.iOS渲染出来的是 UIKit 的控件。这个机制带来的好处是大部分官方 API 都能在 C# 里直接调不需要等框架提供“插件”。举一个很实在的例子——你需要在 Android 上调用文本转语音Java 里要实例化 TextToSpeech 再设监听器Xamarin.Android 的绑定库里同样能调到这个类只是换成了 C# 语法。遇到绑定库里没有的新 API还可以通过编写绑定定义Android 的 Metadata 配置iOS 的 ApiDefinition把原生接口“翻译”成 C#进阶玩法很多资深团队完全能自己补。坏处也很直观新系统 API 出来后官方绑定包的更新不会像当年那样及时尤其到了 2026 年这层“翻译官”基本处于不更新的冻结状态要么自己动手要么绕开新特性。2.3 Xamarin.Forms 的 UI 抽象成也抽象败也抽象Xamarin.Forms 是另一条产品线它的价值是跨平台 UI用一套 XAML 声明页面结构系统自动把 Button、Label、ListView 映射成 Android 和 iOS 的原生控件。对标准业务界面来说这个抽象非常高效——表单、列表、详情页、Tab 页写一遍出双端开发速度肉眼可见地快。很多企业内部系统的 App 都是这么攒出来的业务界面就是一组表单不追求炫酷动效求的是稳定和开发效率。但抽象必然有边界。一旦碰上复杂交互事情就开始难看了。比如你要做一个小程序里常见的“在地图上放自定义气泡手势联动”或者做一个高性能的聊天消息流Forms 的默认控件会被打得节节败退。这时候你就得搬出 Renderer渲染器或者 Effect效果自己去写平台代码把它“翻译”回原生实现。我见过不少项目在这层踩坑团队成员只会写 Forms 页面不懂 Android 自定义 View遇到控件不满足需求就卡住。换句话说Forms 把简单的事情变简单了但“简单”和“复杂”之间的鸿沟是用原生功底填的。2.4 性能真话启动慢、包大但业务代码并不慢关于 Xamarin 性能这些年流传了很多说法真话是它确实慢在“壳”上但没慢在“芯”上。Xamarin.iOS 因为苹果对动态代码的限制采用 AOT 把 C# 编译成机器码启动性能和原生差不太多Xamarin.Android 则默认跑在 Mono 运行时 JIT 上App 冷启动要先初始化运行时环境再加上嵌入的 .NET 基础类库体感和原生 Java 相比有可感知的差距——尤其在低端 Android 设备上那种“点开图标要等两秒”的体验就是这么来的。包体积也会大一圈因为要带上运行时和框架。不过一旦进入业务代码执行阶段情况就不一样了。C# 经过 JIT/AOT 之后的执行效率和 Java/Kotlin 的差距并不像社区吐槽得那么夸张面向业务规则的计算逻辑、网络数据处理、数据库访问这些才是大多数 App 的实际负载在这一层 Xamarin 完全能打。这也解释了为什么很多老系统“虽然启动慢但用起来不难受”——壳慢是固定的业务承载能力才是长期的体验。3. 2026 年还留在 Xamarin 的都是些什么人3.1 存量项目最庞大的一群“被迫留守者”如果把时间拨回 2016 到 2019 年那是 Xamarin.Forms 最风光的几年。很多企业级 App、外包交付项目都是那时候落地的它们有几个共同特点业务逻辑复杂到不敢重写、界面以表单为主、验收流程长、IT 预算常年紧张。到了 2026 年这些项目的主管如果被问“为什么不迁移”答案通常不是“Xamarin 很好”而是“App 只是现有业务的外壳重写要冒的风险和花的钱领导层看不到回报”。这类项目的状态很微妙。系统还在跑用户还在用代码也能编译只是在每次 Android 升级 targetSdk 版本、或者 iOS 更新隐私政策时维护团队会感受到一次“阵痛”。没有官方支持之后每一次系统大版本更新都像一次赌博——赌现有代码不会碰上兼容问题。我在实际沟通中见过不少团队的做法是能不升就不升能拖就拖直到应用市场强制要求为止。3.2 行业垂直场景工业、医疗、物流里的“扫地僧”比普通 App 更顽固的是一批垂直行业里的 Xamarin 应用。工业 PDA、冷链运输终端、医疗设备手持机、港口调度系统、外勤销售终端这些场景有几个共同点设备是 Android 一体机或定制平板屏幕小、系统版本老旧但稳定界面要求低后台系统大概率是 .NET团队里 C# 工程师遍地都是。在这些场景里Xamarin.Android 反而是很“顺手”的选择。对接蓝牙、串口、USB、打印机这些外设需要频繁调用 Android 原生 APIC# 绑定库虽然要自己调调但比起 Flutter 的 FFI 通道和 Dart 侧的类型映射C# 和 Java 的互操作模型反而更直接。这些项目通常不需要上架应用商店不存在“系统版本强制升级”的压力它们可以非常沉默地一直跑下去。这也是 Xamarin 在今天仍然有“实际使用者”的重要盘面——互联网圈看不到工厂车间里看得到。3.3 C# 团队和人才结构路径依赖是真实的成本还有一类是“纯 C# 团队”的选择。假设你的团队背景是 .NET 后端产品是一个行业 SaaS附带一个给客户用的移动端。让团队全员学 Kotlin 或 Swift 不现实招 Flutter 工程师又和后端技能树割裂。这时候Xamarin 的老项目就成了一种“妥协但自洽”的存在后端和客户端逻辑可以共享工程师可以在 Web 和 App 之间轮岗知识沉淀是连续的。这种路径依赖在成本账上很难打破。团队里没有原生开发专家迁移到 Flutter 意味着重新建立 UI 技术栈迁移到 MAUI 也是一个学习曲线而继续留在 Xamarin至少所有人都是 C# 舒适区。只要上架压力和功能需求没有逼到眼前“维持现状”就是成本最低的答案。这也解释了为什么 2026 年的招聘市场上Xamarin 岗位虽然少但偶尔出现的需求方往往是这类“安静”的行业公司——他们不需要技术明星只需要一个能稳住老系统的 C# 工程师。4. 继续坚守和果断跑路各自的账怎么算4.1 还能继续用 Xamarin 的合理场景先别急着“劝退”。我梳理了一下下面几类场景在 2026 年继续用 Xamarin 并不是不可接受应用生命周期清晰可见产品本身进入维护期两三年内没有大版本功能规划换技术栈的收益趋近于零。纯内网/私有化部署App 只在受控设备上运行不被应用商店的 targetSdk、隐私清单、版本审核约束兼容压力小。团队短期抽不出人正忙着一个更紧急的后端/Web 改造移动端的“技术债”被明确暂缓。业务逻辑全在共享库UI 很薄核心价值是那几千个单元测试和业务规则移动端只是壳。这些场景的共同特征是Xamarin 的“缺陷”没有被放大成为日常痛点。技术栈只要不出问题它就是“能用”的而企业系统最看重的恰恰是“能用”。4.2 你迟早会被它卡脖子的几个地方反过来如果下面的信号出现了就不能再装看不见了。第一个是应用商店的新规压力。Android 每年提升 targetSdk 要求iOS 对隐私清单、权限用途说明、“仅需提供整数倍的启动图”这类审核细节越来越敏感。Xamarin 老项目踩在这些门槛上时官方不会给你出补丁了每一次适配都是“自己动手”而且改的是绑定层的代码难度不比迁移小。第二个是组件生态枯竭。当年依赖的第三方库图表、日历、支付 SDK、推送 SDK纷纷停更如果某天遇到一个无法绕过的 bug你连替换选项都没有。第三个是工具链摩擦。新的 Visual Studio 版本虽然还带 Xamarin 工作负载但和新版 SDK、模拟器、签名工具的兼容问题只会越来越多最终你可能被迫锁死在一台特定的老构建机上。还有一点常被忽视安全。没有官方修复就意味着漏洞没人管如果 App 处理用户信息一旦出现库级别或者运行时级别的安全公告你连升级的渠道都没有。这在合规视角上是很致命的问题尤其是金融、医疗、政府配套项目。4.3 一张判断清单走还是留五分钟找到结论我不喜欢给模棱两可的建议所以整理了一个简单的“自检表”你可以带着自己的项目过一遍判断维度关键问题“继续留”倾向“开始迁”倾向发布渠道是否上架 Google Play / App Store不上架内网可控上架且审核频繁系统适配未来一年是否有强制 API 升级没有设备封闭有且有时间表功能规划未来还有没有大版本功能迭代没有纯维护有UI 和原生交互重团队结构团队的能力重心能否复用全员 C#原生知识弱有原生工程师愿意接预算风险一次重写失败的影响有多大可控业务不核心影响大不能失败法规合规是否涉及敏感数据收集不涉及内部工具涉及有审计要求规则很简单如果有两个以上格子落在“开始迁”这一列建议你提前规划不要等系统强制那一天才动手如果基本都是左边那你确实还有时间继续稳着跑并不丢人。5. 如果要走Xamarin 到 MAUI 的迁移路线怎么走最省力5.1 MAUI 和 Xamarin 的关系换血不是输血先说一个最关键的心法从 Xamarin 到 MAUI 不是“升级”而是“重写壳、保留核”。如果你打开 Visual Studio 试图把 Xamarin.Forms 项目直接改 TargetFramework 变成 MAUI大概率会得到一堆红色波浪线。原因是两者的项目模型、XAML 命名空间、控件实现机制都不一样。MAUI 是单项目模型一个项目同时产出 Android、iOS、Windows 等多平台而 Xamarin.Forms 时代是“共享类库 各平台壳项目”的结构五六个项目在解决方案里摆着。换血的方向是确定的平台绑定层Xamarin.iOS → .NET iOSXamarin.Android → .NET Android比 UI 层好迁移改动主要集中在命名空间和少量 API 调整ET 层Xamarin.Forms → MAUI的工作量最大但控件、页面、布局类大多是“同名同姓”基本可以从 XAML 批量替换起步。迁移的实质是把 C# 逻辑和 XAML 结构“搬”进新壳而不是推倒重来。5.2 工作量拆解与执行顺序我自己实践过的迁移顺序大致分成五个阶段。第一阶段是环境准备装好最新版 Visual Studio 和 .NET SDK用 MAUI 模板新建一个空项目先解决能不能跑起来的问题。第二阶段是搬业务层把 .NET Standard 类库、数据模型、服务层直接复制进新项目这个阶段几乎不需要改代码——这是 Xamarin 当初最扎实的遗产。第三阶段是处理命名空间替换这一步可以用批量脚本先过一遍Get-ChildItem -Recurse -Filter *.cs | ForEach-Object { (Get-Content $_.FullName -Raw) -replace Xamarin.Forms, Microsoft.Maui.Controls -replace Xamarin.Essentials, Microsoft.Maui.Essentials | Set-Content $_.FullName }注意这只是帮你“过第一轮”做完之后必然还有 API 报错要手动调。比如 Border 的用法、旧版绝对布局的 API、一些已重命名的控件属性都得对照官方迁移文档一个个确认。第四阶段是组件替换Xamarin.CommunityToolkit 早就停更了对应的功能散落在 MAUI CommunityToolkit 和官方控件里凡是引用了三方库的地方都要重新核对授权和版本。第五阶段是平台工程调整AndroidManifest、Info.plist、资源文件、启动图这些配置要重新整理MAUI 把它们整合进了单项目路径和命名规则都变了。5.3 迁移路上的典型坑挑几个我见过最多人踩的坑说。第一个是自定义渲染器。Xamarin.Forms 时代的 Renderer 和 Effect迁移到 MAUI 后统换成 Handler 和新版 Effect 机制这不是改签名就能过的逻辑上要重写。如果你项目里有大量自定义控件这个工作量可能占全程一半以上评估时一定要单独列出来。第二个是第三方付费控件。以前买的 Syncfusion、DevExpress、Telerik 的 Xamarin 授权在 MAUI 里基本要重新购买别想当然地以为“同一个厂商就能直接换”。第三个是 XAML 兼容。虽然页面根节点和大部分控件名字没变但 MAUI 的样式系统、资源合并方式、VisualStateManager、DataTemplate 的查找逻辑都有差异批量复制过去很可能出现“编译过了但运行布局不对”的诡异问题。还有一个原则性建议迁移期间不要顺手重构业务逻辑不要“顺便”改掉旧接口更不要借机升级功能。迁移的本质是行为等价的换壳如果迁移过程还夹带需求变更出了问题根本没法定位是“搬错了”还是“改错了”。把所有功能变化全部隔离到迁移完成后的下一个迭代这是一条血泪换来的铁律。6. 选型与决策2026 年移动开发不该有偏见6.1 不同场景的最终建议如果你在 2026 年还在做技术选型——注意是全新项目的选型——Xamarin 应该直接从名单上划掉这不是技术情怀问题是“一个官方不维护的技术栈不应该承担新业务”的常识。但替代方案要看团队背景纯 C# 团队且业务以表单、列表、业务流为主.NET MAUI 是自然的延续迁移成本低逻辑复用依旧成立如果追求 UI 复杂度和性能上限Flutter 依然是稳的选择如果团队前端是 React 技术栈React Native 能最大化人员复用如果已经有成熟的原生团队Kotlin Multiplatform 做逻辑共享越来越值得考虑。对还在纠结“Xamarin 老项目怎么办”的人我给的建议更直接先做一次 4.3 节里的自检如果判断结果偏“留”至少做三件事兜底——锁定所有 NuGet 包版本并建立本地包缓存、专门留一台构建机和配套的老版本工具链、把 CI 构建产物完整归档。这样即使未来某天工具链彻底不兼容你还在可控环境里维持“能发布”的底线。如果判断结果偏“迁”不要拖到最后一个季度越早启动团队的学习成本和项目的迁移风险都越低。6.2 我自己的态度和一些工具链经验我见过太多人对 Xamarin 态度极端化一边把它说得一文不值一边又不知道它当年解决的问题是什么。我个人的实际感受是Xamarin 技术上并不差它死于生态节奏和商业策略的错位而不是死于“不能写 App”。它给一批 .NET 团队提供了低成本进入移动开发的桥梁也让相当多传统行业完成了一轮移动化改造这些价值不该被互联网社区的一两句调侃抹掉。如果让我给还在维护老 Xamarin 项目的人一句实在话那就是别指望奇迹也别盲目恐慌。把你手头项目的“发布日期、上架渠道、系统适配时间表、团队技能结构”这几个变量认真过一遍答案其实自己会长出来。技术的意义永远在于解决业务问题而业务问题从来不看框架的新旧——能稳定交付、能控制风险、能让团队睡得着觉就是好方案。至少到今天那些藏在物流仓库、医院走廊、工厂产线背后的 Xamarin 进程还在一句一句地证明这件事。