Flutter中的布局绘制流程简析（一）

时间  2019-11-07
标签 flutter 布局 绘制 流程 繁體版
原文   原文链接

开始

Flutter对比前端流行的框架，除了构建控件树和控件状态管理等，还多了布局和绘制的流程，布局和绘制以往都是前端开发可望而不可及的都被封锁在浏览器渲染引擎的实现里面，而咱们只能经过文档或者作一些demo去深刻，就像盲人摸象，不少时候都是只知其一不知其二。相对而言，Flutter把这个黑盒打开了，意味着咱们能够作更加深刻的优化，开发效率也能成倍提升。
接下来就去深刻去了解，尽量把这个过程完整展示给你们。前端

入口

界面的布局和绘制在每一帧都在发生着，甚至界面没有变化，它也会存在；能够想象每一帧里面，引擎都像流水线的同样重复着几个过程：build（构建控件树），layout（布局）, paint（绘制）和 composite（合成），周而复始。那么驱动整个流水线的入口在哪里呢？
直接来到WidgetBinding.drawFrame方法：node

void drawFrame() {
    ...
    try {
      if (renderViewElement != null)
        buildOwner.buildScope(renderViewElement);
      super.drawFrame();
      buildOwner.finalizeTree();
    } finally {
     ...
    }
    ...
  }

这里renderViewElement就是Root了，在第一帧的时候，控件树尚未构建，固然也不存在renderViewElement了；而接下来buildOwner这个对象是干吗的呢？算法

BuilderOwner

先看一下从哪里开始会用到builderOwner的方法：
clipboard.png浏览器

能够看到咱们常用setState方法就与BuilderOwner紧密关联了，接着再看BuilderOwner.scheduleBuildFor方法：框架

void scheduleBuildFor(Element element) {
    ...
    if (element._inDirtyList) {
      ...
      _dirtyElementsNeedsResorting = true;
      return;
    }
    if (!_scheduledFlushDirtyElements && onBuildScheduled != null) {
      _scheduledFlushDirtyElements = true;
      onBuildScheduled();
    }
    _dirtyElements.add(element);
    element._inDirtyList = true;
   ...
  }

这里的处理过程：若是_scheduledFlushDirtyElements不为true，就调起onBuildScheduled方法，并把Elment都加入到_dirtyElements中，那么onBuildScheduled又会干些啥尼？
回到WidgetBinding.initInstances方法：dom

void initInstances() {
    super.initInstances();
    ...
    buildOwner.onBuildScheduled = _handleBuildScheduled;
    ...
  }

看到真实调用的是WidgetBinding._handleBuildScheduled方法，咱们继续完善刚才的调用过程：
clipboard.png
因此这里就能够看到咱们调用setState方法最终会触发界面新的一帧绘制。ide

当触发新的一帧时，咱们又回到最初的WidgetBinding.drawFrame方法中，那么builderOwner.buildScope方法究竟会干些工做：布局

void buildScope(Element context, [VoidCallback callback]) {
    if (callback == null && _dirtyElements.isEmpty)
      return;
    ..l
    Timeline.startSync('Build', arguments: timelineWhitelistArguments);
    try {
      _scheduledFlushDirtyElements = true;
      if (callback != null) {
        
        _dirtyElementsNeedsResorting = false;
        try {
          callback();
        } finally {
         ...
        }
      }
      _dirtyElements.sort(Element._sort);
      _dirtyElementsNeedsResorting = false;
      int dirtyCount = _dirtyElements.length;
      int index = 0;
      while (index < dirtyCount) {
        ...
        try {
          _dirtyElements[index].rebuild();
        } catch (e, stack) {
          ...
        }
        index += 1;
        if (dirtyCount < _dirtyElements.length || _dirtyElementsNeedsResorting) {
          _dirtyElements.sort(Element._sort);
          _dirtyElementsNeedsResorting = false;
          dirtyCount = _dirtyElements.length;
          while (index > 0 && _dirtyElements[index - 1].dirty) {
            index -= 1;
          }
        }
      }
        ...
        return true;
      }());
    } finally {
      for (Element element in _dirtyElements) {
        assert(element._inDirtyList);
        element._inDirtyList = false;
      }
      _dirtyElements.clear();
      _scheduledFlushDirtyElements = false;
      _dirtyElementsNeedsResorting = null;
      Timeline.finishSync();
    }
  }

首先把_scheduledFlushDirtyElements标记设为true，表示正在重新构建新的控件树，而后_dirtyElements会作一轮排序，看一下Element._sort的方法如何实现的:性能

static int _sort(Element a, Element b) {
    if (a.depth < b.depth)
      return -1;
    if (b.depth < a.depth)
      return 1;
    if (b.dirty && !a.dirty)
      return -1;
    if (a.dirty && !b.dirty)
      return 1;
    return 0;
  }

嗯，由于在这里最初排序都是标记为dirty的Element，因此最后的结果是，depth小的Element会排最前，depth大的排最后；也就是说父Element会比子Element更早被rebuild，这样能够防止子Element会重复rebuild。
当在rebuild过程当中有可能会加入新的Dirty Element，因此每次rebuild的时候都会从新检查_dirtyElements是否有增长或者检查_dirtyElementsNeedsResorting标记位，接着重新排序一遍，这个时候咱们的_dirtyElements列表中就有可能存在以前已经rebuild完，dirty为false的Element了，从新排序后，depth小的和dirty不为true的会排最前，从新把index定位到第一个Dirty Element继续rebuild。
若是在这个过程咱们想把已经rebuild过一次的Element想重复加入到_dirtyElements中，造成死循环，会怎样的尼，这个时候Element._inDirtyList仍是为true，代表Element已经在_dirtyElements列表中，在开发模式下引擎会报错，给出相应提示；通常状况下是不该该出现的，万一出现就须要思考一下代码是否合理了。优化

接着先跳过super.drawFrame方法，来到builderOwner.finalizeTree方法：

void finalizeTree() {
    Timeline.startSync('Finalize tree', arguments: timelineWhitelistArguments);
    try {
      lockState(() {
        _inactiveElements._unmountAll(); // this unregisters the GlobalKeys
      });
     ...
    } catch (e, stack) {
      _debugReportException('while finalizing the widget tree', e, stack);
    } finally {
      Timeline.finishSync();
    }
  }

主要把_inactiveElements都进行一次清理，因此使用GlobalKey的控件，若是想起到重用控件的效果，必须在同一帧里面完成“借用”，不然就会被清理了。

简单总结一下BuilderOwner的功能就是：管理控件rebuild过程，让控件有序的进行rebuild。

PipelineOwner

终于来到super.drawFrame方法，这个方法实际上调起的是RenderBinding.drawFrame方法：

void drawFrame() {
    pipelineOwner.flushLayout();
    pipelineOwner.flushCompositingBits();
    pipelineOwner.flushPaint();
    renderView.compositeFrame(); // this sends the bits to the GPU
    pipelineOwner.flushSemantics(); // this also sends the semantics to the OS.
  }

咱们又见到一个跟BuilderOwner名称很类似的PipelineOwner，那PipelineOwner又起到什么样的功能尼？直接深刻
pipelineOwner.flushLayout方法：

void flushLayout() {
    Timeline.startSync('Layout', arguments: timelineWhitelistArguments);
    _debugDoingLayout = true;
    try {
      while (_nodesNeedingLayout.isNotEmpty) {
        final List<RenderObject> dirtyNodes = _nodesNeedingLayout;
        _nodesNeedingLayout = <RenderObject>[];
        for (RenderObject node in dirtyNodes..sort((RenderObject a, RenderObject b) => a.depth - b.depth)) {
          if (node._needsLayout && node.owner == this)
            node._layoutWithoutResize();
        }
      }
    } finally {
      _debugDoingLayout = false;
      Timeline.finishSync();
    }
  }

跟builderOwner处理类似，先进行一次排序，depth小的排最前优先处理，而后调起RenderObject._layoutWithoutResize方法。

暂时先整理一下，这个时候咱们出现三个名词：Widget，Element，RenderObject；它们的关系到底是咋样的尼，假设你熟悉前端的Vue或者React框架，它们的关系等同于下面这张图:

clipboard.png

也就是说RenderObject负责着界面的布局绘制和事件处理等；而Element则是进行virtual dom diff，而且负责建立RenderObject；Widget则是咱们控件业务逻辑组织的地方， 负责建立Element。

大概能够想到PipelineOwner的主要功能：负责管理那些dirty render object，让它们进行布局和绘制。

接着RenderObject._layoutWithoutResize方法：

void _layoutWithoutResize() {
    ...
    try {
      performLayout();
      markNeedsSemanticsUpdate();
    } catch (e, stack) {
      _debugReportException('performLayout', e, stack);
    }
    ...
    _needsLayout = false;
    markNeedsPaint();
  }

能够看到其实直接调用了RenderObject.performLayout方法，而这个方法则是应由开发者本身实现的布局逻辑，接着会调起RenderObject.markNeedsPaint方法，也就是说每次从新layout都会触发一次paint。

void markNeedsPaint() {
    if (_needsPaint)
      return;
    _needsPaint = true;
    if (isRepaintBoundary) {
      if (owner != null) {
        owner._nodesNeedingPaint.add(this);
        owner.requestVisualUpdate();
      }
    } else if (parent is RenderObject) {
      final RenderObject parent = this.parent;
      parent.markNeedsPaint();
    } else {
      if (owner != null)
        owner.requestVisualUpdate();
    }
  }

这里的逻辑，主要判断当前的RenderObject.isRepaintBoundary是否为true，若是是则把当前RenderObject加入到PipelineOwner对应的列表中等待接下来的flushPaint处理，并触发下一帧的绘制；当isRepaintBoundary不为true的时候，则会一直往上查找直到找到isRepaintBoundary为true的RenderObject，也就是有可能会找到根节点RenderView，而后加入到_nodesNeedingPaint列表中：

class RenderView extends RenderObject with RenderObjectWithChildMixin<RenderBox> {
    ...
    bool get isRepaintBoundary => true;
    ...
}

这样的话咱们就得注意了，若是常常须要重绘区域，最好把isRepaintBoundary标记true，这样就尽可能避免触发全局重绘，提升性能，对应的flutter就已经提供了一个RepaintBoundary控件，自动把isRepaintBoundary标记为true，很是方便咱们去作优化。

既然有markNeedsPaint方法，固然也有markNeedsLayout方法：

void markNeedsLayout() {
    if (_needsLayout) {
      return;
    }
    if (_relayoutBoundary != this) {
      markParentNeedsLayout();
    } else {
      _needsLayout = true;
      if (owner != null) {
        ...
        owner._nodesNeedingLayout.add(this);
        owner.requestVisualUpdate();
      }
    }
  }

处理逻辑基本上跟markNeedsPaint差很少，_relayoutBoundary也能够减小全局从新布局，能够把布局范围缩小，提升性能，可是_relayoutBoundary的设置是有点不同的，等会再去讨论。

简单整理一下

当咱们用调起setState改变某些状态，例如：控件的高度；先回到BuilderOwner.buildScope，继续dirty element的rebuild方法：

void rebuild() {
    if (!_active || !_dirty)
      return;
    performRebuild();
  }

接着执行performRebuild方法：

void performRebuild() {
    Widget built;
    try {
      built = build();
      debugWidgetBuilderValue(widget, built);
    } catch (e, stack) {
      _debugReportException('building $this', e, stack);
      built = new ErrorWidget(e);
    } finally {
      // We delay marking the element as clean until after calling build() so
      // that attempts to markNeedsBuild() during build() will be ignored.
      _dirty = false;
      assert(_debugSetAllowIgnoredCallsToMarkNeedsBuild(false));
    }
    try {
      _child = updateChild(_child, built, slot);
      assert(_child != null);
    } catch (e, stack) {
      _debugReportException('building $this', e, stack);
      built = new ErrorWidget(e);
      _child = updateChild(null, built, slot);
    }
  }

控件会从新build出子控件树，而后调起updateChild方法：

Element updateChild(Element child, Widget newWidget, dynamic newSlot) {
    if (newWidget == null) {
      if (child != null)
        deactivateChild(child);
      return null;
    }
    if (child != null) {
      if (child.widget == newWidget) {
        if (child.slot != newSlot)
          updateSlotForChild(child, newSlot);
        return child;
      }
      if (Widget.canUpdate(child.widget, newWidget)) {
        if (child.slot != newSlot)
          updateSlotForChild(child, newSlot);
        child.update(newWidget);
        return child;
      }
      deactivateChild(child);
    }
    return inflateWidget(newWidget, newSlot);
  }

  1. 若是newWidget为null可是child不为null，也就是删除原来的控件，就会调起deactivateChild方法，会把当前的Element加入到BuilderOwner._inactiveElements列表中（最后可能会被清除也可能会被重用）。

  2. 若是newWidget和child都不为null，也就是更新原来的控件，先调起Widget.canUpdate方法判断是否可以更新（通常都是根据Widget运行时类型是否相同来判断），若是相同调起update方法，继续更新的逻辑，若是不同，就要deactivate原来的控件，而且建立新的控件。

  3. 若是child为null而Widegt不为null，也就是要建立新的控件。

接下来会分别分析更新的逻辑和建立的逻辑：

  • 更新

直接来到StatefulElement.update方法：

void update(StatefulWidget newWidget) {
    super.update(newWidget);
    final StatefulWidget oldWidget = _state._widget;
    _dirty = true;
    _state._widget = widget;
    try {
      _state.didUpdateWidget(oldWidget);
    } finally {
    }
    rebuild();
  }

这里首先会调起一个控件很重要的生命回调didUpdateWidget，综合上述能够知道，这里是当新的子控件和旧的子控件类型一致时才会调起；接着就是子控件的rebuild过程，而后不停重复下去。

  • 建立

直接来到Element.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) {
        newChild._activateWithParent(this, newSlot);
        final Element updatedChild = updateChild(newChild, newWidget, newSlot)
        return updatedChild;
      }
    }
    final Element newChild = newWidget.createElement();
    newChild.mount(this, newSlot);
    return newChild;
  }

这里判断key是否为GlobalKey，若是是会调起_retakeInactiveElement方法，目的是从Globalkey上重用控件，并把控件从BuilderOwner._inactiveElements列表上移除，防止它被unmount，接着就是重新跑一次updateChild流程；若是不是就在新的子控件上建立新的Element,而且mount上去。

可是若是多个child的时候是怎么更新的尼？
来到MultiChildRenderObjectElement.update方法：

void update(MultiChildRenderObjectWidget newWidget) {
    super.update(newWidget);
    _children = updateChildren(_children, widget.children, forgottenChildren: _forgottenChildren);
    _forgottenChildren.clear();
  }

框架里面好像只规定跟RenderObject相关的控件才能够支持多个child，而updateChildren就是一个flutter版本的virtual dom diff算法的实现。

刚才假设咱们须要修改控件的高度，既然跟显示有关，必然跟RenderObejct相关，直接来到RenderObjectElement.update方法：

void update(covariant RenderObjectWidget newWidget) {
    super.update(newWidget);
    widget.updateRenderObject(this, renderObject);
    _dirty = false;
  }

最后调起的是RenderObjectWidget.updateRenderObject方法，在这里咱们能够获得新建立的RenderObject，咱们在这里把新的RenderObject的属性赋值给旧的RenderObject，而在RenderObject相关属性的setter方法中会调起markNeedsLayout方法，这样在下一帧布局绘制的时候就会生效。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程