文章/答案/技术大牛

发布

Flutter框架分析

共 4 篇文章

Flutter框架分析（一）-- 总览和Window

Flutter框架分析（二）-- 初始化

Flutter框架分析（三）-- Widget，Element和RenderObject

Flutter框架分析（四）-- Flutter框架的运行

清单首页Flutter框架分析文章详情

清单「Flutter框架分析」 04/04

Flutter框架分析（四）-- Flutter框架的运行

HowHardCanItBe

前言

前面几篇文章介绍了Flutter框架的渲染流水线，window，初始化以及Widget，Element和RenderObject体系。其中对Widget，Element和RenderObject的介绍主要是一些静态的说明，了解了以上这些技术点之后，在这篇文章里我们会通过动态运行的方式来介绍一下Flutter框架是如何运行的。从之前介绍的渲染流水线可以知道，这个过程大致可以分为两段操作。第一段是从State.setState()到去engine那里请求一帧，第二段就是Vsync信号到来以后渲染流水线开始重建新的一帧最后送入engine去显示。我们先来看第一段Flutter框架都做了什么。

调度之前

先看一下State.setState()

void setState(VoidCallback fn) {
    
    final dynamic result = fn() as dynamic;
  
    _element.markNeedsBuild();
  }

这里会调用到Element的markNeedsBuild()函数。

void markNeedsBuild() {
    if (!_active)
      return;
    if (dirty)
      return;
    _dirty = true;
    owner.scheduleBuildFor(this);
  }

Element首先看自己是不是active的状态，不是的话就直接返回了，如果是“脏”（dirty）的状态也直接返回，不是的话会置上这个状态然后调用BuildOwner的scheduleBuildFor()函数，这个BuildOwner我们之前介绍过，它的实例是在WidgetsBinding初始化的时候构建的。每个Element的都会持有BuildOwner的引用。由其父Element在mount的时候设置。

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

BuildOwner会维护一个_dirtyElements列表，所有被标记为“脏”（dirty）的element都会被添加进去。在此之前会调用onBuildScheduled()。这个函数是WidgetsBinding初始化的时候设置给BuildOwner的，对应的是WidgetsBinding._handleBuildScheduled()。

void _handleBuildScheduled() {
    ensureVisualUpdate();
  }

这里会调用到ensureVisualUpdate()。这个函数定义在SchedulerBinding里的

void ensureVisualUpdate() {
    switch (schedulerPhase) {
      case SchedulerPhase.idle:
      case SchedulerPhase.postFrameCallbacks:
        scheduleFrame();
        return;
      case SchedulerPhase.transientCallbacks:
      case SchedulerPhase.midFrameMicrotasks:
      case SchedulerPhase.persistentCallbacks:
        return;
    }
  }

函数ensureVisualUpdate()会判断当前调度所处的状态，如果是在idle（空闲）或者postFrameCallbacks运行状态则调用scheduleFrame()。其他状态则直接返回。下面这三个状态正是渲染流水线运行的时候。

void scheduleFrame() {
    if (_hasScheduledFrame || !_framesEnabled)
      return;
    window.scheduleFrame();
    _hasScheduledFrame = true;
  }

在函数scheduleFrame()里我们看到了熟悉的window。这里就是通知engine去调度一帧的地方了。调度之后会置上_hasScheduledFrame标志位，避免重复请求。另外一个标志位_framesEnabled是代表当前app的状态，或者说其所处的生命周期是否允许刷新界面。这个状态有四种：resumed，inactive，paused和suspending。

resumed：app可见且可以响应用户输入。
inactive：app不能响应用户输入，例如在Android上弹出系统对话框。
paused：app对用户不可见。
suspending：app挂起？？这个状态貌似Android和iOS都没有上报。

_framesEnabled只有在resumed和inactive状态下才为true。也就是说，只有在这两个状态下Flutter框架才会刷新页面。

至此第一阶段，也就是调度之前的工作做完了。看起来比较简单，主要就是把需要重建的Element放入_dirtyElements列表。接下来Flutter框架会等待Vsync信号到来以后engine回调框架，这就是第二段要做的事情了。

Vsync到来之后

我们之前说过Vsync信号到来之后，engin会按顺序回调window的两个回调函数：onBeginFrame()和onDrawFrame()。这两个回调是SchedulerBinding初始化的时候设置给window的。对应的是SchedulerBinding.handleBeginFrame()和SchedulerBinding.handleDrawFrame()。

onBeginFrame

这个回调会直接走到SchedulerBinding.handleBeginFrame()。

  void handleBeginFrame(Duration rawTimeStamp) {
   ...
    _hasScheduledFrame = false;
    try {
      // TRANSIENT FRAME CALLBACKS
      _schedulerPhase = SchedulerPhase.transientCallbacks;
      final Map<int, _FrameCallbackEntry> callbacks = _transientCallbacks;
      _transientCallbacks = <int, _FrameCallbackEntry>{};
      callbacks.forEach((int id, _FrameCallbackEntry callbackEntry) {
        if (!_removedIds.contains(id))
          _invokeFrameCallback(callbackEntry.callback, _currentFrameTimeStamp, callbackEntry.debugStack);
      });
      _removedIds.clear();
    } finally {
      _schedulerPhase = SchedulerPhase.midFrameMicrotasks;
    }
  }

这个函数主要是在依次回调“Transient”回调函数，这些回调函数是在调度之前设置在SchedulerBinding里的，这里的“Transient”意思是临时的，或者说是一次性的。原因是这些回调函数只会被调用一次。注意看代码里_transientCallbacks被置为空Map了。如果想在下一帧再次调用的话需要提前重新设置回调。这些回调主要和动画有关系。也就是渲染流水线里的第一阶段，动画（Animate）阶段。关于动画后续我会再写文章从框架角度分析一下动画的机制。

在运行回调之前_schedulerPhase的状态被设置为SchedulerPhase.transientCallbacks。回调处理完以后状态更新至SchedulerPhase.midFrameMicrotasks意思是接下来会处理微任务队列。处理完微任务以后，engine会接着回调onDrawFrame()。

onDrawFrame

这个回调会直接走到SchedulerBinding.handleDrawFrame()。

void handleDrawFrame() {
    try {
      // PERSISTENT FRAME CALLBACKS
      _schedulerPhase = SchedulerPhase.persistentCallbacks;
      for (FrameCallback callback in _persistentCallbacks)
        _invokeFrameCallback(callback, _currentFrameTimeStamp);

      // POST-FRAME CALLBACKS
      _schedulerPhase = SchedulerPhase.postFrameCallbacks;
      final List<FrameCallback> localPostFrameCallbacks =
          List<FrameCallback>.from(_postFrameCallbacks);
      _postFrameCallbacks.clear();
      for (FrameCallback callback in localPostFrameCallbacks)
        _invokeFrameCallback(callback, _currentFrameTimeStamp);
    } finally {
      _schedulerPhase = SchedulerPhase.idle;
      _currentFrameTimeStamp = null;
    }
  }

在handleDrawFrame里按顺序处理了两类回调，一类叫“Persistent”回调，另一类叫“Post-Frame”回调。

“Persistent”字面意思是永久的。这类回调一旦注册以后是不能取消的。主要用来驱动渲染流水线。渲染流水线的构建（build），布局（layout）和绘制（paint）阶段都是在其中一个回调里的。

“Post-Frame”回调主要是在新帧渲染完成以后的一类调用，此类回调只会被调用一次。

在运行“Persistent”回调之前_schedulerPhase状态变为SchedulerPhase.persistentCallbacks。在运行“Post-Frame”回调之前_schedulerPhase状态变为SchedulerPhase.postFrameCallbacks。最终状态变为SchedulerPhase.idle。

这里我们主要关注一个“Persistent”回调：WidgetsBinding.drawFrame()。这个函数是在RendererBinding初始化的时候加入到“Persistent”回调的。

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

这里首先会调用buildOwner.buildScope(renderViewElement)。其入参renderViewElement是element tree的根节点。此时渲染流水线就进入了构建（build）阶段。接下来调用了super.drawFrame()。这个函数定义在RendererBinding中。

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.
}

可以看出渲染流水线的接力棒传到了pipelineOwner的手里，渲染流水线就进入了布局（layout）阶段和绘制（paint）阶段。关于最后这两个阶段本篇不做详细介绍。这里大家只要知道绘制完成以后Flutter框架最终会调用window.render(scene)将新帧的数据送入engine显示到屏幕。

最后调用buildOwner.finalizeTree();。这个函数的作用是清理不再需要的Element节点。在element tree更新以后可能有些节点就不再需要挂载在树上了，在finalizeTree()的时候会将这些节点及其子节点unmount。

构建（build）阶段

void buildScope(Element context, [VoidCallback callback]) {
    try {
      _scheduledFlushDirtyElements = true;
      _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;
      }
      
    } finally {
      for (Element element in _dirtyElements) {
        element._inDirtyList = false;
      }
      _dirtyElements.clear();
      _scheduledFlushDirtyElements = false;
      _dirtyElementsNeedsResorting = null;
     
    }
  }

还记得在调度帧之前会把需要更新的Element标记为“脏”（dirty）并放入BuildOwner的_dirtyElements列表。这里Flutter会先按照深度给这个列表排个序。因为Element在重建的时候其子节点也都会重建，这样如果父节点和子节点都为“脏”的话，先重建父节点就避免了子节点的重复重建。

排完序就是遍历_dirtyElements列表。依次调用Element.rebuild()。这个函数又会调用到Element.performRebuild()。我们之前介绍Element的时候说过performRebuild()由其子类实现。

我们之前的出发点是State.setState()。那就先看看StatefulElement如何做的。它的performRebuild()是在其父类ComponentElement里：

void performRebuild() {
    Widget built;
    built = build();
    try {
      _child = updateChild(_child, built, slot);
    } catch (e, stack) {
      ...
    }
  }

回忆一下ComponentElement。这个build()函数最终会调用到State.build()了。返回的就是我们自己实例化的Widget。拿到这个新Widget就去调用updateChild()。之前在讲Element的时候我们介绍过updateChild()这个函数。由增，删，改这么几种情况，对于MyWidget，从State.setState()过来是属于改的情况。此时会调用child.update(newWidget);。这个update()函数又是由各个Element子类实现的。这里我们只列举几个比较典型的。

StatefulElement和StatelessElement的update()函数最终都会调用基类Element的rebuild()函数。好像在兜圈圈的感觉。。。

RenderObjectElement的update()函数就比较简单了

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

更新只是调用了一下RenderObjectWidget.updateRenderObject()。这个函数我们之前介绍过，只是把新的配置设置到现有的RenderObject上。

回到上面那个兜圈圈的问题。理清这里的调用关系的关键就是要搞清楚是此时的Element是在对自己进行操作还是对孩子进行操作。假设我们有这样的一个三层element tree进行更新重建。

  父(StatefulElement)

  子(StatefulElement)

  孙(LeafRenderObjectElement)

那么从父节点开始，调用顺序如下：

父.rebuild()--->父.performRebuild()--->父.updateChild()--->子.update()--->子.rebuild()--->子.performRebuild()--->子.updateChild()--->孙.update()。

可见构建（build）过程是从需要重建的Element节点开始一层层向下逐个更新子节点。直到遇到叶子节点为止。

至此渲染流水线的构建（build）阶段就跑完了。接下来就由pipelineOwner驱动开始布局（layout）和绘制（paint）阶段了。这两个阶段留待以后再给大家介绍一下。

总结

本篇文章从我们熟悉的State.setState()函数出发，大致介绍了Flutter框架是如何运行渲染流水线的。总体来说其运行时分为两个阶段，向engine调度帧之前和Vsync信号到来engine回调Flutter框架之后。剩余篇幅则是以更新Element为例介绍了一下渲染流水线的构建（build）阶段都做了一些什么事情。限于篇幅，没有更多涉及Element的新增和删除步骤。大家感兴趣的话可以直接看源码来了解相关信息。