Flutter 流畅度优化实践总结

5. UI Thread RenderObject 树 Layout、Paint 生成 Scene 对象，最后传递给 Raster Thread 进行绘制上屏；

上述流程，必须要 16.6 ms 内完成，才能保证不掉帧。大部分情况，不需要构建新的卡片，但当新卡片进入列表区域时，整个计算量就会变得巨大，尤其是在复杂的业务场景下，如何保证在一帧 16.6ms 内完成全部计算，是一个不小的挑战。

上图是一次滑动 devtool 样例，卡顿阶段都是新卡片上屏时发生，其他阶段均很流畅，因为滚动速度在衰减，所以卡顿间隔也在变大。因为大部分时候都很流畅，所以平均 FPS 不低。但新卡片构建时的产生画面停顿，给我们的卡顿体感却很明显。

▐  动态能力的挑战 - Flutter DynamicX

闲鱼 App 卡片使用自研 Flutter DynamicX 来支持我们的动态能力。基本原理：在线编辑布局 DSL，生成 dx 文件并下发。端侧通过解析 dx 文件，并结合后台卡片数据，生成 DXComponentWidget，最后生成 Widget Tree。Flutter DynamicX 技术给闲鱼带来动态更新的能力，统一监控能力（如在 DXComponentWidget 监控卡片创建），良好研发体感（在线 DSL 和 Android Layout 基本一致，对 Android 开发优化），在线编辑能力；

但在性能上，我们也付出了一定的代价：DX 卡片相比增加了模板装载和数据绑定开销，Widget 要通过 WidgetNode 递归遍历动态创建，视图嵌套层级会更得更深（后续讲述）。

说明：Flutter DynamicX 参考阿里集团 DSL 规则实现

▐  用户体感的挑战

前面已经讲述过，相同 FPS 下，Flutter 列表的卡顿体感更明显；

在 Android RecycleView 发生小卡顿（16.6*2ms）时，体感并不明显，而 Flutter 列表在发生卡顿时，不仅时间上停顿，滑动 Offset 上也发生了跳变，为此小卡顿的体感也变得明显了；

假设列表内容足够简单，滚动不会发生卡顿，我们也发现 Flutter 列表和 Android RecycleView 也不太一样：

1. 使用 ClampingScrollPhysics，在列表快停止的时候，会感受到类似磁铁吸住的感觉。

2. 使用 BouncingScrollPhysics，列表滚动开始时，速度衰减的更快；

在 90hz 机器上，早期 Flutter 列表并不流畅，原因是部分机器上，触控采样率是 120hz，屏幕刷新率是 90hz，导致部分画面是 2 次触控事件，部分是 1 次触控事件，最后导致滚动 offset 发生跳变。在 Flutter 1.22 版本时，可以使用 resamplingEnabled 对触控事件进行重采样。

列表容器和FlutterDx组件优化

讲述了 Flutter 流畅度优化的挑战，现在来分享闲鱼如何优化流畅度，并沉淀进 PowerScrollView 和 Flutter Dynamic 组件。

▐  Power****ScrollView 设计和性能优化

PowerScrollView 是闲鱼团队自研 Flutter 列表组件，在 Sliver 协议上有了更好的封装和补充：数据增删改方面，补充了局部刷新；布局方面，补充了瀑布流；事件方面，补充了卡片上屏、离屏、滚动事件；控制方面，补充了滚动到 index 的能力。

在性能方面，补充了瀑布流布局优化、局部刷新优化、卡片分帧优化和滑动曲线优化。

▐  Powe****rScrollView 瀑布流布局

PowerScrollView 瀑布流布局提供了纵向布局、横向布局、混排布局（横向卡片和普通卡片混排）。现在闲鱼大部分列表页面均采用 PowerScrollView 的瀑布流布局，如首页同城页、搜索结果页等。

▐  PowerS****crollView 瀑布流布局优化

首先通过常规的缓存优化，缓存每个卡片左上角 x 值和属于哪一列。

相比 SliverGrid 卡片是并排进入列表区域，而瀑布流布局，我们需要定义 Page，卡片入场创建和离场销毁需要以 Page 为单位。优化前，Page 以屏幕可视区域为单位计算卡片，同时为了确定 Page 的起点 Y 值，一次布局需要计算 Page N 和 N+1 二页，所以参与布局计算的卡片量较多，性能变低。优化后，使用全部卡片高度平均值的近似值计算 Page，极大减少参与布局卡片的数量，同时 Page 离场销毁的卡片数量也变少。

经过列缓存和分页优化，使用闲鱼自研 benchmark 工具（后续介绍）对比瀑布流和 GridView，查看丢帧数和最差帧耗时，能发现性能表现基本一致。

▐  PowerScrollVi****ew 局部刷新优化

闲鱼产品期望用户浏览商品更流畅，不会被 loadmore 加载打断，所以列表在滚动过程中就需要触发 loadmore。Flutter SliverList 在 loadmore 补充卡片数据时，会对 List 控件标脏，而标脏后 SliverList build 会销毁全部卡片并重新创建，此刻性能数据能想象非常的差。PowerScrollView 提供了布局刷新优化：缓存屏幕上的全部卡片，不再重新创建，UI Thread 耗时从原来的 34ms 优化至 6ms（见左下图），右图查看 Timeline，视图构建的深度和复杂度均有明显优化。

▐  PowerScrollView 卡片分帧优化

左图2个卡片是闲鱼早期搜索结果页，当时还不是瀑布流。查看卡片创建时的 Timeline 图（补充了 Dx Widget 创建 和 PerformLayout 开销），可以发现一次卡片创建的复杂度极大，在普通中端机器上，UI Thread 耗时机已经超出 30ms，要优化至 16.6ms 以内，用常规的优化手段就很困难了。为此想象 2 个卡片能否拆解掉，各自使用 1 帧的时间去渲染。

直接看源码，基本思想是：对卡片 Widget 进行标记，在左边卡片真实创建的时候，右边卡片先 _buildPlaceholderCell 构建占位 Widget（空的 Container），并注册监听下一帧。在下一帧，右边卡片进行修改 needShowRealCell 为 true，并自我标脏，此后构建真实内容。

延迟构建卡片真实内容，是否会对显示内容产生影响？因为 Flutter 列表在可视区域上下还有 CacheExtends 区域，这部分区域用户不可见。为此在大部分场景下，用户并不会看到空白卡片的场景。

同样使用 Flutter BenchMark 工具进行性能测试，能看到卡片分帧前后 90分位，99分位帧耗时都有明显的降级，丢帧数也从 39 降低至 27

这里注意，监听下一帧的时候，需要 WidgetsBinding.instance.scheduleFrame() 触发 requestFrame。因为在列表首屏显示的时候，有可能因为没有下一帧的回调，导致延迟显示队列的任务没有执行，最终使得首屏内容显示不正确。

▐  延迟****分帧优化思路和使用建议

对比 Flutter 和 H5 设计比较接近：

1. dart 和 js 都是单线程模型，跨线程通信需要走序列化和反序列化；

2. Flutter Widget 和 H5 vDom 类似，都有一个 Diff 过程。

早期 FaceBook 在 React 优化时，提出了 Fiber 架构：基于 vDom tree 的父节点→子节点→兄弟节点→子节点的方式，将 vDom tree 转化为 fiber 数据结构（链式结构），进而实现 reconcile 阶段的可中断可恢复；基于 fiber 数据结构，控制部分 fiber 节点在下一帧继续操作。

基于 React Fiber 思路，我们提出了自己的延迟分帧优化，不只是左右卡片粒度，更进一步，将渲染内容拆解为当前帧任务、高优延迟任务和低优延迟任务，上屏优先级依次变低。其中当前帧任务，是左右 2 个空白 Container；高优延迟任务独占一帧，其中图片部分也使用 Container 占位；在闲鱼场景，我们把全部的 DX Image Widget 从卡片内拆解出来，作为低优延迟任务，并设置在一帧消费不超过 10 个。

通过将 1 帧显示任务拆解到 4 帧时间，高端机上最高 UI 耗时从 18ms 优化至 8ms。

说明1：不同业务场景下，高优任务和低优任务设置要有所不同 说明2：在低端机（如 vivo Y67）上快速列表滑动，分帧方案会让用户看到列表变白和内容上屏的过程

▐  Flu****tter-DynamicX组件优化-原理详解

在线编辑“类 Android Layout DSL”，编译生成二进制 dx 文件。端侧通过文件下载、加载和解析，生成 WidgetNode Tree，见右图。

之后结合后台下发的业务数据，通过递归遍历 WidgetNode Tree 动态生成 Widget Tree，最后显示上屏。

说明：Flutter DynamicX 参考阿里集团 DSL 规则实现

▐  Flutt****er-DynamicX组件优化-缓存优化

知道了原理，就容易发现上图红色框中的流程：二进制（模板）文件解析装载、数据绑定、Widget 动态创建都有一定的开销。为避免反复开销，我们对 DxWidgetNode 和 DxWidget 均进行了缓存，蓝色选中代码展示了 Widget 缓存。

▐  Flutte****r-DynamicX组件优化-独立 isolate 优化

此外，将上述逻辑放置到独立 isolate 中，最大限度的将开销降低至最低。经过线上技术灰度 AB 实验，平均卡顿坏帧比例从 2.21% 降低至 1.79%。

▐  Flut****ter-DynamicX组件优化-层级优化

Flutter DynamicX 提供了类 Android Layout DSL，为实现每个控件 padding、margin、corner 等属性，增加了 Decoration 层；为实现类 Android FrameLayout、LinearLayout 布局能力，增加了 DXContainerRender 层。每一层都有自己的清晰职责，代码层次清晰。但也因为增加 2 层导致 Widget Tree 层级变深，3棵树的 Diff 逻辑变得复杂，性能变低。为此，我们将 Decoration 层和 DXContainerRender 层进行了合并，查看中间 Timeline 图，可以发现优化后的燃焰图层级和复杂度都变低。经过线上技术灰度 AB 实验，平均卡顿坏帧比例从 2.11% 降低至 1.93%。

性能衡量和devtool扩展

讲述了优化手段，这里讲述我们的流畅度性能如何做衡量，以及工具的构建/扩展。

▐  线****下场景-flutter benchmark

检测 Flutter 每帧耗时，需要统计 UI Thread 和 Raster Thread 上的计算耗时。所以 Flutter 优化前后比较，使用 SchedulerBinding.instance.addTimingsCallback 获取每一帧的 UI Thread 和 Raster Thread 的耗时数据。

此外，流畅度性能数值受操作手势、滚动速度影响，所以基于人工操作的测量结果会存在误差。这里使用 WidgetController 控制列表控件 fling。

工具提供设置滚动速度、滚动次数、滚动之间的间隔时间等。滚动测试完成后，显示 UI 和 Raster Thread 丢帧数，50分位、90分位、99分位的帧耗时等数据，从多种维度给出了性能数据。

▐  线****下场景-基于录屏的流畅度检测

flutter benchmark 在 flutter 页面给出了多维度的测量数据，但有时候我们需要横向比较竞品 App，所以我们需要有工具横向比较不同技术栈的页面流畅度。闲鱼在 Android 端自研了基于录屏数据的流畅度检测。将手机界面想象成多个画面，通过向系统录屏服务 MediaProjection 注册获取 VirtualDisplay，间隔 16.6 ms读取其中的画面数据（字节数组），这里使用字节数组的 hash 值代表当前画面，当前后 2 次读取的 hash 值不变，则认为发生了卡顿。

为了保证流畅度检测工具 app自身不发生卡顿，这里读取的是压缩画面数据，低端机上压缩比例要更高

通过工具无侵入的检测，可以检测到一次滚动测试，平均 FPS 值（图中 57），帧分布均方差（7.28），1s 时间发生的大卡顿次数平均值（0.306），大卡顿累计时间（27.919）。中间数组展示帧分布情况：371 代表正常帧数量，6 代表 16.62ms 的小卡顿数量，1 代表 16.63ms 的卡顿数量。

这里大卡顿的定义是：大于 16.6*2 ms 的卡顿

▐  线下****场景-基于devtool的性能检测

此外，闲鱼线下场景也扩展了 devtool。在一次 Timeline 图扩展了每个阶段的耗时，大于 16.6ms 红色高亮显示，便捷了开发使用。

▐  线下场景-Flutter高可用检测FPS实现原理

在线上场景，闲鱼自研了 Flutter 高可用。基本原理是基于2个事件：

• ui.window.onBeginFrame 事件

• engine 通知 Vysnc 信号到来，通知 UI Thread 开始准备下一帧画面构建

• 触发 SchedulerBinding.handleBeginFrame 回调

• ui.window.onDrawFrame 事件

• engine 通知 UI Thread 开始绘制下一帧画面

• 触发SchedulerBinding.handleDrawFrame 回调

这里我们在 handleBeginFrame 处理之前，记录一帧开始事件，在 handleDrawFrame 之后记录一帧的结束。这里每一帧都需要计算列表控件 offset 值，具体代码实现见右图。在整个累计超过 1s 时，执行一次计算，使用 offset 过滤掉没有发生滚动的场景，使用每一帧的时间计算 fps 值。

▐  线上****场景-FlutterBlockCanary线上卡顿堆栈检测

使用 Flutter 高可用计算得到线上 FPS 数值后，如何定位卡顿问题，需要收集堆栈信息。闲鱼使用自研的 FlutterBlockCanary 收集卡顿堆栈。基本原理是，在 C 层轮询发送信号，比如 5ms 一次，每次信号接收触发 dart UI Thread 堆栈采集，对得到的一系列堆栈进行聚合，连续多次相同堆栈就认为是发生了卡顿，这时这个堆栈就是我们想要的卡顿堆栈。

上图是 FlutterBlockCanary 采集的堆栈信息，中间 FrameFpsRecorder.getScrollOffset 就是发生卡顿的调用。

**▐  线****上场景-****FlutterBlockCanary检测过度渲染

**

此外，FlutterBlockCanary 也集成了过度渲染检测的能力。通过复写 WidgetsFlutterBinding 的 buildOwner 方法替换 BuildOwner 对象，进而重写 scheduleBuildFor 方法，实现拦截脏 element。基于脏 element 节点，提取出脏节点的深度、直接子节点的数量、全部子节点的数量。

基于全部子节点数量，在闲鱼详情页，我们定位到“快速提问视图”在滚动过程中，频繁被标脏和全部子节点数量过大。查看代码，定位该视图层级过高，通过将视图下沉到叶子节点，一次标脏 build 节点数量从 255 优化至 43。

Flutter 滑动曲线优化

前面讲述了卡顿优化手段和衡量工具和标准，主要还是围绕着 FPS。但从用户体感出发，我们发现 Flutter 也有很多可优化点。

▐  Flutter 列表滑动曲线和原生曲线

分别对比 offset/time 的滚动曲线，可以发现 Flutter BouncingScrollSimulation 和iOS 滚动曲线接近，ClampingScrollSimulation 和 RecyclerView 接近。查看 Flutter 源码注释，也确实是如此。

因为 BouncingScrollSimulation 具有回弹能力，所以很多下拉刷新和加载更多功能，都是基于 BouncingScrollSimulation 封装实现，这也就造成 Flutter 页面滑动时，体感和原生 Android 页面不一致的原因。

▐  Flutter 列表在快速滑动下的表现和优化

虽然 ClampingScrollSimulation 滑动曲线和 Android RecyclerView 接近，但在快速滑动场景下，可以发现 Flutter 列表滚动快停止的时候会像磁铁吸住一般，快速滑动一下停止。究其原因，可以看到滑动曲线快停止的瞬间，速度并不是下降，而会加快，最后到达终点，快速停止。基于源码公式，绘制曲线，可以发现，Flutter ClampingScrollSimulation 是通过公式拟合方式，去逼近 Android RecyclerView 曲线（BSpline）。在快速滑动的情况下，公式曲线的重点并不是 1 对应的值，而是右图虚线位置，速度会变快。

可以理解 Flutter 的公式拟合结果并不理想，为此近期也有 PR 提出使用 dart 实现了 RecyclerView 曲线。

▐  Flutter 列表在卡顿情况下的表现和优化

第一章提过相同 FPS 情况下，如 FPS 55，原生列表感受流畅，而 Flutter 列表的卡顿体感更明显。这里一个原因是原生列表通常有多线程操作，出现大卡顿的概率更低；另一个原因是，相同小卡顿的体感，Flutter 有明显的卡顿感，而原生列表几乎感受不出来。那这是为什么呢？

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
4年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。**

[外链图片转存中…(img-e4oFUnpI-1715516823233)]

[外链图片转存中…(img-fjmrbnNM-1715516823237)]

[外链图片转存中…(img-gRDoHl7v-1715516823238)]

[外链图片转存中…(img-YuffjdMD-1715516823239)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！