Flutter训练营(零)-浅谈Flutter框架原理及其生态圈-一一网

这是我参与更文挑战的第15天，活动详情查看：更文挑战

面试大厂，跨端技术免不了，今天再次对Flutter框架做深度剖析。

Flutter的锋芒

跨平台高性能的渲染引擎逐渐成为移动端、大前端领域的一个热点，作为其中的明星框架Flutter，经过近几年来的迅速发展，有极大的可能成为下一代跨端终端解决方案。自从2017 年 5 月，谷歌公司发布的了 Alpha 版本的 Flutter；2018 年底 Flutter Live 发布的 1.0 版本；2019年7月发布1.5版本，截止今日（2020年2月）已经发布了v1.14.6 Beta版本。
在Flutter诞生之前，已经有许多跨平台UI框架的方案如Cordova、ReactNative、weex、uni-app、Hippy等，常见的需要处理兼容的终端平台也包括android、ios、web、Iot等，但是在大前端的浪潮下，对于企业和开发者来说开发效率和使用体验都十分重要，传统的做法莫过于分不同的团队开发不同的终端项目，如果还要继续向其他平台，拓展的话，我们需要付出的成本和时间将成倍增长。正因为如此，在这样的背景下，Flutter等跨端框架的兴起，从本质上讲，帮助开发者增加业务代码的复用率，减少因为要适配多个平台带来的工作量，从而降低开发成本、提高开发效率。

纵观已有的跨端方案，可以分为三类：Web 容器、泛 Web 容器、自绘引擎框架。

基于web容器即基于浏览器的跨平台也做得越来越好，自然管线也越来越短，与native的一些技术手段来实现性能上的相互补充。比如Egret、Cocos、Laya这些游戏引擎，它们在跨平台方面的做法多以Typescript编写，在iOS和安卓平台的各种浏览器中轻松的运行HTML5游戏，并在不同平台浏览器里提供近乎一致的用户体验，比如Egret还会提供高效的 JS-C Binding 编译机制，以满足游戏编译为原生格式的需求，不过大多数HTML游戏引擎也属于web容器这个范畴内。web容器框架也有一个明显的致命（在对体验&性能有较高要求的情况下）的缺点，那就是WebView的渲染效率和JavaScript执行性能太差。再加上Android各个系统版本和设备厂商的定制，很难保证所在所有设备上都能提供一致的体验。

泛 Web 容器框架比如ReactNative和Weex，即上层通过面向前端友好的UI，下层通过native的渲染形式，虽然同样使用类HTML+JS的UI构建逻辑，但是最终会生成对应的自定义原生控件，以充分利用原生控件相对于WebView的较高的绘制效率，同时H5与native相互补充来达到更好的用户体验，这也是一种很好的解决方案。缺陷也很明显，随着系统版本变化和API的变化，开发者可能也需要处理不同平台的差异，甚至有些特性只能在部分平台上实现，这样框架的跨平台特性就会大打折扣。

自绘引擎框架这里专指Flutter框架，从底层就承担跨端的任务和渲染方式，从目前来看，从技术的实现和方案的成熟度、产品的性能方面比较，Flutter有很大可能成为下一代主流跨平台框架。

Flutter与其他跨端框架的不同点之一就是自带渲染引擎，Flutter渲染引擎依靠跨平台的Skia图形库来实现，Skia引擎会将使用Dart语言构建的抽象的视图结构数据加工成GPU数据，交由 OpenGL 最终提供给 GPU 渲染，至此完成渲染闭环，因此可以在最大程度上保证一款应用在不同平台、不同设备上的体验一致性。

而开发语言选用的是同时支持 JIT和 AOT的 Dart语言，Dart本身提供了三种运行方式，应对web环境，用Dart2js编译成JavaScript代码，运行在常规浏览器中；使用DartVM直接在命令行中运行Dart代码；AOT方式编译成机器码，例如Flutter App框架。而且Dart 避免了抢占式调度和共享内存，可以在没有锁的情况下进行对象分配和垃圾回收，在性能方面表现相当不错，不仅保证了开发效率，代码性能和用户体验也更卓越。因此，Flutter在各类跨平台移动开发方案中脱颖而出。同时在去年2019的Google IO大会上，备受关注的Fuchsia系统虽然并没有发布，但是宣布了 Flutter除了支持开发 Android 和 iOS 程序之外，现在还支持开发Web程序了，在 I/O 大会上，谷歌发布了 Web 版 Flutter 的首个技术预览版，宣布 Flutter 将为包括 Google Home Hub 在内的 Google Smart Display 平台提供技术支持，并迈出利用 Chrome 操作系统支持桌面级应用的第一步。

很多JS开发者会思考Google Flutter团队至于为啥选择Dart而不是JS，其实Google 公司给出的原因很简单也很直接：Dart 语言开发组就在隔壁，对于 Flutter 需要的一些语言新特性，能够快速在语法层面落地实现；而如果选择了 JavaScript，就必须经过各种委员会（TC39等）和浏览器提供商漫长的决议。

Flutter绘制原理

在计算机系统中，图像的显示需要 CPU、GPU 和显示器一起配合完成：CPU 负责图像数据计算，GPU 负责图像数据渲染，而显示器则负责最终图像显示。

CPU 把计算好的、需要显示的内容交给 GPU，由 GPU 完成渲染后放入帧缓冲区，随后视频控制器根据垂直同步信号（VSync）以每秒 60 次的速度，从帧缓冲区读取帧数据交由显示器完成图像显示。

操作系统在呈现图像时遵循了这种机制，而 Flutter 作为跨平台开发框架也采用了这种底层方案。下面有一张更为详尽的示意图来解释 Flutter 的绘制原理。可以看到，Flutter 关注如何尽可能快地在两个硬件时钟的 VSync 信号之间计算并合成视图数据，然后通过 Skia 交给 GPU 渲染：UI 线程使用 Dart 来构建视图结构数据，这些数据会在 GPU 线程进行图层合成，随后交给 Skia 引擎加工成 GPU 数据，而这些数据会通过 OpenGL 最终提供给 GPU 渲染。

Skia原理

Skia 是一款用由C++ 开发的2D 图像绘制引擎。在2005 年被 Google 公司收购后被广泛应用在 Android和其他等核心产品上，Skia 目前是Android 官方的图像渲染引擎，因此 Flutter Android SDK 无需内嵌 Skia 引擎就可以获得天然的 Skia 支持；而对于 iOS 平台来说，由于 Skia 是跨平台的，因此它作为 Flutter iOS 渲染引擎被嵌入到 Flutter 的 iOS SDK 中，替代了 iOS 闭源的 Core Graphics/Core Animation/Core Text，这也正是 Flutter iOS SDK 打包的 App 包体积比 Android 要大一些的原因。

底层渲染能力统一了，上层开发接口和功能体验也就随即统一了，开发者再也不用操心平台相关的渲染特性了。也就是说，Skia 保证了同一套代码调用在 Android 和 iOS 平台上的渲染效果是完全一致的。

Flutter架构

Framework底层是Flutter引擎，引擎主要负责图形绘制（Skia）、文字排版（libtxt）和提供Dart运行时，引擎全部使用C++实现，Framework层使我们可以用Dart语言调用引擎的强大能力。Flutter 架构采用分层设计，从下到上分为三层，依次为：Embedder、Engine、Framework。

Embedder 是操作系统适配层，实现了渲染 Surface 设置，线程设置，以及平台插件等平台相关特性的适配。从这里我们可以看到，Flutter 平台相关特性并不多，这就使得从框架层面保持跨端一致性的成本相对较低。
Engine 层主要包含 Skia、Dart 和 Text，实现了 Flutter 的渲染引擎、文字排版、事件处理和 Dart 运行时等功能。Skia 和 Text 为上层接口提供了调用底层渲染和排版的能力，Dart 则为 Flutter 提供了运行时调用 Dart 和渲染引擎的能力。而 Engine 层的作用，则是将它们组合起来，从它们生成的数据中实现视图渲染。

Framework 层则是一个用 Dart 实现的 UI SDK，包含了动画、图形绘制和手势识别等功能。为了在绘制控件等固定样式的图形时提供更直观、更方便的接口，Flutter 还基于这些基础能力，根据 Material 和 Cupertino 两种视觉设计风格封装了一套 UI 组件库，开发者可以直接使用这些组件库。

Flutter运行流程

页面中的各界面元素（Widget）以树的形式组织，即控件树。Flutter 通过控件树中的每个控件创建不同类型的渲染对象，组成渲染对象树。在Flutter界面渲染过程分为三个阶段：布局、绘制、合成，布局和绘制在Flutter框架中完成，合成则交由引擎负责。

Flutter 采用深度优先机制遍历渲染对象树，决定渲染对象树中各渲染对象在屏幕上的位置和尺寸。在布局过程中，渲染对象树中的每个渲染对象都会接收父对象的布局约束参数，决定自己的大小，然后父对象按照控件逻辑决定各个子对象的位置，最终完成布局过程。这里只需要注意一点，无论布局还是绘制，都是父子间的遍历关系：父Widget的布局需要依赖子Widget的布局结果；而绘制则反过来（子Widget需要盖在父Widget上），布局是后续遍历，绘制是前序遍历，他们都是深度优先遍历。

Flutter生命周期

可以看到，Flutter中State 的生命周期可以分为 3 个阶段：创建（插入视图树）、更新（在视图树中存在）、销毁（从视图树中移除）。接下来，我们一起看看每一个阶段的具体流程。

第一步创建

State 初始化时会依次执行：构造方法 -> initState -> didChangeDependencies -> build，随后完成页面渲染。构造方法是 State 生命周期的起点，Flutter 会通过调用StatefulWidget.createState() 来创建一个 State。我们可以通过构造方法，来接收父 Widget 传递的初始化 UI 配置数据。这些配置数据，决定了 Widget 最初的呈现效果。
initState，会在 State 对象被插入视图树的时候调用。这个函数在 State 的生命周期中只会被调用一次，所以我们可以在这里做一些初始化工作，比如为状态变量设定默认值。
didChangeDependencies 则用来专门处理 State 对象依赖关系变化，会在 initState() 调用结束后，被 Flutter 调用。
build，作用是构建视图。经过以上步骤，Framework 认为 State 已经准备好了，于是调用 build。我们需要在这个函数中，根据父 Widget 传递过来的初始化配置数据，以及 State 的当前状态，创建一个 Widget 然后返回。

第二步更新

Widget 的状态更新，主要有几个方法触发：setState、didchangeDependencies、didUpdateWidget。

setState：我们最熟悉的方法之一。当状态数据发生变化时，我们总是通过调用这个方法告诉 Flutter：“我这儿的数据变啦，请使用更新后的数据重建 UI！”
didChangeDependencies：State 对象的依赖关系发生变化后，Flutter 会回调这个方法，随后触发组件构建。哪些情况下 State 对象的依赖关系会发生变化呢？典型的场景是，系统语言 Locale 或应用主题改变时，系统会通知 State 执行 didChangeDependencies 回调方法。
didUpdateWidget：当 Widget 的配置发生变化时，比如，父 Widget 触发重建（即父 Widget 的状态发生变化时），热重载时，系统会调用这个函数。一旦这三个方法被调用，Flutter 随后就会销毁老 Widget，并调用 build 方法重建 Widget。