Flutter性能问题分析思路&案例

Flutter泳道和各线程介绍

确认为Flutter页面：在应用进程中，有<number\>.raster和<number\>.ui线程的为Flutter页面。

线程介绍

platform线程

platform线程和应用包名，应用进程ID一样的一个线程，就是应用的主线程 ，主要是运行插件的相关线程，原生调flutter的组件或是和flutter通信会经过platform线程；比如flutter要打开蓝牙等功能，flutter本身不具备此功能，需要通过与platform通信线程来实现。

UI线程

UI线程在Dart VM中执行Dart代码。包括开发者写下的代码和Flutter框架根据应用行为生成的代码。该线程当应用创建和展示场景的时候，会计算组件的大小，位置，以及页面滑动过程中展示那些内容，UI线程首先建立一个 图层树（layer tree），“1.ui”多引擎的情况下这个数字会增加，trace上也会相应的增加。

新加入打点的trace：

1.raster线程

1.raster线程拿到layer tree，进行光栅化(将连续的几何图形转换为离散的像素点的过程)处理后，将Layer Tree转化为平台可执行的GPU指令，并将它交给 GPU（图形处理单元）。

1.raster线程本身则是在CPU上运行的，无法直接与GPU线程数据通信，它对应有一个gpu\_worker的线程，来保持与gpu的通信.但如果该线程变慢，可能是开发者 Dart 代码中的某处导致的。

新加入打点的trace：

I/O线程

执行复杂操作（常见的有 sockets, file handles等）以避免阻塞UI或raster线程，类似瀑布流，商品信息展示的图片，网络拉取图片，每个加载图片都有一个IO，耗时操作在后台运行。

Flutter信号传递流程

关键流程：

1.多模收到事件上报。

2.应用收到触摸事件,刷新UI并将数据提交到1.UI侧。

3.1.ui将计算页面元素坐标，位置生成图层树（layer tree），发送给1.raster。

4.1.raster线程拿到 layer tree，光栅化处理后并将它交给GPU。

5.在H:oh\_flutter\_1Surface的buffer数会加1。

6.rs侧收到绘制指令。

7.接收rs侧的vsync的信号。

8.GPU渲染完成并合成。

9.dpu\_gfx信号上屏。

案例分析

1.常规1.UI耗时表现。

问题表现：

**优化方案：ui线程主要做帧构建的处理，需业务侧降低页面复杂度，优化页面布局。

2.加载JavaScriptThrea和应用长帧导致响应时延不满足S标。

问题描述：点击响应时延 不满足S标（实测：314ms，S标：100ms，A标：150ms，IOS：221ms）。

点击响应耗时起始点确认：

起始点：搜索dispatchtouchevent，查找H:DispatchTouchEvent id:0, pointX=550.000000 pointY=1424.000000 type=1，如图1为起点。

截至点：根据测试数据的314ms，减去设备耗时15ms，整体的响应耗时为299ms，如图2为终点。

问题trace点分析：

查看1.ui线程执行1段时间后(下图1)出现了大段空闲时间，主线程执行一段时间后 唤醒了1.ui线程；

根据唤醒关系(下图2)，后面的一段空闲时间，都在javaScriptThrea上执行任务导致阻塞，耗时180ms，应用加载H5页面耗时。

原因2应用长帧耗时86.7ms，页面H:aboutToAppear耗时22.ms(下图2)，说明应用在初始化页面时，在生命周期aboutToAppear方法内执行了相关任务，下图2应用执行一段JS任务，耗时40ms；

下图3，应用对创建的自定义视图布局测算耗时17.8ms，UI元素较多，布局复杂；

优化方案：h5页面加载耗时建议使用预加载方案，减少资源加载耗时，长帧的优化需要应用排除具体的业务逻辑。

3.滑动响应延迟。

列表滑动 响应时延超S标（实测：106ms，S标：80ms，A标：120ms ）

问题描述：滑动丢帧卡顿超S标（实测：1，S标：0，A标：2）

滑动响应范围确认：

搜索框输入找到mmi\_service泳道，如下图红色1，2，选择mmi\_service泳道查看Y轴坐标详情，发现绿色1与2比较产生的位移，所以1为起始点；根据测试结果106ms，减去设备耗时15ms，从起始点开始，

后移91ms(下图红4)，找到对应结束点（下图红5）

trace分析：

滑动场景送显流程：mmi\_service-\>1.ui-\>1.raster-\>render\_service-\>上屏；

1.raster线程上requestbuffer flushbuffer之前耗时19.5ms，导致滑动响应延迟超S标；flutter侧框架问题导致。

优化方案：engine版本过低导致，应用侧更新engine。

4.滑动丢帧。

问题描述：

滑动丢帧卡顿超S标（实测：1，S标：0，A标：2）

丢帧范围确认：

测试数据

起始点：根据起始点，在搜索框内输入619360655或者少输入末尾一位找相近的时间节点(下图1)，找到卡顿开始节点(下图2)；

截至点：根据结束时间，或是持续时间，从起始时间开始数25ms(下图3)就是卡顿结束时间(下图3)，然后找到丢帧的范围(下图4)；

丢帧点：根据范围点，dpu信息到来前没有接收到present信号，确认丢帧点(下图5)；

flutter判断是否丢帧：

问题trace点分析：

根据下图1两侧的信号传递，发现图1的1.UI线程对应的1.raster线程信号丢失了，导致丢帧，初步分析为UI线程复杂导致(下图2)

优化方案：丢帧原因为应用页面布局复杂导致丢帧，需业务侧降低页面复杂度，优化页面布局。