Gecko 路线：浏览器引擎级移植

Gecko 是 Firefox 的引擎，也是一批大型桌面应用的地基：文献管理器、邮件客户端都构建在 Gecko 的 XUL 平台层上。这是一条重量级路线——Air 工作区的 Gecko 源码树就有 25GB 量级——但换来的是这些复杂应用近乎完整的可用性。

▍原理
Gecko 应用 = Gecko 布局引擎 + XUL 界面描述 + 上层 JavaScript 与 CSharp 逻辑。移植要做三件事：整套交叉编译 Gecko（含 NSPR、js 引擎、WebRender）；给窗口层接 OHOS 原生窗口；把 XUL 的窗口与输入模型桥到触摸环境。文献管理器工程的亮点是零源码复用：上游本体一行不改，全靠平台层适配与补丁族完成对接。

▍触摸化的深水区
Gecko 为鼠标键盘设计，触摸交互有一族缺口：双击全选行为异常、拖拽分隔条调宽失灵、滚动偶发冻结、松手触发的逻辑失效、点击被合成事件吞掉。这些不是零散 bug，而是同一根源的家族症状——指针事件语义在触摸环境下的翻译不完整。Air 系列逐个修复并归纳成缺口清单，后来又碰上 APZ 异步合成管线的换代，把滚动流畅度治理做了一轮。邮件客户端工程在这套地基上继续推进，XUL 向导流程的桌面假设（屏幕尺寸、向导窗居中）被逐项改写。

▍适用场景与代价
适合界面复杂、逻辑在 XUL 与脚本层的大型应用，这类应用用其他路线重写不现实。代价：编译一次以小时计；内存占用是所有路线里最高一档；JIT 在沙箱里的可执行内存策略要逐层验证，不行就降级到解释执行。

▍路线价值
一旦平台层跑通，同类应用可以搭车——Air 系列第二个 Gecko 应用复用第一个的地基，接入成本大幅下降。

更多真实移植案例，欢迎到 apps 板块翻看 56 篇《鸿蒙PC适配全记录》系列实录。