flutter 卡顿_Flutter渲染性能优化全攻略（解决应用卡顿）

大规模应用开发过程中，性能优化是重中之重，其中包括了包体积，UI 渲染、交互等多个方面。

在之前的文章中，我通过 Flutter 应用的混淆为入口，探讨了应用包体积优化的实践方案，本文，我把话题再次转到渲染性能上来。

这里，也会涉及到一个非常关健的概念 ——「FPS，Frame Per Second」即「每秒展示帧数」，它代表了应用的流畅度。我们知道，动画和物体动态的运动都是由在一段时间内一系列连续变化的静态帧构成的。

在考虑应用的渲染性能时，我们就是在试图分析应用每秒渲染的帧数。

从物理角度看，对于连续的一系列图像帧，人脑会根据眼睛发出的视觉信号做出反应，一个个静态帧的切换到达一定速度后，就可以欺骗我们的大脑，让我们以为它们是连续的，FPS 就是图像帧切换的速度单位。因此有人说，物体运动的概念其实就是一种思维的束缚。

当 FPS 达到 10-12 时，大脑便可以感知运动，但此时并不流畅，达到 24 FPS 时，人眼就能看到流畅的运动了，但是在电影和视频中，则至少需要每秒 60 帧的速度才可以使人的大脑轻松感知到流畅地运动。

帧数不同的感觉

因此，就有了下面这个公式：1000ms / 60 frames = 16.666 ms/frame

我们需要在 16.66 毫秒内完成整个帧的计算，布局和渲染，否则不流畅，就需要掏出我们的 24K 合金双摄眼，找到优化点，让应用保持流畅。

定位优化方向

那么，当我们想优化 Flutter 应用的渲染性能时，入口点在哪里。Flutter 应用的每一帧都由框架层和引擎层互相协作完成。

最初，某些外部事件(如手势，网络等)或者异步任务会导致屏幕更新，该消息消息页会通知到引擎层。Flutter 框架层会拦截了该请求，执行 Tickers 相关的任务(如动画)。

这些任务也可能会重新发出一个请求，以供以后的帧渲染。(如动画暂停后再继续，需要在以后的阶段接收另一个 Begin 帧)。

然后，引擎层就可以开始做屏幕渲染工作了，但在开始之前，Flutter 框架依然会拦截该请求，并根据当前的组件结构和尺寸大小计算出更新布局、绘制相关的所有数据。

完成这些任务后，如果最终确定真的要在屏幕上绘制一些东西，它就会将需要渲染的新数据发送到 Flutter Engine，做最终的屏幕更新。

整个过程都在 Flutter 的 UI 线程中运行，如若阻塞，就会卡顿。

通常，应用开发者不需要关心引擎层的逻辑，但并不意味着我们不需要关心渲染性能。

引擎层的功能其实也是单一的，他只是拿到框架层的数据去做渲染而已。但是框架层是由我们控制的，我们所写的每一个组件都在框架层之上。

如何将传递给引擎层的更新数据做到最优，就是渲染优化时我们需要考虑的问题。

这些更新数据就是由