Rust跨平台探索：前端中的后端

最新推荐文章于 2025-07-21 22:37:20 发布

2401_84092727

最新推荐文章于 2025-07-21 22:37:20 发布

阅读量1.1k

点赞数 23

CC 4.0 BY-SA版权

分类专栏：程序员文章标签： rust 前端开发语言

本文链接：https://blog.csdn.net/2401_84092727/article/details/137465495

这些解决方案各有优劣，从架构的角度，大致是以下几种模式：

跨平台方案的几种类型

1. 桥接（Bridge）

桥接要解决的核心问题是两种语言（JS 和原生语言）之间的通信，或者说 JS thread 和 native thread 之间的通信。 native layer 的能力被 bridge layer 封装起来，然后提供给 JS layer 调用，反过来，JS layer 的功能也可以借由 bridge layer 供 Native layer 调用。

这个模型很像客户端与服务器之间的通信，客户端和服务器约定好服务接口（REST API）后，通过 JSON 交换数据。React Native 借鉴了这种模式，通过 JS bridge 来回传递 JSON。

桥接的代表是：Cordova / React native。两者的区别是在 Cordova 的 UI 层基于 WebView 渲染，所以只需要通过桥接调用 Native 基础服务；而 RN 的 UI 基于平台渲染，因此在 UI 层也做大量了桥接。由于 JS bridge 层依靠 JSON 通信，当大量数据在两端传输时（复杂的动画，大列表的快速滑动），JSON 的性能瓶颈会造成UI卡顿。

2. 进程间通信（IPC）

在桌面系统上，应用程序有更多的灵活性，可以通过使用多进程来组织自己的应用程序。我们同样可以通过进程间通信来解决 JS 和原生语言之间的调用问题，其代表方案是：Electron。

Electron 使用 IPC 某种程度上说也是迫不得已，因为其依赖的 chromium rengier engine 就是为每一个窗口开启一个进程。对于 chrome 来说，这是一个合理的设计，一个 tab 内部的 crash 不会导致整个 chrome crash。然而对依赖于 Electron 的桌面应用来说这样设计没有必要，反而增加了 IPC 的成本

进程间通信可以使用很多方式来进行消息的传递，比如大家熟悉的管道（pipe）。然而，Eletron 使用了 web worker API postMessage 相同的 structured clone algorithm 来做 IPC 数据的序列化和反序列化。这个方法效率和 JSON 差不太多，在传输大量数据时同样会有性能问题，所以 Electron 推荐使用 CSS animation，而非常不建议做 JS anination。