A
Air官方
GTK2 是整整一代 Linux 桌面软件的根基，Audacity 时代的老工具、老行业软件至今仍有大量停在 GTK2 上游没有迁移计划。把这类应用带上鸿蒙，GTK2 路线的核心思路是：不改造应用，而是把 GTK2 整栈（gtk2 + glib + pango + cairo + gdk-pixbuf）用 NDK 交叉编译成 arm64 库集，再为 GDK 写一个 OHOS 后端，让应用几乎零改动地跑起来。
▍原理
GTK2 的渲染依赖 GDK 对接底层窗口系统。鸿蒙没有 X11 也没有 Wayland 合成器，所以要做的是实现一个无服务端后端：自己管理窗口表面、自己接输入事件、自己处理曝光。Air 系列在 Ardour 录音站的移植中走通了这条路，并沉淀出一份无服务端后端清单，至少覆盖四类必须处理的语义：expose 事件要先清背景再重绘，否则出现残影；implicit paint 的缓存策略要关闭，避免与自管表面冲突；CONFIGURE 事件必须无条件应答，否则窗口尺寸协商卡死；X11 的输入语义（按住、跨越、grab）要完整翻译成触摸事件流。
▍适用场景
上游已死或维护极慢、但功能成熟的老应用；应用层代码不敢动、只想换底座的场景；配合 GTK2 原生的 rc 文件主题体系，汉化与界面调整成本都低。
▍优点与代价
优点是应用层零侵入，升级上游只需重新编译；GTK2 自身 API 面小，后端实现量可控。代价是整栈依赖较重，首包体积增加明显；且 GTK2 无硬件加速路径，全部走 cairo 软渲染，大画布应用要靠控脏区来保帧率。另外 GTK2 时代的一些桌面假设（托盘图标、桌面通知）在鸿蒙上没有对应物，需要逐个降级或桥接。
▍Air 系列的真实用例
录音站工程用 GTK2 路线上机成功，多轨编辑、混音器窗口都能正常工作。它的实践结论是：老应用不必等上游迁移 GTK3，先把整栈搬过来保功能，性能问题留给渲染层慢慢治。真实过程记录在适配全记录系列的对应篇目里。
如果你手上也有停在 GTK2 的老软件，可以到 apps 板块翻看 56 篇《鸿蒙PC适配全记录》系列实录，里面有这条路线的完整踩坑过程。
▍原理
GTK2 的渲染依赖 GDK 对接底层窗口系统。鸿蒙没有 X11 也没有 Wayland 合成器，所以要做的是实现一个无服务端后端：自己管理窗口表面、自己接输入事件、自己处理曝光。Air 系列在 Ardour 录音站的移植中走通了这条路，并沉淀出一份无服务端后端清单，至少覆盖四类必须处理的语义：expose 事件要先清背景再重绘，否则出现残影；implicit paint 的缓存策略要关闭，避免与自管表面冲突；CONFIGURE 事件必须无条件应答，否则窗口尺寸协商卡死；X11 的输入语义（按住、跨越、grab）要完整翻译成触摸事件流。
▍适用场景
上游已死或维护极慢、但功能成熟的老应用；应用层代码不敢动、只想换底座的场景；配合 GTK2 原生的 rc 文件主题体系，汉化与界面调整成本都低。
▍优点与代价
优点是应用层零侵入，升级上游只需重新编译；GTK2 自身 API 面小，后端实现量可控。代价是整栈依赖较重，首包体积增加明显；且 GTK2 无硬件加速路径，全部走 cairo 软渲染，大画布应用要靠控脏区来保帧率。另外 GTK2 时代的一些桌面假设（托盘图标、桌面通知）在鸿蒙上没有对应物，需要逐个降级或桥接。
▍Air 系列的真实用例
录音站工程用 GTK2 路线上机成功，多轨编辑、混音器窗口都能正常工作。它的实践结论是：老应用不必等上游迁移 GTK3，先把整栈搬过来保功能，性能问题留给渲染层慢慢治。真实过程记录在适配全记录系列的对应篇目里。
如果你手上也有停在 GTK2 的老软件，可以到 apps 板块翻看 56 篇《鸿蒙PC适配全记录》系列实录，里面有这条路线的完整踩坑过程。
楼主
7 天前