纷争再起：Flutter-UI绘制解析

为避免传统的源码讲解方式的枯燥乏味，这一次，我尝试换一种方式，带着你以轻松的心态了解Flutter世界里的UI绘制流程，去探究Widget、Element、RenderObject的秘密。

废话不多说，听故事！《纷争再起》（ps：故事有点长，文末有福利！）

故事

十载干戈，移动端格局渐定，壁垒分明。

北方草原金帐王朝Javascript虽内部纷争不断，但却一直窥视中原大陆，数年来袭扰不断，如今已夺得小片领土(ReactNative)。民间盛传：大前端融合之势已现！

2018年冬，Android边境小城Flutter突然宣布立国！并对两个移动端帝国正式宣战！！短短几日，已攻下数城。

而今天我们要讲的故事，就发生在战火最严重的Android边陲重镇：View城。

某日，Android View 城军事会议：

镇边大将军对手下谋士道：“Flutter 最近对我们发起了数次进攻，已下数城，知己不知彼乃军家大忌！谁能给我说说这个Flutter和我们现在的View到底有什么区别？”

下方谋士面面相窥，不得已终于一个谋士站了出来：“我愿意替将军前去打探一番！”

数日后，谋士：“臣卧底归来，探明Flutter与我们View城的主要区别在于编程范式和视图逻辑单元不同”

将军：“先讲编程范式如何不同？”

Android/Flutter 编程范式

将军，我们Android现在视图开发是命令式的，我们的每一个View都直接听从将军(Developer)的指挥，例如：想要变更界面某个文案，便要指明具体TextView调用他的setText方法命令文字发生变更；

而Flutter的视图开发是声明式的，对方的将军要做的是维护一套数据集,以及设定好一套布军计划（WidgetTree），并且为Widget“绑定”数据集中的某个数据，根据这个数据来渲染。 例如当需要变更文案时，便改变数据集中的数据，然后直接触发WidgetTree的重新渲染。这样Flutter的将军不再需要关注每一个士兵，大部分的精力都用来维护核心数据即可。

如果每一次操作都消耗一点将军的精力值，又刚好有同一个数据“绑定”到了多个View或Widget上。命令式的编程需要做的事情是 命令N个View发生变更，消耗N点精力值；

声明式编程需要做的事情是 变更数据+触发WidgetTree重绘,消耗2点精力值；对精力的解放，也是Flutter可以快速招揽到那么多将军的原因之一。

将军：”但每次数据变更，都会触发WidgetTree的重绘，消耗的资源未免也太大了吧，我现在虽然多消耗些精力，但不会存在大量对象创建的情况“。

Widget、Element、RenderObject概念

谋士：这也是马上要讲的第二点不同。因为WidgetTree会大量的重绘，所以Widget必然是廉价的。

Flutter UI有三大元素：Widget、Element、RenderObject。对应这三者也有三个owner负责管理他们，分别是WidgetOwner(将军&Developer)、BuildOwner、PipelineOwner。

• Widget，Widget 并不是真正的士兵，它只是将军手中的棋子，是一些廉价的纯对象，持有一些渲染需要的配置信息，棋子在不断被替换着。

• RenderObject，RenderObject 是真正和我们作战的士兵，在概念上和我们Android的View一样，渲染引擎会根据RenderObject来进行真正的绘制，它是相对稳定且昂贵的。

• Element，使得不断变化Widget转变为相对稳定的RenderObject的功臣是Element。

WidgetOwner（Developer) 在不断改变着布军计划，然后向BuildOwner发送着一张又一张计划表（WidgetTree），首次的计划表（WidgetTree）会生成一个与之对应的ElementTree，并生成对应的RenderObjectTree。

后续BuildOwner每次收到新的计划表就与上一次的进行对比，在ElementTree上只更新变化的部分，Element有可能仅是update一下，也有可能会被替换，Element被替换之后，与之对应的RenderObject也就被替换了。

可以看到WidgetTree全部被替换了，但ElementTree和RenderObjectTree只替换了变化的部分。

差点忘了讲 PipelineOwner， PipelineOwner类似于Android中的ViewRootImpl,管理着真正需要绘制的View， 最后PipelineOwner会对RenderObjectTree中发生变化节点的进行flush操作，最后交给底层引擎渲染。

将军：“我大概明白了，看来保证声明式编程性能稳定的核心在于这个Element和BuildOwner。但我看这里还有两个问题，RenderObject好像少了一个节点？你画图画错了吗？还有能给我讲下他是怎么把Widget和RenderObject链接起来，以及发生变化时，BuildOwner是如何做到元素Diff的吗？”

Widget、Element、RenderObject之间的关系

首先，每一个Widget家族的老长辈Widget赋予了所有的Widget子类三个关键的能力：保证自身唯一以及定位的Key, 创建Element的 createElement, 和 canUpdate。 canUpdate 的作用后面讲。

Widget子类里还有一批特别优秀强壮的，是在纸面上代表着有渲染能力的RenderObjectWidget,它还有一个创建 RenderObject的 createRenderObject 方法。

从这里你也看出来了，Widget、Element、RenderObject的创建关系并不是线性传递的，Element和RenderObject都是Widget创建出来的，也并不是每一个Widget都有与之对应的RenderObjectWidget。这也解释上面图中RenderObjectTree看起来和前面的WidgetTree缺少了一些节点。

Widget、Element、RenderObject 的第一次创建与关联

讲第一次创建，一定要从第一个被创建出来的士兵说起。我们都知道Android的ViewTree:

-PhoneWindow
    - DecorView
        - TitleView
        - ContentView
复制代码

已经预先有这么多View了，相比Android的ViewTree，Flutter的WidgetTree则要简单的多，只有最底层的root widget。

- RenderObjectToWidgetAdapter<RenderBox>
    - MyApp (自定义)
    - MyMaterialApp （自定义）
复制代码