A
Air官方
面对一个 Linux 桌面软件，第一个决策不是怎么移植，而是走哪条路线。Air 系列的选型经验浓缩成三问：源码量、依赖、GUI 深度。三问过完，路线基本自明。
▍第一问：源码量与可改性
拿得到源码且许可证允许改，是大多数路线的前提。源码几十万行、上游活跃，走整栈迁移（GTK 或 Qt 路线），改动集中在平台层；源码拿不到，只剩三选一：无源码资产路线（数据文件类）、官方库直调路线（有暴露的引擎库）、全系统模拟路线（跑原环境）。先确认你站在哪一格。
▍第二问：依赖形态
把依赖树倒出来看三层：语言运行时（Python、Java、CSharp 还是纯 C）决定要不要嵌解释器或 VM；构建体系（meson、CMake、autotools、waf）决定交叉编译的工程量，都能走但要按各自的规矩来；系统服务依赖（dbus、systemd、X11、桌面环境）是要重点审计的一层——每项都要决定桩化、模拟还是裁剪，依赖越桌面化，移植摩擦越大。
▍第三问：GUI 深度
界面是标准控件拼的，还是自绘画布？标准控件型应用走框架整栈路线，控件触摸化在框架层统一解决；画布型应用（绘图、音频、3D）反而适合引擎直连或 SDL，把交互交给上游自己的事件系统；界面极简或纯展示，无头核心加 ArkUI 重写界面，体验上限最高。
▍三问合流
三问的答案组合出路线：源码在、依赖常规、控件型，GTK 或 Qt 整栈；源码在、画布型，直连；源码不在、有库，直调；啥都没有，模拟器兜底。Air 的 90 个工程恰好把每格都填了实例。
▍常见误判提醒
最容易犯的错是低估 GUI 深度：看上去标准控件，实际菜单树上百项、快捷键几十组，这类界面走整栈路线后还要做菜单 ArkTS 化，工作量在桥接不在框架。选型时把菜单规模数一遍。
▍行动
三问写进立项文档，每问的答案附证据（依赖树导出、菜单计数、源码统计），评审过了再动手。
有疑问欢迎在本板块直接发帖，我们会逐条回复。
▍第一问：源码量与可改性
拿得到源码且许可证允许改，是大多数路线的前提。源码几十万行、上游活跃，走整栈迁移（GTK 或 Qt 路线），改动集中在平台层；源码拿不到，只剩三选一：无源码资产路线（数据文件类）、官方库直调路线（有暴露的引擎库）、全系统模拟路线（跑原环境）。先确认你站在哪一格。
▍第二问：依赖形态
把依赖树倒出来看三层：语言运行时（Python、Java、CSharp 还是纯 C）决定要不要嵌解释器或 VM；构建体系（meson、CMake、autotools、waf）决定交叉编译的工程量，都能走但要按各自的规矩来；系统服务依赖（dbus、systemd、X11、桌面环境）是要重点审计的一层——每项都要决定桩化、模拟还是裁剪，依赖越桌面化，移植摩擦越大。
▍第三问：GUI 深度
界面是标准控件拼的，还是自绘画布？标准控件型应用走框架整栈路线，控件触摸化在框架层统一解决；画布型应用（绘图、音频、3D）反而适合引擎直连或 SDL，把交互交给上游自己的事件系统；界面极简或纯展示，无头核心加 ArkUI 重写界面，体验上限最高。
▍三问合流
三问的答案组合出路线：源码在、依赖常规、控件型，GTK 或 Qt 整栈；源码在、画布型，直连；源码不在、有库，直调；啥都没有，模拟器兜底。Air 的 90 个工程恰好把每格都填了实例。
▍常见误判提醒
最容易犯的错是低估 GUI 深度：看上去标准控件，实际菜单树上百项、快捷键几十组，这类界面走整栈路线后还要做菜单 ArkTS 化，工作量在桥接不在框架。选型时把菜单规模数一遍。
▍行动
三问写进立项文档，每问的答案附证据（依赖树导出、菜单计数、源码统计），评审过了再动手。
有疑问欢迎在本板块直接发帖，我们会逐条回复。
楼主
7 天前