Flutter 核心渲染流程分析 [完结篇]

导语

作为一个 Flutter 开发者，我们仅需组合 widget 即可实现各种不同的交互。这其中 Flutter 是如何通过 widget 完成屏幕上的呈现？Native 层起到了怎样的作用？作为 UI 核心渲染流程的完结篇，这次我们不陷于每一个细节，而是从全局梳理主要流程，把握关键节点。对于细节的知识点，我会附上一些更深入的文章。希望能对你认识 Flutter 渲染机制有所帮助。

---

一、缘起：setState()

无论是一个简单的列表，还是一段灵巧的动画，本质都是由一个个快速切换的画面组成，术语称其为「帧」。 当我们在滑动列表，或者播放动画的时候。系统不断地生产帧，并将其绘制到屏幕上，呈现出「动」起来了的感觉。

而在 Flutter 中当需要更新 UI 展示的时候，我们第一时间往往想到 setState()。更新 UI 本质上，不就是用一个新的「帧」去替换上一个「帧」么。所以，其中必定会执行帧的调度逻辑。而 setState 最终调用到 BuildOwner.scheduleBuildFor。

  /// dart
  /// Adds an element to the dirty elements list so that it will be rebuilt
  /// when [WidgetsBinding.drawFrame] calls [buildScope].
  void scheduleBuildFor(Element element) {
    .......
    if (!_scheduledFlushDirtyElements && onBuildScheduled != null) {
      _scheduledFlushDirtyElements = true;
      onBuildScheduled();
    }
    _dirtyElements.add(element);
    element._inDirtyList = true;
    ........
   }

方法中有两个关键点：

1、onBuildScheduled()

2、将 element 添加到 _dirtyElements 中

第二点没什么好说，后面会用到，关键先看第一点。跟踪引用，会发现第一个方法最终会执行到 SchedulerBinding.scheduleFrame()，这便是绘制的源头。

---

二、渲染起源：SchedulerBinding.scheduleFrame()

 

  /// dart
  /// 调用 C++ 到 Native 层，请求 Vsync 信号
  void scheduleFrame() {
    if (_hasScheduledFrame || !_framesEnabled)
      return;
     ensureFrameCallbacksRegistered();
     window.scheduleFrame();
    _hasScheduledFrame = true;
  }

这个方法代码量并不多，关键在 window.scheduleFrame() ，这是一个 native 方法。

  void scheduleFrame() native