Rust跨平台探索：前端中的后端，下血本买的

进程间通信可以使用很多方式来进行消息的传递，比如大家熟悉的管道（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 调用平台侧的服务）。