0. 一个扎心的现实 你想把桌面软件搬到手机、搬到鸿蒙，于是去看了主流跨平台方案。然后发现： Qt ：得学 QML / 信号槽那一套，Widget 和 QML 两套心智； Flutter ：得学 Dart ，UI 层基本用 Dart 重写； Electron ：包体 100MB+，跑个工具像开浏览器； wxWidgets ：API 随平台变，"跨平台"很大程度是"换 api 重写"。 如果你是个写了十几年 Win32 / WTL / MFC 的人，最理想的方案其实是： 我那套 C++ 手感别动，界面逻辑一次写完，六端编译。 这正是 SOUI4 在做的事。 1. 硬证据：一套 C++，业务代码零平台宏 空口无凭。SOUI4 自带一个跨平台样板项目 games/cnchess （中国象棋），它在 Windows / Linux / macOS / iOS / Android / 鸿蒙 六个平台共用同一份 C++ 业务代码。 我们逐文件统计了它的 业务源码 里平台宏的出现次数： 宏 业务 C++ 源码出现次数 __ANDROID__ 0 __OHOS__ 0 核心绘制与逻辑文件 ChessBoard.cpp 、 ChessPiece.cpp 、 algorithm/* （ AI 引擎） 完全没有平台宏 。平台差异被 swinx 兼容层和移动端宿主库完全吸收，业务层只在薄薄的入口处用 __MOBILE__ 一个开关区分"移动触屏 vs 桌面弹窗"。 这意味着什么？意味着"一套 C++ 六端运行"不是 PPT 口号，是 工程现实 ——一个中国象棋的完整对弈 + 联机 + 主题下载，六端复用同一份代码。 2. 它是怎么做到的：用 Win32 当"世界语" SOUI4 的核心设计哲学是： 不造一套抽象层，而是重演 Win32 语义 。 框架里有一层叫 swinx 的跨平台兼容层，它提供了 44 个与 Windows SDK 同名同结构的公共头文件 （ windows.h / gdi.h / unknwn.h / oleacc.h …）。于是 SOUI 内核直接 #include ，零平台 #ifdef 。 非 Windows 平台不是"模拟一个长得像的 API"，而是 链接期解析 ：公共声明集中在头文件，各平台目录给出同名同签名的实现，构建时只把当前平台的源文件编进去。调用方写同一个函数名，正文里没有平台分支。 这套机制甚至能整块搬运重量级组件： RichEdit （ Microsoft RichEdit 4.1 ，499 个文件）被整体搬到了非 Windows 平台，富文本能力六端一致； Scintilla 的 Win32 分支（语法着色编辑器）也是靠 swinx 把 CreateWindowEx / SendMessage / GDI 这套桌面子系统整体模拟出来，无需为每端另写后端。 3. 鸿蒙是"一等公民"，不是社区补丁 这一点对国内开发者尤其重要：在主流跨平台框架里，鸿蒙（ OpenHarmony ）要么是弱支持，要么根本没官方支持（评估报告对比表：Qt "OHOS 弱"、Flutter "官方无"）。 SOUI4 通过 PlatformAPI 桥接，把 SApplication 托管进鸿蒙的 EntryAbility （ ArkTS 侧经 HAR 包 @soui/ohos 导出）。鸿蒙是 正式支持平台 ，和另外五个平台共用同一套语义。 而且，鸿蒙原生开发用的是 ArkTS （托管语言，有 GC 停顿），而 SOUI 整套 UI 树、事件路由、绘制调度、业务逻辑全部是 AOT 编译的原生 C++——没有虚拟机的 GC 抖动，这对游戏类、实时类应用价值最大。调系统能力时，你按原生习惯自己写 NAPI ，调用发生在 SOUI 的 UI 线程（即宿主原生线程）上，同一线程、无需线程切换，摩擦最接近原生开发。 4. 它适合谁、不适合谁 适合： 熟悉 Win32/WTL/MFC ，想跨平台但不想学新语言/新范式； 需要上鸿蒙、又有 C++ 存量代码要复用； 独立开发者 / 小团队，想要体积小（核心约 2MB ，无 VM ）、快速出界面； 桌面工具、游戏类软件，重视帧时序与低延迟。 不适合（诚实说）： 想"把公司一套老 Win32 程序零成本迁移到六端"——这是 SOUI 的 延伸目标 ，当前为"用 SOUI 编写的新应用"提供六端；旧 Win32 程序迁移所需的原生控件库 / 窗口菜单栏 / 资源对话框三块接口面尚未补齐（但地基已具备，差距是工作量不是架构问题）。 想要"开箱即用的丰富原生控件"——SOUI 是自绘 DirectUI ，控件面靠内置 40 个控件头 + 37 个扩展控件 + SRealWnd 挂原生窗口。 5. 为什么我愿意把这个项目讲给你听 不是因为它"完美"。评估报告里也老实列了 11 项风险和 15 项优势——移动端还没自动构建门禁、核心维护者集中在一人、vendor 代码占了两仓库受控文件的 67%。 但这些短板 性质高度一致：都是"工作量与流程"问题，不是"架构不确定性"问题 。没有一项需要推翻现有设计。对一个开发者来说，这反而是最强的信任锚： 坑在工程量里，不在架构里。 如果你也是那个"写了十几年 Win32 、又想让代码跑遍六端"的人，欢迎看看： 官网： soui.com.cn GitHub / Gitee 搜 soui4 知乎专栏「启程软件」（我会持续写 SOUI 的跨平台实战）

  • 情报分类：硬件与数码
  • 分类依据：内容涉及硬件、数码产品或通信卡
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/10/19 15:30:37