2024年Web前端最全Rust跨平台探索：前端中的后端，Web前端事件分发面试

最新推荐文章于 2024-05-11 20:03:34 发布

2401_84447328

最新推荐文章于 2024-05-11 20:03:34 发布

阅读量809

点赞数 14

分类专栏：程序员文章标签：前端面试学习

本文链接：https://blog.csdn.net/2401_84447328/article/details/138693401

版权

程序员专栏收录该内容

150 篇文章 0 订阅

订阅专栏

最后

面试题千万不要死记，一定要自己理解，用自己的方式表达出来，在这里预祝各位成功拿下自己心仪的offer。
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

大厂面试题

面试题目录

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

3. 基于 Canvas 绘制

Canvas绘制是实现UI跨平台的主流思路：

平台渲染: 用 JS 来调用原生 UI, 这是 React Native 采用的方式。优点是大部分时候性能足够好；缺点是 JS bridge 需要适配所有支持的平台，当平台侧UI控件想要在RN中使用，需要开发者花费额外精力去适配。
统一渲染：用其他技术来模拟原生 UI。这是 Cordova / Electron 采用的方式。优点是代码简单，UI 直接在第三方渲染器（webview）中渲染出来；缺点是 UI 性能受 JS 单线程及 webview 本身渲染性能的影响，在复杂交互时往往表现不佳。

当大多数选择统一渲染方案的技术栈只是把目光停留在了webview ，人们忽略了其实所有的 UI 渲染，最终都是在 canvas 上一个像素一个像素填充出来的。如果做一套系统，略过 dom/css/js 复杂的渲染逻辑，直接定制好各种各样的控件，将其绘制到 canvas 上，是不是可以鱼与熊掌兼得？

做到这点的要数 flutter 了。它使用 chrome 底层的图形渲染引擎 skia，从底向上设计出来一套可以高效工作的控件库，比 webview 性能高的同时，又不依赖平台侧的控件。

现有跨平台方案中的问题

目前所有这些方案的着眼点还是局限在UI层的跨平台，那么业务逻辑代码怎么办？用JS这样的 UI 层的语言撰写难以保证运行时效率，最终还是要诉诸于 native 语言实现，原本一种语言统一天下的初衷，最终发现要学习三种语言，iOS、android、JS/dart 各来一套（flutter可能做得稍微强一点儿，但是依然需要借助 channel 调用平台侧的服务）。

“相比UI跨平台，如何在业务逻辑层跨平台是一个容易被忽略但更值得被关注的问题。”

那么为什么逻辑层跨平台技术进展如此缓慢呢？一个主要原因是没有一个合适的语言工具，很难找到一门语言能够同时覆盖这么多平台的原生语言的优势。

在 Rust 成熟以前，C/C++ 几乎是跨端做业务逻辑的唯一的选择。用 C/C++ 实现一次，然后在各个端上用静态链接的方式编译到 app 中。当然这免不了要做很薄的一层接口：每个平台原生语言到 C/C++ 的桥接。

但是 C/C++ 的代码（相对于 java/kotlin/swift来说）的撰写难度较高，跨平台编译链接有很多坑要踩，最终会遮掩所谓「一次撰写，到处链接」的好处。

如今有了Rust， Rust 有不输于任何一门现代语言的依赖管理和生态，有非常完备的跨平台编译系统和跨语言FFI支持，而 Rust 本身的不依赖运行时的内存安全和并发安全性，还有几乎最高质量的 webassembly 支持，使其成为 C/C++ 跨平台的完美替代品。除了 rust 本身的跨平台工具链之外，Rust 生态里还有专门为简化与 iOS 原生语言互操作的工具 cargo lipo（封装 C FFI），以及为与 java 互操作的 jni，甚至还有专门针对 Android 的 android-ndk-rs。

接下来，我们需要的就是一套组织各个平台原生语言和 Rust 互操作的思路，来解决通用性的问题。

前端中的后端

所谓前端中的后端，就是在前后端分离的基础上，进一步把前端中偏 UI 的业务逻辑和偏数据处理的业务逻辑分开。而掌管数据处理的这部分功能，我们管它叫前端中的后端。

基本架构

无论是前端架构中被广泛使用的 MVC 还是 MVVC 模式，其第一个 M，Model（包含数据，状态，以及业务逻辑），就是我们要分离出来统一处理的「后端」。借鉴之前提到的 bridge 模式，可以构想出来这么一套前端代码的前后端分离的模型：

这个模型相对于传统的 UI 跨平台方案，其最大不同是：让所有的相关方处理自己最擅长的事情，而不要强行适配。和平台相关的代码，比如 UI，平台设备的访问等，用更擅长做这件事情的平台原生语言实现（或者 flutter），而平台无关的业务逻辑代码，算法，网络层代码，使用 Rust 来实现。这样，Rust backend 不用去花大量的精力去包裹平台的东西，而只需干好一个 backend 需要干好的事情。

通信方式

之前的 UI 方案，采用的都是 JSON 或者类 JSON 的序列化方案，JSON 是效率非常低下，且类型安全度比较低的一种序列化方案，在这样的场景下，我们还有更多更好效率更高类型更安全的方案，比如 protobuf，flatbuffers 等。

反序列化	序列化

以 Rust 和 Kotlin 之间做通信为例，使用 JSON 以及 Protobuf 的通信流程分别如下：

JSON	Protobuf

Rust 和 Kotlin 分别将定义好的 protos 编译成平台代码，然后可以在两端自由地传递 protobuf 的数据。

示例

比如要展示电影网站 Tubi 的首页，假设我们基于 clean architecture 的 MVP 结构实现此逻辑

后端提供 API 获取电影列表 GET /api/v1/get_movies
建立一个 TubiRepository 处理网络层的请求
请求的响应被反序列化成 Category / Movie models，然后以 Entity 的形式交给 Use cases
最后presentation layer 将结果被渲染到屏幕

这里，尝试对 Model层用Rust实现，如下：

暴露给 native 层的方法是：getMovies()
getMovies() 内部将参数序列化成 protobuf 传递给一个 Rust 函数 dispatcher
dispatcher 反序列化请求后得知是一个 RequestGetMovies，随后被 dispatch 给 get_movies()
get_movies()从本地 cache 里读取数据，读不到的话通过 reqwest 从远程 API 获取数据并缓存

从 native 开发者的角度，她就调用了一个 getMovies() 后返回了序列化好的 Movie，Category等数据结构，其它的细节不需要理会。

再举个例子，用户在观看视频的时候，客户端会定期向服务器汇报当前观看的位置

API: PUT /api/v1/update_history
在 native 层暴露出一个 updateHistory() 的方法
dispatcher 将其 dispatch 给 Rust 函数 update_history()

从上述的例子，我们大概可以看到在 Rust 侧我们可以处理的工作：

更高效的网络层：自动管理的连接池，更好的流控，更灵活的安全处理方式，以及，UI 侧无感知的网络层处理，比如有一天我们把 REST API 升级成 gRPC，API 层的签名采用 schnorr signature，或者 HTTP/2 升级到 HTTP/3。native 侧根本无需关心。
更好的数据管理。Rust 有丰富高效的数据结构，可以为每一种数据设置量身定制的方案。我们还可以做非常高效的数据缓存。
在此之上给数据的赋能。比如为 get_movies() 获取到的数据做简单的索引，方便数据在各个不同维度的展示和过滤。