4. 主流跨平台框架概览
跨平台 GUI 架构设计的第一步，不是立刻写代码，而是选对技术路线。不同框架在渲染方式、语言生态、包体积、性能上限和平台覆盖上差异巨大。本节从“渲染栈 + 宿主模型 + 语言生态”三个维度，梳理六款主流框架的定位，并给出可落地的选型判断依据。
一、核心原理：三条技术路线
所有跨平台 GUI 框架，本质上都在回答同一个问题：界面由谁绘制、逻辑跑在哪里。据此可分为三条路线。
- 自绘引擎路线：框架自带渲染引擎，直接调用 GPU 或系统绘图 API 绘制每一个像素。代表是 Qt（QPainter/QML Scene Graph）、Flutter（Skia/Impeller）、Compose Multiplatform（Skia）。优点是各平台外观与行为高度一致，动画与自定义控件能力强；代价是包体积较大，且难以完全贴合原生控件语义。
- WebView 宿主路线：界面用 HTML/CSS/JS 编写，由系统 WebView 渲染，原生层只提供窗口与系统能力桥接。代表是 Electron（Chromium + Node.js）、Tauri（系统 WebView + Rust）。优点是前端生态复用度极高、开发速度快；代价是内存占用与启动性能受 WebView 制约。
- 原生控件映射路线：逻辑用统一语言编写，界面映射为各平台原生控件。代表是 .NET MAUI（映射到 WinUI/UIKit/Android View）。优点是外观贴近系统、无障碍支持好；代价是跨平台一致性受各平台控件差异影响，自定义能力受限。
选型的第一性问题：你的产品更看重“跨平台像素级一致”，还是“贴近各平台原生体验”，还是“复用现有 Web 团队与生态”？这三者几乎不可兼得。
二、方法流程：六步选型决策法
- 明确目标平台矩阵：只做 Windows/macOS/Linux 桌面，还是必须覆盖 iOS/Android，甚至 Web 与嵌入式？平台矩阵直接淘汰一批候选。
- 确定一致性要求：品牌化 UI、需要像素级一致，优先自绘引擎；希望贴近系统外观，优先原生映射。
- 评估团队语言栈：前端团队选 Electron/Tauri；C++ 团队选 Qt；C# 团队选 .NET MAUI；Kotlin 团队选 Compose Multiplatform；Dart 团队选 Flutter。
- 量化资源约束：安装包体积、内存占用、冷启动时间是否有硬指标。Tauri 包体可低至几 MB，Electron 通常上百 MB。
- 检查系统能力需求：串口、USB、注册表、托盘、多窗口、硬件加速、离线运行等，需确认框架桥接能力与成熟度。
- 做最小验证原型：用真实业务场景做 1～2 周 PoC，重点验证性能瓶颈、打包流程与升级机制，再定稿。
三、对比清单：六框架关键参数
| 框架 | 语言 | 渲染方式 | 主要平台 | 包体/内存 | 典型定位 |
|---|---|---|---|---|---|
| Qt | C++ / QML | 自绘（Widgets/QML） | 桌面、嵌入式、移动 | 中～大 | 工业、车载、专业软件 |
| Flutter | Dart | 自绘（Skia/Impeller） | 移动、桌面、Web | 中 | 高一致性多端产品 |
| Electron | JS / TS | Chromium WebView | 桌面 | 大 | 内容型、工具型桌面 |
| Tauri | Rust + 前端 | 系统 WebView | 桌面、移动 | 小 | 轻量、安全敏感桌面 |
| .NET MAUI | C# / XAML | 原生控件映射 | 移动、桌面 | 中 | .NET 企业业务应用 |
| Compose Multiplatform | Kotlin | 自绘（Skia） | Android、桌面、iOS、Web | 中 | Kotlin 团队多端复用 |
四、案例场景：三种真实选型
场景 A：工业设备上位机。需要串口通信、长时间稳定运行、复杂图表与自定义控件，部署在 Windows 与 Linux 工控机。Qt 是首选：C++ 性能可控、Qt SerialPort 与 Charts 成熟、嵌入式支持完善。若团队是 C# 背景，.NET MAUI 也可行，但需评估 Linux 端支持与第三方硬件库。
场景 B：面向消费者的笔记类桌面应用。需要快速迭代、丰富排版、插件生态，团队是前端背景。Electron 开发效率最高；若对安装包体积和内存敏感，可迁移到 Tauri，用 Rust 重写系统层，前端代码基本复用。
场景 C：一套 UI 同时上 Android、iOS 与桌面。要求视觉高度统一、动效流畅。Flutter 与 Compose Multiplatform 都合适：前者生态与工具链更成熟，后者在 Kotlin/Android 团队中迁移成本更低。
五、误区与复盘
常见误区一：只看“能不能跨平台”，不看“跨得好不好”。很多框架能编译到目标平台，但输入法、无障碍、托盘、多显示器等细节体验差距明显，必须在 PoC 阶段验证。
- 误区：包体小就等于性能好。Tauri 包体小，但系统 WebView 版本差异会导致渲染与兼容性波动；Electron 包体大，却自带一致的 Chromium 运行时。
- 误区：自绘框架不需要平台知识。Flutter/Qt 仍需处理平台通道、权限、签名与打包，平台工程能力不可省略。
- 误区：一次选型终身不变。建议把 UI 层与业务逻辑分层，通过接口隔离框架依赖，为未来迁移留出空间。
选型检查清单（PoC 必测项）
[ ] 目标平台全部可编译、可安装、可升级
[ ] 冷启动时间与内存占用满足指标
[ ] 中文输入法、高分屏缩放、深色模式正常
[ ] 系统能力：文件、托盘、通知、串口/USB、注册表
[ ] 打包体积与自动更新方案可行
[ ] 团队可在 2 周内独立完成一个真实页面
总结来看，Qt 与 Flutter、Compose Multiplatform 属于自绘阵营，追求一致性与表现力；Electron 与 Tauri 属于 WebView 宿主阵营，追求开发效率与生态复用；.NET MAUI 属于原生映射阵营，追求系统融合。没有绝对最优，只有与平台矩阵、团队栈和资源约束最匹配的那一个。