![]()
作者：谢伟(韦圣)
不同的业务背景引出不同的技术诉求，“用户体验特爽”是淘特的不懈追求，本文将介绍笔者加入淘特以来在Flutter流畅度方面的诸多优化实践，这些优化不涉及Engine改造、不涉及高大上的“轮子建设“，只需细心细致深入业务抽丝剥茧，坚持实际体感导向，即能为用户体验带来显著提升，值得Flutter开发者将其应用在产品的每一个像素。
背景
淘特具备鲜明的三大特征：
- 业务特征：淘特拥有业界最复杂的淘系电商链路
- 用户特征：淘特用户中有大量的中老年用户，大量的用户手机系统版本较低，大量的用户使用中低端机
- 技术特征：淘特大规模采用Flutter跨平台渲染技术
综上所述：
最复杂业务链路+最低性能用户群体+最新的跨平台技术==>核心问题之一：页面流畅度受到严峻挑战
| Flutter核心链路 |
20S快速滚动帧率 |
卡顿率(每秒卡顿率) |
| 直播Tab |
27 |
7.04% |
| 我的 |
41.3666 |
7.63% |
| 详情 |
26.7 |
15.58% |
注：相关数据以vivo Y67，淘特
3.32.999.10 (103) 测得
目标
流畅度是用户体验的关键一环，大家都不希望手机用起来像看电影/刷PPT，尤其是现在高刷屏(90/120hz)的普及，更是极大强化了用户对流畅度的感知，但流畅度也跟产品复杂度强相关，也是一次繁与简的取舍，淘特流畅度一期优化目标：
Flutter核心链路页面达到高流畅度(平均帧率：低端机45FPS、中端机50FPS、高端50FPS)
一期优化后的状态
| 事项 |
平均帧率 |
卡顿率 |
提升效果 |
| 1.直播Tab推荐、分类栏目 |
46.0 |
0.35% |
帧率提高19帧、卡顿率降低6.7% |
| 2.我的页面 |
46.0 |
0% |
帧率提高4.6帧，卡顿率降低7.6% |
| 3.详情 |
45.0 |
2% |
帧率提高18.3桢，卡顿率降低13.58% |
旧版3.32如视频左，新版3.37如视频右。因uiautomator工具会触发无障碍性能ISSUE，此版本对比为人工测试。
视频请见：淘特 Flutter 流畅度优化实践
除了数据上的明显提升，体感上，旧版快滑卡顿明显，画面突变明显，新版则基本消除明显的卡顿，画面连续平稳。
问题
回到技术本身，Flutter为什么会卡顿、帧率低？总的来说均为以下2个原因：
- UI线程慢了-->渲染指令出的慢
- GPU线程慢了-->光栅化慢、图层合成慢、像素上屏慢
那么，怎么解上述的 2 个问题是咱们所关心的重点。既然知道某块有问题，我们自然要有工具系统化的度量问题水平，以及系统化的理论支撑实践，且看以下2节，过程中穿插相关策略在淘特的实践， 理论与实践结合理解更透。
怎么解
解法 - 案例
降低setState的触发节点
大家都知道Flutter的刷新机制，在越高的Widget树层级触发setState标脏Element，“脏树越大”，在越低层级越局部的Widget触发状态更新，“脏树越小”，被标记为脏树后将触发Element.Rebuild，遍历组件树。原理请看下图“Flutter页面刷新机制源码解析”:
![]()
![]()
![]()
“Element.updateChild源码分析”请见下文优化二。
实际应用淘特为例。直播Tab的视频预览功能为例，最初直播Tab的视频播放index通过状态层层传递给子组件，一旦状态变更，顶层setState触发播放index更新， 造成整个页面刷新。但实际整个页面需要更新状态的只有“需要暂停的原VideoWidget”和“待播放的VideoWidget”， 我们改为监听机制，页面中的所有VideoWidget注册监听，顶层用EventBus统一分发播放index至各VideoWidget，局部Widget Check后改变自身状态。
再比如详情页，由于使用了“上一个页面借图”的功能，监听到滚动后隐藏借的图，但setState的调用节点放在了详情顶层Widget，造成了全局刷新。实际该监听刷新逻辑可下放至“借图组件”，降低“脏树”的大小。
![]()
![]()
缓存不变的Widget
缓存不变的Widget有2大好处。1.被缓存的Widget将无需重复创建， 虽然Flutter官方认为Widget是一种非常轻量级的对象，在实际业务中，Build耗时过高仍是一种常见现象。2.返回相同引用的Widget将使Flutter停止该子树后续遍历， 即Flutter认为该子树无变化无需更新。原理请看下图“Element.updateChild源码分析”
![]()
应用场景以淘特实际页面为例。详情页部分组件使用了DXWidget，理论上组件内容一经创建后当次页面生命周期不会再有变化，此种情况即可缓存不变的Widget，避免重复动态渲染DX，停止子树遍历。
Feed流的Item组件，布局复杂，创建成本较高，理论上创建一次后内容也不会再变化，但item可能被删除，此时应该用Objectkey唯一标识组件，防止状态错位。
![]()
![]()
![]()
减少不必要的build(setState)
直播Tab用到一个埋点曝光组件，经过DevTools检查，发现其在每一次进度回调中重新创建itemWidget，虽然这不会造成业务异常，但理论上itemWidget只需被创建一次，这块经排查是使用组件时误传了builder函数，而不是直接传itemWidget实例。
详情页的逻辑非常复杂，AppBar根据滚动距离实时计算透明度，这会导致高频的setState，实际上透明度变化前后应该满足一个差值后才应刷新一次状态， 为了性能考量，透明度应该只有少数几种值变更。
![]()
![]()
多变图层与不变图层分离
在日常开发中，会经常遇到页面中大部分元素不变，某个元素实时变化。如Gif，动画。这时我们就需要RepaintBoundary，不过独立图层合成也是有消耗，这块需实测把握。以淘特为例。
直播Feed中的Gif图是不断高频跳动，这会导致页面同一图层重新Paint。此时可以用RepaintBoundary包裹该多变的Gif组件，让其处在单独的图层，待最终再一块图层合成上屏。
同理， 秒杀倒计时也是电商常见场景， 该组件也适用于RepaintBoundary场景。
![]()
![]()
避免频繁的triggerGC
因为AliFlutter的关系，我们得以主动触发DartGC，但GC同样也是有消耗的，高频的GC更是如此。淘特之前因为iOS的内存压力，在列表滚动停止时ScrollEndNotification则会触发GC，ScrollEndNotification在每一次手Down->up事件后都会触发一次，如果用户多次触摸，则会较为频繁的触发GC，实测影响Y67 4帧左右的性能，这块增加页面不可见时GC 和在Y67等android低端机关闭滑动GC，提高滑动性能。
![]()
大JSON解析子线程化
Flutter的isolate默认是单线程模型，而所有的UI操作又都是在UI线程进行的，想应用多线程的并发优势需新开isolate 或compute。无论如何await，scheduleTask 都只是延后任务的调用时机，仍然会占用“UI线程”， 所以在大Json解析或大量的channel调用时，一定要观测对UI线程的消耗情况。在淘特中，我们在低端机开启json解析compute化，不阻塞UI线程。
![]()
尽量减少或降级Clip、Opacity等组件的使用
Flutter中，Clip主要用于裁剪，裁矩形、圆角矩形、圆形。一旦调用，后续所有的绘图指令都会受其Clip影响。有些ClipRRect可以用ShapeDecoration代替，Opacitiy改用AnimatedOpacity， 针对图片的Clip裁切，可以走定制图片库Transform实现。
![]()
降级CustomScrollView预渲染区域为合理值
默认情况下，CustomScrollView除了渲染屏幕内的内容，还会渲染上下各250区域的组件内容，即如双列瀑布流，当前屏幕可显示4个组件，实际仍有上下共4个组件在显示状态，如果setState（加载更多时），则会进行8个组件重绘。实际用户只看到4个，其实应该也只需渲染4个， 且上下滑动也会触发屏幕外的Widget创建销毁，造成滚动卡顿。高性能的手机可预渲染，淘特在低端机降级该区域距离为0或较小值。
![]()
高频埋点 Channel批量化操作
在组件曝光时上报埋点是很常见的行为，但在快速滚动的场景下， 瞬间10+ item的略过，20+ channel的调用同样会占用一定的UI线程资源和Native UI线程资源。这里淘特针对部分场景做了批量、定时上传， 维护一个埋点队列，默认定时3S或50条，业务不可见时上报，合并20+channel调用为单次。业务也可在合适时机点强制flush队列上报， 同时在Native侧，将埋点行为切换至子线程进行。
其他有效优化措施
部分业务特效，业务繁忙度在低端机上都是可以适度降级的，如淘特将Feed视频预览播放延迟时间从500ms降为1.5S，Feed流预加载阈值距离从2000+降为500，图片圆角降直角等降级措施的核心思路都是先保证最低端的用户也能用的顺畅，再美化细节锦上添花。
Flutter在无障碍开启情况下，快速滚动场景存在性能问题，如确定业务无需无障碍或用户误触发无障碍，可添加ExcludeSemantics Widget屏蔽无障碍。
通过DevTools检测，发现high_available高可用帧率检测在老版本存在性能问题，这块可升级插件版本或低端机屏蔽该检测。
解法 - 优化案例总结
上述十条优化实践，抛开细节看原理，大致分为以下几类， 融会贯通，实践出真知。
如何提高UI线程性能：
-
如何提高build性能
-
如何提高layout性能
-
如何提高paint性能
- RepaintBoundary分离多变和不变的图层，如Gif、动画， 但多图层的合成也是有开销的
-
其他
-
耗时方法如大JSON解析用compute子线程化
-
减少不必要的channel调用或批量合并
-
减少动画
-
减少Release时的log
-
提高UI线程在Android/iOS的优先级
-
列表组件支持局部build
-
较小的cacheExtent值，减少渲染范围
如何提高GPU线程性能：
- 谨慎saveLayer
- 尽量少ClipPath、一旦调用，后续所有绘图指令需与Path做相交。(ClipRect、ClipRRect等)
- 减少毛玻璃BackdropFilter、阴影boxShadow
- 减少Opacity使用，必要时用AnimatedOpacity
解法 - 测量工具
工欲善其事，必先利其器。工具主要分为以下两块。
- 流畅度检测：无需侵入代码的流畅度检测方案有几种， 既可以通过adb取surfaceflinger数据， 也可以基于VirtualDisplay做图像对比，或者使用官方DevTools。第三方比较成熟的如PerfDog
- 卡顿排查：DevTools是官方的开发配套工具，非常实用
- Performance检测单帧CPU耗时(build、layout、paint)、GPU耗时、Widget Build次数
- CPUProfiler 检测方法耗时
- Flutter Inspector观察不合理布局
- Memory 监控Dart内存情况
DevTools
Flutter分为三种编译模式，Debug/Release大家都很熟悉，Debug最大特性为HotReload可调试，Release为最高性能，Profile模式则取其中间，专用于性能分析，其产物以AOT模式无限接近Release性能运行，又保留了丰富的性能分析途径。
如何以Profile模式运行flutter？
如果是混合工程，android为例，在app/build.gradle添加profile{init with debug}即可， 部分应用资源区分debug/profile，也可Copy一份profile。当然，更hack更彻底的方式，可直接修改$flutterRoot/packages/flutter_tools/gradle/flutter.gradle文件中buildModeFor方法，默认返回想要的Profile/Release模式。
如何在Profile模式下打开DevTools？
推荐使用IDE的flutter attach 或者 命令行采用flutter pub global run devtools，填入observatory的地址，即可开始使用DevTools。
Flutter Performance&Inspector
以AS为例，右侧会出现Flutter Performance和Inspector2个功能区。Performance功能区如下图：
![]()
Overlay效果如下图。可以看到有2排柱状图，上方为GPU帧耗时，下方为CPU耗时，实时显示最近300帧情况，当当前帧耗时超过16ms时，绿色扫描线会变红色， 此图常用于观察动态过程中的“瞬时卡顿点”。
![]()
Inspector较为简单，可观看Widget树结构和实际的Render Tree结构，包含基本的布局信息，DevTools中Inspector包含更详细信息。
![]()
![]()
DevTools&Flutter Inspector
![]()
DevTools&Performance
![]()
![]()
Performance功能是性能优化的核心工具，这里可以分析出大部分UI线程、GPU线程卡顿的原因。为方便分析，此图用Debug模式得来，实际性能分析以Profile模式为准。
如上图1所示，Build函数耗时明显过长，且连续数十帧如此，必然是Build的逻辑有严重问题。理论上Widget创建一次后状态未改变时无需重建。由前文淘特案例可以发现，这里实际是业务错误的在滚动进度回调中重复创建Widget所致。实际的Build应只在瀑布流Layout逻辑中创建执行2次。
Paint函数详情可在debug模式通过debugProfilePaintsEnabled=true开启。当多变的元素与不变的元素混在同一图层时可造成图层整体的过度重复绘制， 如元素内容无变化，Paint函数中也不应出现多余元素的绘制耗时。通过前面提及的Repain RainBow开关或debugRepaintRainbowEnabled=true， 可实时观察重绘情况，如下图所示。
每一个图层都有对应的不同颜色框体。只有发生Repaint的图层颜色会发生变化，多余的图层变色，我们就要排查是否正常。
![]()
GPU耗时过多一般源于重量级组件的过度使用如Clip、Opacity、阴影， 这块发现耗时过多可参考前文解法进行优化或降级， 关于GPU更多的优化可参考liyuqian的高性能图形引擎分享。
在图1最下方的CPU Profile即代表当帧的CPU耗时情况，BottomUp方便查找最耗时的方法。
DevTools&CPU Profiler
![]()
在Performance的隔壁是CPU Profiler，这里用于统计一段时间内CPU的耗时情况，一般根据方法名结合经验判断是业务异常还是正常耗时，根据visitChilddren-->getScrollRenderObject方法名搜索，发现高可用帧率监控存在性能问题。
Devtools还有内存、Debugger、网络、日志等功能模块，这块流畅度优化中使用不多，后续有更好的经验再和大家分享。
DebugFlags&Build
![]()
上图是一张针对build阶段常见的debug功能表， debugPrintRebuildDirtyWidgets开关将在控制台打印什么树当前正在被重建，debugProfileBuildsEnabled作用同Performance的Track Widget Builds，监控Build函数详情。前3个字段在debug模式使用，最后一个可在Profile模式使用。
DebugFlag&Paint
![]()
上图是一张针对Paint阶段常见的debug功能表。debugDumpLayerTree()函数可用于打印layer树，debugPaintLayerBordersEnabled可在每一个图层周围形成边界（框），debugRepaintRainbowEnabled作用同Inspector中的RainBow Enable， 图层重绘时边框颜色将变化。debugProfilePaintsEnabled前文已提到，方便分析paint函数详情。
![]()
展望
以上便是淘特Flutter流畅度优化第一期实践，也是体感优化最明显的的一期优化。但距离极致的用户体验目标仍有不小的差距。集团同学提供了很多秀实践学习。如UC Hummer的Engine流畅度优化， 闲鱼的局部刷新复用列表组件PowerScrollView、线上线下的高精准多维度检测卡顿，及如何防止流畅度优化不恶化的方案， 淘特也在不断学习成长挑战极限，在二期实践中，为了最极致的体验，淘特将结合Hummer引擎，深度优化高性能图片库、高性能流式容器、建立全面的线下线上数据监控体系，做一个”让用户爽的淘特App“。
参考资料
关注【阿里巴巴移动技术】微信公众号，每周 3 篇移动技术实践&干货给你思考！
