Flutter(八)--Flutter渲染逻辑+源码解读

Flutter渲染逻辑+源码浅显解读

前言

flutter渲染引擎-flutter.framework，而真正的渲染工作是由skia来做的
由于Flutter中几乎所有对象都是Widget，那么现在抛出两个问题：

我们在屏幕上看到的就是以Widget为依据渲染的吗？
我们开发中创建的每一个Widget都会被渲染到屏幕上吗？

带着这三个问题，开始这篇文章，阅读大概需要8-10分钟。

Flutter渲染逻辑

三种树

这是Flutter中三棵树：Widget tree、Element Tree、Render Tree，他们之间的关系从图中也很容易看出来，问题是Flutter是通过什么方式来建立他们之间的关系呢，这个就是需要我们来探索的问题。

u=686962278,1728905797&fm=15&gp=0.jpg

在我的理解中这三棵树其实都是一种类似树的数据结构，并不是真的有这样的树存在内存，只是通过这种方式表述更加容易理解和表述。
其中：

Widget Tree是用于做数据、逻辑、功能的存储。就像是原型图，比较基础也更加轻量级。加上flutter团队对Widget做了优化，不用担心整个Widget树频繁创建、销毁所带来的性能问题；
Render Tree中的RenderObject主要负责layout、paint等复杂操作，是真正用于处理渲染操作的。相比于Widget更加"重"，创建和销毁的成本比较大。
Element Tree中的Element主要负责进行协调，持有Widget并创建持有RenderObject。同时决定是否将RenderObject实例attach到Render Tree上，并决定是否进行Update；

通过对三种树关系的探索，从而回答之前的问题一，其实参与渲染是以Render Tree为依据，而不是WidgetTree；

Widget

Widget包含三种：StatelessWidget、StatefulWidget、RenderObjectWidget
通过源码来看看这三种Widget中做了什么。


abstract class StatelessWidget extends Widget {
...
StatefulElement createElement() => StatefulElement(this);
Widget build(BuildContext context);
}

abstract class StatefulWidget extends Widget {
...
StatefulElement createElement() => StatefulElement(this);
@protected
State createState();
 }
abstract class State<T extends StatefulWidget> ... {
...
Widget build(BuildContext context);
//还有一些和生命周期有关方法的列如：setState、initState，都可以自行查看实现
}

//常见的Row、Colum、Stack都是继承自它
abstract class RenderObjectWidget extends Widget {
...
RenderObjectElement createElement();
RenderObject createRenderObject(Element);
}

从三种widget中都发现了createElement，通过查找发现createElement是Flutter在widget创建之后隐式调用的，通过该方法创建Element并加入Element树，所有的Widget都会创建对应的element。
build只有在StatelessWidget中出现了，这也是为什么在平时的开发中我们只有在StatelessWidget这个Widget中会重写build，而StatefulWidget是在对应的State中，而其他Widget都只有child、children属性。
createRenderObjectFlutter就是通过这个方法将Element添加到RenderTree中。更加关键的是只有在RenderObjectWidget中才出现了这个方法，从而得出一个结论只有RenderObjectWidget才会被渲染，而其他两种Widget只负责通过build()来确定RenderObjectWidget的结构。

通过源码的阅读从而回答之前的问题二并不是所有的widget都会被渲染的屏幕上，只有RenderObjectWidget的子类才会参与渲染。但这也不是完整的答案，在RenderObject会继续补存。

Element

Element对标Widget也有三种：StatelessElement、StatefulElement、RenderObjectElement
通过源码来看看这三种Element中做了什么,当然这只是一部分。

class StatelessElement extends ComponentElement {
...
Widget build() => widget.build(this);
  }

class StatefulElement extends ComponentElement {
...
//构造方法
StatefulElement(StatefulWidget widget) 
    : _state = widget.createState(),super(widget) {
        _state._element = this;
        _state._widget = widget;
    }
   
Widget build() => _state.build(this);
....
  }

//他们的父类
abstract class ComponentElement extends Element {
void mount(Element parent, dynamic newSlot) {
    ...
    _firstBuild();
  }

void _firstBuild() {
    rebuild();  
  }

//rebuild是在父类的Element中实现的，在本类中并没有重写
void rebuild() {
...
performRebuild();
  }

//最重要的一个方法
void performRebuild() {
...
built = build();
  }
}

可以看到StatelessElement,StatefulElement中都有build方法，都会调用到widget中的build，这也就是我们平时写页面逻辑的地方，其实是在element中被调用的。
element中持有widget，并且在buidl方法中将自己(element)传了出去；
在StatefulElement的构造方法中看到了熟悉的createState，创建并持有了State，并将widget赋值给State。我们为什么可以在State中使用widget；
ComponentElement中有一个mount方法,这个方法类似Widget中的createElement都是Flutter自行调用，我们只需知道Element创建弯沉过后就会调用这个方法，并在一系列嵌套后调用到Element中的build方法，从而Widget树进行创建；
所以我认为Widget树和Element树并没有创建的先后顺序，是交替完成的。所以说单个不可渲染Widget的创建是先Widget->Element->子Widget；

abstract class RenderObjectElement extends Element {
void mount(Element parent, dynamic newSlot) {
    ...
    _renderObject = widget.createRenderObject(this);
    _dirty = false;
  }
}

RenderObjectElement没有build方法，只有mount；
在mount中调用的createRenderObject创建了RenderObject，同时也创建了Render tree；
顺便解释一下dirty，被标记为dirty=true，就是需要更新的，反之；

Element作为中间者，负责了Widget的build调用，和RenderObject的创建。并在刷新流程中起到非常重要的作用

RenderObject

RenderObject 作为一个抽象类。每个节点需要实现它才能进行实际渲染。扩展 RenderOject 的两个最重要的类是RenderBox 和 RenderSliver。这两个类分别是应用了 Box 协议和 Sliver 协议这两种布局协议的所有渲染对象的父类，其还扩展了数十个和其他几个处理特定场景的类，并实现了渲染过程的细节，如 RenderShiftedBox 和 RenderStack 等等。

其实在对RenderObject的了解后发现，只有出现在屏幕中的元素才会被添加到Render Tree中，移出屏幕就立马会被销毁。所以问题二的完整答案是：1，必须是RenderObjectWidget的子类，而且在屏幕中显示的widget才会被渲染

后序

通过对源码的阅读来进一步了解，三棵树之间的关系、以及一个widget是如何从创建到最后的渲染的。以及窥探到一些这样设计的’妙‘，比如elementTree的中间者模式，尤其是在页面更新时体现的更加明显。

下一篇就是我对Flutter中的页面更新逻辑的一些自己的理解。

Flutter(八)--Flutter渲染逻辑+源码解读

Flutter(八)--Flutter渲染逻辑+源码解读

Flutter渲染逻辑+源码浅显解读

前言

Flutter渲染逻辑

三种树

通过对三种树关系的探索，从而回答之前的问题一，其实参与渲染是以Render Tree为依据，而不是WidgetTree；

Widget

通过源码的阅读从而回答之前的问题二并不是所有的widget都会被渲染的屏幕上，只有RenderObjectWidget的子类才会参与渲染。但这也不是完整的答案，在RenderObject会继续补存。

Element

Element作为中间者，负责了Widget的build调用，和RenderObject的创建。并在刷新流程中起到非常重要的作用

RenderObject

其实在对RenderObject的了解后发现，只有出现在屏幕中的元素才会被添加到Render Tree中，移出屏幕就立马会被销毁。所以问题二的完整答案是：1，必须是RenderObjectWidget的子类，而且在屏幕中显示的widget才会被渲染

后序

传送门:

Flutter-汇总