Flutter 架构介绍(flutter项目结构)
该文章旨在提供更深入的 Flutter 架构概览，包含其设计层面的核心原则及概念。
在开发中，Flutter 应用会在一个 VM（程序虚拟机）中运行，从而可以在保留状态且无需重新编译的情况下，热重载相关的更新。对于发行版 (release) ，Flutter 应用程序会直接编译为机器代码（Intel x64 或 ARM 指令集），或者针对 Web 平台的 JavaScript。 Flutter 的框架代码是开源的，遵循 BSD 开源协议，并拥有蓬勃发展的第三方库生态来补充核心库功能。
接下来我们主要分为以下几部分内容来了解 Flutter 架构：
简介：Flutter 是什么？干什么？谁会用到？
架构层：Flutter 的构成要素。
响应式用户界面：Flutter 用户界面开发的核心概念。
布局和渲染：Flutter 如何将界面布局转化为像素。
widgets 树：构建 Flutter 用户界面的基石。
平台嵌入层：让 Flutter 应用可以在移动端及桌面端操作系统执行的代码。
与其他代码进行集成：Flutter 应用可用的各项技术的更多信息。
一. Flutter 简介
Flutter 是 Google 的便携式 UI 工具包，帮助你在移动、web、桌面端创造高质量的绝妙原生体验的应用。 Flutter 可以和世界上的开发人员和开发组织广泛使用的那些现存代码一起使用，并且是开源的、免费的。
对于用户来说，Flutter 让漂亮的应用 UI 变得生动有趣。
对于开发者来说，Flutter 降低了创建移动应用的门槛。它加速了移动应用的开发，降低了兼顾 Android 和 iOS 应用开发的成本和复杂性,减少了跨平台开发的成本以及复杂度。
对于设计师而言，Flutter 可以确保精确地实现设计意图，而无需降低保真度或被迫进行妥协。在设计师的手里，Flutter 还可以作为一种高效的原型设计工具。
Flutter 适用于希望快速构建精美的移动应用，或者希望用一套代码库覆盖更多用户的开发者。
Flutter 也适用于需要领导研发团队的工程经理们。 Flutter 可以让工程经理打造一个统一的应用研发团队，这个“应用”包含：移动端、Web 端以及桌面端。这可以帮助以便更快地开发更多功能，将相同的功能部署到多平台的应用中，并降低维护成本。
说到底，如果您想要漂亮的应用，令人愉悦的动效和动画，以及富有个性和身份感的 UI，那您就是 Flutter 的目标用户。
对于开发者来说，Flutter 降低了应用开发的入门门槛。它加速了应用开发的过程，减少了跨平台开发的成本以及复杂度。
对于设计师来说，Flutter 提供了一个能够实现高保真度用户体验的画布。 Fast 公司评价 Flutter 是 [一个设计灵感的源泉][one of the top design ideas of the decade]，提供了将概念转换为生产代码的能力，却没有典型的框架强加的妥协。
对于工程主管以及雇主来说，Flutter 可以将不同平台的应用开发者，统一为一个 移动端、前端和桌面端应用程序 的团队，共同建立品牌，并在单个代码库中打造的多个平台的应用程序。 Flutter 加速了跨平台下开发以及同步发布进程的开发进度。
在开发过程中，Flutter 应用程序在 VM 中运行，该 VM 提供更改的有状态热重载，而无需完全重新编译。对于发布，Flutter 应用程序直接编译为机器代码，无论是 Intel x64 还是 ARM 指令，或者如果面向网络，则编译为 JavaScript。该框架是开源的，具有宽松的 BSD 许可证，并拥有一个蓬勃发展的第三方软件包生态系统，补充了核心库功能。
二. Flutter 架构层
Flutter 被设计为一个可扩展的分层系统。它可以被看作是各个独立的组件的系列合集，上层组件各自依赖下层组件。组件无法越权访问更底层的内容，并且框架层中的各个部分都是可选且可替代的。
Flutter的架构主要分成三层: Framework（Dart），Engine（C/C++）和 Embedder （platform-specific）。
Framework 使用 dart 实现，包括 Material Design 风格的Widget，Cupertino(针对iOS)风格的Widgets，UI/文本/图片/按钮等基础 Widgets，渲染，动画，手势等。此部分的核心代码是: flutter 仓库下的flutter package，以及 sky_engine 仓库下的 io, async, ui (dart:ui 库提供了 Flutter 框架和引擎之间的接口)等package。
Engine使用C++实现，主要包括: Skia, Dart 和 Text。
Skia是开源的二维图形库，提供了适用于多种软硬件平台的通用API。其已作为Google Chrome，Chrome OS，Android, Mozilla Firefox, Firefox OS等其他众多产品的图形引擎，支持平台还包括Windows, macOS, iOS，Android，Ubuntu等。
Dart 部分主要包括:Dart Runtime，Garbage Collection(GC)，如果是Debug模式的话，还包括JIT(Just In Time)支持。Release和Profile模式下，是AOT(Ahead Of Time)编译成了原生的arm代码，并不存在JIT部分。
Text 即文本渲染，其渲染层次如下:衍生自 Minikin 的 libtxt 库(用于字体选择，分隔行)；HartBuzz用于字形选择和成型；Skia作为渲染/GPU后端，在Android和Fuchsia上使用FreeType渲染，在iOS上使用CoreGraphics来渲染字体。
Embedder 是一个嵌入层，即把 Flutter 嵌入到各个平台上去，这里做的主要工作包括渲染 Surface 设置,线程设置，以及插件等。从这里可以看出，Flutter 的平台相关层很低，平台(如iOS)只是提供一个画布，剩余的所有渲染相关的逻辑都在Flutter内部，这就使得它具有了很好的跨端一致性。
从架构图可以看出，Flutter 从头到尾重写一套跨平台的UI框架，包括UI控件、渲染逻辑甚至开发语言。渲染引擎依靠跨平台的Skia图形库来实现，依赖系统的只有图形绘制相关的接口，可以在最大程度上保证不同平台、不同设备的体验一致性，逻辑处理使用支持AOT的Dart语言，执行效率也比JavaScript高得多。
对底层操作系统而言，Flutter应用程序与其他本地应用程序一样，以相同的方式进行打包。一个平台特定的嵌入器提供了一个入口点；与底层操作系统协调，以访问服务，如渲染表面、可访问性和输入；并管理消息事件循环。嵌入器是用适合平台的语言编写的：目前 Android 的 Java 和 C++，iOS 和 macOS 的 Objective-C/Objective-C++，Windows 和 Linux 的 C++。使用嵌入器，Flutter 代码可以作为一个模块集成到现有的应用程序中，也可以是应用程序的全部内容。Flutter 包含了许多针对常见目标平台的嵌入器，但也存在其他嵌入器。
Flutter 的核心是 Flutter 引擎，它主要用 C++ 编写，支持所有 Flutter 应用所需的基元。每当需要绘制新的帧时，该引擎负责对合成场景进行光栅化。它提供了 Flutter 核心 API 的低层实现，包括图形（通过Skia）、文本布局、文件和网络I/O、可访问性支持、插件架构以及 Dart 运行时和编译工具链。
该引擎通过dart:ui暴露给Flutter框架，它将底层的C++代码封装在Dart类中。这个库暴露了最底层的基元，例如用于驱动输入、图形和文本渲染子系统的类。
通常情况下，开发人员通过Flutter Framework 与 Flutter 进行交互，Flutter 框架提供了一个用 Dart 语言编写的现代、反应式框架。它包括一套丰富的平台、布局和基础库，由一系列的层组成。从底层到顶层有：
基础类和构件服务，如动画，绘画和手势，在底层基础上提供了常用的抽象。
渲染层提供了一个处理布局的抽象。通过这一层，你可以建立一个可渲染对象的树。你可以动态地操作这些对象，树会自动更新布局以反映你的变化。
widgets 层是一个组成抽象。渲染层中的每个渲染对象在 widgets 层中都有一个对应的类。此外，widgets层还允许你定义可以重用的类的组合。这是引入反应式编程模型的一层。
Material和Cupertino库提供了全面的控件集，这些控件使用 widget 层的组合基元来实现 Material 或 iOS 设计语言。
Flutter框架相对较小；许多开发者可能会用到的更高级别的功能都是以包的形式实现的，包括像摄像头和 webview 这样的平台插件，以及像字符、http 和动画这样的平台无关的功能，这些都是建立在核心Dart和Flutter库的基础上的。其中一些包来自更广泛的生态系统，涵盖应用内支付、苹果认证和动画等服务。
Flutter framework 由许多抽象的层级组成。在这些层级的最顶端是我们经常用到的 Material 和 Cupertino Widgets。我们大多数情况下使用的就是这两类 Widget。 在 Widget 层下面，你会发现 Rendering 层。Rendering层简化了布局和绘制过程。它是 dart:ui 的的抽象化。dart:ui 是框架的最底层，它负责处理与 Engine 层的交流沟通。 简而言之，等级越高的层越容易使用，但是等级越低的层，暴露出来的api越多，越能够增加自定义功能。
2.1 dart:ui library
dart:ui library暴露出最底层的服务，这些服务被用来引导Application，例如用来驱动输入、绘制文字、布局和渲染子系统。
所以你可以仅仅通过使用实例化dart:ui库中的类（例如Canvas、Paint和TextField）来构建一个 Flutter App。但是如果你对于直接在 canvas 上绘制比较熟悉，就会知道使用这些底层 api 绘制一个图案是既难又繁琐的。 接下来考虑一些不是绘制的东西吧，例如布局和命中测试。 这些意味着什么呢？ 这意味着你必须手动的计算所有在你布局中使用的坐标，然后混合一些绘制和命中测试来捕获用户的输入。对每一帧进行上述操作并追踪它们。这个方法对于那些比较简单的APP，比如一个在蓝色区域内展示文字这种比较适用。如果对于那些比较复杂的APP或者简单的游戏来说可够你受的了。更不用说产品经理最喜爱的动画、滚动和一些酷炫的UI效果了。用我多年的开发经验告诉你，这些是开发者无穷无尽的梦魇。
2.2 Rendering library
Flutter 的 Rendering tree（渲染树）。RenderObject的层级结构被Flutter Widgets库使用来实现其布局和后台的绘制。通常来说，尽管你可能会使用RenderBox来在你的应用中实现自定义的效果，但是大多数情况下我们唯一与RenderObject的交互就是在调试布局信息的时候。
Rendering library 是 dart:ui library 上第一个抽象层。它替你做了所有繁重的数学计算工作（例如跟踪需要不断计算的坐标）。它使用 RenderObjects 来处理这些工作。你可以把 RenderObjects 想象成一个汽车的发动机，它承担了所有把你的APP展示到屏幕的工作。Rendering tree 中的所有 RenderObjects 都会被Flutter分层和绘制。为了优化这个复杂的过程，Flutter 使用了一个智能算法来缓存这些实例化很耗费性能的对象从而实现在性能最优化。 大多数情况，你会发现 Flutter 使用 RenderBox 而不是 RenderObject。这是因为项目的构建者发现使用一个简单和盒布局约束就能够成功的构建出有效稳定的UI。想象一下所有的 Widget 都被放置在它们的盒中。这个盒中的相关参数都计算好了，然后被放置到其他已经整理好的盒中间。所以如果在你的布局中仅有一个 Widget 改变了，只需要装载其的盒被系统重新计算即可。
2.3 Widget library
Flutter Widgets框架
Widget 库或许是最有意思的库。它是另外一个用来提供开箱即用的 Widget 的抽象层。这个库中所有的 Widget 都属于以下三种使用适当的 RenderObject 处理的 Widget 之一。
Layout，例如 Column 和 Row Widgets 用来帮助我们轻松的处理其他 Widget 的布局。
Painting，例如 Text 和 Image Widgets 允许我们展示（绘制）一些内容在屏幕上。
Hit-Testing，例如 GestureDetector 允许我们识别出不同的手势，例如点击和滑动。
大多数情况下我们会使用一些“基础” Widget 来组成我们需要的 Widget。例如我们使用 GestureDetector 来包裹Container，Container 中包裹 Button 来处理按钮点击。这叫做组合而不是继承。 然而除了自己构建每个UI组件，Flutter团队还创建了两个包含常用的 Material 和 Cupertino 风格的 Widgets 的库。
2.4 Material & Cupertino library
使用 Material 和 Cupertino 设计规范的Widgets库。
Flutter 为了减少开发者的负担，创建了这个拥有 Material 和 Cupertino 风格的 Widgets 层。
三. 响应式用户界面
粗略一看，Flutter 是 一个响应式的且伪声明式的 UI 框架，开发者负责提供应用状态与界面状态之间的映射，框架则在运行时将应用状态的更改更新到界面上。这样的模型架构的灵感来自 Facebook 的 React 框架 ，其中包含了对传统设计理念的再度解构。
在大部分传统的 UI 框架中，界面的初始状态通常会被一次性定义，然后，在运行时根据用户代码分别响应事件进行更新。在这里有一项大挑战，即随着应用程序的复杂性日益增长，开发者需要对整个 UI 的状态关联有整体的认知。让我们来看看如下的 UI：
很多地方都可以更改状态：颜色框、色调滑条、单选按钮。在用户与 UI 进行交互时，状态的改变可能会影响到每一个位置。更糟糕的是，UI 的细微变动很有可能会引发无关代码的连锁反应，尤其是当开发者并未注意其关联的时候。
我们可以通过类似 MVC 的方式进行处理，开发者将数据的改动通过控制器（Controller）推至模型（Model），模型再将新的状态通过控制器推至界面（View）。但这样的处理方式仍然存在问题，因为创建和更新 UI 元素的操作被分离开了，容易造成它们的不同步。
Flutter 与其他响应式框架类似，采用了显式剥离基础状态和用户界面的方式，来解决这一问题。你可以通过 React 风格的 API，创建 UI 的描述，让框架负责通过配置优雅地创建和更新用户界面。
在 Flutter 里，widgets（类似于 React 中的组件）是用来配置对象树的不可变类。这些 widgets 会管理单独的布局对象树，接着参与管理合成的布局对象树。 Flutter 的核心就是一套高效的遍历树的变动的机制，它会将对象树转换为更底层的对象树，并在树与树之间传递更改。
build() 是将状态转化为 UI 的方法，widget 通过重写该方法来声明 UI 的构造：
UI = f(state) 复制代码
build() 方法在框架需要时都可以被调用（每个渲染帧可能会调用一次），从设计角度来看，它应当能够快速执行且没有额外影响的。
这样的实现设计依赖于语言的运行时特征（特别是对象的快速实例化和清除）。幸运的是，Dart 非常适合这份工作。
四. Flutter 的布局和渲染
你是否思考过：既然 Flutter 是一个跨平台的框架，那么它如何提供与原生平台框架相当的性能？它是如何 从widget 层级结构转换成屏幕上绘制的实际像素？需要经历那些步骤？
让我们从安卓原生应用的角度开始思考。当你在编写绘制的内容时，你需要调用 Android 框架的 Java 代码。 Android 的系统库提供了可以将自身绘制到 Canvas 对象的组件，接下来 Android 就可以使用由 C/C++ 编写的 Skia 图像引擎，调用 CPU 和 GPU 完成在设备上的绘制。
通常来说，跨平台框架都会在 Android 和 iOS 的 UI 底层库上创建一层抽象，该抽象层尝试抹平各个系统之间的差异。这时，应用程序的代码常常使用 JavaScript 等解释型语言来进行编写，这些代码会与基于 Java 的 Android 和基于 Objective-C 的 iOS 系统进行交互，最终显示 UI 界面。所有的流程都增加了显著的开销，在 UI 和应用逻辑有繁杂的交互时更为如此。
相比之下，Flutter 通过绕过系统 UI 组件库，使用自己的 widget 内容集，削减了抽象层的开销。用于绘制 Flutter 图像内容的 Dart 代码被编译为机器码，并使用 Skia 进行渲染。 Flutter 同时也嵌入了自己的 Skia 副本，让开发者能在设备未更新到最新的系统时，也能跟进升级自己的应用，保证稳定性并提升性能。
4.1 从用户操作到 GPU
对于 Flutter 的渲染机制而言，首要原则是 简单快速。 Flutter 为数据流向系统提供了直通的管道，如以下的流程图所示：
【user input】对输入手势的响应(键盘、触屏) 【animation】由计时器触发用户界面变化 【build】在屏幕上创建小部件的应用程序代码 【layout】在屏幕上定位和调整元素大小 【paint】将元素转换为可视化表示 【composition】按绘制顺序叠加视觉元素 【rasterize 光栅化】将输出转换为GPU渲染指令 复制代码
接下来，让我们更加深入了解其中的一些阶段。
4.2 构建：从 Widget 到 Element
首先观察以下的代码片段，它代表了一个简单的 widget 结构：
Container( color: Colors.blue, child: Row( children: [ Image.network('https://www.example.com/1.png'), const Text('A'), ], ), ); 复制代码当 Flutter 需要绘制这段代码片段时，框架会调用 build() 方法，返回一棵基于当前应用状态来绘制 UI 的 widget 子树。在这个过程中，build() 方法可能会在必要时，根据状态引入新的 widget。在上面的例子中，Container 的 color 和 child 就是典型的例子。我们可以查看 Container 的 源代码，你会看到当 color 属性不为空时，ColoredBox 会被加入用于颜色布局。
if (color != null) current = ColoredBox(color: color!, child: current); 复制代码
与之对应的，Image 和 Text 在构建过程中也会引入 RawImage 和 RichText。如此一来，最终生成的 widget 结构比代码表示的层级更深，在该场景中如下图2：
这就是为什么你在使用 Dart DevTools 的 Flutter inspector 调试 widget 树结构时，会发现实际的结构比你原本代码中的结构层级更深。
在构建的阶段，Flutter 会将代码中描述的 widgets 转换成对应的 Element 树，每一个 Widget 都有一个对应的 Element。每一个 Element 代表了树状层级结构中特定位置的 widget 实例。目前有两种 Element 的基本类型：
ComponentElement，其他 Element 的宿主。
RenderObjectElement，参与布局或绘制阶段的 Element。
RenderObjectElement 是底层 RenderObject 与对应的 widget 之间的桥梁，我们晚些会介绍它。
任何 widget 都可以通过其 BuildContext 引用到 Element，它是该 widget 在树中的位置的句柄。类似 Theme.of(context) 方法调用中的 context，它作为 build() 方法的参数被传递。
由于 widgets 以及它上下节点的关系都是不可变的，因此，对 widget 树做的任何操作（例如将 Text('A') 替换成 Text('B')）都会返回一个新的 widget 对象集合。但这并不意味着底层呈现的内容必须要重新构建。 Element 树每一帧之间都是持久化的，因此起着至关重要的性能作用， Flutter 依靠该优势，实现了一种好似 widget 树被完全抛弃，而缓存了底层表示的机制。 Flutter 可以根据发生变化的 widget，来重建需要重新配置的 Element 树的部分。
4.3 布局和渲染
很少有应用只绘制单个 widget。因此，有效地排布 widget 的结构及在渲染完成前决定每个 Element 的大小和位置，是所有 UI 框架的重点之一。
在渲染树中，每个节点的基类都是 RenderObject，该基类为布局和绘制定义了一个抽象模型。这是再平凡不过的事情：它并不总是一个固定的大小，甚至不遵循笛卡尔坐标规律（根据该 极坐标系的示例 所示）。每一个 RenderObject 都了解其父节点的信息，但对于其子节点，除了如何 访问 和获得他们的布局约束，并没有更多的信息。这样的设计让 RenderObject 拥有高效的抽象能力，能够处理各种各样的使用场景。
在构建阶段，Flutter 会为 Element 树中的每个 RenderObjectElement 创建或更新其对应的一个从 RenderObject 继承的对象。 RenderObject 实际上是原语：渲染文字的 RenderParagraph、渲染图片的 RenderImage 以及在绘制子节点内容前应用变换的 RenderTransform 是更为上层的实现。
大部分的 Flutter widget 是由一个继承了 RenderBox 的子类的对象渲染的，它们呈现出的 RenderObject 会在二维笛卡尔空间中拥有固定的大小。 RenderBox 提供了 盒子限制模型，为每个 widget 关联了渲染的最小和最大的宽度和高度。
在进行布局的时候，Flutter 会以 DFS（深度优先遍历）方式遍历渲染树，并 将限制以自上而下的方式 从父节点传递给子节点。子节点若要确定自己的大小，则 必须 遵循父节点传递的限制。子节点的响应方式是在父节点建立的约束内 将大小以自下而上的方式 传递给父节点。
在遍历完一次树后，每个对象都通过父级约束而拥有了明确的大小，随时可以通过调用 paint() 进行渲染。
盒子限制模型十分强大，它的对象布局的时间复杂度是 O(n)：
父节点可以通过设定最大和最小的尺寸限制，决定其子节点对象的大小。例如，在一个手机应用中，最高层级的渲染对象将会限制其子节点的大小为屏幕的尺寸。（子节点可以选择如何占用空间。例如，它们可能在设定的限制中以居中的方式布局。）
父节点可以决定子节点的宽度，而让子节点灵活地自适应布局高度（或决定高度而自适应宽度）。现实中有一种例子就是流式布局的文本，它们常常会填充横向限制，再根据文字内容的多少决定高度。
这样的盒子约束模型，同样也适用于子节点对象需要知道有多少可用空间渲染其内容的场景，通过使用 LayoutBuilder widget，子节点可以得到从上层传递下来的约束，并合理利用该约束对象，使用方法如下：
Widget build(BuildContext context) { return LayoutBuilder( builder: (context, constraints) { if (constraints.maxWidth < 600) { return const OneColumnLayout(); } else { return const TwoColumnLayout(); } }, ); } 复制代码更多有关约束和布局系统的信息，及可参考的例子，可以在 深入理解 Flutter 布局约束 文章中查看。
所有 RenderObject 的根节点是 RenderView，代表了渲染树的总体输出。当平台需要渲染新的一帧内容时（例如一个 vsync 信号或者一个纹理的更新完成），会调用一次 compositeFrame() 方法，它是 RenderView 的一部分。该方法会创建一个 SceneBuilder 来触发当前画面的更新。当画面更新完毕，RenderView 会将合成的画面传递给 dart:ui 中的 Window.render() 方法，控制 GPU 进行渲染。
有关渲染流程的合成和栅格化阶段的更多细节，将不在本篇深入文章中讨论，但可以在 关于 Flutter 渲染流程的讨论 中了解更多。
五. Widget树
Flutter 是如何创建布局？RenderObject 又是如何与 Widgets 连接起来的呢？Element 又是什么呢？我们接下来看个简单的例子，简单了解它们之间的关系。
我们构建的这个 APP 是非常简单的。它由三个 Stateless Widget 组成：SimpleApp、SimpleContainer、SimpleText。所以如果我们调用 Flutter 的 runApp() 方法会发生什么呢？ 当 runApp() 被调用时，第一时间会在后台发生以下事件。
Flutter 会构建包含这三个 Widget 的 Widgets 树。
Flutter 遍历 Widget 树，然后根据其中的 Widget 调用 createElement() 来创建相应的 Element 对象，最后将这些对象组建成 Element 树。
第三个树被创建，这个树中包含了与 Widget 对应的 Element 通过 createRenderObject() 创建的RenderObject。 下图是 Flutter 经过这三个步骤后的状态：
Flutter创建了三个不同的树，一个对应着 Widget，一个对应着 Element，一个对应着 RenderObject。每一个Element中都有着相对应的 Widget 和 RenderObject 的引用。
那什么是 RenderObject 呢？RenderObject 中包含了所有用来渲染实例 Widget 的逻辑。它负责 layout、painting 和 hit-testing。它的生成十分耗费性能，所以我们应该尽可能的缓存它。我们把它在内存中尽可能的保存更长的时间，甚至回收利用它们（因为它们的实例化真的很耗费资源），这个时候 Element 就需要登场了。
Element 是存在于可变 Widget 树和不可变 RenderObject 树之间的桥梁。Element 擅长比较两个 Object，在Flutter里面就是 Widget 和 RenderObject。它的作用是配置好 Widget 在树中的位置，并且保持对于相对应的RenderObject 和 Widget 的引用。 为什么使用三个树而不是一个树呢？ 简而言之是为了性能。当 Widget 树改变的时候，Flutter 使用 Element 树来比较新的 Widget 树和原来的 RenderObject 树。如果某一个位置的 Widget 和RenderObject 类型不一致，才需要重新创建 RenderObject。如果其他位置的 Widget 和 RenderObject 类型一致，则只需要修改 RenderObject 的配置，不用进行耗费性能的 RenderObject 的实例化工作了。
因为 Widget 是非常轻量级的，实例化耗费的性能很少，所以它是描述 APP 的状态（也就是 configuration）的最好工具。重量级的 RenderObject（创建十分耗费性能）则需要尽可能少的创建，并尽可能的复用。就像 Simon 所说：整个Flutter APP就像是一个 RecycleView。 然而，在框架中，Element 是被抽离开来的，所以你不需要经常和它们打交道。每个 Widget 的 build（BuildContext context）方法中传递的 context 就是实现了 BuildContext 接口的Element，这也就是为什么相同类别的单个 Widget 不同的原因。
因为 Widget 是不可变的，当某个 Widget 的配置改变的时候，整个 Widget 树都需要被重建。例如当我们改变一个Container 的颜色为红色的时候，框架就会触发一个重建整个 Widget 树的动作。然后在 Element 的帮助下，Flutter 比较新的 Widget 树中的第一个 Widget 类型和 RenderObject 树中第一个 RenderObject 的类型。接下来比较 Widget 树中第二个 Widget 和 RenderObject 树中第二个 RenderObject 的类型，以此类推，直到 Widget 树和 RendObject 树比较完成。
Flutter遵循一个最基本的原则：判断新的 Widget 和老的 Widget 是否是同一个类型。 如果不是同一个类型，那就把 Widget、Element、RenderObject 分别从它们的树（包括它们的子树）上移除，然后创建新的对象。 如果是一个类型，那就仅仅修改 RenderObject 中的配置，然后继续向下遍历。 在我们的例子中，SimpleApp Widget 是和原来一样的类型，它的配置也是和原来的 SimpleAppRender 一样的，所以什么都不会发生。下一个 item 在 Widget 树中是 SimpleContainer Widget，它的类型和原来是一样的，但是它的颜色变化了，RenderObject的配置发生变化了。因为 SimpleObject 仍然需要一个 SimpleContainerRender 来渲染，Flutter只是更新了SimpleContainerRender 的颜色属性，然后要求它重新渲染。其他的对象都保持不变。
这个过程是非常快的，因为 Flutter 非常擅长创建那些轻量级的 Widgets。那些重量级的 RenderObject 则是保持不变，直到与其相对应类型的 Widget 从 Widget 树中被移除。那如果 Widget 的类型发生改变了会发生什么呢？
和原来一样，Flutter 会对 Widget 树的顶端向下遍历，与 RenderObject 树中的 RenderObject 类型进行对比。
因为 SimpleButton 的类型与 Element 树中相对应位置的 Element 的类型不同（实际上还是与 RenderObject 的类型进行比较），Flutter 将会从各自的树上删除这个 Element 和相对应的 SimpleTextRender。然后 Flutter 将会重建与 SimpleButton 相对应的 Element 和 RenderObject。
然后新的 RenderObject 树已经被重建，并将会计算布局，然后绘制在屏幕上面。Flutter内部使用了很多优化方法和缓存策略来处理，所以你不需要手动处理这个。
六. 平台嵌入器
我们已知道，Flutter 的界面构建、布局、合成和绘制全都由 Flutter 自己完成，而不是转换为对应平台系统的原生组件。获取纹理和联动应用底层的生命周期的方法，不可避免地会根据平台特性而改变。 Flutter 引擎本身是与平台无关的，它提供了一个稳定的 ABI（应用二进制接口），包含一个 平台嵌入层，可以通过其方法设置并使用 Flutter。
平台嵌入层是用于呈现所有 Flutter 内容的原生系统应用，它充当着宿主操作系统和 Flutter 之间的粘合剂的角色。当你启动一个 Flutter 应用时，嵌入层会提供一个入口，初始化 Flutter 引擎，获取 UI 和栅格化线程，创建 Flutter 可以写入的纹理。嵌入层同时负责管理应用的生命周期，包括输入的操作（例如鼠标、键盘和触控）、窗口大小的变化、线程管理和平台消息的传递。 Flutter 拥有 Android、iOS、Windows、macOS 和 Linux 的平台嵌入层，当然，开发者可以创建自定义的嵌入层，正如这个 可用的例子 以 VNC 风格的帧缓冲区支持了远程 Flutter。
每一个平台都有各自的一套 API 和限制。以下是一些关于平台简短的说明：
在 iOS 和 macOS 上， Flutter 分别通过 UIViewController 和 NSViewController 载入到嵌入层。这些嵌入层会创建一个 FlutterEngine，作为 Dart VM 和您的 Flutter 运行时的宿主，还有一个 FlutterViewController，关联对应的 FlutterEngine，传递 UIKit 或者 Cocoa 的输入事件到 Flutter，并将 FlutterEngine 渲染的帧内容通过 Metal 或 OpenGL 进行展示。
在 Android 上，Flutter 默认作为一个 Activity 加载到嵌入层中。此时视图是通过一个 FlutterView 进行控制的，基于 Flutter 内容的合成和 z 排列 (z-ordering) 的要求，将 Flutter 的内容以视图模式或纹理模式进行呈现。
在 Windows 上，Flutter 的宿主是一个传统的 Win32 应用，内容是通过一个将 OpenGL API 调用转换成 DirectX 11 的等价调用的库 ANGLE 进行渲染的。目前正在尝试将 UWP 应用作为 Windows 的一种嵌入层，并将 ANGLE 替换为通过 DirectX 12 直接调用 GPU 的方式。
七. 与其他代码进行集成
Flutter 提供了多种代码交互机制，无论你是在调用 Kotlin 或者 Swift 这些语言编写的代码或 API，或是调用 C 语言基础的 API，或是将原生代码能力嵌入 Flutter 应用，又或是将 Flutter 嵌入现有的应用。
7.1 平台通道
对于移动端和桌面端应用而言，Flutter 提供了通过 平台通道 调用自定义代码的能力，这是一种非常简单的在宿主应用之间让 Dart 代码与平台代码通信的机制。通过创建一个常用的通道（封装通道名称和编码），开发者可以在 Dart 与使用 Kotlin 和 Swift 等语言编写的平台组件之间发送和接收消息。数据会由 Dart 类型（例如 Map）序列化为一种标准格式，然后反序列化为 Kotlin（例如 HashMap）或者 Swift（例如 Dictionary）中的等效类型。
下方的示例是在 Kotlin (Android) 或 Swift (iOS) 中处理 Dart 调用平台通道事件的简单接收处理：
// Dart side const channel = MethodChannel('foo'); final String greeting = await channel.invokeMethod('bar', 'world'); print(greeting); 复制代码// Android (Kotlin) val channel = MethodChannel(flutterView, "foo") channel.setMethodCallHandler { call, result -> when (call.method) { "bar" -> result.success("Hello, ${call.arguments}") else -> result.notImplemented() } } 复制代码// iOS (Swift) let channel = FlutterMethodChannel(name: "foo", binaryMessenger: flutterView) channel.setMethodCallHandler { (call: FlutterMethodCall, result: FlutterResult) -> Void in switch (call.method) { case "bar": result("Hello, \(call.arguments as! String)") default: result(FlutterMethodNotImplemented) } } 复制代码更多关于如何使用平台通道的例子，包括 macOS 平台的示例，可以在 flutter/plugins 代码仓库 3找到。
7.2 在 Flutter 应用中渲染原生内容
由于 Flutter 的内容会绘制在单一的纹理内，并且 widget 树是完全在内部的，因此在 Flutter 的内部模型中无法存在 Android 视图之类的内容，也无法与 Flutter 的 widget 交错渲染对于需要在 Flutter 应用中展示原生组件（例如内置浏览器）的开发者来说，这是一个问题。
Flutter 通过引入了平台 widget (AndroidView 和 UiKitView) 解决了这个问题，开发者可以在每一种平台上嵌入此类内容。平台视图可以与其他的 Flutter 内容集成。这些 widget 充当了底层操作系统与 Flutter 之间的桥梁。例如在 Android 上，AndroidView 主要提供了三项功能：
拷贝原生视图渲染的图形纹理，在 Flutter 每帧渲染时提交给 Flutter 渲染层进行合成。
响应命中测试和输入手势，将其转换为等效的原生输入事件。
创建类似的可访问性树，并在原生层与 Flutter 层之间传递命令和响应。
但不可避免的是，这样的同步操作必然会带来相应的开销。因此该方法通常更适合复杂的控件，例如谷歌地图这种不适合在 Flutter 中重新实现的。
通常 Flutter 应用会在 build() 方法中基于平台判断来实例化这些 widget。例如在 google_maps_flutter 插件中：
if (defaultTargetPlatform == TargetPlatform.android) { return AndroidView( viewType: 'plugins.flutter.io/google_maps', onPlatformViewCreated: onPlatformViewCreated, gestureRecognizers: gestureRecognizers, creationParams: creationParams, creationParamsCodec: const StandardMessageCodec(), ); } else if (defaultTargetPlatform == TargetPlatform.iOS) { return UiKitView( viewType: 'plugins.flutter.io/google_maps', onPlatformViewCreated: onPlatformViewCreated, gestureRecognizers: gestureRecognizers, creationParams: creationParams, creationParamsCodec: const StandardMessageCodec(), ); } return Text( '$defaultTargetPlatform is not yet supported by the maps plugin'); 复制代码如上文所述，AndroidView 和 UiKitView 通常是利用平台通道的机制与原生进行通信。
目前桌面平台尚未支持平台视图，但这并不是一个架构层面的限制。未来可能将增加对桌面平台的支持。
7.3 在上层应用中托管 Flutter 内容
与上一个场景相反的是，将 Flutter widget 集成至现有的 Android 或 iOS 应用中。先前提到，新创建的 Flutter 应用，在移动设备上是在一个 Android 的 Activity 或 iOS 的 UIViewController 中运行。开发者可以使用相同的嵌入 API 将 Flutter 内容集成至现有的 Android 或 iOS 应用中。
Flutter 模块模板设计简单，易于嵌入。开发者可以将其作为源代码依赖项集成到 Gradle 或 Xcode 构建定义中，或者将其打包成 Android Archive (AAR) 或 iOS Framework 二进制供其他开发者使用，而无需安装 Flutter。
Flutter 引擎需要一段短暂的时间做初始化，用于加载 Flutter 的共享库、初始化 Dart 的运行时、创建并运行 Dart isolate 线程并将渲染层与 UI 进行绑定。为了最大限度地减少呈现 Flutter 界面时的延迟，最好是在应用初始化时或至少在第一个 Flutter 页面展示前，一并初始化 Flutter 引擎，如此一来用户不会在首个 Flutter 页面加载时感到突然地卡顿。另外，Flutter 的引擎分离使得多个 Flutter 页面可以复用引擎，共享必要库加载时的内存消耗。
更多将 Flutter 集成至现有的 Android 和 iOS 应用的内容，可在 控制加载顺序，优化性能与内存 文章中查看。
若你对 Flutter 的更多内部细节感兴趣 Flutter 工作原理 白皮书为框架的设计理念提供了很好的入门途径。
作者：ghroosk
链接：https://juejin.cn/post/7031503392102940709