站在巨人的肩膀上

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 在语言、渲染等基础库上大量的投入下产生的。如此跨时代的跨平台开发框架，值得各位去尝试一下。