之前，写了一篇《iOS 浅谈GPU及“App渲染流程”》阐述了iOS端App的渲染流程。
其中包括三种渲染方式，分别是：
1.iOS原生渲染：使用原生控件、原生语言编写。
2.大前端渲染（一种是WebView，另一种是JSCore引擎作为虚拟机）。
3.Flutter渲染。
《上篇博客》主要讲解了iOS APP渲染的流程，以及GPU的渲染流水线。
但关于Flutter是如何渲染的？我上篇写的并不是很透彻。
所以本篇将和大家一起谈谈 —— “ Flutter 究竟是如何渲染的？ ”
一、Flutter 的架构
先从Flutter的整体架构说起，共分为三层，又下到上分别为：Embedder层、Engine层、Framework层。
分别对应：
- Embedder层：操作系统底层适配层。
- Engine层：渲染引擎层。
- Framework层：用Dart实现的上层UI SDK。
那么，这三层的职责是什么？究竟分别做了哪些事呢？
从上到下开始，先从我们相对比较熟悉的 Framework 层说起。
1. Framework层：Dart实现的上层UI SDK
实现了：Animation（动画）、Painting（图形绘制）、Gestures（手势操作）等功能，并包装成对应的 api 提供给上层开发者调用。
为了保证Flutter所绘制的控件与原生控件风格类似，Flutter封装了Material（对应Android）、Cupertino（对应iOS）风格的UI组件库，供开发者直接使用。
2. Engine层：Skia渲染 + DartVM 引擎
这层主要包含三块：Skia、Dart、Text。
Skia 是渲染引擎，为 Framework 层提供“底层渲染”能力。
Dart 是 Dart 运行时引擎，为 Framework 层提供运行时调用Dart和渲染能力。
Text 是文字排版，为 Framework 层提供视图排版能力。
3. Embedder层：操作系统适配
对不同平台操作系统的适配，包括一些配置：surface、线程、插件等特性。
由于Flutter相关特性并不多，因此对不同平台操作系统的适配成本很低。
二、Flutter 的 渲染策略
我们都知道，在Flutter中，Everything is widget。
所有 Widget 会组成 Widget Tree 。
界面更新时，会更新 Widget Tree ，
再更新 Element Tree ，最后更新 RenderObjectTree 。
那么，究竟Flutter是怎么更新界面的？又有哪些优化的渲染策略呢？？
分为4个阶段，分别是：
布局阶段 => 绘制阶段 => 合成阶段 => 渲染阶段
（Layout => Paint => Composite => Rasterize）
1. 布局（Layout）
Flutter采用 “深度优先” 机制遍历Widget Tree。
我们都知道，在布局过程中，Widget树中的每个孩子节点都会受到父节点所加的位置约束。（也就是说，父节点决定孩子节点的位置，孩子节点只能决定自己的大小。）
先确定父节点的大小、位置，
再确定孩子节点的位置，
再确定孩子节点的大小。
....一直往下，
直到没有孩子Widget后，返回完成。
PS：深度优先于广度优先的区别：参考博客
为了防止孩子节点的变化，导致整个 Widget Tree 重新布局。
Flutter加入了 “布局边界” 机制（Relayout Boundary）。（划重点，★优化点★）
在某些节点，“自动”或“手动”加上 “布局边界” ，控制边界。
在该布局边界内的任何节点发生重新布局，都不会影响边界外的 Widget Tree的布局。
布局完成后，树上每个节点都确定了“尺寸大小”和“位置”。
2. 绘制（Paint）
刚才，我们确定了树上的控件的“尺寸”与“位置”。
接下来是绘制阶段。
和布局类似，Flutter也是采用 “深度优先” 机制遍历渲染树。
先绘制自身，再绘制子节点。
但是，会出现一些绘制图层覆盖问题。
比如，当节点2需要重绘时，节点2、5、6一起重绘了（其实只要重绘节点2、5）。
为了解决绘制覆盖问题，Flutter采用了也是和布局阶段相似的策略： 重绘边界 机制（Repaint Boundary）。
其实，本质上就是加个新的图层，避免在同一图层重绘产生影响。（划重点，★优化点★）
典型的例子是，ScrollView。
一旦设置好重绘边界，滚动时，只会重绘ScollView中的视图内容，而其他部分不用重新绘制。（划重点，★优化点★）
3. 合成（Composite）
由于绘制出来的渲染树，会有很多层，同步多层渲染会出现性能问题。
因此，Flutter会在渲染前，将多个渲染树图层进行合成。（划重点，★优化点★）
根据多层渲染树的大小、层级、透明度等计算后，
合成为最终“简化版”的渲染树，以提高下一步的渲染效率。
4. 渲染（Rasterize）
将处理过的“简化版”渲染树，交给Skia引擎转换成“二维图像数据”。
然后 Skia 把计算好的图形数据，通过 OpenGL 接口交给 GPU 渲染，走上一篇《iOS 浅谈GPU及“App渲染流程”》中提到的 GPU 工作流水线：
顶点着色器 => 形状装配 => 几何着色器 => 光栅化 => 片段着色器 => 测试与混合。
然后，GPU工作流水线六阶段完成。
最终，展示到我们的终端屏幕上。
当然这只是一个垂直同步信号（VSync）的过程。（按60fps算，一秒需要60个VSync才不会感到卡顿。）
三、Flutter 渲染工作流水线
按60fps算，一秒需要60个VSync才不会感到卡顿。
在流水线的Widget更新，Flutter也有优化的点：
简单来说，就是chind节点能复用就复用。不能复用，就重新绘制。
更新Widget的逻辑如下：
| \ | newWidget == null | newWidget != null |
|---|---|---|
| child == null | 返回null | 返回新的Element |
| child != null | 移除旧的child并返回null | 如果旧child被更新就返回child，否则返回新的Element |
参考与致谢：
1.《Flutter核心技术与实战》（陈航老师）
2. 小德 -- Flutter 技术分享
3.《Flutter从加载到显示》 （圣文前辈）