现在的位置是： 小猿圈 > 【问题回溯】记录处理launcher3滑动卡顿问题_android launcher3去掉抽屉模式后滑动翻页卡帧

项目

Android14，展锐T606

问题背景

老平台升级Android13升级到Android14，对此问题无影响

问题描述

客户反馈在launcher应用列表中滑动卡顿明显，选中的刷新率为60hz

分析过程

初步分析

先精确问题，自测发现只有launcher中滑动会掉帧，在其他应用不会掉帧

直接自己抓trace看，掉帧发生时的trace中，直接宏观观察app和sf出帧姿态，不是常规的卡顿掉帧，是稳定的出一帧掉一帧，帧率为30fps

app这边不用看了，因为app发生挤压的原因是dequeuebuffer在等待sf唤醒，不是执行耗时；而sf这边因为本身需要合成的时候没有合成，让app等待，才造成app挤压。

所以下一步是看sf为什么稳定掉帧

如下两图，选取任意两帧，其中A帧不掉，B帧掉，进行分析，发现其差异在B帧没有setSfWakeUp这个动作，并且多了scheduleFrame动作后中断合成

继续追溯到源码中，在surfaceflinger模块搜索isFencePending，找到相关源码的对应逻辑

在SurfaceFlinger::commit函数中，进行了isFencePending判断，B帧为true，退出。含义为fence未被release。

初步结论：fence未被release，造成掉帧。

下一步：继续查看为什么fence不释放，造成稳定的掉帧。

挖根因

目前继续从trace中查看，也不知道查看哪一路信号量。

尝试从其他的log类型获取信息。

既然问题出在合成阶段，那就dump一下launcher应用列表界面的sf，看看合成情况

adb shell dumpsys SurfaceFlinger > sf.txt

如果是解锁后的debug版本，还可以打开以下宏控，然后抓取ylog

adb root
adb remount
adb shell setprop debug.hwc.info 1
adb shell setprop debug.gsp.info 1
adb shell setprop debug.dpu.info 1

adb shell "echo 0x3 > /sys/module/drm/parameters/debug"

从sf中可以看到当前合成的图层信息，其中很明显的是Wallpaper有一个缩放动作，从4k缩到720p

因为缩放是采用的GSP合成，此芯片GSP合成慢，可能是这个原因导致gsp合成超时，fence释放慢，引发的掉帧问题。

如果开启了上述宏控，还能从抓到的ylog中搜索gsp相关信息：

目前能得出一个信息：和gsp合成相关

所以可以到trace中继续搜索gsp信号，能搜到如下信息

能看到此处的drm在等待gsp-core唤醒，而gsp-core为sleep状态，该trace中无法进一步往更底层追查。

结合目前的信息，能得到如下影响链：

壁纸为4k->bsp合成耗时长->drm等待超时->fence不能在一个vsync内释放->sf拿不到fence不进行合成->掉帧

验证观点

为了验证这一观点，可将合成方式强制转换为更快的gpu合成。

可用于验证是否合成方式引发的掉帧

方式：设置->开发者选项中->打开停用hw叠加层

打开后，再进行测试，现象未见卡顿，从trace中未见掉帧，dump sf也能看到wallpaper的合成方式变为了GPU。

这说明之前的分析是正确的

修改和验证

拍摄照片，查看相册中照片的分辨率，为4k。进到设置中，分别尝试将系统自带的壁纸资源和拍摄的4k照片设置为壁纸，都不会有掉帧现象，说明设置中修改壁纸时，会对资源做裁剪。

进一步更新现象为：在系统默认的壁纸下，launcher中进行滑动会稳定30fps。

所以，只需要将源码中默认壁纸的尺寸换为720p的，就可以处理此问题。

注：

1.GSP合成慢是芯片的瓶颈，只能想办法不用gsp合成，即修改图片尺寸，使用dpu合成。

2.为什么不强制使用gpu合成？因为功耗会很高，强制gpu合成仅作为debug手段，排查是否合成方式导致的掉帧。

默认壁纸存放路径：
framework/base/core/res/res/drawable-sw720p-noapi/default_wallpaper.png

结论和反思

结论

壁纸为4k->bsp合成耗时长->drm等待超时->fence不能在一个vsync内释放->sf拿不到fence不进行合成->掉帧

遂修改默认壁纸的尺寸为720p，不让其以gsp方式合成

反思

之后出现类似问题，在前方保留现场时，除了要求trace以外，应同步要一下sf的dump。这次问题是自己抓取信息，所以随时可以抓取，以后场景就不一定了。分析到一半再要求需要的信息，会比较拖节奏