3、常见跨平台SDK对比

选跨平台框架，就像挑工具箱。每个工具都有趁手的活儿，也有死穴。我接过不少项目，客户上来就问“哪个最好？”。其实没有最好，只有最合适。这一章，我把 Flutter、React Native、Xamarin、Qt、Unity 摆在一起，从架构、性能、生态、适用场景几个角度撸一遍。

3.1 五个主流框架，先混个脸熟

• Flutter（Google） – 自绘渲染引擎 Skia，语言 Dart。所有 UI 自己画，不依赖原生控件。所以我常说它是“屏幕上的画家”。
• React Native（Meta） – JavaScript + React，通过桥接层把 JS 调用转成原生控件。体验接近原生，但桥接有性能损耗。
• Xamarin（Microsoft） – C# 写业务，底层通过 P/Invoke 直接调用原生 API。适合已有 .NET 团队的公司。
• Qt（Qt Group） – C++ 编写，原生风格 + 自绘 QPainter，桌面端王者，移动端也有人用。
• Unity（Unity Technologies） – 游戏引擎起家，后来用 uGUI 做 App 界面。性能猛，但包体大，非游戏场景有点大材小用。

我个人的经验是：千万别只看技术热度，要看团队背景和业务形态。 比如你团队全是前端 JS 工程师，硬上 Flutter 学 Dart 就挺伤士气。

3.2 核心参数对比

下面这张表，我把关键维度拉出来。你选型时可以直接翻到这页做参考。

对比维度	Flutter	React Native	Xamarin	Qt	Unity
开发语言	Dart	JavaScript / TypeScript	C#	C++ / QML	C#（脚本）
渲染引擎	Skia（自绘）	原生控件（桥接）	原生 API（P/Invoke）	QWidget / QML (自绘+原生)	Unity 渲染管线（自绘）
启动性能	较好（AOT编译）	一般（JS 引擎启动）	较好（AOT）	优秀（C++ 原生）	中等（引擎初始化）
包体大小	~6MB（最小）	~12MB（含 JSC）	~15MB（Mono/IL2CPP）	~20MB（动态库多）	~30MB+（含引擎）
插件生态	pub.dev 很活跃	npm 丰富但碎片化	NuGet 偏企业级	Qt Marketplace 偏工业	Asset Store 游戏向
适用场景	移动 App、Web、桌面	移动 App为主	移动 + 桌面（Win优先）	桌面 + 嵌入式	游戏 / 3D / 可视化

3.3 架构差异——为什么性能差距这么大？

下面这张 SVG 图，展示了我理解的“渲染亲戚关系”。核心分两派：自绘派和桥接派。

你看，Flutter 和 Unity 走的是“自绘”路，从底层就控制每个像素。React Native 和 Xamarin 则依赖原生控件——好处是 UI 与系统一致，坏处是桥接有延迟。Qt 是个“墙头草”，用 QWidget 时走原生，用 QML 时自绘，所以在桌面和嵌入式领域很灵活。

3.4 选型避坑指南

说几个我踩过的坑，都是真金白银换来的教训。

• Flutter – 安卓/iOS 双端一致性极好，但遇到地图、视频这类需要原生控件的场景，Platform Channel 通信会有点疼。我建议拆到 Channel 里做批量调用，减少往返。
• React Native – 适合已有 React 技术栈的团队。但别让业务逻辑过度依赖桥接层——我遇到过列表滑动卡顿，最后改成 Native Driver 动画才解决。
• Xamarin – 微软生态里的老手很舒服，但第三方库更新慢。曾经我和另一个团队合作，他们用 Swift 写了个 NFC 读写模块，我用 Xamarin 调了三天才打通……
• Qt – 桌面/嵌入式的性能王者。但移动端生态弱，找个“扫码”插件都要自己写。如果只做移动，我不太推荐。
• Unity – 做 App 可以，但慎用。包体 30MB+ 起步，而且热更新方案复杂。非游戏场景，我一般拿来做 3D 可视化模块，主 App 还是用 Flutter 或 RN。

3.5 总结一张“选择决策表”

别纠结了，直接对号入座：

1. 纯移动 App，团队有 JS 基础 → React Native
2. 移动 App，追求一致性和高性能 → Flutter
3. .NET 团队，主要做移动/Windows → Xamarin
4. 桌面/嵌入式，C++ 团队 → Qt
5. 游戏/3D/VR 或重度可视化 → Unity