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 <windows.h>，**零平台 #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 的跨平台实战）
Select Language