Rust 具有高性能和出色的类型系统，尤其在跨平台方面表现精良正是许多 UI 开拓者所看重的。他们希望能够编写一次代码，在不同平台上运行；
Rust 也为替代底层部分供应了可能。像 Flutter、React Native 等当代跨平台框架，底层部分仍由 C 和 C++编写，在利用和掩护上存在一些困难。如果全体系统能用 Rust 这样的单一措辞编写，利用起来会更加方便；
Rust 还能知足开拓者同时开拓网页和原生运用的需求。Electron 已经实现了这一功能，但在网页修正上存在限定，而 React Native Web 在这方面的表现也并不理想，Rust 有很大的发展前景，有望率先打破。
在 Rust UI 领域，目前存在多种类似于 Flutter 的办理方案，这些框架采取自定义渲染办法。另一类框架则类似于 React Native，它们依赖底层系统工具包来处理布局和界面天生，实际的渲染事情则交由系统平台库完成。Web 前端开拓同样有多种框架供选择，例如 React、Angular 和 Vue 等。Rust UI 生态系统与以上有一定相似性，一些框架较为盛行，而许多其他框架则属于“长尾”部分，因此开拓职员拥有广泛的选择空间，社区中的竞争和互换都非常生动。另一方面，Rust UI 领域的模块化特性使开拓更加灵巧。传统的 UI 运用程序十分繁芜，涉及的内容大概多，须要许多库和框架的合营，而模块化可以让开发者避免从零开始构建所有内容。一些 Rust 组件只管是开源的，但缺少利用解释和示例，这使得想要利用这些组件的人难以入手。Nico 希望在未来几个月里改进这种情形。如今的 Rust 社区核心贡献者虽然仅有 10 人旁边，但商业代价已经凸显，已有资金注入，正处于商业帮助的早期阶段，未来可期。
如何用 Rust 构建运用程序？
接下来，Nico 详细分享了在利用 Rust 构建运用程序时涉及的各项功能及其开拓进展。
1. 创建窗口运用：跨平台能力优先还是实际需求优先？
创建窗口运用程序的核心需求之一是能够跨平台运行，Rust 的 WinIt 库可以实现这一功能，在知足基本的功能需求的情形下，还能支持所有主流平台，在跨平台开拓中非常实用。然而，WinIt 也存在局限性，它无法完备实现开拓者想要的功能，在某些情形下乃至可能成为开拓的障碍。当前 WinIt 在逐步改进原有功能。最近发布的 WinIt 0.30 版本通过行列步队处理，实现了 API 的及时相应，开拓者在实现新功能时将有更多的灵巧性。这也表明 WinIt 团队逐渐开放的态度。WinIt 团队一向坚持的原则是“只开拓面向多平台的功能”。然而这种做法并不总是符合实际需求，Nico 希望 WinIt 能够添加纵然不能跨平台但可以办理开拓者急迫须要的功能，使其更加灵巧。首先许可在单个平台上优先实现某些功能，然后再考虑如何抽象出跨平台的办理方案。WinIt 团队也可以给故意拓展功能的开拓者供应扩展点。如果开拓者想要将窗口嵌入到其他运用程序中，例如通过一个插件来掌握音频制作运用，虽然这在 WinIt 中不能实现，但 BaseView 库和 nih-plug 包装库可以达成。遗憾的是，它们不能与 WinIt 稠浊利用，这给开拓者带来了一定的不便。只管 WinIt 在知足根本需求方面表现良好，但随着开拓者对更多功能需求的增加，改进和扩展将会成为未来的关键。Nico 期待看到更多工具和解决方案的涌现，能帮助 Rust 开拓者更轻松地实现繁芜的 UI 功能。有了窗口后，该如何绘制呢？Nico 先容了四种紧张的办法：软件渲染、OpenGL 渲染、Vulkan/Metal/DirectX 12，以及 WGPU。它们不仅仅适用于 Rust，也适用于跨平台。虽然这些渲染办法在 Rust 中都可用，但开拓者常日不想直接与这些底层 API 打交道。因此，有很多更高等的库可供选择，这些库供应了更直不雅观的接口，例如绘制矩形、笔墨、图像等。然而，许多纯 Rust 库在功能上还有所欠缺，比如处理模糊效果、阴影和笔墨渲染等功能，未来还需进一步补充这些空缺。Nico 特殊推举了两个库：skia 和 webrender，分别运用于 Chrome 和 Firefox。skia-safe 是绑定了 C++版本的 skia。只管构建过程较为繁琐，但它文档完好，功能强大，许多开拓者都在利用。webrender 由 Rust 编写，构建起来很随意马虎，但文档较为混乱。开拓者可以根据自己的需求选择得当的渲染技能。另一个库 Velo 利用了打算着色器，而非更传统的内置渲染管线，理论上性能更强，但目前还不太成熟，如果开拓者乐意考试测验新技能，Velo 是一个不错的选择关于文本渲染功能，渲染单个字形（例如字母、连字或表情符号）和确定要渲染哪些字形及其位置是两个独立的过程。字形渲染基本上是将字体文件转换为图像，详细有以下几种选择。如果瞄准确匹配的需求较高，可选择 WebRender。它利用 Mac OS、Windows 和 Linux 的底层系统库来渲染字形，使其与系统中的其他运用程序保持同等。但利用这种方法须要与系统 API 交互，过程较为繁芜。比较常用的是纯 Rust 编写的 Swash。它实行缩放和提示，即将字体文件转换为特定字体大小的精确矢量路径，并通过通用的矢量渲染器进行渲染。comsmic-text、femtovg 都利用了 swash。由 Rust 编写的 Scripher 能够兼容不同系统也是不错的选择，它与 Swash 非常相似，都是高质量的字形渲染技能。将笔墨渲染成图像之后，接下来就须要系统合成器将多个图像层叠加在一起。面对不同进程且互不通信的窗口时，须要将其组合起来。利用系统供应的合成器可以极大地提高效率。如通过滚动操作，可以直接渲染到纹理上，然后让操作系统卖力高下移动，而不须要每帧重新渲染所有内容。许多运用处景都涉及到将来自运用程序外部的内容渲染到窗口中，比如视频、网页视图或操作系统控件，它对付高效的 UI 渲染至关主要，目前专门从事系统合成器的开拓的人不多，未来还须要更多人参与个中。合成完成后，开拓者可以利用内置的布局方法（如网页上的 Flexbox 和 CSS Grid）或自己的布局算法。内置方法虽然方便，但可能无法知足一些高等需求。自己的布局算法可能会很慢，但也不一定像内置的那么好。如果采取 box 布局，所有内容都以部件树的形式呈现，常日有三种处理模型：第一种模型是直策应用网页布局，其好处在于它与网页布局完备相同或非常靠近，对付熟习网页开拓的人来说更随意马虎上手。但这种方法的韶光繁芜度可能会呈指数级上升，如果追求极致性能，可能会碰着寻衅。有些人对所利用的 API 感到困惑，对此，Nico 表示，他参与开拓的 Taffy 布局引擎在基准测试中的表现优于 React Native 利用的 Yoga 布局引擎。第二种模型，拥有伸缩和添补能力。你可以指定一个固定大小的部件布局，其余两个部件各自霸占剩余可用空间的一半。这种布局办法可以根据窗口大小等成分动态调度。第三种模型类似苹果平台内置的办法，将内容彼此对齐。除了 TUI 框架 Ratatui，大多数 Rust 的 UI 框架尚未实现繁芜的布局功能。在文本布局方面，Nico 提到目前 Rust 生态系统中的富文本支持还存在一定的局限。一些基本的文本布局可以实现，但内联图像、小部件、区域打消、浮动图像或引用块等繁芜功能目前还无法实现。Cosmic Text 和 Parley 是两个比较常见的库，前者在等宽字体的虚拟化优化上表现出色，而后者在多字号支持上表现良好。 此外，输入方面挑也存在寻衅。虽然 Rust 可以处理基本的鼠标和键盘输入，但对付更繁芜的输入法编辑器（IME）等输入系统的支持仍旧有限。IME 对处理字符重音、表情符号输入、中文和日文等措辞的输入非常主要，是 Rust 生态系统中急需改进的部分。可优化空间与赞助工具的主要性
如何使运用程序被屏幕阅读器等赞助工具利用？可访问性至关主要。例如，屏幕阅读器应能够读取运用内容、感知内容更新，这样才能并实现一定的交互。AccessKit 库为 Rust 运用供应了这方面的支持，不过该库仍有改进的空间。 在 Rust UI 开拓中，系统菜单和剪贴板等功能已具备，但实现布局的实时呈现、网络要求、能否自我驱动等功能有待开拓者进一步探索。 Nico 还特殊强调了赞助文档的主要性：目前，Rust UI 生态系统中的文档质量参差不齐，许多开拓者并不知道如何利用这些工具，他希望未来能有更多的教程和文档来辅导如何利用屏幕阅读器和其他可访问性工具，也呼吁开拓者为库和代码编写更多的文档，特殊是针对用户和贡献者的文档。此外关于编译韶光。只管大部分编译韶光问题可以通过编译器优化来办理，但热重载功能十分主要——可以避免频繁重新编译。如 Dioxus、Leptos 和 Bevy 都支持这一功能，Nico 希望未来更多的库能加入这一行列。
为了 Rust 更好的来日诰日，改进
Rust 措辞存在哪些问题？又通过什么办法进行改进呢？Nico 在末了总结了 Rust 在 UI 开拓方面须要改进的内容，并提出了几点建议。1. 自动克隆：UI 框架中常常须要利用到 Rc （引用计数）和 Arc（原子引用计数）。开拓者期望的调用办法是能够实现隐式克隆。目前，一些 UI 框架通过宏来隐蔽这一过程。未来，希望能够开拓出一种环绕 Rc 或 Arc 的新类型，以实现自动克隆的功能。2. 字段借用：有时开拓者希望在构造体上同时拥有多个可变方法，同时借用不同字段。虽然逻辑上行得通，但在 Rust 编译器中较难实现。跟踪借用的机制是可行的，但是须要设置特定的语法，以便开拓者可以同时对构造体的不同字段进行操作。3. 默认值支持：在 Rust 中，如果你为一个构造体实现了一个 trait，常日须要为所有字段供应默认值。然而，在很多情形下，只有部分字段拥有合理的默认值，而别的字段则须要在创建时明确设置。目前，利用构建器模式是办理这一问题的方法，但这会使代码变得冗长且天生大量模板代码。对付底层代码而言，涉及的类型较为严格且配置选项有限，这种影响较小；但在高等代码中，这种影响则更为显著。希望未来能有一种机制，许可开拓者只为部分字段供应默认值。4. 改进孤儿规则：当前的孤儿规则限定了外部 crate 之间的相互操作性。5. 采取特化机制：有助于构建模块化的生态系统，并且供应更经济性的 API。例如，利用特定类型时可以直接走分外路径，作为 API 的消费者，乃至不须要花韶光去理解。6. 外部构建系统/代码天生：有助于减少编译韶光、定制个性化 crate。
末了，Nico 再次强调告终构、输入处理和可访问性的主要性。对商业运用而言，可访问性的主要性不容忽略。改进 Winit 以增强对系统功能的访问同样主要，这须要更多成熟的组件和文档支持。长远来看，这些改进将有助于提升 Rust 生态系统的整体质量和运用开拓体验。
10 月 17 - 18 日，GOSIM CHINA 2024 （北京站）与多位开源领域资深大咖面对面互换！
