在鸿蒙设备上体验 Air 系列软件：Krita 与 Audacity 的 Qt/KDE 观察
最近看到 GitCode 上的 Air 系列软件项目，比较有兴趣。这个系列主要尝试将一些桌面开源软件移植到 HarmonyOS 上。
项目仓库：
我自己比较关注 Qt / KDE 应用在 HarmonyOS 上的移植情况，所以这次主要体验了 Krita 和 Audacity。
我的测试设备
目前使用了两台设备进行测试：
- Huawei MateBook Pro（2-in-1 / PC）
- Huawei MatePad Pro Max（Tablet）
这两台设备分别代表了比较典型的 PC 和平板使用场景，也比较适合观察桌面应用在 HarmonyOS 上的实际体验。
Harmony-krita / AirDraw
Harmony-krita 的完成时间相对较早，大约是在 8 月中旬。
实际使用下来，连续两周左右基本没有遇到明显问题。最让我印象比较深的是，手指和手写笔都可以正常进行绘画，整体使用体验已经比较完整。
从代码以及项目结构来看，这个版本应该是基于 Qt 5 的 Krita。
KDE ECM 的处理方式
Krita 本身是一个 KDE 生态中的大型应用，因此移植 Krita 时，一个比较值得关注的问题就是：
KDE Extra CMake Modules（ECM）是如何处理的？
上游 ECM：
https://github.com/KDE/extra-cmake-modules
目前我还没有在 Harmony-krita 中找到比较明确的 ECM 处理方式。
Harmony-krita 仓库目前只有两个 commit：
- 第一个 commit：主要代码、引入内容以及修改基本都集中在这里。
- 第二个 commit：主要是 README 的修改。
也就是说，核心移植工作基本都放在了第一个 commit 中。
这种方式对于快速完成一次移植是比较直接的，但从后续维护和 upstream review 的角度来看，历史会显得比较难追踪。
我对提交历史重新整理了一下
因此，我对比了 Krita 的上游仓库：
https://invent.kde.org/graphics/krita
然后重新组织了一下 Harmony-krita 的提交历史，希望能够让：
- 上游代码
- HarmonyOS 相关修改
- 构建相关修改
之间的关系更加清晰。
新的提交历史放在：
https://github.com/liangqi/krita/commits/Harmony-krita/
目前这个版本我还没有完成本地编译，后续还需要继续验证。
不过从代码组织的角度来看，这种方式应该更有利于后续分析和维护，也更接近开源项目通常采用的 upstream + patch 的开发模式。
Harmony-Audacity / AirAudio
Harmony-Audacity 大约是在 8 月 25 日左右完成的。
我在设备上进行了实际测试，整体情况比单纯“能启动”要进一步一些。
第一次启动的问题
第一次打开应用时，没有立即弹出“是否允许应用使用麦克风”的授权提示。
同时应用还有一些类似卡顿的感觉。
当时应用看起来像是没有完全初始化成功。
我的处理方式是：
- 结束应用进程；
- 再次启动；
- 这次出现麦克风权限请求；
- 允许麦克风权限之后，录音和播放功能就可以正常工作了。
所以目前看起来，第一次启动时的权限初始化可能还存在一些问题。
平板模式
在平板设备上，目前还存在一个比较明显的问题：
应用不能全屏。
对于 Audacity 这样的桌面应用来说，平板上的窗口尺寸和显示方式还是一个值得继续优化的地方。
Audacity 背后的技术栈
从代码来看，Audacity 涉及了不少音频领域的专业第三方库。
其中比较值得关注的是：
- PortAudio
- 以及其他音频处理相关依赖
这让我觉得 HarmonyOS 对桌面软件的支持，已经不只是简单的 GUI 移植问题。
一个应用真正能够运行起来，实际上意味着下面这些基础设施也必须逐步具备：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
桌面应用 │ ├── GUI Framework │ └── wxWidgets / Qt │ ├── Audio Framework │ └── PortAudio │ ├── Codec / DSP Libraries │ ├── File / Thread / Network │ └── HarmonyOS Platform |
尤其是像 PortAudio 这种底层库，如果 HarmonyOS 上已经能够正常工作，那么它对后续更多专业桌面软件的移植会很有价值。
另外，Audacity 3.7.8 使用的是 wxWidgets。
这本身也是一个很有意思的信号：
如果 Audacity 在 HarmonyOS 上已经能够基本运行，那么至少说明 wxWidgets 这一层在 HarmonyOS 上已经具备了一定的可行性。
因此，未来可能不只是 Qt/KDE 应用，其他传统 Linux/Windows 桌面应用框架也有机会逐步进入 HarmonyOS。
从代码仓库看，Audacity 比 Krita 更进一步
如果单纯从“应用能不能运行”来看，Krita 和 Audacity 都已经取得了不错的进展。
但如果从代码仓库本身来看，我觉得 Harmony-Audacity 相比 Harmony-krita 有比较明显的进步。
Harmony-Audacity 对以下内容记录得更加完整：
- 上游代码来源
- HarmonyOS patch
- 构建脚本
- 构建过程
- 第三方依赖
也就是说，不只是“把软件编译出来”，而是开始逐步记录：
这个软件如何从 upstream source 构建成 HarmonyOS 应用。
这对于后续维护非常重要。
特别是第三方库的处理，现在已经开始出现比较统一的思路。
这可能会成为后续 HarmonyOS 桌面软件移植非常重要的一步。
从 Krita 到 Audacity，可以看到一个变化
这两个项目放在一起看，其实可以发现一个比较有意思的趋势。
Harmony-krita 更像是一次比较早期的快速移植：
|
1 2 3 4 5 6 |
上游代码 ↓ 引入 HarmonyOS 修改 ↓ 完成构建和运行 |
而 Harmony-Audacity 开始更加关注：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Upstream │ ├── Source │ ├── Patch │ ├── Build Script │ └── Third-party Dependencies │ ↓ HarmonyOS Build |
这意味着项目关注点正在从：
“能不能跑”
逐渐转向：
“如何规范地维护和构建”
对于大型桌面开源软件来说，后者其实更加重要。
因为真正困难的地方往往不是第一次把程序跑起来，而是：
- 如何跟踪 upstream；
- 如何维护 HarmonyOS patch；
- 如何解决第三方依赖；
- 如何让构建过程可重复；
- 如何持续同步新版本；
- 最终如何把修改贡献回 upstream。
我比较期待的下一步
从我自己的兴趣来看，目前比较值得继续关注的是 Qt/KDE 应用在 HarmonyOS 上的生态化问题。
例如 Krita 只是其中一个案例。
如果 Qt、KDE Frameworks、ECM 以及常见的第三方库都能够逐渐建立比较稳定的 HarmonyOS 支持，那么理论上未来可能会看到更多 KDE/Qt 桌面应用进入 HarmonyOS。
而像 Audacity 这样的项目，则提供了另一条路线：
除了 Qt 之外，传统桌面应用框架 + 专业领域第三方库，也开始具备移植可能性。
这两条路线如果能够继续发展，HarmonyOS 上的开源桌面应用生态会比单纯移植几个 GUI 应用更有意义。
总结
这次主要体验了两个项目：
| 项目 | 软件 | 大致完成时间 | 主要框架 | 当前体验 |
|---|---|---|---|---|
| Harmony-krita | Krita / AirDraw | 8 月中旬 | Qt 5 / KDE | 手指、手写笔绘画基本正常 |
| Harmony-Audacity | Audacity / AirAudio | 8 月 25 日左右 | wxWidgets | 录音、播放基本可用 |
我个人觉得，目前更值得关注的并不是“某一个应用已经跑起来”，而是背后的变化：
HarmonyOS 上的开源桌面软件移植，正在逐渐从一次性的代码修改，向 upstream、patch、构建脚本以及第三方依赖管理的系统化方向发展。
尤其是第三方库开始出现统一处理思路，这可能会成为后续大规模移植 Qt、KDE 以及其他桌面应用的重要基础。
对我来说，这也是这次测试中最有意思的部分。
相关链接
- Air 系列软件
- Harmony-krita / AirDraw
- Harmony-Audacity / AirAudio
- Krita upstream
- KDE Extra CMake Modules
- 重新整理后的 Krita Harmony-krita 分支