前端领域有哪些跨端方案？

跨平台指的是跨操作系统，而跨端是指客户端。

客户端的特点就是有界面、有逻辑，所以包含逻辑跨端和渲染跨端。主要的客户端有 web、安卓、ios、iot 设备等。

现在主流的跨端方案有 react native、weex、flutter、kraken 以及各家自研的跨端引擎等。

跨端包括逻辑跨端和渲染跨端，rn 的逻辑跨端是基于 js 引擎，通过 bridge 注入一些设备能力的 api，而渲染跨端则是使用安卓、ios 实现 react 的 virtual dom 的渲染。

其中 native api 和组件（灰色画出的部分）并没有做到双端一致，而且有的时候扩展图中灰色部分需要原生配合，混杂 rn 代码和自己扩展的代码导致代码比较难管理。最著名的事件就是 airbnb 从最大的 react native 支持者到弃用 react native。

weex 也是类似的思路来实现跨端的，不过他对接的上层 ui 框架是 vue，而且努力做到了双端的组件和 api 的一致性（虽然后续维护跟不上了）。架构和上图类似。

flutter 是近些年流行的跨端方案，跨的端包括安卓、ios、web 等。它最大的特点是渲染不是基于操作系统的组件，而是直接基于绘图库（skia）来绘制的，这样做到了渲染的跨端。逻辑的跨端也不是基于 js 引擎，而是自研的 dart vm 来跨端，通过 dart 语言来写逻辑，

跨端包括两部分，渲染跨端和逻辑跨端。有时候只需要渲染跨端、有时候只需要逻辑跨端，有的时候需要完整的跨端引擎，这 3 种情况都有各自的适用场景。

kraken 就是一个跨端渲染引擎，基于 flutter 的绘图能力实现了 css 的渲染，实现了渲染的跨端。

跨端引擎很依赖底层实现的组件和 api，用开源方案也一样得扩展这部分，所以有一定规模的团队都会选择自研。

自研跨端引擎会和 rn、weex 不同：

渲染部分不需要实现 virtual dom 的渲染，而是直接对接 dom api，上层应用基于这些 dom api 实现跨端渲染。这样理论上可以对接任意前端框架。
逻辑部分也是基于 js 引擎，通过 binding 直接注入一些 c++ 实现的 api，或者运行时通过 bridge 来注入一些安卓、ios 实现的 api。

自研跨端引擎的好处是组件和 api 可以自己扩展，更快的响应业务的需求。其中组件和 api 的双端一致性，以及统一的 api 的设计都是难点。

跨端的通用原理是什么

其实跨端和跨平台的思路类似，都是实现一个容器，给它提供统一的 api，这套 api 由不同的平台各自实现，保证一致的功能。

具体一些的话，跨端分为渲染和逻辑跨端，有的时候只需要单独的渲染跨端方案（比如 karen）和逻辑跨端方案，有的时候需要完整的跨端引擎。

weex、react native 的渲染部分都是通过实现了 virtual dom 的渲染，用安卓、ios 各自的渲染方式实现，逻辑部分使用 js 引擎，通过 bridge 注入一些安卓、ios 的 api。

flutter 则是直接使用 skia 绘图库绘制，并且逻辑跨端使用 dart vm。

但是不管具体实现怎样，思路都大同小异：跨端引擎需要实现一个渲染引擎、实现一个 vm，基于这套架构实现各种组件和 api，跨端容器上层对接一个 ui 框架，再上层的业务代码可以基于容器的 api 实现跨端的渲染和逻辑

这两天 web container 比较火，其实也是一种跨平台技术，它是在浏览器里面实现的容器，通过 wasm 实现了 node 的 api，这样在这个容器里面可以跑 node 代码。其实思路比较常见，但是是一个新场景。

浏览器容器之上又跑了个容器，容器套娃。