Hummingbird: 在Web上运行Flutter应用

原文作者：Yegor Jbanov

译者：UC 国际研发 Jothy

写在最前：欢迎你来到“UC国际技术”公众号，我们将为大家提供与客户端、服务端、算法、测试、数据、前端等相关的高质量技术文章，不限于原创与翻译。

今天，我们在 Flutter Live 上宣布了一个消息：我们正尝试在 Web 上运行 Flutter。 这篇文章描述了我们应对挑战的方式，以及该技术的当前状态。 在文末，我们附上了协同工作和嵌入等问题的答案。

让我们快速回顾一下 Flutter 的架构。 Flutter 是一个多层系统，这样高的层更易用，用很少的代码就能表达很多，而较低的层能提供更多的控制，代价是必须处理一些复杂性。 当较高层不能满足开发者的需求时，它们可以降到较低层。 开发者可以访问 Flutter Engine 之上的所有层。

Flutter 的 Mobile 架构

在 Flutter 中，Flutter Engine 作为最低级别的库 dart:ui 暴露。它不关心 组件，物理实现，动画或布局（文本布局除外）。它所关心的是如何将图片组合到屏幕上，渲染变成像素。在 dart:ui 上直接编写应用是很困难的。这正是我们创建更高层的原因。

dart:ui 之上的一切是我们所谓的“框架”。它下面的一切都是“引擎”。该框架完全使用 Dart 语言编写。大多数引擎都是用 C++ 编写的，特定于 Android 的部分用 Java 编写，而 iOS 特定的部分用 Objective-C 编写。 dart:ui 中的一些基本类和函数是用 Dart 编写的，主要用作 Dart 和 C++ 之间的桥梁。

Flutter 还提供插件系统。插件使用指定语言编写，可以直接访问移动生态系统日积月累的 OEM 库和第三方库。你可以使用 Java 或 Kotlin 为 Android 创建插件。 iOS 插件开发是使用 Objective-C 或 Swift。

Hello, The Web

Web 平台已经发展了数十年，包含了许多技术和规范。 有一些涵盖性术语用于描述大量相关功能：HTML，CSS，SVG，JavaScript，WebGL。 为了在 Web 上运行 Flutter，我们需要：

• 编译 Dart 代码：Flutter 是用 Dart 编写的，我们需要在 Web 上运行 Dart。

• 选择要在 Web 上运行的 Flutter 子集：在 Web 上运行所有 Flutter 代码是不切实际的。 其中一些是特定于平台的，例如 Android 和 iOS。

• 选择足够的 Web 功能子集：随着时间的推移，Web 平台会累积重复的功能。 例如，你可以使用 HTML + CSS，SVG，Canvas 和 WebGL 绘制图形。

从 Dart 诞生之初，它就一直在编译 JavaScript。 现在有许多重要的应用都从 Dart 编译为 JavaScript，并在生产环境中运行。 Flutter 的编译策略依赖于同样的基础设施。

当我们开始探索时，我们面临着 UI 渲染的几种选择。 我们很快意识到，要想支持的特定 Flutter 层，决定了我们将用什么 Web 技术。 我们构建了三个原型：

• 仅仅是 Widgets（组件）：这个原型实现了 Flutter 的 widget 框架，并提供了一组核心布局 widget 作为构建自定义 widget 的基础。 对于布局和定位，它依赖于 Web 的内置功能，例如 flexbox，grid 布局，浏览器滚动（通过 overflow:scroll 实现）等。

• Widgets + 自定义布局：此原型包括 Flutter 的布局系统（由 RenderObject 提供），但将渲染对象直接映射到 HTML 元素。

• Flutter Web Engine：这个原型保留了 dart:ui 之上的所有层，并提供了一个在浏览器中运行的 dart:ui 实现。

Flutter 最有价值的功能之一是它可以跨平台移植。 你完全可以（有时甚至被鼓励）编写自定义的特定平台代码，代码无需跨平台定制即可共享。 意味着使用单个代码库就可以编写面向多个平台的应用。

在尝试将几个示例应用移植到 Web 之后，我们意识到原型 #1 和 #2 不能提供 Flutter 开发者喜欢的可移植性级别。 因此，我们决定使用 Flutter Web Engine 设计的原型 #3，因为它有着平台之间最高的框架级代码重用：

Flutter的Web架构 (Hummingbird)

既然我们知道我们想要实现整个 dart:ui API，我们需要选择一组 Web 技术来构建。 Flutter 一次渲染一帧 UI。 在每个帧内，Flutter 会构建 widgets，执行布局，最后在屏幕上绘制它们。

构建 Widgets

Widget 构建机制不依赖于应用运行的环境。该过程只是实例化内存中的对象，跟踪其状态、以及状态变更何时计算系统低级别的最小更新，布局和绘制等。 将此部分移植到 Web 上非常简单。 在 Dart 团队用 dart2js 中实现了 super-mixin 支持之后，编译器将所有 widget 和 widget frame 都编译成了 JavaScript，几乎没有 issue 产生。

布局

布局系统有点棘手。 最大的挑战是文本布局。 除了 Center，Row， Column，Stack，Scrollable，Padding，Wrap 等之外的所有内容都由框架布局，因此无需修改即可编译到 Web。

在 Flutter 中，你可以创建 Paragraph 对象并调用其 layout() 方法来实现文本布局。 不幸的是，Web 缺少直接的文本布局 API。 我们用来测量文本布局属性的技巧是：先让浏览器布局，然后从 DOM 元素中读回相关属性。

布局文本段落时，Flutter 会测量段落的高度，宽度，最大内在宽度，最小内在宽度以及字母和表意基线。 这些属性如下所示。

Paragraph layout attributes

你可以在 Flutter 的 Paragraph 文档中找到更多详细信息。

要测量这些属性，我们首先在 HTML DOM 元素中放置一个段落，然后读取元素的维度。 这会引起浏览器布局。 例如，要获取元素的宽度和高度，我们调用 offsetWidth 及 offsetHeight。 为了测量基线，我们将段落放置在一个元素中，该元素配置为使用 flex 行进行布局。 在段落旁边，我们放置另一个名为 probe 的元素。 因为 probe 与文本的基线对齐，所以调用 getBoundingClientRect 就可以得到基线。 我们使用类似的技巧来测量最小和最大固有宽度。

Painting（绘制）

不得不提的是，我们得绘制 widgets。 对这个区域的探索最是麻烦，它仍然是我们的研究中最活跃的领域。 在框架最后，我们所有的 widget 都需要在屏幕上绘制成像素。 在浏览器中，这意味着它们必须归结为 HTML / CSS，Canvas，SVG 和 WebGL 的某种组合。

我们还没有看过 WebGL，主要是因为它级别较低，并且要求我们重新实现浏览器已经可以做的事情，例如文本布局和光栅化 2D 图形。另一个原因是我们还没有弄清楚非 Flutter 组件与 WebGL 如何结合才能实现可访问性，文本选择，和组合。

我们的早期原型为每个 RenderObject 生成了一个 HTML 元素。 结果符合预期，但最后事实却证明 API 的变化太大了。 我们必须用 Flutter 维持一个巨大的代码增量，所以我们搁置了这个想法。

我们目前正在同时探索两种方法：

• HTML+CSS+Canvas

• CSS Paint API

HTML+CSS+Canvas

基于这种方法，我们将框架生成的图片分类为使用 HTML + CSS 表达的图片以及使用 Canvas 2D 表达的图片。然后，我们输出结合了 HTML，CSS 和 2D 画布的 HTML DOM。

我们更喜欢 HTML + CSS，因为它受浏览器的显示列表支持。这意味着我们可以把图片的光栅化优化留给浏览器的渲染引擎去做。并且，我们还可以应用任意变换，尤其是旋转和缩放，而不必担心像素化。我们将此画布实现称为 DomCanvas。

如果我们无法使用 HTML + CSS 表达图片，我们会用 Canvas。 Canvas 2D 允许我们绘制几乎所有的 Flutter 绘图命令。如果将 Flutter 的 Canvas 与 Web 的 CanvasRenderingContext2D 进行比较，你会发现许多相似之处。在 Canvas 上绘画很高效，因为它不会创建需要随时间维护的可变树节点，如 HTML DOM 或 SVG。

2D Canvas 的一个挑战是浏览器将其表示为位图，即存储 Width x Height 像素的内存缓冲区。因此，缩放 canvas 会导致像素化。如果缩放导致图片大小变化，我们也需要调整 canvas 大小。我们发现分配 canvas 操作相当昂贵，因此方案改成调整它们的大小。最重要的是，当将多个 canvas 合成到同一页面上时，浏览器必须执行栅格合成，这也需要配置。合成栅格与显示列表的方式不同。你可以将多个显示列表绘制到同一个内存缓冲区中。我们调用 Canvas 2D 支持的 canvas 实现 BitmapCanvas。我们正在发掘使位图 canvas 更高效的方法。

为了表达 Flutter 的不透明度，变换，偏移，剪辑矩形和其他图层，我们使用纯 HTML 元素。例如，不透明度层变为 <flt-opacity> 元素，其上具有 opacity CSS 属性，变换图层变为带有 transform CSS 属性的 <flt-transform> 元素，剪辑 rect 变为使用 overflow: hidden 的 <flt-clip-rect >。

完成所有操作后，框架将作为 HTML 元素树呈现在页面上，其中 DomCanvas 和 BitmapCanvas 作为叶节点。举个例子?：

Sample HTML DOM structure of a frame

Flutter Engine 中的等效 Flutter layer tree（称为flow layer）如下所示：

Sample Flutter Engine layer structure

它们的结构非常相似。 最大的区别是，在 Web 上，我们必须根据内容选择不同的图片实现。

HTML + CSS + Canvas 适用于所有现代浏览器。 但是，我们已经在展望未来：

CSS Paint API

CSS Paint 是一个新的 Web API，是 Houdini 的更大组成部分。 Houdini 是多个浏览器厂商合作的项目，旨在向开发者展示 CSS 引擎的某些部分。 特别的是，CSS Paint API 允许开发者在这些元素请求绘制时将自定义图形绘制成 HTML 元素。 例如，你可以将元素背景的绘制分配给自定义 CSS 绘制器。 它与 canvas 非常像，但有以下重要区别：

• 这个绘画不是由核心 JavaScript 独立完成的，而是由一个叫做 paint worklet 的东西完成的。 它有点像 web worker，因为它有自己的内存空间。 它会在 DOM 更改提交之后，在浏览器的绘制阶段执行绘制工作。

• CSS paint 由显示列表支持，而不是位图。 这真是两全其美 - 2D canvas 般的绘画效率和无像素化。

• 目前 CSS paint 不支持绘制文本。

在撰写本文时，Chrome 和 Opera 是唯一在正式版本中支持 CSS Paint 的浏览器。 而其他浏览器正处于发布各自实现的不同阶段。

我们在 Flutter for Web 中对 CSS Paint API 进行了实验性支持，它已经展现出良好的结果，特别是在性能方面。 我们的实现只是将 paint 命令序列化为自定义 CSS 属性。 paint worklet 读取这些命令并执行它们。 我们使用像 <p> 和 <span> 这样普通的 HTML 元素来渲染文本。

我们当前的序列化机制不是特别有效 - 它是一个嵌套列表转换成的 JSON 树 - 但 Houdini 项目的一部分是添加对类型化数组的支持。 当它可用时，我们会将绘制命令编码为类型化数组而不是 JSON 字符串。 类型化数组是可转移的，这意味着它们可以通过引用从主 JavaScript 传递到 paint worklet，而不复制内存。

协同和嵌入

从 Flutter 调用 Dart 库

Flutter Web 应用可以访问当前在 Web 上运行的所有 Dart 库。

从 Flutter 调用 JavaScript 库

Flutter Web 应用完全支持 Dart 的 JS-interop 软件包：package:js和 dart:js。

在 Flutter Web 应用中使用 CSS

目前，Flutter 假定完全控制网页的正确性和性能。 例如，我们只使用遵循某些性能指南的一小部分 CSS，例如 https://csstriggers.com/。 在页面上随意使用 CSS 可能会导致 Flutter 出现不可预期的后果。

在 Flutter for Web 应用中避免使用 CSS 的另一个原因是，在设计时，Flutter 需要在渲染框架时知道所有布局属性。 CSS 充当黑盒。 例如，如果要显示可滚动的窗口 widget 列表，则必须实例化并为所有 widgets 生成 HTML 并应用必要的 CSS 属性（例如，flex-direction row 和 overflow:scroll）。 然后浏览器将所有内容都布局并将其渲染到屏幕上。 应用代码不参与布局过程。

最后，本着保持 Flutter 代码可跨平台移植的精神，我们尽量避免使用 CSS，因此我们可以在 Android 和 iOS 上本机运行相同的代码。

将 Flutter 嵌入现有的 Web 应用中

我们还没有为此添加适当的支持，但我们打算在将来探索。 我们正在考虑的方法是 <iframe> 和 shadow DOM。

在 Flutter 中嵌入非 Flutter 组件

我们还未支持在 Flutter Web 应用中嵌入非 Flutter 组件 - 自定义元素、React 组件、Angular 组件，但我们打算在将来探索。 有可能是使用平台视图将外部内容放入 Flutter Web 应用中。需要考虑的是外部内容可能对应用的性能和正确性产生影响。 因为非 Flutter 组件可能包含任意 CSS，如上所述，它可能会有问题。 需要更多的研究。

可移植性

我们的目标是尽可能多地将框架移植到 Web 上。 但是，这并不意味着任何 Flutter 应用将在 Web 上运行而不更改代码。 Flutter Web 应用仍然是一个 Web 应用; 它在浏览器中被沙箱化，只能执行 Web 浏览器允许的操作。 例如，如果你的 Flutter 应用使用 Web 未实现的本机插件（例如 ARCore），你将无法在 Web 上运行该应用。 同样，也无权限直接访问文件系统或低级网络。

当前状态

我们构建了足够的 Web 引擎来渲染大部分 Flutter Gallery。 我们还未移植 Cupertino widgets，但所有 Material widgets，Material Theming，以及 Shrine 和 Contact Profile 演示应用均已运行在 Web 上。

Flutter running in desktop Chrome 演讲视频

https://www.youtube.com/watch?v=5IrPi2Eo-xM

源代码在哪里？

我们计划很快开源这个项目，并很高兴与开源社区分享。 该项目最初是作为 Google 内部源代码树的一项探索而开始的。 待代码稳定后，我们打算将开发转移到 GitHub，我们有机会将其从内部基础架构中剥离出来。 与此同时，如果您在 github.com/flutter 组织下看到与 Web 相关的 pull 请求，请不要感到惊讶！

结论

希望这篇文章能让你了解我们正在解决的问题，以帮助 Flutter 在 Web 上更好运行。 欢迎表达您的观点和意见。

请继续关注 Google I/O 2019！

英文原文：

https://medium.com/flutter-io/hummingbird-building-flutter-for-the-web-e687c2a023a8

好文推荐：

我想学Flutter，但是我不知道应该如何开始？
Google Flutter团队成员李宇骞 确认出席第13届D2前端技术论坛

“UC国际技术”致力于与你共享高质量的技术文章

欢迎关注我们的公众号、将文章分享给你的好友