Flutter流畅度优化神器-开源组件keframe详解

当下贝壳移动端业务中有大量的 Flutter 页面，新代理作为去年成立的业务线也在广泛使用。在享受 Flutter 带来的高效开发同时，我们也发现了项目中一些 Flutter 页面存在明显的卡顿现象，实际业务场景中，我们就遇到了这样一个示意页面。

这是一个竖向的列表，其中每一行的item是三个 TextField。如图中 Performance OverLay 显示一般，Profile 模式下这个页面在 Vivo X23 (骁龙 660)上出现了严重的卡顿。

1. 基本原理

我们知道，对于滑动列表的这个过程，其实是由一个个的画面组成，术语称为帧。对于大部分人而言，当每秒的画面达到 60，也就是俗称 60FPS 的时候，整个过程就是流畅的。而不及 60FPS 的时候，可能产生卡顿的感觉。

一秒 60 帧，也就意味着平均两帧之间的间隔为 16.7ms。通过系统提供的 DevToools 工具可以查看到，上面的例子中出现卡顿时一帧的耗时高达 130ms。

2. 系统绘制一帧需要经历哪些阶段？

为什么一帧的耗时会超过16.7ms？为了搞清楚这个问题我们需要知道，Flutter为了绘制一帧会做些什么？

绘制过程分析：首先 dart 通过 Window_scheduleFrame 方法调用 engine，之后 engine 向 Choreographer 注册一个 vsync 回调。等到下一个 vsync 信号来到时，通过 nativeOnVsync 将整个渲染任务 post 到 UI task 的队列中，回调到 Flutter之后经历以下流程：

关键步骤有三：

Build：通过widget 配置生成 Element 与 RenderObject 树

Layout：遍历 RenderObject 树，测量每一个页面元素的大小与决定位置

Paint：根据 RenderObject 树中的节点生成 Layer 树，合成语义化后提交给 engine 给 GPU 进行渲染

图中的卡顿问题主要由于 build 阶段耗时过长，而对于列表组件过程会更复杂一点。

Flutter 的列表一般都采用 Lazy Build 的方式生成列表单元，当列表单元接近可见区域的时候，列表根据视窗高度与缓存区大小，动态构建和布局多个 item。

如果 item 比较复杂，比如一个耗时 10ms，屏幕加上缓存区同时构建 10 个 item，共耗时 100ms，自然发生了卡顿。结合 DevTools的数据也验证了这个过程。

不管是对于列表还是非列表而言，卡顿大多由于构建耗时引起。从本质来看，就是一个模块的执行时间过长。

1. 基本思路

由于卡顿的本质原因是一个模块的执行时间过长，自然有两个思路去解决：

A、降低模块复杂度：在这上面我们也进行了一些实践，比如：列表增量更新，绘制优化、模态的 TextField、 状态管理对项目中存在的不合理刷新进行优化等。

B、在不优化模块的情况下，将模块拆分到每个一帧中，提升流畅度，即分帧优化

假设，我们屏幕能显示4个item，每个item构建耗时是10ms。在现有的ListView布局过程中，会在第一帧的时候，同时构建这四个item，总共40ms。采用分帧之后，在页面的第一帧我们先通过构建简单的占位item，占位的item可以是个简单的Container。由于其构建基本不耗时，在第一帧的时候构建四个Container不会导致卡顿。之后将实际的四个item，分别延迟到后面四帧进行渲染。这样对于每个16.7ms而言，都没有发生超时渲染，整个流程不会发生卡顿。

2. 方案设计与实现

设计条件分帧队列实现，其原理如图：

这个设计可以用三个关键字理解：条件、分帧、队列

条件：首先，为了不影响系统本身的渲染过程，整个队列会在系统渲染完成之后才被调度。但是任务并非立刻执行，而是需要满足一定的条件，参考系统的权重值的枚举，我为每个任务定义一个权重值，当权重值满足策略配置时才可执行。

例如，如果我们的任务权重是 Priority.idle 时，这样的任务只会在完全空闲时刻执行（与定义的调度策略有关）。如果此时屏幕上有一个不间断的动画，那么整个 task 队列就会被阻塞。

分帧：在满足策略的情况下，队列中的所有任务不会同时执行。每一帧只移除队列中的首位元素，当然下一个任务执行之前还会进行权重判断。

队列：任务先进先出，并且有容量上限。

2. 分帧流程

例如，对于列表构建场景来说，假设屏幕上能显示五个 item。首先在第一帧的时候，列表会渲染 5 个占位的 Widget，同时添加 5 个高优先级任务到队列中，这里的任务可以是简单的将占位 Widget 和实际 item进行替换，也可通过渐变等动画提升体验。在后续的五帧中占位 Widget 依次被替换成实际的列表 item。

当然分帧方案也非十全十美，在我看来主要有两点成本：

1. 额外的构建开销：整个构建过程的构建消耗由「n * widget消耗 」变成了「n *（ widget + 占位）消耗 + 系统调度 n 帧消耗」。可以看出，额外的开销主要由占位的复杂度决定。如果占位只是简单的 Container，测试后发现整体构建耗时大概提升在 15 % 左右。这种额外开销对于当下的移动设备而言，成本几乎可以不计。

   
   

2. 视觉上的变化：如同上面的演示，组件会将 item 分帧渲染，页面在视觉上出现占位变成实际 widget 的过程。但其实由于列表存在缓存区域（建议将缓存区调大），在高端机或正常滑动情况下用户并无感知。而在中低端设备上快速滑动能感觉到切换的过程，但比严重顿挫要好。

1. 列表流畅度优化

代码中 example 运行在 VIVO X23（骁龙 660），在相同的滚动操作下优化前后 200 帧采集数据指标对比：

采用分帧优化后，卡顿次数从 平均 33.3 帧出现了一帧，降低到 200 帧中仅出现了一帧，峰值也从 188ms 降低到 90ms。卡顿现象大幅减轻，流畅帧占比显著提升，整体表现更流畅。下方是详细数据。

2. 页面切换流畅度提升

在打开一个页面或者 Tab 切换时，系统会渲染整个页面并结合动画完成页面切换。对于复杂页面，同样会出现卡顿掉帧。借助分帧组件，将页面的构建逐帧拆解，通过 DevTools 中的性能工具查看。切换过程的峰值由 112.5ms 降低到 30.2 ms，整体切换过程更加流畅。

在 pubspec.yaml 中添加 keframe 依赖

更多说明请查看：

• github 地址：

  https://github.com/LianjiaTech/keframe

• pub 地址：

  https://pub.dev/packages/keframe

欢迎大家交流。