站在巨人的肩膀上

PonyCui 发表于 2019.05.12

自移动平台（iOS / Android）诞生以来，跨平台开发的尝试从未中止，成功与失败并存。而 Flutter 的出现并不是偶然，是 Google 基于前人长期以来探索的道路，辅以大规模人力、物力创造获得的。

在真正开始 Flutter Talk 以前，我以为有必要让你们知道，十多年来前辈们是如何走出这条血路的。

跨平台方案的演进

WebKit

在初代 iPhone 发布之时，也就是 iOS 1 的年代，WebKit 技术是全球开发者最为尊崇的跨平台技术之一。同时，Apple 也致力于推进 WebKit 走向商业化、跨平台化。你可能不知道的是，在 iOS 6 以前，iOS 应用的渲染引擎就是基于 WebKit，iOS 应用实质上也是一个 WebApp。自那时开始，Chrome、Safari 份额日渐上升，WebKit 功不可没。

然而，WebKit 终究只是一个浏览器渲染引擎，跨平台方案要求的不只是通用的渲染方案，其背后的语言层、图形层以及基础环境层都占据很是重要的位置。可是，恰恰就是这些重要的底层组件，各家浏览器开发商都有不一样的实现方案，通俗来说，就是不兼容。

以 WebKit 为基础的跨平台方案，终于走向各自为政的道路。iOS 6 之后，WebKit 成为了配角。Android 自此至终没有将 WebKit 置于正室位置。

WebView

假如 WebKit 不能成为原生组件的惟一渲染引擎，那么，可否取而代之使用 WebView 做为替代方案？毕竟 WebView 的使用已经有二十多载的历史了，网页的编写也相对简单，各类浏览器厂商也广泛遵循 w3c 和 ecma 规范。

可是，使用 WebView 做为跨平台方案有一个重大的弊端 —— 没法调用原生能力。例如，WebView 要调起原生系统的相机、胶卷，就很是困难。

为了弥补这一缺陷，有了 PhoneGap、 JavascriptBridge 这些方案。然而，Patch 终究只是打补丁，这种小修小补的集合体，最终只能让『跨平台』成为一个替补演员的角色。同时，WebView 又是一个黑盒子，一旦出现未知问题，只能干着急。

Facebook 的主应用在最初的版本就是使用 WebView 进行开发的，然而，在后续的版本中，又彻底使用原生重构整个应用了，具体缘由？

React Native

React Native 是 Facebook 于 2016 年公布开源的 Hybrid 开发引擎，其核心思想是但愿在 ReactJS 的基础上，封装一套 Native 渲染的混合开发框架。React Native 仍然是基于 JavaScript 的跨平台方案，与 WebView 不同的是，渲染层由原生实现。其优势在于，RN 能充分使用原生组件能力，从而减小无谓的组件开发工做。

然而，React Native 有一个致命的缺点 —— 慢！这种慢很大程度是由于 JavaScript 的单线程模型形成的，RN 的跨平台能力，很大程度依赖于 JavaScript 的统一实现，RN 将全部的触摸事件、动画驱动以及页面栈都封装在 JS 内，经过一致的 JS 实现以求达到跨平台一致性。这是一个极大的矛盾，一方面，咱们不该该将过于繁重的工做交给 JavaScript 实现，而一方面，过多的平台代码会使得平台一致性的特性减弱。

更要命的是，RN JS 线程与原生 UI 线程并不处于同一线程，线程间通讯彻底依赖以 JSON 为主的序列化、反序列化方式进行。当使用 RN 构建大规模应用时，性能问题更显突出。

小程序

小程序并非严格意义上的跨平台开发框架，鉴于小程序产品的成功，仍然有必要在这里讨论一下。小程序实质上仍然是 WebView，没错，是 WebView。小程序的核心是敲掉 WebView 的 JS 环境，使开发者没法直接操纵 WebView 中的对象。紧接着，提供一个彻底受控的 JavaScript 环境，经过该环境控制多个 WebView 的 DOM 渲染并响应 DOM 事件。

小程序能够很好地运行在受控应用中，但在性能、交互、功能要求更高的场景中，并没有太大优点。笔者认为，小程序是一个好产品，但不是一个好方案。

Flutter

那么，Flutter 呢？Flutter 比上面所说的各类方案更优秀吗？在论证 Flutter 是否更优秀前，笔者以为应该先让你们知道 Flutter 背后的原理。

原理

Flutter 的原理很简单，建立一张画布，并在这张画布上渲染界面。同时，监听原生事件，在 Dart 层响应全部触摸事件。这和跨平台游戏引擎的原理是一致的。抽象出统一的界面、触摸、交互语言，而后使用一致的渲染引擎呈现最终产物。

简单的原理背后，总有复杂的实现支撑！

Dart

Dart 是 Google 开发的相似 Java 的一门编程语言，是 Flutter 的基础运行环境，它支持编译至 JS / AOT / JIT 多种 Target。 在 AOT Target 下，其执行效率与原生编译型语言几乎一致！在 JIT Target 下，又兼有热更新、热重载的便利性，使得应用 Restart 更轻松。同时，Dart 能够编译至 JS，使得 Flutter Web 成为可能。

Dart 能够说是精简版的 Java，若是你有相关的 Java 编码经验，应该很容易上手。

Skia

Skia 是 Google 开发的 2D 渲染引擎，是 Flutter 的底层渲染环境，它支持在不一样平台上运行，包括 iOS / macOS / Windows / Android / Linux 等，Skia 同时是 Chrome 的渲染引擎。

借助 Skia，Flutter 得以在不一样平台上有极为一致的输出表现。

UIToolbox

在 Skia 与 Dart 之上，是 Flutter UIToolbox，UIToolbox 是基于 Dart 开发的一套全新的界面方案。为什么 Flutter 须要一套全新的界面方案？还记得原理中说起到，Flutter 是在一块独立的画布上渲染的吗，正因如此，Flutter 没法复用 iOS / Android 原生的 UI 组件，必须自行实现一套。

在这背后，是庞大的工做量！

Flutter 完整的实现 Material 和 Cupertino 两套组件库，Material 团队还告知 Flutter 团队，Flutter 是 Material 的最佳还原。

工具链

Flutter 团队也意识到，编码工具的易用性对于开发者来讲，很是重要！所以，Flutter 团队花费了大量精力改进 VSCode 和 Android Studio 的插件表现。今天，你能快速地开始、构建 Flutter 应用，背后负载着 Flutter 工程师无数多个日夜的努力，在此为他们点赞。

整体表现

那么，将全部的基础混合在一块儿，效果如何？

在性能上，能与原生应用并肩吗？

答案是，能！并且，可能更好！笔者借助 Flutter 开发了一个完整的应用，从应用的帧率表现来看，Flutter 能在大部分状况下达到 >= 50 FPS 的效果。

同时，Flutter 也很好的避免了 RN 所遇到的困境，Flutter 的主线程就是 UI 线程，它能够在主线程处理 UI 的更新，也能够在主线程处理触摸的响应而无须通过复杂的线程间通讯。

再者，Flutter 也借鉴了 React 以数据驱动界面的思想，在应用开发的过程当中，极大地提高了开发效率。

结论

Flutter 的面世离不开前辈们的努力，同时，也是基于 Google 在语言、渲染等基础库上大量的投入下产生的。如此跨时代的跨平台开发框架，值得各位去尝试一下。