从 Linux 桌面到 Web：通过 Webswing 将 Linux 应用带到浏览器

应用本身可能仍然可靠，困难往往在于交付方式：不同的访问方法、独立的基础设施、额外的许可证、分散的支持，以及迫使用户在互不连通的环境之间切换的工作流程。

Webswing 的 Linux Desktop to Web 方案旨在弥合这一差距。应用继续在服务器上原有的 Linux 环境中运行，而用户界面则通过浏览器交付。实现这一能力的核心组件是 Linux Web Launcher（LWL）。它基于自定义 Wayland 合成器构建，并与现有的 Webswing 前端、服务器、会话管理及管理基础设施集成。

访问我们的 Linux 应用介绍页面，了解常见使用场景、部署方式，并体验浏览器演示。

应用保留在原有的 Linux 运行环境中

Linux Desktop to Web 不要求重写应用，也不是逐个 GUI 工具包进行转换的项目。Linux 应用在服务器上运行，使用的仍是其原本适用的环境。改变的是应用与用户之间的交付层。

Linux Web Launcher 提供应用所需的显示环境，捕获应用渲染后的输出，并将其接入 Webswing 已有的浏览器交付流程。用户交互会传回应用，使浏览器成为访问入口，同时软件仍保留在原有的运行环境中。

当应用仍有价值，而替换它又困难、风险较高或根本没有必要时，这种方式尤其有用。

为什么 Webswing 在显示服务器层面进行集成

Linux 桌面应用可以使用不同的 UI 技术构建，但都需要显示服务器。因此，显示服务器层是一个实用的通用集成点。

Wayland 合成器负责管理应用连接和图形表面、合成最终场景、路由输入事件，并保持客户端之间的隔离。Linux Web Launcher 为此实现了一个自定义合成器。它支持原生 Wayland 应用，也支持通过 XWayland 运行的 X11 应用，因此架构不局限于某一种应用工具包。

在这一层面进行集成，有三个重要结果：

• Webswing 捕获应用的真实输出，而不是逐个控件重建界面。

• 应用可以在服务器上无显示器运行，同时仍获得完整的显示环境。

• 不同的 Linux 桌面应用可以共用这套集成，而不必为每个 UI 框架重新开发。

Linux Web Launcher 的架构如何协同工作

这套架构可以理解为四个相互协作的层。

1. Linux 应用

应用作为 Wayland 客户端在服务器上运行；如果是 X11 应用，则通过 XWayland 运行。应用保留自身的 UI 逻辑，并按照标准的 Linux 桌面模型提交图形表面更新。

2. 自定义合成器与捕获中间件

自定义 Wayland 合成器管理应用窗口、图形表面合成及输入。它更新场景，并将最终输出渲染到缓冲区。其下方的 Mesa 3D、DRM/KMS 和 Linux 内核等标准 Linux 图形组件提供渲染基础。

捕获中间件从图形缓冲区中读取已渲染的输出。随后，帧发送器将更新加入队列、删除重复内容、按需对帧进行编码，并构建将通过 Webswing 发送的消息。

3. Webswing 服务器与会话层

连接管理器通过 WebSocket 发送更新。Webswing 服务器接收并解码消息，会话路由器则识别正确的用户会话，并将应用数据转发给它。

这一层复用 Webswing 已有的基础设施，包括浏览器前端、服务器端会话管理，以及用于应用配置和监控的 Admin Console。因此，Linux 应用交付成为同一套运维模式的一部分，而不是另一套独立的交付技术栈。

4. 浏览器呈现层

在浏览器中，WebSocket 连接接收更新。分发器验证并解码消息载荷，渲染流水线批量处理绘制请求并去除重复工作，渲染器再按照正确的图形表面顺序执行绘制操作。Web UI 应用最终更新，并捕获用户输入。

从 Linux 图形表面更新到浏览器：三个阶段的生命周期

完整的输出路径分为三个阶段：合成、传输和呈现。

合成

Linux 应用提交图形表面更新。合成器更新场景图和输出状态，然后将新的输出渲染到缓冲区。捕获中间件读取渲染后的表面，帧发送器将更新加入队列、合并并去重，随后编码帧并构建待发送的消息。

传输

连接管理器通过 WebSocket 发送已编码的更新。Webswing 服务器接收并解码更新，会话路由器再将用户数据转发到正确的浏览器会话。当多个用户或应用实例共享同一个 Webswing 环境时，这种基于会话的路由尤为重要。

呈现

浏览器接收消息并将其转换为渲染指令。分发器检查载荷，渲染流水线批量处理工作，渲染器执行绘制操作并处理图形表面的顺序。Web UI 更新浏览器视图，同时捕获键盘和指针输入，以便传回应用。

最终，用户获得的是通过浏览器访问的交互式 Linux 桌面应用，而应用本身仍运行在服务器上。

这一方式为应用团队带来什么

无需先重写应用

目标是让现有 Linux 桌面应用可以通过浏览器访问，而不必先重建界面或修改业务逻辑。团队可以独立处理应用交付和访问问题，再另行规划长期现代化决策。

无需为每种应用工具包单独集成

由于 Linux Web Launcher 工作在显示服务器层，Webswing 不需要为每种桌面 UI 工具包分别开发浏览器实现。Wayland 提供通用层，XWayland 则将这一方式扩展到 X11 应用。

保留应用的原生外观

这套架构捕获并渲染应用的真实输出。用户继续使用熟悉的界面，应用也保留在其原本适用的运行环境中。

为 Java 与 Linux 工作流程提供统一的交付模式

其价值不仅在于访问某一个 Linux 应用，还在于可以将 Webswing 用作混合技术应用组合的通用浏览器交付层和会话层。

Java 应用可以与 Linux 编辑器、查看器、终端或诊断工具参与同一个工作流程。文件可以在不同技术之间传递，应用可以作为共享流程的一部分启动，而 Webswing 则为整个工作流程提供统一的浏览器入口。

架构上的取舍：应用输出，而非语义化 Web 控件

Linux Web Launcher 处理的是像素级的应用输出。它不会自动将每一个桌面控件转换成语义化的浏览器组件。

这一区别很重要。目标是忠实地交付现有应用，并且不依赖特定工具包，而不是自动将应用转换成重新设计的原生 Web 前端。组织应将其视为一种应用交付架构：保留正常运行的软件，让其可以通过浏览器访问，并将其融入现代运维工作流程，而不必先重写应用。

实际使用场景

这一方式适用于多种常见场景：

• 辅助系统应用： 通过浏览器受控访问终端、诊断工具，以及与主要业务应用配合使用的其他实用程序。

• 专业的非 Java 应用： 交付文件编辑器、查看器及其他 Linux 桌面软件；这些软件原本可能需要单独的访问方案。

• Java 与 Linux 混合工作流程： Java 应用与 Linux 应用可以参与同一个基于浏览器的流程，包括文件交接和应用启动。

• 受管理的应用会话： Webswing 可以将 Linux 应用纳入现有的用户与会话管理模式。

• 浏览器中的文件与打印流程： 该技术可以支持受控文件访问、处理与隔离、跨技术文件交换，以及虚拟打印。

这些场景反映了企业的常见现实：用户并不关心某项任务背后使用什么工具包或运行环境。他们需要连贯的工作流程，而 IT 团队需要便于管理的方式来交付和运行相关应用。

将 Webswing 扩展到 Java 之外

Webswing 传统上专注于将 Java 桌面应用带到浏览器。Linux Desktop to Web 沿着相同的产品方向，将覆盖范围扩展到更多应用。

核心理念保持一致：让经过验证的软件继续在服务器上运行，减少终端设备上不必要的依赖，并以浏览器作为交付界面。借助 Linux Web Launcher，这一模式可以覆盖 Java 生态之外的应用，同时复用 Webswing 中已有的配置、会话、传输和浏览器渲染组件。

Linux Web Launcher 已包含在 Webswing 26.2 中，支持原生 Wayland 应用以及通过 XWayland 运行的 X11 应用。如果您希望探讨适合的应用或混合技术工作流程，请访问 Linux 应用页面，或联系 sales@webswing.org。

深入了解架构与演示

如需了解最初的技术介绍，请阅读网络研讨会文章：Webswing 26.1 介绍与超越 Java——在 Webswing 中运行 Linux 应用。

完整视频包含架构讲解、Admin Console 配置及应用演示：在 YouTube 上观看完整网络研讨会录像。