GSY Flutter Book

主题

大家好，我是郭树煜，掘金 《Flutter 完整开发实战详解》 系列的作者，Github GSY 系列开源项目的维护人员，系列包括 GSYVideoPlayer 、GSYGitGithubApp (Flutter \ ReactNative \ Kotlin \ Weex 四大版本)、GSYFlutterBook 电子书等，系列总 star 数在 25k 左右，目前 Github 中国区粉丝数暂居 67 名，主要负责移动端项目开发，大前端方向，主要涉及领域有 Android、Flutter、React Native、Weex 、小程序等等。

这次分享的主题主要涉及：移动端跨平台开发的发展、Flutter Widget 的实现原理 、 Flutter 的实战技巧 、Flutter Web的现状 四个方面，而整体主题将围绕 Widget 为中心展开。

一、移动端跨平台开发的发展 ​

按照惯例，我们先介绍历史进程，随着用户终端种类的百花齐放，如今跨平台开发已然成为移动领域的热门话题之一，移动端跨平台开发技术的发展，也代表着开发者对于性能、复用、高效上不断的追求。

移动端的跨平台开发主要有三个阶段，这些阶段的代表框架主要有：Cordova 、React Native 、Flutter 等，如下图所示，是移动端的跨平台发展历程：

Cordova ​

Cordova 作为早期跨平台领域应用最广泛的框架，为前端人员所熟知，其主要原理就是：

将 web 代码打包到本地，利用平台的 WebView 进行加载，通过内部约定好的 JS 通讯协议，加载和调用具备平台原生能力的插架。

Cordova 让前端开发人员可以快速的构建移动应用，获取平台入口，对早期 web 上欠缺的如摄像机、本地缓存、文件读写等能力进行快速支持。

早期的移动开发市场除了 Android 和 iOS 之外，还有 WindowPhone、黑莓等，Cordova 简单又实用的理念，使得它成为早期热门的跨平台框架，至今仍在更新的 ionic 框架，也是在其基础上进行了封装发展。

React Native ​

Cordova 虽然实用方便，但是由于 WebView 的性能瓶颈，开发者开始追求更高性能，且具备平台特色的跨平台能力，这时候由 Facebook 开源的 React Native 框架开始引领新潮流。

React Native 让 JS 代码运行在框架内置的 JS 引擎（JavaScriptCore）上，利用 JS 引擎实现了跨平台能力，同时又将 JS 控件，对应解析为平台原生控件进行渲染，从而实现性能的优化与提升。

由于 React 框架的盛行， React Native 也开始成为 React 开发人员，将自身能力拓展到应用开发的最佳选择之一。同时 React Native 也是应用开发人员，接触前端的不错尝试。

后来阿里开源的 Weex 框架设计相似，利用了 V8 引擎实现跨平台，不过使用了 Vue 的设计理念，而 Weex 因为种种原因，最终还是没能大面积推广开来。

Flutter ​

事实上 JS Bridge 同样存在性能等限制，Facebook 也在着力优化这一问题，比如 HermesJS 、底层大规模重构等 ，而 JS -> 平台控件映射，也导致了框架和平台耦合过多，在版本兼容和系统升级等问题上让框架维护越发困难。

这时候谷歌开源了 Flutter ，它另辟蹊径，只要求平台提供一个 Surface 和一个 Canvas ，剩下的 Flutter 说：“你可以躺下了，我们来自己动”。

Flutter 的跨平台思路快速让他成为“新贵”，连跨平台界的老大哥 “JS” 语言都“视而不见”，大胆的选择 Dart 也让 Flutter 在前期的推广中饱受争议。

短短两年，不算 PR ，Flutter 的 issue 已经有近 1.8 万的 closed 和 8000+ open , 这代表了它的热度，也代表着它需要面对的问题和挑战。 不支持 Release 模式下的热更新，也让用户更多徘徊于 React Native 不愿尝试。

不过有一点可以确定的，那就是 Flutter 的版本号上是彻底战胜了 React Naitve 。

总结起来，我们可以看到，移动端跨平台的发展，从单纯的套壳打包，到提供高性能的跨平台控件封装，再到现在的控件与平台脱离的发展。 整个发展历程，就是对 性能、复用、高效 的不断追求。

题外话，什么要学习跨平台？ ​

1、开发成本

我直接学 Java/Kotlin 、Object-C/Swift 、JavaScript/CSS 去写各平台的代码可以吗？

当然可以，这样的性能肯定最有保证，但是跨平台的主要优势在于代码逻辑的复用，减少各平台同一逻辑，因人而异的开发成本。

2、学习机会

一般情况下，各平台开发者容易局限在自己的领域开发，而作为应用开发者，跨平台是接触另一平台或领域的过渡机会。

下面开始今天的主题 Flutter ，Flutter 整体涉及的内容很多，由于篇幅问题，本篇我们的主题整体都围绕一个 Widget 展开。Flutter 作为跨平台 UI 框架，Widget 是其灵魂设定之一。

二、Flutter Widget 的实现原理 ​

Flutter 是 UI 框架，Flutter 内一切皆 Widget ，每个 Widget 状态都代表了一帧，Widget 是不可变的。 那么 Widget 是怎么工作的呢？

如下图可以看到，是一个简单的 Flutter Widget 页面代码，页面包含了一个标题和容易，那在页面 build 时，它是怎么表绘制出来的呢？同时它是如何保证性能？ 而Widget 又是怎么样的一个概念？后面我们将逐步揭晓。

首先看上图代码，其实如图的代码并不是真正的 View 级别代码，它们更像是配置文件。

而要知道 Widget 是如何工作的，这就涉及到 Flutter 的三大金刚： Widget 、 Element 、RenderObject 。 事实上，这三大金刚才能组成了 Flutter Framework 的基础渲染闭环。

如上图所示，当一个 Widget 被“加载“的时候，它并不是马上被绘制出来，而是会对应先创建出它的 Element ，然后通过 Element 将 Widget 的配置信息转化为 RenderObject 实现绘制。

所以，在 Flutter 中大部分时候我们写的是 Widget ，但是 Widget 的角色反而更像是“配置文件” ，真正触发工作的其实是 RenderObject。

小结一下这里的关系就是：

  • Widget 是配置文件。
  • Element 是桥梁和仓库。
  • RenderObject 是解析后的绘制和布局。

对应详细的解释就是：

  • 所以我们写的 Widget，它需要转化为相应的 RenderObject 去工作；
  • Element 持有 Widget 和 RenderObject ，作为两者的桥梁，并保存着一些状态参数，我们在 Flutter 框架中常见到的 BuildContext ，其实就是 Element 的抽象 ；
  • 最后框架会将 Widget 的配置信息，转化到 RenderObject 内，告诉 Canvas 应该在哪个 Rect 内，绘制多大 Size 的数据。

所以 Widget 和我们以前的布局概念不一样，因为 Widget 是不可变的（immutable），且只有一帧，且不是真正工作的对象，每次画面变化，都会导致一些 Widget 重新 build 。

那到这里，我们可能就会关心性能的问题，Flutter 是如何保证性能呢？

1.1、Widget 的轻量级 ​

其实就是回归到了 Widget 的定位，作为“配置文件”，Widget 的变化，是否也会导致 Element 和 RenderObject 也会重新创建？

答案是不一定会，Widget 只是一个 “配置文件” 的作用，是非常轻量级的，它的存在，只是起到对 RenderObject 的数据进行配置的作用。

但是 RenderObject 就不一样了，它涉及到了 layout、paint 等真实 的绘制操作，可以认为是一个真正的 “View” ，如果频繁创建就会导性能出现问题。

所以在 Flutter 中，会有一系列的判断，来处理 Widget 到 RenderObject 转化的性能问题 ，这部分操作通常是在 Element 中进行的 ，例如 updateChild 时，会有如下图所示的判断：

  • 当 element.child.widget == widget.build() 时，就不会触发 update 操作；

  • 在 update 时，canUpdate(element.child.widget, newWidget) 返回 true， Element 才会被更新；（这里代码中的 slot 一般为 Element 对象，有时候会传空）

  • 其他还有利用 isRelayoutBoundary 、 isRepaintBoundary 等参数，来实现局部的更新判断，比如：当执行 markNeedsPaint() 触发绘制时，会通过 isRepaintBoundary 是否为 true ， 往上确定了更新区域，通过 requestVisualUpdate 方法触发更新往下绘制。

通过 isRepaintBoundary 参数， 对应的 RenderObject 可以组成一个 Layer 。

所以这就可以解答一些初学者的疑问，嵌套那么多 Widget ，性能会不会有问题？

这也体现出 Flutter 在布局上和其他框架不同的地方，你写的 Widget 只是配置文件，堆叠嵌套了一堆控件，对最终的 RenderObject 而言，可能只是多几个 Offset 和 Size 计算而已。

结合上面的理解，可以知道 Widget 大部分时候，其实只是轻量级的配置，对于性能问题，你更需要关心的是 Clip 、Overlay 、透明合成等行为，因为它们会需要产生 saveLayer 的操作，因为 saveLayer 会清空GPU绘制的缓存。

最后总结个面试点：

  • 同一个 Widget 可以同时描述多个渲染树中的节点，作为配置文件是可以复用的。 Widget 和 RenderObject 一般情况是一对多的关系。 （ 前提是在 Widget 存在 RenderObject 的情况。）

  • Element 是 Widget 的某个固定实例，与 RenderObject 一一对应。（前提是在 Element 存在 RenderObject 的情况。）

  • RenderObject 内 isRepaintBoundary 标示使得它们组成了一个个 Layer 区域。

当 isRepaintBoundary 为 true 时，该区域就是一个可更新绘制区域，而当这个区域形成时，就会新创建一个 Layer 。 但不是每个 RenderObject 都会有 Layer ， 因为这受 isRepaintBoundary 的影响。

注意，Flutter 中常见的 BuildContext ，其实就是 Element 的抽象，通过 BuildContext ，我们一般情况就可以对应获得 Element ，也就是拿到了“仓库的钥匙” ，通过 context 就可以去获取 Element 内持有的东西，比如前面所说的 RenderObject ，还有后面我们会谈到 State 等。

1.2 Widget 的分类 ​

这里我们将 Widget 分为如下图所示分类：是否存在 State 、是否存在RenderObject 。

其实还可以按照 RenderBox 和 RenderSliver 分类，但是篇幅原因以后再介绍。

1.2.1 是否存在 State ​

Flutter 中我们常用的 Widget 有： StatelessWidget 和 StatefulWidget 。

如下图， StatelessWidget 的代码很简单，因为 Widget 是不可变的，传入的 text 决定了它显示的内容，并且 text 也算是 final 的。

注意图中 DemoPage 有个黄色警告，这是因为我们定义了 int i = 0 不是 final 导致的，在 StatelessWidget 中， 非 final 的变量起始容易产生误解，因为 Widget 本事就是不可变的。

前面我们说过 Widget 都是不可变的，在这个基础上， StatefulWidget 的 State ，帮我们实现了 Widget 的跨帧绘制 ，也就是在每次 Widget 重构时，可以通过 State 重新赋予 Widget 需要的配置信息，而这里的 State 对象，就是存在每个 Element 里的。

同时，前面我们说过，Flutter 内的 BuildContext 其实就是 Element 的抽象，这说明我们可以通过 context 去获取 Element 内的东西，比如 State 、RenderObject 、 Widget 。

 Widget ancestorWidgetOfExactType
 State ancestorStateOfType
 State rootAncestorStateOfType
 RenderObject ancestorRenderObjectOfType

如下图所示，保存在 State 中的 text ，当我们点击按键时，setState 时它被标志为 "变化了" ， 它可以主动发生改变，保存变量，不再只是“只读”状态了。

1.2.2、容器 Widget/渲染 Widget ​

在 Flutter 中还有 容器 Widget 和 渲染Widget 的区别，一般情况下:

  • Text、Slider 、ListTile 等都是属于渲染 Widget ，其内部主要是 RenderObjectElement ，对应有 RenderObject 参数。

  • StatelessWidget / StatefulWidget 等属于容器 Widget ，其内部使用的是 ComponentElement ， ComponentElement 本身是不存在 RenderObject 的。

所以作为容器 Widget， 获取它们的 RenderObject 时，获取到的是 build 后的树结构里，最上面渲染 Widget的 RenderObject 。

如上图所示 findRenderObject 的实现，最终就是获取 renderObject，在遇到 ComponentElement 时，执行的是 element.visitChildren(visit); , 递归直到找到 RenderObjectElement ，再返回它的 renderObject。

获取 RenderObject 在 Flutter 里很重要的，因为获取控件的位置和大小等，都需要通过 RenderObject 获取。

1.3、RenderObject ​

Flutter 中各类 RenderObject 的实现，大多都是颗粒度很细，功能很单一的存在 ：

然而接触过 Flutter 的同学应该知道 Container 这个 Widget ，Container 的功能却不显单一，这是为什么呢？

如下图，因为 Container 其实是容器 Widget ，它只是把其他“单一”的 Widget 做了二次封装，然后通过配置参数来达到 “多功能的效果” 而已。

所以 Flutter 开发中，我们经常会根据功能定义出各类如 Continer、Scaffold 等脚手架模版，实现灵活与复用的界面开发。

回归到 RenderObject ，事实上 RenderObject 还属于比较“低级”的阶段，因为绘制到屏幕上我们还需要坐标体系和布局协议等，所以 大部分 Widget 的 RenderObject 会是子类 RenderBox (RenderSliver 例外) ，因为 RenderObject 本身只实现了基础的 layout 和 paint ，而绘制到屏幕上，我们需要的坐标和大小等，这些内容是在 RenderBox 中开始实现。

RenderSliver 主要是在滚动控件中继承使用。

比如控件被绘制在 x=10,y=20 的位置，然后大小由 parent 对它进行约束显示，RenderBox 继承了 RenderObject，在其基础上实现了 笛卡尔坐标系 和布局协议。

这里我们通过 Offstage 这个 Widget ，看下其 RenderBox 子类的实现逻辑， Offstage 是用于控制 child 是否显示的作用，如下图，可以看到 RenderOffstage 对于 offstage 标志位的内部逻辑：

那么 Flutter 中的布局协议是什么呢？

简单来说就是 child 和 parent 之间的大小应该怎么显示，由谁决定显示区域。 相信从 Android 到接触 Flutter 的同学有这样的疑惑， Flutter 中的 match_parent 和 wrap_content 逻辑需要怎么设置？

就我们从一个简单的代码分析，如下图所示，Row 布局我们没有设置任何大小，它是怎么确定自身大小的呢？

我们翻阅源码，可以发现其实 Flutter 中常用的 Row 、Column 等其实都是 Flex 的子类，只是对 Flex 做了简单默认配置。

那按照我们前面的理解，看一个 Widget 的实现逻辑，就应该看它的 RenderObject ，而在 Flex 布对应的 RenderFlex 中，我们可以看到如下一段代码：

可以看到在布局的时候，RenderFlex 首先要求 constraints != null ，Flex 布局的上层中必须存在约束，不然肯定会报错。

之后，在布局时，Row 布局的 direction 是横向的，所以 maxMainSize 为上层布局的最大宽度，然后根据我们配置的 mainAxisSize 的参数：

  • 当 mainAxisSize 为 max 时，我们 Row 的横向布局就是 maxMainSize ；
  • 当 mainAxisSize 为 min 时，我们 Row 的横向布局就是 allocatedSize ；

前面 maxMainSize 我们知道了是父布局的最大宽度，而 allocatedSize 其实就是 child 的宽度之和。所以结果很明显了：

对于 Row 来说， mainAxisSize 为 max 时就是 match_parent ；mainAxisSize 为 min 时就是 wrap_content 。

而高度 crossSize ，其实是由 math.max(crossSize, _getCrossSize(child)); 决定，也就是 child 中最高的一个作为其高度。

最后小结一个知识点：

布局一般都是由上层往下传递 Constraints ，然后由下往上返回 Size。

那如何直接自定义 RenderObject 布局？

抛开 Flutter 为我们封装的好的，三大金刚 Widget 、Element 、RednerObject 一个不少，当然， Flutter 内置了很多封装帮我们节省代码。

一般情况下自定义 RenderObject 布局：

  • 我们会继承 MultiChildRenderObjectWidget 和 RenderBox 这两个 abstract 类，实现自己的Widget 和 RenderObject 对象；
  • 然后利用 MultiChildRenderObjectElement 关联起它们；
  • 除此之外，还有几个关键的类： ContainerRenderObjectMixin 、 RenderBoxContainerDefaultsMixin 和 ContainerBoxParentData 等可以帮你减少代码量。

总结起来， 对于 Flutter 而言，整个屏幕都是一块画布，我们通过各种 Offset 和 Rect 确定了位置，然后通过 Canvas 绘制上去，目标是整个屏幕区域，整个屏幕就是一帧，每次改变都是重新绘制。

这里没有介绍 RenderSliver 相关，它的输入和输出和 Renderbox 又不大一样，有机会我们后面再详细介绍。

三、Flutter 的实战技巧 ​

3.1、InheritedWidget ​

InheritedWidget 是 Flutter 的灵魂设定之一。

InheritedWidget 共享的是 Widget ，只是这个 Widget 是一个 ProxyWidget ，它自己本身并不绘制什么，但共享这个 Widget 内保存有的数据，从而到了共享状态的目的。

如下图所示，是 Flutter 中常见的 Theme ，其内部就是使用了 _InheritedTheme 这个 InheritedWidget 来实现主题的全局共享的。那么 InheritedWidget 是如何实现全局共享的呢？

其实在 Element 的内部有一个 Map<Type, InheritedElement> _inheritedWidgets; 参数，_inheritedWidgets 一般情况下是空的，只有当父控件是 InheritedWidget 或者本身是 InheritedWidget 时，它才会被初始化，而当父控件是 InheritedWidget 时，这个 Map 会被一级一级往下传递与合并。

所以当我们通过 context 调用 inheritFromWidgetOfExactType 时，就可以通过这个 Map 往上查找，从而找到这个上级的 InheritedWidget 。（毕竟 context is Element）

如我们的 Theme/ThemeData 、Text/DefaultTextStyle、Slider / SliderTheme 等，如下代码所示，我们可以定义全局的 ThemeData 或者局部的 DefaultTextStyle ，从而实现全局的自定义和局部的自定义共享等。

其实，Flutter 中大部分的状态管理控件，其状态共享方法，也是基于 InheritedWidget 去实现的。

3.2、支持原生控件 ​

前面我们说过， Flutter 既然不依赖于原生控件，那么如何集成一些平台已有的控件呢？比如 WebView 和 Map ？

我们这里以 WebView 为例子：

在官方 WebView 控件支持出来之前 ，第三方是直接在 FlutterView 上覆盖了一个新的原生控件，利用 Dart 中的占位控件传递位置和大小。

如下图，在 Flutter 端 push 出一个 设定好位置和大小 的 SingleChildRenderObjectWidget ，从而得到需要显示的大小和位置，将这些信息通过 MethodChannel 传递到原生层，在原生层 addContentView 一个指定大小和位置的 WebView 。

这时候 WebView 和 SingleChildRenderObjectWidget 处于一样的大小和位置，而空白部分则用 FLutter 的 Appbar 显示。

这样看起来就像是在 Flutter 中添加了 WebView ，但实际这脱离了 Flutter 的渲染树，其中一个问题就是，当你跳转 Flutter 其他页面的时候，会被 WebView 挡住；并且打开页面的动画，Appbar 和 WebView 难以保持一致。

后面 官方 WebView 控件支持出来后，这时候官方是利用 PlatformView 的设计，完成了不脱离 Flutter 渲染堆栈，也能集成平台原生控件的功能。

以 Android 为例，Android 上是利用了副屏显示的底层逻辑，使用 VirtualDisplay 类，创建一个虚拟显示器，需要调用 DisplayManager 的 createVirtualDisplay() 方法，将虚拟显示器的内容渲染在一个内存的 Surface 上 ，生成一个唯一的 textureId 。

如下图，之后渲染时将 textureId 传递给 Dart 层，渲染引擎会根据 textureId , 获取到内存里已渲染数据，绘制到 AndroidView 上进行显示。

3.3、错误处理 ​

Flutter 中比较有趣的情况是，在 Dart 中的一些错误，并不会导致应用闪退，而是通过如下的红色堆栈 UI ，错误区域不同，可能是全屏红，也可能局部红，这种状态就和传统 APP 的“崩溃”状态不大一样了。

在开发过程中这样的显示没太大问题，但事实发布线上版本就不合适了，所以我们一般会选择自定义错误显示。

如下图所示，一般我们可以通过如下处理，自定义我们的错误页面，并且收集错误信息。

重写 ErrorWidget 的 builder 方法，然后将信息收集到 Zone 中，返回自己的自定义错误显示，最后在 Zone 内利用 onError 统一处理错误。

ps 图中的 Zone 等概念这里就不展开了，有兴趣的可以去以前的文章详细查看。

四、Flutter Web ​

最后简单说下 Flutter Web ，Flutter 在支持 Web 平台上的优势在于 Flutter UI 与平台的耦合度很低，而 Dart 起初就是为了 Web 而生，一拍即合下 Flutter 支持 Web 并不是什么意外。

但是 Web 平台就绕不过 JS ，在 Web 平台，实际上 Image 控件最后会通过 dart2js 转化为 <img> 标签并通过 src 赋值显示。

同时，多了一个平台就多了需要兼容的，目前 Flutter 的 issue 仍然不少，而 Web 支持虽然已经合并到主项目中，但是在兼容、性能等问题上还需要继续优化，比如 Flutter Web 中 canvas.drawColor(Colors.black, BlendMode.clear); 是会出现运行错误的，因为不支持 BlendMode.clear 。

资源推荐 ​

其他文章 ​

《Flutter完整开发实战详解系列》

《移动端跨平台开发的深度解析》

《全网最全Flutter与React Native深入对比分析》

Released under the MIT License.

Copyright © 2018-present 恋猫de小郭 (CarGuo)

本站访客 -- 人次 · 总访问量 -- 次