Flutter视图基础简介--Widget、Element、RenderObject

　　前言：Flutter官方文档里的一句话：you build your UI out of widgets（使用Flutter开发UI界面时，都是使用Widget），然而，Widget并非咱们真正看到的视图，背后到底是什么？其实Flutter Framework提供了三种视图树，即：Widget  Element  RenderObject,只不过，咱们使用Flutter开发界面时，一般只和widget打交道，就如前文中所展现的Materail风格或者Cupertino（IOS风格）的各类Widget,然而Flutter界面开发是一种响应式编程，而且Widget都是immutable的，那么，真正的渲染，刷新，布局这些问题是谁来处理呢？本文就来了解一下除了Widget，还有哪些基础类在背后支撑Widget的快速轻量渲染；

　　Widget部分:

看下官网对Widget的定义和描述：Describes the configuration for an Element. （为Element提供配置信息），从这一句话，隐隐感受到Widget和Element是紧密关联着的，而且给了Element某些信息，难道是老板和员工的关系？老板给员工发个指令，具体的事情都让员工去作了？咱们再尝试着从官方文档中提取一些详细信息,先来看看到底什么是Widget？

咱们先来看下Widget这个类中都包含哪些属性：

 

 1:KEY key

 2:int hasCode

 3:TYPE runtimeType

 

Widget是用户界面的一部分,而且是不可变的（immutable）。Widget会被inflate到Element,并由Element管理底层渲染树。Widget自己没有可变状态（全部的字段必须是final）。若是想要把可变状态与Widget关联起来，可使用StatefulWidget，StatefulWidget经过使用StatefulWidget.createState方法建立State对象，并将之扩充到Element以及合并到树中；

 

因此，Widget并不会直接管理状态及渲染,而是经过State这个对象来管理状态,下篇文章会主要讲到State这个对象；

 

给定的Widget能够被包含在树中（零次或屡次）。一个给定的Widget能够放置在树中屡次，好比：多个TextWidget。每次将一个Widget放入树中时，它都会被扩充到一个Element中，这也意味着屡次并入树中的Widget将会被屡次扩充进对应的element。

 

   好比在实际界面开发当中，一个UI视图树可能包含有多个TextWidget(Widget可能被使用屡次)，可是这些都叫做TextWidget的widget却被填充（inflate）进一个个独立的Element中；

 

Widget中的Key这个属性控制一个Widget如何替换树中的另外一个Widget。若是两个Widget的runtimeType和key属性相等（==），则新的widget经过更新Element（即经过使用新的Widget调用Element.update）来替换旧的Widget。不然，若是两个Widget的runtimeType和key属性不相等，则旧的Element将从树中被移除，新的Widget将被扩充到一个新的Element中，这个新的Element将被插入树中。

 这里主要涉及到Widget的更新和移除，插入等操做，在执行此操做前，会用Widget的两个属性:runtimeType和key来进行对比判断；

　　Element部分

Flutter建立Element的可见树，相对于Widget来讲，是可变的，一般的Flutter界面开发中，咱们不用直接操做Element,而是由框架层实现内部逻辑；就如一个UI视图树中，可能包含有多个TextWidget(Widget被使用屡次)，可是放在内部视图树的视角，这些TextWidget都是填充到一个个独立的Element中；

一样，咱们先来看一下Element这个类中的属性：

Element property表格

property	Type	Desc	implement
depth	int	树根Element的深度必须大于0	int get depth => _depth;
dirty	bool	若是Element已经被标注成须要重建，返回true	bool get dirty => _dirty;
hashCode	int		@overrideint get hashCode => _cachedHash;
owner	BuildOwner	管理Element生命周期	@overrideBuildOwner get owner => _owner;
renderObject	RenderObject	若是此对象是RenderObjectElement，则渲染对象是树中此位置处的对象。不然，这个getter将沿着树走下去，直到找到一个RenderObjectElement。
size	Size	省略	省略
slot		省略	省略
widget	Widget	这个Element的配置信息	@overrideWidget get widget => _widget;
runtimeType

能够从Element的属性中看到renderObject和widget，说明Element持有这两个类的实例；

再来看看文档中对于Element的介绍：An instantiation of a Widget at a particular location in the tree.  Element是在树中特定位置Widget的实例；

这里进一步描述了Widget与Element之间的关系：Element是Widget的实例,也就是说，Element才是真正干活的员工，执行老板战略部署；咱们接着看文档中的描述：

Widget描述如何配置子树，但因为Widget是不可变的(immutable)，所以可使用相同的Widget同时配置多个子树。Element表示Widget配置树中的特定位置的实例。随着时间的推移，与给定Element关联的Widget可能随时会发生变化，例如，若是父Widget重建并为此位置建立新的Widget。Element构成一棵树。大多数Element都有一个惟一的子Element，可是一些Widget（例如RenderObjectElement的子类）能够有多个子Element。

 

 

Element具备如下生命周期：

• 框架层经过调用即将被用来做为Element的初始化配置信息的Widget的Widget.createElement方法来建立Element; 

• 框架层经过调用mount方法来将新建立的Element添加到给定父级中给定槽点的树上。 mount方法负责将任何Widget扩充到Widget并根据须要调用attachRenderObject，以将任何关联的渲染对象附加到渲染树上。

• 此时，Element被视为“激活的”，并可能出如今屏幕上。
   
• 在某些状况下，父(Element)可能会更改用于配置此Element的Widget，例如由于父Element从新建立了新状态。发生这种状况时，框架层将调用新的Widget的update方法。新Widget将始终具备与旧Widget相同的runtimeType和key属性。若是父Element但愿在树中的此位置更改Widget的runtimeType或key，能够经过unmounting(卸载)此Element并在此位置扩充新Widget来实现。

• 在某些时候，祖先Element可能会决定从树中移除该Element（或中间祖先Element），祖先Element本身经过调用deactivateChild来完成该操做。停用中间祖先将从渲染树中移除该Element的渲染对象，并将此Element添加到owner属性中的非活动元素列表中，从而让框架层调用deactivate方法做用在此Element上。
• 此时，该Element被视为“无效状态”，而且不会出如今屏幕上。一个Element能够保持”非活动"状态，直到当前动画帧结束。在动画帧结束时，任何仍处于非活动状态的Element都将被卸载。
• 若是Element被从新组合到树中（例如，由于它或其祖先之一有一个全局键(global key)被重用），框架层将从owner属性中的非活动Element列表中移除该Element，并调用该Element的activate方法，并从新附加Element的渲染对象到渲染树。 （此时，Element再次被视为“活动状态”并可能出如今屏幕上。）
• 若是Element在当前动画帧的末尾没有被从新组合到树中，则框架层将调用该元素的unmount方法。
• 此时，该元素被视为“已停用”，而且未来不会并入树中。

 

由此咱们可知：Element存放Widget上下文，经过遍历视图树，Element 同时持有 Widget 和 RenderObject；

　　RenderObject部分

官网定义：An object in the render tree.渲染树中的一个对象。从其名字，咱们能够很直观地知道，它就是负责渲染的工做；

RenderObject的属性太多，且该类的细节涉及不少渲染知识，咱们会在后面的系列中再详细说明其工做原理，在此先继续看下官网对其描述： RenderObject类的层次结构是渲染库的核心。

RenderObjects有一个父级，并有一个名为parentData的插槽，其中父级RenderObject能够存储特定于子级的数据，例如子级位置。 RenderObject类也实现了基本的布局和绘制协议。

可是，RenderObject类没有定义子模型（例如，节点是否有零个，一个或多个子节点）。它也没有定义坐标系（例如，子级是否位于笛卡尔坐标系，极坐标系等）或特定的布局协议（例如布局是宽度高度仍是尺寸约束或者父级在子级布置以前仍是以后设置子级的大小和位置等;或者确实是否容许子级读取他们父级的parentData插槽）。 RenderBox子类引入布局系统使用笛卡尔坐标。

编写一个RenderObject子类

在大多数状况下，RenderObject自己的子类化过分，RenderBox将是一个更好的起点。可是，若是渲染对象不想使用笛卡尔坐标系，那么它应该直接从RenderObject继承。这容许它经过使用约束的新子类而不是使用BoxConstraints来定义本身的布局协议，而且可能使用全新的一组对象和值来表示输出的结果而不只仅是一个Size。这种增长的灵活性的代价是没法依赖RenderBox的功能。例如，RenderBox实现了一个内在的尺寸调整协议，它容许您在没有彻底铺设的状况下测量一个子级，以这样的方式，若是该子级改变了尺寸，父级将再次布置（考虑到子级的新尺寸）。这是一个微妙的和容易出错的功能。

编写RenderBox的大多数方面也适用于编写RenderObject，所以推荐先阅读RenderBox的相关讨论。主要区别在于布局和命中测试，由于这些是RenderBox主要专一的方面。

Layout

布局

布局协议从约束的子类开始。有关如何编写Constraints子类的更多信息，请参阅Constraints中的讨论。

performLayout方法应该接受约束并应用它们。布局算法的输出是设置在对象上的字段，用于描述父对象布局的对象几何图形。例如，使用RenderBox的输出是RenderBox.size字段。若是父级指定parentUsesSize为true，则在调用子级布局时，此输出只能由父级读取。 任什么时候候渲染对象上的任何变化都会影响该对象的布局，它应该调用markNeedsLayout。 

Flutter渲染对象树的根是一个RenderView。这个对象有单独的子级，它必须是一个RenderBox。所以，若是你想在渲染树中有一个自定义的RenderObject子类，你有两种选择：你可能须要替换RenderView自己，或者你须要一个RenderBox做为它的子类。 （后者是更常见的状况。）

它会覆盖performLayout方法来建立一个适合您的类的Constraints对象，并将其传递给该子对象的布局方法。

渲染对象的布局应该仅取决于其子布局的输出，而且只有在布局调用中将parentUsesSize设置为true时才是如此。此外，若是设置为true，且要呈现子对象，则父对象必须调用子对象的布局，不然在子对象更改布局输出时不会通知父对象。

能够设置传输附加信息的渲染对象协议。 例如，在RenderBox协议中，您能够查询您的子级的固有尺寸和基线几何。 可是，若是这样作了，那么当父级在最后一个布局阶段使用它时，每当附加信息发生变化时，子级都必须在父级上调用markNeedsLayout。 有关如何实现此操做的示例，请参阅RenderBox.markNeedsLayout方法。 它覆盖了RenderObject.markNeedsLayout，以便若是父节点查询了内部或基准信息，则每当子节点的几何结构发生变化时，它都会被标记为dirty。

 

  转载请注明出处

From crash_coder linguowu linguowu0622@gamil.com