Flutter(八)--Flutter渲染逻辑+源码解读
Flutter渲染逻辑+源码浅显解读
前言
flutter渲染引擎-flutter.framework,而真正的渲染工作是由skia来做的
由于Flutter中几乎所有对象都是Widget,那么现在抛出两个问题:
- 我们在屏幕上看到的就是以Widget为依据渲染的吗?
- 我们开发中创建的每一个Widget都会被渲染到屏幕上吗?
带着这三个问题,开始这篇文章,阅读大概需要8-10分钟。
Flutter渲染逻辑
三种树
这是Flutter中三棵树:
u=686962278,1728905797&fm=15&gp=0.jpgWidget tree
、Element Tree
、Render Tree
,他们之间的关系从图中也很容易看出来,问题是Flutter是通过什么方式来建立他们之间的关系呢,这个就是需要我们来探索的问题。
在我的理解中这三棵树其实都是一种类似树
的数据结构,并不是真的有这样的树存在内存,只是通过这种方式表述更加容易理解和表述。
其中:
-
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属性。 -
createRenderObject
Flutter就是通过这个方法将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中的页面更新逻辑的一些自己的理解。