UI 线程在 Dart VM 执行 Dart 代码。该线程包括开发者写下的代码和 Flutter 框架根据应用行为生成的代码。当应用创建和展示场景的时候，UI 线程首先建立一个 图层树(layer tree) ，一个包含设备无关的渲染命令的轻量对象，并将图层树发送到 GPU 线程来渲染到设备上。不要阻塞这个线程！在性能图层的最低栏展示该线程。

GPU 线程

GPU 线程取回图层树并通知 GPU 渲染。尽管无法直接与 GPU 线程或其数据通信，但如果该线程变慢，一定是开发者 Dart 代码中的某处导致的。图形库 Skia 在该线程运行，有时也被叫做光栅器 (rasterizer) 线程。在性能图层的最顶栏显示该线程。

I/O 线程

可能阻塞 UI 或者 GPU 线程的耗时任务（大多数情况下是 I/O）。该线程并不会在性能图层中展示。

所以，我们做性能优化，关心DartUI，关心GPU两个线程，掉不掉帧，卡不卡的关键，就看这两位了，而且在99%情况下，作为Flutter开发人员，我们我们基本上解决好，DartUI线程上的问题，就==解决了渲染性能问题。

三棵树

Widget是为Element描述需要的配置，负责创建Element，决定Element是否需要更新。Flutter Framework通过差分算法比对Widget树前后的变化，决定Element的State是否改变。当重建Widget树后并未发生改变，则Element不会触发重绘，则就是Widget树的重建并不一定会触发Element树的重建。
Element表示Widget配置树的特定位置的一个实例，同时持有Widget和RenderObject，负责管理Widget配置和RenderObject渲染。Element状态由Flutter Framework管理，开发人员只需更改Widget即可。
RenderObject表示渲染树的一个对象，负责真正的渲染工作，比如测量大小、位置、绘制等都由RenderObject完成。

为了更加直观的表示3个树的从生到死，我不得不抛出下面这幅图来

然后，我们经常在做性能调优的时候，会用到timeline工具，你会看到这样一幅图：

现在串起来了吗，4个线程，build---layout---paint三个阶段是不是都一目了然，各发生在什么地方，什么阶段，谁先谁后。

所以，我们说要解决卡顿掉帧的问题，就是要解决build,layout,paint这三个阶段各函数执行耗时的问题。

具体如何做性能优化

首先，我们配置下环境，这里我配置这个变量debugProfileBuildsEnabled=true不然，我不知道build他具体做了些啥，观望台默认不会告诉我。一般来说，放在main函数中，在runApp之前开启即可，比如我是这么干的：

这里面有一些其他需要用到的开关，可以在数据不足的时候开启，这样我们参考的数据多些，优化的参考点就明确些。

然后，我们执行 flutter run --profile ,请记住，我们需要在profile模式来性能调优，debug模式因为在渲染过程中记录了很多分析数据且加上支持热重载的特性是损失了很多性能为代价的，profile模式更加接近release模式性能。

然后跑起来了，会出现一个链接：

点一下就去了观望台了，当然，你也可以使用devTools，貌似后面会取代观望台。devTools的启动姿势是：

flutter pub global activate devtools
devTools

先安装，然后在直接运行即可：

点击这个链接，会弹出一个网页来，让你输入url，这个url就是我们那个观望台的url，因此你似乎秒懂了，然来，devTools是在观望台的基础至上做的一个分析工具，所以，Google一定是觉得观望台不大友好了，然而，遗憾的是，devTools并不是特别全面，因为现在还是preview阶段嘛，一切都会好起来的。