Flutter 核心原理与混合开发模式，张口就来

跨端方案1

所谓 Web 容器，即是基于 Web 相关技术通过浏览器组件来实现界面和功能，包括我们通常意义上说的基于 WebView 的 “H5”、Cordova、Ionic、微信小程序。

这类 Hybrid 开发模式，只需要将开发一次 Web，就可以同时在多个系统的浏览器组件中运行，保持基本一致的体验，是迄今为止热度很高的跨端开发模式。而 Web 与 原生系统之间的通信，则通过 JSBridge 来完成，原生系统通过 JSBridge 接口暴露能力给 Web 调用。而页面的呈现，则由浏览器组件按照标准的浏览器渲染流程自行将 Web 加载、解析、渲染。

这类方案的优点：简单、天然支持热更新、生态繁荣、兼容性强、开发体验友好。

当然，缺点也很明显，否则就没有后面两个方案什么事了，主要是体验上的问题：

1. 浏览器渲染流程复杂，页面需要在线加载，体验受限于网络。所以 Web 存在白屏时间（PWA 例外）、且交互上体验上与原生体验有着非常非常明显区别。

2. 双端需要分别实现 JSBridge 接口，且 JSBridge 的通信效率一般。

2.2 泛 Web 容器

跨端方案2

所以轮到泛 Web 容器方案出场了，代表性框架是 React Native，Weex，Hippy。

• 它放弃了浏览器渲染，而采用原生控件，从而保证交互体验；

• 它支持内置离线包，来规避加载耗时避免长时间白屏；

• 它依然采用前端友好的 JavaScript 语言，来保证开发体验。

在跨端通信上，React Native 依然通过 Bridge 的方式来调用原生提供的方法。

这套方案理想是美好的，但现实确实骨感的，它在实践下来之后也依然发现了问题：

1. 直接调用原生控件虽然提升了体验和性能，但是不同端相同的原生控件的渲染结果是存在差异的，跨端的差异需要巨大的工作量来抹平。

2. Bridge 的通信效率一般，在需要高频通信的场景下会造成丢帧。

2.3 自绘引擎

那我们究竟能不能既简单地抹平差异，又同时保证性能呢？

答案是可以，那就是自绘引擎。不调用原生控件，我们自己去画。那就是 Flutter。好比警察问 React Native 嫌疑犯长什么样子，React Native 只能绘声绘色地去描绘嫌疑犯的外观，警察画完之后再拿给 React Native 看，React Native 还要回答像不像；但 Flutter 自己就是一个素描大师，它可以自己将嫌疑犯的画像画好然后交给警察看。这两者的效率和表现差异，不言而喻。

1. 其通过 Skia 图形库直接调用 OpenGL 渲染，保证渲染的高性能，同时抹平差异性。

2. 开发语言选择同时支持 JIT 和 AOT 的 Dart，保证开发效率的同时，较 JavaScript 而言，更是提升了数十倍的执行效率。

跨端方案3

通过这样的思路，Flutter 可以尽可能地减少不同平台之间的差异, 同时保持和原生开发一样的高性能。并且对于系统能力，可以通过开发 Plugin 来支持 Flutter 项目间的复用。所以说，Flutter 成了三类跨端方案中最灵活的那个，也成了目前业内受到关注的框架。

至于通信效率，Fluter 跨端的通信效率也是高出 JSBridge 许许多多。Flutter 通过 Channel 进行通信，其中：

1. BasicMessageChannel，用于传递字符串和半结构化的信息，是全双工的，可以双向请求数据。

2. MethodChannel，用于传递方案调用，即 Dart 侧可以调用原生侧的方法并通过 Result 接口回调结果数据。

3. EventChannel：用户数据流的通信，即 Dart 侧监听原生侧的实时消息，一旦原生侧产生了数据，立即回调给 Dart 侧。

其中，MethodChannel 在开发中用的比较多，下图是一个标准的 MethodChannel 的调用原理图：

MethodChannel

但为什么我们说 Channel 的性能高呢？梳理一下 MethodChannel 调用时的调用栈，如下图所示：

通信效率

可以发现，整个流程中都是机器码的传递，而 JNI 的通信又和 JavaVM 内部通信效率一样，整个流程通信的流程相当于原生端的内部通信。但是也存在瓶颈。我们可以发现，methodCall 需要编解码，其实主要的消耗都在编解码上了，因此，MethodChannel 并不适合传递大规模的数据。

比如我们想调用摄像头来拍照或录视频，但在拍照和录视频的过程中我们需要将预览画面显示到我们的 Flutter UI中，如果我们要用 MethodChannel 来实现这个功能，就需要将摄像头采集的每