选择Flutter原因汇总（性能角度对比跨平台）

前言

Flutter 是 Google 2018 年公开发布的一个移动 App 开发方案，通过 Flutter 前端开发者就能够开发出真正意义上的原生 App。
选择 Flutter 并不是为了代替 iOS 或者 Android，而是做一个技术互补，比如，Flutter 负责业务功能，而 iOS 和 Android 则负责部分的底层交互提供服务给到 Flutter 应用。Flutter 也是在这两年刚刚兴起的，在应用起步初期还需要部分底层的服务与原生平台进行交互。相信再经过一段时间的发展，Flutter 在这方面会不断地优化和提升，也将能够独立覆盖到更多复杂的业务场景。

跨平台技术对比

• Hybrid （H5 + WebView + JsBridge）始终是 Web 平台，所以性能相比于原生根本不在一条起跑线。（WebView实质上就是一个浏览器内核）（依赖于WebView的，且用于在JS与原生之间通信并实现了某种消息传输协议的工具称之为WebView JavaScript Bridge, 简称 JsBridge，它也是混合开发框架的核心。）
  Hybrid 就是在每个 APP 中包了一个 H5 的 Web 页面，在需要原生功能的地方，通过 JsBridge 封装一些 JSAPI 给 Web 来调用，扩充了 Web 应用能力，看起来就像是 H5 拥有了原生 APP 交互功能。
  但是这种方法有两个不足，一是依赖客户端，二是在性能和体验上都非常依赖于 Web 端。因此，整体上的体验不可预知。
  目前这个技术还经常被应用到，例如，当前 App 内会提供白名单域名和可调用的 JSBridge 方法，由此来增强 H5 与客户端交互能力，从而提升 App 内 H5 的灵活性。

• RN / Weex 这种方案，改变了用 H5 实现的方式，使用的是原生的界面，将 JavaScript 的界面以及交互转化为 Native 的控件，从而在体验上和原生界面基本一致。
  性能上最大的弊端在于 RN 项目最终打包的结构还是一个 JS bundle，也就是说需要到运行阶段才能够去解析 JavaScript（JIT模式）
  再通俗一点讲就是：用户的各类事件操作，都是需要与 JS 进行操作，而 JS 操作后，需要将响应反馈到原生 Native 中，中间有一个交互过程。因此频繁地在 JS 与 Native 之间进行通信，从而会有一定的性能损耗影响，导致体验上与原生会有一些差异。（JIT 意思就是运行时编译，就像在运行的时候将 JS 编译为原生界面的过程 ）

• Flutter 就是一个纯原生的开发方案，采用的是静态编译（AOT），也可以叫作提前编译。一个 Flutter 项目编译后的结果就是原生应用，相比于即时编译（JIT）性能自然有显著提升，同时也有了自渲染模式（基于自绘特性很好的解决了多端一致性的问题）