- StatefulElement
Widget build() => _state.build(this);
- ProxyElement
Widget build() => widget.child;
对于StatelessElement和StatefulElement就是调用我们开发中直接接触到的
Widget build(BuildContext context);
对于这三个类,其实都是为了获得一个widget.然后这个拿这个widet去调用Elemnt中的updateChild方法 而这个updateChild方法,就是framework.dart的最重要的方法了,贯穿整个Element树的构建和更新流程. updateChild方法的定义如下
Element updateChild(Element child, Widget newWidget, dynamic newSlot) {
if (newWidget == null) {
//1 移除Element
if (child != null) deactivateChild(child);
return null;
}
Element newChild;
if (child != null) {
//2 更新Element
…
if (hasSameSuperclass && child.widget == newWidget) {
//2.1 有相同的widget
if (child.slot != newSlot)
updateSlotForChild(child, newSlot); //如果插口位置不一致,则更新插口位置
newChild = child;
} else if (hasSameSuperclass &&
Widget.canUpdate(child.widget, newWidget)) {
//2.2 widget不是同一个,但是canUpdate不是返回yes,重用elemnt,更新element的widget
if (child.slot != newSlot) updateSlotForChild(child, newSlot);
child.update(newWidget);
…
newChild = child;
} else {
//2.3 element和widget都不是同一个,在将element变为deactivate并增加一个新的element
deactivateChild(child);
…
newChild = inflateWidget(newWidget, newSlot);
}
} else {
//3 创建或是从GloabalKey中重用一个Element
//根据newwidget的值判断是否需要返回一个新的element
newChild = inflateWidget(newWidget, newSlot);
}
…
return newChild;
}
因为这里设计到了很多widget树更新的逻辑,我们在讲到更新流程的时候再回过头来去说这个方法。当我们首次构建的时候,我们创建了widget,但是还没创建Element,所以此时widget不为null,child为null。这时候会直接走到inflateWidget(newWidget, newSlot);这个方法里面。inflateWidget的定义如下
Element inflateWidget(Widget newWidget, dynamic newSlot) {
…
final Key key = newWidget.key;
if (key is GlobalKey) {
final Element newChild = _retakeInactiveElement(key, newWidget);
if (newChild != null) {
//如果存在globalkey而且已经纳入到 inactive elements中,则拿出来重用,否则创建新的
…
newChild._activateWithParent(this, newSlot);
final Element updatedChild = updateChild(newChild, newWidget, newSlot);
assert(newChild == updatedChild);
return updatedChild;
}
}
final Element newChild = newWidget.createElement(); //创建新的element
…
newChild.mount(this, newSlot); //对新的element进行mount
…
return newChild;
}
这个方法中,首先处理GloabalKey相关的逻辑(第3小节会说到),然后调用widget的createElement()方法去创建一个Elemnt。创建完Element方法后,会对该Element调用mount()方法。
这时候又会调用Elemnt的mount方法,但是注意,这个是子Element的mount方法。当调用这个子Element的mount()方法的时候,又会重新走一遍绑定流程,直到没有子节点为止。调用流程如下
mount -> firstBuild -> rebuild - > performRebuild -> updateChild -> inflateWidget -> mount
如果看到这里,觉得调用流程有点复杂,可以先不用记住流程,后面会给出构建的流程图
RenderObjctElemnt的mount方法
在RenderObjctElemnt中,mount方法的定义如下
@override
void mount(Element parent, dynamic newSlot) {
super.mount(parent, newSlot);
…
attachRenderObject(newSlot); //绑定render object
_dirty = false;
}
这里调用了RenderObjctElemnt的attachRenderObject方法为该RenderObjctElemnt去绑定一个RenderObjcet,RenderObjctElemnt 中 attachRenderObject的实现如下
@override
void attachRenderObject(dynamic newSlot) {
_slot = newSlot;
_ancestorRenderObjectElement = _findAncestorRenderObjectElement();
_ancestorRenderObjectElement?.insertChildRenderObject(
renderObject, newSlot);
final ParentDataElement parentDataElement =
_findAncestorParentDataElement();
if (parentDataElement != null) _updateParentData(parentDataElement.widget);
}
attachRenderObject方法中,先调用_findAncestorRenderObjectElement找到是RenderObjctElement类型的Element.赋值给_ancestorRenderObjectElement。再调用insertChildRenderObject把对应的RenderObjct插入到_ancestorRenderObjectElement的子RenderObelct列表中。这样做是因为RenderObjct树不是和Element树一一对应的。RenderObjct是会渲染屏幕上的节点,不是所有的Element都会渲染在屏幕上。所以为了保证renderObjct树正确的构建,需要调用_findAncestorRenderObjectElement找到有RenderObjct的上级Element节点,忽略与渲染无关的节点,找到父RenderObject。
可以看出RenderObjctElemnt中的mount方法中只调用了attachRenderObject去绑定由widget产生的RenderObjct,并没有对子Element节点的处理。那么对于RenderObjctElemnt,是怎么构建子树的呢?
RenderObjctElemnt是一个渲染的节点。但不是每一个渲染的节点都会有子节点,所以对于子节点的构建,交由具体有子节点的子类去实现。RenderObjctElemnt有两个子类是有子节点的,分别是有一个子节点的SingleChildRenderObjectElement和多个子节点的MultiChildRenderObjectElement。
SingleChildRenderObjectElement的mount方法如下(其中的child就是创建widget中的child)
void mount(Element parent, dynamic newSlot) {
super.mount(parent, newSlot);
_child = updateChild(_child, widget.child, null);
}
MultiChildRenderObjectElement的mount方法如下(其中的children就是创建widget中的childrenl列表)
void mount(Element parent, dynamic newSlot) {
super.mount(parent, newSlot);
_children = List(widget.children.length);
Element previousChild;
for (int i = 0; i < _children.length; i += 1) {
final Element newChild = inflateWidget(
widget.children[i], IndexedSlot(i, previousChild));
_children[i] = newChild;
previousChild = newChild;
}
}
从上面的代码可知其中的updateChild,会调用inflateWidget方法。所以对于带有的子节点的RederObjctElement的子类,构建过程中都会去调用inflateWidget方法。inflateWidget方法中会产生一个子节点,再调用子节点的mount方法。流程如下图
这里总结一下树的构建流程
当调用runAPP()方法开始,调用根Widge的createElement方法,得到一个根Element,调用根Elemnt的mount方法,然后不断的往下去创建子Widget,再调用子Widget的createElement方法创建子Elemnt,再调用子Elemnt的mount方法,一直往下创建节点,直到没有子节点的叶子节点为止。如下图
三 树的更新过程
更新流程
当构建完树后,是如何对树进行增加,删除,修改树中节点的操作呢?前面提到过,BuildOwner是负责处理构建,更新树的管理者。它与树的角色大概如图所示。
更新树的流程大概如下:BuildOwner负责一个调度的作用,当我们操作树的时候,通知BuildOwner需要更新。当框架知道需要更新的时候,会调用BuildOwner的buildScope方法。buildScope方法中会对需要更新的Elemnt进行更新。
现在我们先从最熟悉的方法,也就是State的setState方法开始讲起。setState方法定义如下
void setState(VoidCallback fn) {
…
final dynamic result = fn() as dynamic;
…
_element.markNeedsBuild();
}
可以看出,这个方法先是我们调用了传入的方法,执行方法后,就调用了State中的_element的markNeedsBuild()方法,markNeedsBuild()方法是将一个Element标记为需要更新。方法的定义如下
void markNeedsBuild() {
…
if (!_active) return;
…
_dirty = true;
owner.scheduleBuildFor(this); //加入build owner的rebuild计划
}
markNeedsBuild方法首先判断一个Elemnt是否是_active,如果不是,则不做任何处理,因为一个非活跃的状态不会显示在界面上,所以不需做处理。然后将其_dirty值设置为true,标记这个Element 需要更新。然后调用BuildOwner的scheduleBuildFor方法,并传入需要更新的Element。BuildOwner的scheduleBuildFor定义如下
void scheduleBuildFor(Element element) {
…
if (!_scheduledFlushDirtyElements && onBuildScheduled != null) {
_scheduledFlushDirtyElements = true;
onBuildScheduled(); // 通知Engine 在下一帧需要做更新操作;
}
_dirtyElements.add(element);
…
}
方法里的_scheduledFlushDirtyElements表明是否是在更新过程中,可以看到,这里先判断_scheduledFlushDirtyElements是否为true,就是不在更新过程中,则调用onBuildScheduled通知框架需要进行更新树。 然后将刚才传入的element添加到BuildOwner的_dirtyElements中。这个_dirtyElements是一个列表,存储着需要所有更新的Elemnt。
当框架收到需要更新树的信息后,就会调用BuildOwner的buildScope()方法,前面在构建过程中提到过这个buildScope方法,但是没有细说,在这里我们看一下buildScope方法的实现
void buildScope(Element context, [VoidCallback callback]) {
if (callback == null && _dirtyElements.isEmpty) return;
…
//deng 问题 这个timeline是什么
Timeline.startSync(‘Build’,
arguments: timelineArgumentsIndicatingLandmarkEvent);
try {
_scheduledFlushDirtyElements = true;
if (callback != null) {
…
try {
callback(); //callback先执行
} finally {
…
}
}
…
try {
_dirtyElements[index].rebuild(); //进行rebuild
} catch (e, stack) {
…
}
…
}
…
} finally {
…
_dirtyElements.clear();
…
}
…
}
buildScope()方法中先是执行了callback方法,对于首次构建的流程,这个callback方法就是调用根Elemnt的mount方法进行构建。
然后这个方法主要就做了一件事,就是从_dirtyElements列表中取出每一个需要更新的Element,然后对Elemnt调用rebuild()方法,再清空_dirtyElements列表,标志着这一轮更新完成。
从前面的构建流程可知, rebuild方法会调用performRebuild方法。performRebuild对于不同的Element子类,有着不一样的额外的实现。
首先对于RenderObjctElemnt类,只会调用updateRenderObject去更新RenderObjct对象,不会涉及任何的子节点的更新.那这里就有疑问了,该怎么对有子节点的RenderObjctElemnt进行更新子树呢?这里先留一下小疑问,等讲完ComponetElemnt然后再解答。
对于ComponetElemnt及其子类,调用performRebuild方法会调用updateChild方法。前面在构建过程中,就贴出了performRebuild和updateChild这两个方法,这里就不再重复去贴代码。在这里重点说一下updateChild这个方法
updateChild
updateChild中传入了(Element child, Widget newWidget, dynamic newSlot) 三个参数。child代表的是该ComponetElemnt的子节点,newWidget是子节点对应的Widget,newSlot是子节点的位置信息
在执行updateChild过程中根据传入的参数做了以下的一些处理。
-
如果new widget为空,但是element不为空(也就是原有的widget被删除了)。首先deactivateChild(child),如果child不为空,则解绑child的renderobjce,并添加到build owner中的_inactiveElements列表中,并返回函数。deactivateChild(child会把child添加到BuildOwner_inactiveElements中)
-
如果new widget非空,child不为空
-
2.1 如果传入的widget和原来的widget是同一个,但是slot不一样,则调用updateSlotForChild更新位置
-
2.2 如果不是同一个widget,则判断widget的canUpdate是否是true,如果是true的话(代表element的可以重用),先判断slot是否和原来的slot相等,不相等,则调用updateSlotForChild更新位置。然后调用elemnt的update方法进行更新。
-
2.3 如果不符合上面2.1,2.2的情况(则代表element不可重用,newWidget需要用例外一个新的element),则调用deactivateChild(child)方法,并调用inflateWidget(newWidget, newSlot)产生新的child
- newWidget为空,child为空。则表明该Wiget还不存在Element,则调用inflateWidget去创建一个新的Element。
上面的1,2,3分别代表着删除,修改,增加 Elemnt子节点的三种情况。当对一个element(ComponetElemnt及其子类的实例)调用markNeedsBuild方法的时候,会调用到updateChild方法去更新该element。
对于步骤1,当一个Widget不再使用的时候,会调用deactivateChild方法,这个方法会把对应的Element放入到BuildlOwner的_inactiveElements列表中,如果Element被再次使用到(如使用了GlobalKey),就会从_inactiveElements列表中移除。如果没有被再次用到,再一次更新树的时候就会被销毁。
对于步骤2.2,elemnt的update方法只会简单的设置widget。具体的实现由各个子类实现。这一步可以buid方法可以沿下更新树
如StatelessElement会调用rebuild方法,RenderObjectElemnt会更新renderobjct。像SingleChildRenderObject和MutilChildRederObjectElemnt等有子elemnt的还会调用updateChild方法(MutilChildRederObjectElemnt 是调用updateChildren,但是updateChildren是对updateChild的一个包装,对传入的列表逐个调用updateChild)更新子elemnt,
更新流程下图所示
在说RenderObjctElemnt的时候,留了一个小疑问:如何更新有子节点的RenderObjcetElement的子树。
其实在开发过程中,我们是不会直接调用RenderObjcetElement的markNeedsBuild方法的。就拿Stack这个Wigdet来说。Stack继承自MultiChildRenderObjectWidget。MultiChildRenderObjectWidget对应的是MutilChildRederObjectElemnt。
但会发现,Stack是没有setState方法的,也就说不会直接调用markNeedsBuild方法。Stack一般是被ComponetElemnt及其子类对应的Widget(如StatefuleWidget)所包裹着。当对应的Widget更新的时候,就会调用markNeedsBuild方法。从而进入updateChild更新子树,从而完成对子树的更新。
假设你要在更新流程中,保留Stack,只删除Stack里的一个子节点,会走到updateChild的步骤2.2中,调用Stack对应的MutilChildRederObjectElemnt的update()方法。utilChildRederObjectElemnt的update()如下
@override
void update(MultiChildRenderObjectWidget newWidget) {
super.update(newWidget);
…
_children = updateChildren(_children, widget.children,
forgottenChildren: _forgottenChildren);
_forgottenChildren.clear();
}
}
可以看到,update方法调用了updateChildren方法,updateChildren这个方法会遍历子节点,对每一个子节点调用updateChild方法,从而完成子树的更新。
综合上面的流程可以看出,标记一个Element需要更新,其实就是调用markNeedsRebuild方法标记Element需要更新并通知到Flutter框架需要更细。当框架更新该Element的时候,会调用updateChildren方法向下递归更新子树,直到叶子节点为止。
三GlobalKey,ParentData,依赖更新等机制的实现原理
GloabalKey
在开发的过程中,在一个Widget可以通过GloabalKey去找到另外一个Widget,这是怎样实现的呢?
当我们调用GlobalKey的currentWidget去获取一个Widget的时候,调用的是下面的方法
Widget get currentWidget => _currentElement?.widget;
_currentElement方法定义如下
Element get _currentElement => _registry[this];
可这个_registry[this]是什么呢?
看一下GlobalKey的定义,会发现GlobalKey中这个类有一个类属性
static final Map<GlobalKey, Element> _registry = <GlobalKey, Element>{};
这个_registry以GlobalKey为键,以Element为值。他的作用是存储Widget的key是GloabalKey的Element
前面介绍到,在绑定Element的时候会调用mount方法 mount方法中还会判断对应的widget的key是否是GlobalKey,如果是GlobakKey,就会调用
key._register(this);
_register是GlobakKey中的一个方法
void _register(Element element) {
_registry[this] = element;
}
这个方法将GloabakKey和Element作为健值对存放在GlobalKey类中的_registry中。这样就完成一个GlobalKey和Element的绑定
_registry[this] 就是从GlobakKey类中的_registry中取出这一个GlobakKey对应的Element
这样看来,当我们调用GlobalKey的currentWidget去获取一个Widget的时候,实际上就是从GlobalKey这个类中的_registry取出Element,并返回Element的Widget。
只要GlobalKey对应的Element还存在,就可以通过获取到对应的Widget。
流程大概如下
ParentData
在RenderObjct树中,父RenerObjct负责子RenderObjct布局, 每一个RenderObjct中都有一个parentData属性,用于向父RenderObject提供布局信息,父RenderObject根据子RenderObjct的parentData进行布局。但是这个parentData是什么时候提供的呢?
其实RenderObecjElement通常是不会直接拥有一个RenderObecjElement类型的子节点,通常两个RenderObecjElement中间都会有一个ParentDataElemnt类型的中间节点,这是因为需要给子RenderObecjElement设置parentData的属性,而RenderObjct的parentData信息就是在这里设置的。
就拿Stack为列,Stack通常都不会直接嵌套一个的Elemment是RenderObjctElementl类型的子Widget。通常都会嵌套一个Position。而Positio继承自ParentDataWidget,而ParentDataWidget对应的Element就是ParentDataElemnt类型的。而用Stack和Position构建的Widget树对应的Element树如下图所示。
如果上图的Widget D对应的Element是RenderObjctElement类型的,按照树的构建流程,在绑定这个Widget的Element的时候,会调用attachRenderObject方法,attachRenderObject方法的实现在前面已经贴出来了。可以看到,除了构建RenderObjct树外,还做了寻找上级ParentData的操作 如下
final ParentDataElement parentDataElement =
_findAncestorParentDataElement();
if (parentDataElement != null) _updateParentData(parentDataElement.widget);
如果存在是ParentDataElement类型的上级Element,则调用_updateParentData方法并传入parentDataElement的widget. _updateParentData的方法如下
void _updateParentData(ParentDataWidget parentDataWidget) {
bool applyParentData = true;
…
if (applyParentData) parentDataWidget.applyParentData(renderObject);
}
这个_updateParentData中就做了一个事情,就是调用传入的Elementd的widget的applyParentData方法,并传入Elementd的renderObjct.
回到刚才的例子,在绑定Widget D的Element D得时候,Element D 会向上查找,得到ParentDataElement B,并通过ParentDataElement B找到对应的Positon B,调用Position B的applyParentData方法。Position中的applyParentData方法如下
@override
void applyParentData(RenderObject renderObject) {
assert(renderObject.parentData is StackParentData);
final StackParentData parentData =
renderObject.parentData as StackParentData;
bool needsLayout = false;
if (parentData.left != left) {
parentData.left = left;
needsLayout = true;
}
if (parentData.top != top) {
parentData.top = top;
needsLayout = true;
}
if (parentData.right != right) {
parentData.right = right;
needsLayout = true;
}
if (parentData.bottom != bottom) {
parentData.bottom = bottom;
needsLayout = true;
}
if (parentData.width != width) {
parentData.width = width;
needsLayout = true;
}
if (parentData.height != height) {
parentData.height = height;
needsLayout = true;
}
if (needsLayout) {
final AbstractNode targetParent = renderObject.parent;
if (targetParent is RenderObject) targetParent.markNeedsLayout();
}
}
这个方法中,首先会取到renderObject(在这个例子中就是 Element D的renderObjcet)的parentData,并根据Positon B的情况去更新parentData的数据和判断是否需要更新,如果需要更新,则调用renderObject的父节点,并告诉父节点需要重新布局,从而更新这个RenderObjct
流程如下
找到上级的ParentDataElement -> 调用ParentDataElement的widget的applyParentData方法 ->设置parentData ->通知父RenderObjct更新
Element树和RenderObjct树是紧密相连的,随着Element树的构建和更新,RenderObjct树也会随着改变。
这里虽然是只拿了Stack,Position做例子,但是RenderObjct树中的节点基本上都是依靠这一套机制实现布局信息的传递的。
依赖和更新
开发过程中,可以通过Theme.of(context)这样的方法去获取主题相关的设置。当我们使用了主题信息,而主题信息改变的时候,我们的Widget也会重新执行build方法。其实这个也是依赖于Element树的构建和更新去实现的。可以参照InheritedElement的实现。 这个点留个坑位,分析Provider的时候一起分析。
总结
从上面Element的构建和更新的流程中,我们可以看到其实都是通过递归调用,一级一级的往下去对节点进行修改。Flutter代码中会以嵌套的方式去写Widget,可以保证每个Widget都是最新的,从而确保Element树是正确的。
其实有一个地方需要注意的是,每一个Element和RenderParent都会有一个parent属性,用于指明父节点是谁,但是Widget是没有这个父节点的,也就是说Widget是没有上下级关系的。所以严格一点来说,Widget树并不是一个真正的节点树,只是说每一个Element都会对应一个Widget,而且从开发过程看,Widget看起来像是一颗树而已。
Element是核心,整个构建和更新流程是由BuildOwner的buildScope方法触发,由Element实现,Element协调Widget树和RenderObjct树的构建和更新。
结束语
在这一篇文章中主要讲述了Widget,Elemnet,RenderObjct树的构建和更新流程,至于RenderObjct的实现描述不多。 其实RenderObjct中如何去布局,绘制,layer生成,合成对于理解Flutter的界面构建也是一个很重要的部分,篇幅也较大,留给下一篇文章再去讲述
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
![](https://i-blog.csdnimg.cn/blog_migrate/6b3b34e4be65d78ffb29b9aa524742b4.jpeg)
总结
本文讲解了我对Android开发现状的一些看法,也许有些人会觉得我的观点不对,但我认为没有绝对的对与错,一切交给时间去证明吧!愿与各位坚守的同胞们互相学习,共同进步!
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门即可获取!
外链图片转存中…(img-jNxzwmvU-1712302897036)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
![](https://i-blog.csdnimg.cn/blog_migrate/6b3b34e4be65d78ffb29b9aa524742b4.jpeg)
总结
本文讲解了我对Android开发现状的一些看法,也许有些人会觉得我的观点不对,但我认为没有绝对的对与错,一切交给时间去证明吧!愿与各位坚守的同胞们互相学习,共同进步!