Turbulence in the Big Front-End Era: Let you understand the most comprehensive Flutter Web

Flutter Web 稳定版本发布至今也有一年多了，经过这一年多的发展，今天就让我们来看看作为大前端时代的乱流，Flutter Web 究竟有什么不同之处，本篇分享主要内容是目前 Flutter 下少有较为全面的 Web 内容。

This article comes from my offline technology sharing in "T Technology Salon-Challenges and Opportunities in the Front-End Era (Shenzhen Field)".

1. Origin and realization

说起 Flutter 的起源就很有意思，大家都知道早期 Flutter 最先支持的平台是 Android 和 iOS ，至今最核心的维护平台依然是 Android 和 iOS ，但是事实上 Flutter 其实起源于前端团队。

Flutter came from the front-end Chrome team. At first, the founder and entire team of Flutter were almost all from the Web. In a related interview with Eric, the person in charge of Flutter, Eric said that Flutter came from an experiment within Chrome. After they removed some messy Web specifications, the performance of some internal benchmark tests was actually improved by 20 times, so Google started establishing a project internally, so Flutter appeared.

另外前端的同学应该知道， Dart 起初也是为了 Web 而生，事实上在 Dart 诞生至今也有 10 年了，所以可以说 Flutter 其实充满了 Web 的基因。

但是作为从 Web 里诞生的框架，和 React Native/ Weex 不同的是，前者是先有了 Web 下的 React 和 Vue 实现之后才有的客户端支持，而对于 Flutter 则是反过来，先有客户端实现之后才支持 Web 平台，这里其实可以和 Weex 做个简单对照。

As a cross-platform framework that once shone, Weex also supports three platforms: Android, iOS and Web. On Android and iOS, Weex and React Native are not much different. On the Web, Weex has a reduced version of Vue support. Due to differences in APIs and platforms, Weex's support experience on the Web has not been very good:

Because Weex needs to rely on platform controls for rendering, a Text control needs to take into account the logic of native platform interfaces on Android, iOS and the Web, resulting in various compatibility issues caused by coupling.

The implementation of Flutter is even more special. After implementing an independent rendering engine through Skia, the controls on Android and iOS are almost platform independent, so the controls on Flutter can achieve independent and consistent rendering effects on different platforms.

But returning to the Web is a little special. First of all, the Web platform is completely html/js/css, and the Web platform needs to take into account the different environments of PC and Mobile at the same time. This makes Flutter Web the "most alternative and wonderful" of all Flutter platforms.

First of all, Flutter Web shares the same framework as other Flutter platforms. In theory, most control implementations are universal. Of course, if you want to talk about the most incompatible API object, it must be Canvas. This is actually related to the special implementation of Flutter Web. We will talk about this later.

而由于 Web 的特殊场景，Flutter Web 在“几经周折”之后落地了两种不同的渲染逻辑：html 和 canvaskit ，它们的不同之余在于：

html

• 好处：html 的实现更轻量级，渲染实现基本依赖于 Web 平台的各种 HTMLElement ，特别是 Flutter Web 下定义的各种 <flt-*> 实现，可以说它更贴近现在的 Web 环境，所以有时候我们也称呼它为 DomCanvas ，当然随着 Flutter Web 的发展这个称呼也发了一些变化，后续我们会详细讲到这个。

• 问题：html 的问题也在于太过于贴近 Web 平台，这就和 Weex 一样，贴近平台也就是耦合于平台，事实上 DomCanvas 实现理念其实和 Flutter 并不贴切，也导致了 Flutter Web 的一些渲染效果在 html 模式下存在兼容问题，特别是 Canvas 的 API 。

canvaskit

• Benefit: The implementation of canvaskit can be said to be closer to the Flutter concept, because it is actually the implementation logic of Skia + WebAssembly, which can be more consistent with the implementation of other platforms and has better performance, such as smoother rendering of scrolling lists.

• Problem: Obviously, using the wasm file brought by WebAssembly will cause the size to increase a lot. In web scenarios, loading speed is actually very important. In this regard, there is very little room for wasm optimization, and WebAssembly is relatively poor in compatibility. In addition, problems such as skia also need to bring its own font library are quite troublesome.

默认情况下 Flutter Web 在打包渲染时会把 html 和 canvaskit 都打包进去，然后在 PC 端使用 canvaskit 模式，在 mobile 端使用 html 模式 ，当然你也可以在打包时通过 flutter build web --web-renderer html --release 之类的配置强行指定渲染模式。

Since we have talked about the packaging and construction of Flutter Web here, let us first introduce Flutter Web in depth from the perspective of building packaging.

2. Construction and optimization

• • Although Flutter Web shares a framework with other platforms, it has its own special engine implementation at the dart level **, and this implementation is a special set of code independent of the framework.

所以在 Flutter Web 打包时，会把默认的 /flutter/bin/cache/lib/_engine 变成了 flutter/bin/cache/flutter_web_sdk/lib/_engine 的相关实现，这是因为 Flutter Web 在 framework 之下的 engine 需要一套特殊的 API。

The build on the right side of the figure below is the packaging path for the specified web, compared with the default on the left.

As shown in the figure below, you can see that there will be different implementations such as html and canvaskit in the web sdk, and there will even be a special text directory, because support for text on the web is a very complex issue.

那到这里我们知道了在 _engine 层面，Flutter Web 有着自己一套独立的实现，那构建之后的产物是什么样的情况呢？

The following figure shows a simple open source example project of GSY. After deployment to the server, you can see that by default, when no processing is done, canvaskit will be used for rendering after opening it on the PC side. The main results are:

• 2.3 MB 的 main.dart.js ；
• 2.8 MB 的 canvaskit.wasm ；
• 1.5 MB 的 MaterialIcons-Regular.otf ；
• 284 kB 的 CupertinoIcons.ttf ；

It can be seen that these files occupy most of the volume of Flutter Web compiled products, and their size is indeed unacceptable, because the code volume of the example project is not large and the structure is not complex, so such a volume must be very important. Impact loading speed.

所以我们首先考虑在 html 和 canvaskit 两种渲染模式中先选定一种，出于实用性考虑，结合前面的对比情况，选用 html 渲染模式在兼容性和可优化上会更友好，所以这里优化的第一步就是先指定 html 模式作为渲染引擎。

start optimizing

首先可以看到 CupertinoIcons.ttf 这个矢量图标文件，虽然默认创建项目时会通过 cupertino_icons 被添加到项目里，但是由于我们不需要使用，所以可以在 yaml 文件里去除。

之后通过运行 flutter build web --release --web-renderer html 后，可以看到使用 html 模式加载后的产物很干净，而需要优化的体积现在主要在 main.dart.js 和 MaterialIcons-Regular.otf 上。

虽然在项目中我们会使用到 MaterialIcons 的一些矢量图标，但是每次加载都要全量加载一个 1.5 MB 的字体库文件显然并不符合逻辑，所以在 Flutter 里官方提供了 --tree-shake-icons 的命令帮助我们优化这部分的内容。

但是不幸的是，如下图所示，在当前的 2.10 版本下该配置运行会有 bug ，而不幸中的万幸是，在原生平台的编译中 shake-icons 行为是可以正常执行。

所以我们可以先运行 flutter build apk ，然后通过如下命令，将 Android 上已经 shake-icons 的 MaterialIcons-Regular.otf 资源复制到已经编译好的 web/ 目录下。

cp -r ./build/app/intermediates/flutter/release/flutter_assets/ ./build/web/assets

再次打包后可以看到，经过优化后 MaterialIcons-Regular.otf 资源如今只剩下 3.2 kB ，那接下来就是考虑针对 2.2 MB 的 main.dart.js 进行优化处理。

要优化 main.dart.js ，我们就要讲到 Flutter 里的 deferred-components ， 在 Flutter 里可以通过把控件定义为 “deferred component” 来实现控件的懒加载，而这个行为在 Flutter Web 上被编译之后就会变成多个 *part.js 文本，原理上就是对 main.dart.js 进行拆包。

For example, first we define an ordinary Flutter control and implement it as a normal control.

import 'package:flutter/widgets.dart';
class DeferredBox extends StatelessWidget {
  DeferredBox() {}
  @override
  Widget build(BuildContext context) {
    return Container(
      height: 30,
      width: 30,
      color: Colors.blue,
    );
  }
}

在需要的地方 import 对应控件然后添加 deferred as box 关键字，之后在适当时机通过 box.loadLibrary() 加载控件，最后通过 box.DeferredBox() 渲染。

import 'box.dart' deferred as box;
class MainPage extends StatefulWidget {
  @override
  _MainPageState createState() => _MainPageState();
}
class _MainPageState extends State<MainPage> {
  @override
  void initState() {
    super.initState();
  }
  @override
  Widget build(BuildContext context) {
    return FutureBuilder<void>(
      future: box.loadLibrary(),
      builder: (BuildContext context, AsyncSnapshot<void> snapshot) {
        if (snapshot.connectionState == ConnectionState.done) {
          if (snapshot.hasError) {
            return Text('Error: ${snapshot.error}');
          }
          return box.DeferredBox();
        }
        return CircularProgressIndicator();
      },
    );
  }
}

当然，这里还需要额外在 yaml 文件里添加 deferred-components 来制定对应的 libraries 路径。

deferred-components:
  - name: crane
    libraries:
      - package:gsy_flutter_demo/widget/box.dart

Returning to the GSY example project above, through relatively extreme subcontracting implementation, each page in the GSY example is turned into an independent lazy loading page, which is then loaded and displayed when the page jumps. After final packaging and deployment, the following figure shows:

可以看到拆分之后 main.dart.js 从 2.2 MB 变成了 1.6 MB ，而其他内容通过 deferred components 变成了各个 part.js 的独立文件，并且只在点击时才动态下载对应的 part.js 文件，但是此时的 main.dart.js 依旧并不小，而官方提供的能力上已经没有太多优化的余地。

关于 deferred-components 会遇到的问题，可以参考 《一个编译问题带你了解 Flutter Web 的打包构建和分包实现》

在这里可以通过前端的 source-map-explorer 工具去分析这个文件，首先在编译时要添加 --source-maps 命令，这样在打包时会生成 main.dart.js 的 source map 文件，然后就执行 source-map-explorer main.dart.js --no-border-checks 生成对应的分析图：

这里只展示能够被 mapped 的部分，可以看到 700k 几乎就是 Flutter Web 整个 framewok + engine + vm 的大小，而这部分内容其实可以优化的空间并不大，尽管会有一些如 kIsWeb 的冗余代码，但是其实可以调整的内容并不多，大概有 36 处可以调整和删减的地方，实质上打包时 Flutter Web 也都有相应的优化压缩处理，所以这部分收益并不高。

In addition, as shown in the following figure, the code differences between the two different web renderer are built. You can see that the engine code structures of html and canvaskit are still very different after being built separately.

If you default to auto mode when compiling, you will see that html and canvaskit code will be packaged, so the relative main.dart.js will also increase.

那还有什么可以优化的地方吗？还是有的，通过外部手段，例如通过在部署时开启 gzip 或者 brotli 压缩，如下图所示 ，开始 gzip 后大概可以让 main.dart.js 下降到 400k 左右 。

In addition, there is also a loading effect added to index.html to show the waiting loading process, for example:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>gsy_flutter_demo</title>
    <style>
      .loading {
        display: flex;
        justify-content: center;
        align-items: center;
        margin: 0;
        position: absolute;
        top: 50%;
        left: 50%;
        -ms-transform: translate(-50%, -50%);
        transform: translate(-50%, -50%);
      }

      .loader {
        border: 16px solid #f3f3f3;
        border-radius: 50%;
        border: 15px solid;
        border-top: 16px solid blue;
        border-right: 16px solid white;
        border-bottom: 16px solid blue;
        border-left: 16px solid white;
        width: 120px;
        height: 120px;
        -webkit-animation: spin 2s linear infinite;
        animation: spin 2s linear infinite;
      }

      @-webkit-keyframes spin {
        0% {
          -webkit-transform: rotate(0deg);
        }
        100% {
          -webkit-transform: rotate(360deg);
        }
      }

      @keyframes spin {
        0% {
          transform: rotate(0deg);
        }
        100% {
          transform: rotate(360deg);
        }
      }
    </style>
  </head>
  <body>
    <div class="loading">
      <div class="loader"></div>
    </div>
    <script src="main.dart.js" type="application/javascript"></script>
  </body>
</html>

So basically these are today's optimizations about product volume on Flutter Web, which can be summarized as follows:

• Remove useless icon references;
• 使用 tree-shake-icons 优化引用矢量图库；
• 通过 deferred-components 实现懒加载分包；
• 开启 gzip 等压缩算法压缩 main.dart.js ；

3. Rendering

讲完构建，最后我们聊聊渲染，Flutter Web 的渲染在 Flutter 里是十分特殊，前面我们说过它自带了两种渲染模式，而我们知道 Flutter 的设计理念里，所有的控件都是通过 Engine 绘制出来，如果这时候你去 framework 里看 Canvas 的实现，就会发现它其实继承的是 NativeFieldWrapperClass1 ：

NativeFieldWrapperClass1 也就是它的逻辑是由不同平台的 Engine 区分实现，其中编译后的 Flutter Web 上的 Canvas 代码应该是继承如下所示的结构：

可以看到在 Flutter Web 的 Canvas 里会根据逻辑判断是使用 CanvasKitCanvas 还是 SurfaceCanvas ，而相对于直接使用 skia 的 CanvasKitCanvas ，更贴近 Web 平台的 SurfaceCanvas 在实现的耦合复杂度上会更高。

首先如下图所示是 Flutter Web 里 Canvas 的大致结构，而接下来我们要聊的主要也是集中在 SurfaceCanvas 上，为什么 SurfaceCanvas 层级会这么复杂，它们又是怎么分配绘制，接下来就让深入揭秘它们的规则。

先看例子，如下图所示，可以看到在 html 渲染模式下， Flutter Web 是有一大堆自定义的 <flt-*> 标签实现渲染，并且在一个长列表中，标签会被控制在一个合适的数量，在滚动时动进行动态切换渲染。

如果这时候我们放慢去看细节，如下动图所示，可以看到当 item 处于不可见时 <flt-picture> 里其实并没有内容，而当 Item 可见之后，<flt-picture> 下会有 <canvas> 标签把文字绘制出来。

**看到一个重点没有？在这里的文本为什么是由 <canvas> 标签绘制而不是 <p> 标签之类的呢？**这就是我们重点要讲的 SurfaceCanvas 渲染逻辑。

在 Flutter Web 的 SurfaceCanvas 里，文本绘制一般都会是以这样的情况出现，基本都是从 picture 开始进入绘制流程：

那么在对应的 picture.dart 的代码实现里可以看到，如下关键代码所示，当 hasArbitraryPaint 为 true 时就会进入到 BitmapCanvas 的逻辑，不然就会使用 DomCanvas 。

void applyPaint(EngineCanvas? oldCanvas) {
  if (picture.recordingCanvas!.renderStrategy.hasArbitraryPaint) {
    _applyBitmapPaint(oldCanvas);
  } else {
    _applyDomPaint(oldCanvas);
  }
}

那么这里有两个问题：BitmapCanvas 和 DomCanvas 的区别是什么？hasArbitraryPaint 的判断逻辑是什么？

1、首先 BitmapCanvas 和 DomCanvas 的最大的区别就是：

• DomCanvas 会通过创建标签来实现绘制，比如文本利用 p + span 标签进行渲染；
• BitmapCanvas 会考虑优先使用 canvas 渲染，如果场景需要再使用标签来实现绘制；

2、在 web sdk 里 hasArbitraryPaint 参数默认是 false ，但是在需要执行以下这些行为时就会被设置为 true ，而这些调用上可以看出，其实大部分时候的绘制逻辑是会先进入到 BitmapCanvas 里。

回到前面的文本问题上，在 Flutter 的文本绘制一般都是通过 drawParagraph 实现，所以理论上只要有文本存在，就会进入到 BitmapCanvas 的绘制流程，那么目前看来这个结论符合上面 Item 里文本是使用 canvas 绘制的预期。

那 Flutter 里对于文本，在 BitmapCanvas 又是何时使用canvas 何时使用 p+span 标签呢？

我们先看如下代码，运行后效果如下图所示，可以看到此时的文本是直接使用 canvas 渲染的，这个结果符合我们目前的预期。

Scaffold(
  body: Container(
    alignment: Alignment.center,
    child: Center(
      child: Container(
        child: Text(    "v333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333",
        ),
      ),
    ),
  ),
)

接下来给这段代码加上一个红色背景，运行后可以看到，此时的文本变成了 p+span 标签，并且红色的背景是通过 draw-rect 标签实现，层级里并没有 canvas ，这又是为什么呢？

Scaffold(
  body: Container(
    alignment: Alignment.center,
    child: Center(
      child: Container(
        decoration: BoxDecoration(
          color: Colors.red,
        ),
        child: Text( "v333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333",
        ),
      ),
    ),
  ),
)

这里就需要先讲到 BitmapCanvas 的 drawRect 实现，如下关键代码所示，在 drawRect 时，如果在满足 _useDomForRenderingFillAndStroke 这个函数条件的情况下，就会 x 通过 buildDrawRectElement的方式实现渲染，也就是使用 draw-rect 标签而不是 canvas ，所以我们需要先分析这个函数的判断逻辑。

@override
void drawRect(ui.Rect rect, SurfacePaintData paint) {
  if (_useDomForRenderingFillAndStroke(paint)) {
    final html.HtmlElement element = buildDrawRectElement(
        rect, paint, 'draw-rect', _canvasPool.currentTransform);
    _drawElement(
        element,
        ui.Offset(
            math.min(rect.left, rect.right), math.min(rect.top, rect.bottom)),
        paint);
  } else {
    setUpPaint(paint, rect);
    _canvasPool.drawRect(rect, paint.style);
    tearDownPaint();
  }
}

如下代码所示，可以看到这个函数有很多的判断条件，而得到 true 的条件就是满足其中三大条件之一即可，下述表格里大致描述了每个条件的所代表的意义。

  bool _useDomForRenderingFillAndStroke(SurfacePaintData paint) =>
      _renderStrategy.isInsideSvgFilterTree ||
      (_preserveImageData == false && _contains3dTransform) ||
      ((_childOverdraw ||
              _renderStrategy.hasImageElements ||
              _renderStrategy.hasParagraphs) &&
          _canvasPool.isEmpty &&
          paint.maskFilter == null &&
          paint.shader == null);

大概流程也如图所示，前面绘制红色背景时并没有添加什么特殊配置，所以会进入到 _drawElement 的逻辑，可以看到针对不同的渲染场景，BitmapCanvas 会采取不一样的绘制逻辑，那为什么前面多了红色背景就会导致文本也变成标签呢？

这是因为在 BitmapCanvas 如果有使用标签构建，也就是 _drawElement 的时候，就会执行一个 _closeCurrentCanvas 函数，该函数会把 _childOverdraw 设置为 true ，并且清空 _canvasPool 里的 canvas 。

所以我们看 drawParagraph 的实现，如下所示代码，可以看到由于 _childOverdraw 是 true 时， 文本会采用 Element 来绘制文本。

@override
void drawParagraph(EngineParagraph paragraph, ui.Offset offset) {
  ····
  if (paragraph.drawOnCanvas && _childOverdraw == false &&
      !_renderStrategy.isInsideSvgFilterTree) {
    paragraph.paint(this, offset);
    return;
  }
  ····
  final html.Element paragraphElement =
      drawParagraphElement(paragraph, offset);

  ····
}

而在 BitmapCanvas 里，有三个操作会触发 _childOverdraw = true 和 _canvasPool Empty ：

• _drawElement
• drawImage/drawImageRect
• drawParagraph

So to summarize first, combined with the previous flowchart, we can simply think that: ** Without maskFilter (shadow) and shader (gradient), as long as the above three situations are triggered, label drawing will be used **.

• • Does it feel a little messy? *

不怕，先接着继续看新的例子，在原本红色背景实现的基础上，这里给 Container 增加了 shadow 用于配置阴影，运行之后可以看到，不管是背景色或者文本又都变成了 canvas 渲染的情况。

Scaffold(
      body: Container(
        alignment: Alignment.center,
        child: Center(
          child: Container(
            decoration: BoxDecoration(
              color: Colors.red,
              boxShadow: [
                BoxShadow(
                    color: Colors.black54,
                    blurRadius: 4.0,
                    offset: Offset(2, 2))
              ],
            ),
            child: Text(
              "v333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333",
            ),
          ),
        ),
      ),
    )

结合前面的流程看这是符合预期，因为此时带有 boxShadow 参数，该参数会在绘制时通过 toPaint 方法转化为 maskFilter ，所以在 maskFilter != null 的情况下，流程不会进入到 Element 的判断，所以使用 canvas 。

继续前面的例子，如果这时候我们再加一个 ColorFiltered 控件，前面表格说过，有 ShaderMask 或者 ColorFilter 的时候，sInsideSvgFilterTree 参数就会是 true ，这时候渲染就会直接进入使用 Element 绘制而无视其他条件如 BoxShadow ，从运行结果上看也是如此。

Scaffold(
      body: Container(
        alignment: Alignment.center,
        child: Center(
          child: ColorFiltered(
            colorFilter: ColorFilter.mode(Colors.yellow, BlendMode.hue),
            child:Container(
              decoration: BoxDecoration(
                color: Colors.red,
                boxShadow: [
                  BoxShadow(
                      color: Colors.black54,
                      blurRadius: 4.0,
                      offset: Offset(2, 2))
                ],
              ),
              child: Text(
                "v333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333",
              ),
            ),
          ),
        ),
      ),
    )

可以看到此时变成了两个 draw-rect 和 p 标签的绘制，为什么会有这样的逻辑，因为一些浏览器，例如 iOS 设备上的 Safari， 它不会把 svg filter 等信息传递给 canvas ，如果继续使用 canvas 就会如 shader mask 等无法正常渲染，详细可见 ：#27600 。

继续这个例子，如果此时不加 ColorFiltered ，而是给 Container 添加一个 transform ，运行后可以看到还是 draw-rect 和 p 标签的实现，因为此时的 transform 是属于 TransformKind.complex 的状态，会导致 _contains3dTransform = true ， 从而进入 Element 的逻辑。

Scaffold(
  body: Container(
    alignment: Alignment.center,
    child: Center(
      child: Container(
          transform: Matrix4.identity()..setEntry(3, 2, 0.001) ..rotateX(100)..rotateY(100),
          decoration: BoxDecoration(
            color: Colors.red,
            boxShadow: [
              BoxShadow(
                  color: Colors.black54,
                  blurRadius: 4.0,
                  offset: Offset(2, 2))
            ],
          ),
          child: Text(
            "v333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333",
          ),
        ),
    ),
  ),
)

最后再来一个例子，这里回归到只有红色背景和阴影的情况，在之前它运行后是使用 canvas 标签来渲染文本，因为它的 maskFilter != null，但是这时候我们给 Text 配置上 TextDecoratoin ，运行之后可以看到背景颜色依然是 canvas ，但是文本又变成了 p 标签的实现。

 Scaffold(
      body: Container(
        alignment: Alignment.center,
        child: Center(
          child: Container(
            decoration: BoxDecoration(
              color: Colors.red,
              boxShadow: [
                BoxShadow(
                  color: Colors.black54,
                  blurRadius: 4.0,
                  offset: Offset(2, 2))
              ],
            ),
            child: Text(
              "v333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333",
              style: TextStyle(decoration: TextDecoration.lineThrough),
            ),
          ),
        ),
      ),
    );

这是因为前面说过 drawParagraph ， 在这个函数里有另外一个判断条件 _drawOnCanvas ， 在 Flutter Web 绘制文本时，当文本具备不为 none 的 TextDecoration 或者 fontFeatures 时，_drawOnCanvas 就会被设置为 fasle ，从而变成使用 p 标签渲染的情况。

这也很好理解，例如 fontFeatures 是影响字形选择的参数，如下图所示，这些行为在 Web 上用 Canvas 绘制相对会麻烦很多，关于 fontFeatures 可以参考 《Flutter 上字体的另类玩法：FontFeature》

那前面讲了那么多例子都是 BitmapCanvas ， 那 Domcanvas 什么时候会用到呢？

还记得前面列举的方法吗，需要进入 _applyDomPaint 就需要 hasArbitraryPaint == false ，换言之就是没有文本，然后 drawRect 的时候没有 shader（ radient） 等就可以了。

依然是前面的例子，绘制一个带有阴影的红色方框，但是此时把文本内容去掉，运行后可以看到不是 canvas 而是 draw-rect 标签，因为虽然此时 maskFilter != null （有 shadow），但是因为没有文本或者 shader（ gradient） ，所以单纯普通的 drawRect 并不会触发 hasArbitraryPaint == true， 所以会直接使用 Domcanvas 绘制，完全脱离了 canvas 的渲染。

Scaffold(
  body: Container(
    alignment: Alignment.center,
    child: Center(
      child: Container(
          height: 50,
          decoration: BoxDecoration(
            color: Colors.red,
            boxShadow: [
              BoxShadow(
                  color: Colors.black54,
                  blurRadius: 4.0,
                  offset: Offset(2, 2))
            ],
          ),
        ),
    ),
  ),
)

所以最后总结一下：首先除了下图所示之外的情况，大部分时候 Flutter Web 绘制都会进入到 BitmapCanvas。

结合前面介绍的例子，进入到 BitmapCanvas 之后的流程可以总结：

• Element will be used if ShaderMask or ColorFilter exists;
• 一般情况忽略 _preserveImageData ，有复杂矩阵变换时也是直接使用 Element ，因为复杂矩阵变换 canvas 支持并不好；
• _childOverdraw 经常和 _canvasPool.isEmpty 一起达成条件，一般有 picture 上有 _drawElement 之后就会调用 _closeCurrentCanvas 设置 _childOverdraw = true 并且清空 _canvasPool；
• Combined with the state of the third condition above, if there is no maskFilter or shader, Element will be used to render the UI;

最后针对文本，在 drawParagraph 时还有特殊处理，关于 _childOverdraw 和 !isInsideSvgFilterTree 相关前面解释过了，新增条件是在有 TextDecoration 或者 FontFeatures 时，也会触发文本绘制变为 Element ，也就是 p + span 标签的形式。

4. Finally

虽然本次介绍的东西不少 ，但是 Flutter Web 在 html 渲染模式下的知识点远不止这些，而由小窥大，以 drawRect 和文本为切入点去了解 SurfaceCanvas 就是很不错的开始。

另外可以看到，在 Flutter Web 里有很多的自定义的 <flt-*> 标签，这些标签都是通过如 html.Element.tag('flt-canvas'); 等方式创建，它们和 Flutter 里的对应关系如下图片所示，如果感兴趣可以在 chrome 的 source 里对应的 dart_sdk.js 查看具体实现。

Author: Love Cat de Xiao Guo

Link: https://www.example.com

Source: Rare Earth Nuggets

Copyright belongs to the author. For commercial reprints, please contact the author to obtain authorization, and for non-commercial reprints, please indicate the source.