鸿蒙开发新范式：Gpui

起

这篇文章主要记录我最近做的一件事情：把 GPUI 适配到 OpenHarmony。得益于AI的能力，目前已经基于该适配方案跑通两个“较为复杂”的App。

如果你已经非常了解鸿蒙和Gpui的开发模式和手段，并且想直接开始使可以参考模板仓库（最小可运行）：github.com/ohos-rs/gpu…

在开始阅读前，建议你有这些背景：

1. 有 Rust 基础，能够读懂基本的Rust代码。
2. 了解鸿蒙 Native/Rust 常见的开发范式。
3. 对 GPUI 有最基础认知（知道它是一个跨平台 UI 框架）。

Demo1

Demo2

背景

Gpui作为 zed 编辑器的子项目，承载了 zed 的UI渲染能力，并且由于其良好的架构设计和性能，逐渐在Rust GUI生态中声名鹊起。长桥团队基于Gpui推出了shadcn风格的Gpui-Component，并且将他们的桌面客户端使用Gpui进行了重写。

目前Gpui官方的支持架构为 macOS、Windows、Linux，其中 Web 正在支持中。而因为良好的架构设计和分层设计，使得在鸿蒙上适配并且运行变得有可能。

大概两个月前我开始了 gpui 的适配。

适配

Gles or Vulkan

鸿蒙一般支持 OpenGLES 和 Vulkan 两种渲染方式，不过在 Rust 生态中，Vulkan 大部分场景依赖于 ash。而 ash 对于鸿蒙的支持最简单的适配需要其新合入的代码，这部分代码目前并没有发布正式版本。因此大部分场景下，我们暂时无法直接做到 Vulkan 的开箱即用。

而 Gles 所依赖的包基本上支持或者已经适配了鸿蒙，因此我们此次优先使用 Gles 作为渲染后端。

Shader

Gpui在渲染中使用了shader来进行部分场景的渲染，各个平台使用了各自的渲染机制。其中Linux在老的版本使用了blade来通过Vulkan/Gles进行渲染，新版本则是使用了Wgpu作为渲染依赖。

而 OHOS 在一定程度上可以也认为是一个Linux系统，因此最简单的做法就是直接借用 Linux 的已有能力完成渲染，但是实际上却有一些差异。

而这里最大的问题在于Linux的shader中使用了 BBSO 用于渲染效率的提升。但是很遗憾的是：在Mate60的设备上 Gles 并不支持该特性，因此适配中第一个最大的问题就是将不支持的特性使用其他能力进行替换。

借助于Opus4.6，我大概花了两天左右替换了不支持的能力并且基本上确保渲染效果是符合预期的。

事件循环

与社区其他窗口管理库类似，gpui 也提供了类似的逻辑将不同平台的不同事件归一化到统一的事件机制中。而笔者之前在适配 tao/winit 等框架时，已经完成了这一步，因此只需要将之前的部分代码复用到 gpui 上即可。

尾声

在适配完Gpui之后，我使用该适配方案实现了两个较为复杂的App，整体效果较为不错，相关代码后续将会开源。

后续如果继续演进，我会优先考虑：

1. 补齐更多平台能力（剪贴板、更多系统交互接口）。
2. 优化触摸与滚动体验细节。
3. 稳定性验证（更多机型与场景）。

如果你正在做类似适配或者想要尝试在鸿蒙上体验一些新技术，希望本文对你有所帮助。