Flutter：了解 Widget、Element 和渲染树

Question

我一直在尝试了解 Flutter 以及渲染的幕后工作原理。我看过一个关于“颤振如何渲染小部件？”的视频Flutter 渲染是如何工作的？ 我了解到正在构建 3 棵树（Widget、Element 和 Render Tree）。在视频控件中，是布局的蓝图，元素是配置，而渲染树则进行实际的绘制。我还是没能理解视频中的内容，Matt Sulliman 对这三个的说法如下：

1. Widget：UI 的不可变描述（意味着它不会改变？），也描述了 Element 的配置。
2. Element ：小部件树中特定位置的小部件的实例化。 （构建上下文？）
3. 渲染：处理尺寸、绘画和其他低级内容。

我主要担心的是，在视频的 6:36 处，Matt sulliman 说 Element 代表了 UI 的实际部分。 这部分让我很困惑。因为如果元素是按照配置、生命周期和绘制的类比进行配置的。所以Render Tree应该是UI部分。我没听懂那部分。

有什么类比或简单的方法可以让我理解每棵树的职责是什么？

Answer 1

好吧，这是 Flutter 团队经常进行的工程采访。

元素树（Widget Tree）和渲染树是使数据流反应并能够与 OOP 类交互的方式。

元素树一直在重建，以帮助渲染树找出要修剪的内容并将其添加到生成的每个帧的渲染树中。

Google 工程师将元素树称为 widget 树的原因是每个 widget 都存储为树中每个 Element 类的配置。

这样想 元素树告诉小部件配置 Render Tree是变化和更新

那么它是如何反应的，因为我们仍然需要一个观察者，对吧？

State 类是应用程序开发代码中 OOP 类的观察者。

没有子节点 API 的全部原因是每个 Tree 都可以作为一个 API 层，以以下形式在 OOP 小部件类级别进行访问： BuildContext--元素树中的元素 RenderObject——渲染树 State---Render Tree输出的观察者 元素树中的关键元素

并且，树对于 Google 工程师来说是数学概念，指的是 Widget 树（元素树）和渲染树形式的特定图形结构，因为它是真正的数学树，这也意味着我们只有 DAG 边，边之间没有完整的循环.