2020-08-06 display 各种场景流程 --显示异常问题处理指导手册 <一>

基本思路

每个项目QC过程都会遇到一定数量的显示异常问题,这种问题常常较难排查原因,因为牵涉的模块比较多,想要理清是哪一模块出问题,需要对整个display

flow 有所了解。根据经验,敝司整理出简单的排查flow,可以根据异常的现象,对号入座,初步筛查出哪个模块的问题,在进行深入分析。

首先可找对比机平台是否复现,如果对比平台复现,请客户自行找app vendor 解决。

      如果对比机不复现,可以先勾选Setting -> Developer options -> Disable HW overlays后看问题是否复现。

    (1)如果不复现,表示推给GPU叠图后,显示正常,就需要找HWC owner进一步check 原因,这时候往往需要HWC log。HWC log 会打印在ged.log中,cat log 后提供给MTK进行分析。

adb shell cat /d/ged/gedlog > ged.log

    (2)如果还复现,表示无论GPU 或者HWC 叠图,都可以复现问题,需要往前看哪一步异常。通常会先做BQ dump,BQ dump

是dump 所有给surfaceflinger 前BufferQueue中的数据,具体哪些flow

经过bufferqueue,后面一章的data flow有show 出,可以参考。

      1) dump的图片异常,如是普通UI,请先check SF_bqdump_all.log 中该图层对应layer的mConnectedApi讯息,1表示GPU 绘制,2表示用CPU绘制,其余两种很少碰见。

NATIVE_WINDOW_API_EGL = 1,

NATIVE_WINDOW_API_CPU = 2,

NATIVE_WINDOW_API_MEDIA = 3,

NATIVE_WINDOW_API_CAMERA = 4,

如果mConnectedApi=2,直接找skia onwer分析CPU为何画错;

如果mConnectedApi=1,由于某些app是适配某一种GPU去开发的,所以可以先rename GPU的name看是否正常。如在高通不复现,mali GPU 复现,可以rename成高通的,如下是rename成高通308的CMD,

adb shell setprop debug.gpu.fake_gpu_vendor 'Qualcomm'

adb shell setprop debug.gpu.fake_gpu_renderer 'Adreno (TM) 308'

如果rename成对比平台GPU依然复现,鉴于P版本render

pipeline 改版,由O版本默认的HWUI改成skiaGL,所以可以切换成和O版本一样看问题是否复现。如不复现,找skiaGL owner

check,如复现就找GPU owner check,GPU

onwer通常会抓MGD或者pvrtrace或者Gapid去看怎么画错的,具体如何抓取和如何初步分析,后面第三章会具体介绍。

切Opengl:adb shell "setprop debug.hwui.renderer opengl"

切回去: adb shell "setprop debug.hwui.renderer ''"

如果是camera 或者video 场景的画面异常,

有一层layer通常是surfacetexture,这是一个raw

data,需要用特殊的工具解析出图片是否正常。如异常,直接找camera或者video owner check。如正常,还要看另外一层layer

surfaceview是否正常,这层layer是surfacetexture 经过GPU

render后的结果,通常使用glSurfaceview实现。如果surfaceview正常,就走dump

图片正常的flow,如果异常,可以先找GPU owner,不过也有例外,即不是GPU的问题,要具体问题具体对待。

2) dump的图片正常,可以录screenrecord看录出来的视频是正常,如正常,极有可能是display driver的问题,如不正常,找HWC owner check HWC flow。

下面是具体的flow,如果比较熟悉或经验比较丰富,也可不按照该步骤check,直接分析即可。


Classic Multimedia Data Path

      结合第一章显示异常的Guildline,在了解常见场景的data path,这对于分析问题很有帮助。下面介绍几种常见场景的data flow。由于app写法不一,这里介绍的是最常见的,如遇复杂场景,可以通过抓取systrace了解其flow。

1, 普通UIdata flow

普通UI 的flow 很简单,一般情况下硬件加速都默认开启,所以大部分UI都是通过GPU 绘制后给surfaceflinger 叠图。如果关掉硬件加速,会推给CPU skia 绘制,遇到这种问题,根据第一章Guildline下即可知道哪个模块有问题。


2, Video播放的data flow

Video 播放的data flow 分为两种类型,surfacetexture和surfaceview ,两者的异同点网上有很多,可以自行搜寻了解。

除了做BQ Dump,也可以dump decode output

直接看给surfacefliger或者GPU的surfacetexture是否正常,如果有过MDP,也可以看MDP input 和 output

是否正常。Dump的方法不同平台和android 版本不同,可咨询相应的onwer。

i. surfaceview


ii. surfacetexure


3, Camera data flow

     Camera 场景同video,preview data

分surfacetexture和surfaceview。如video场景一样,如果不抓BQ dump,可抓camera output

看camera送出来的数据是否正常。注意:camera output 是已经过了MDP以后的数据。

i. surfaceview


ii. surfacetexure


4, Recording

i. Camera Recording

     这里以camera preview出surfacetexture为例介绍camera 录屏的data flow,如果是surfaceview,给sf的一路换成3中surfaceview的data flow即可。

     因为是录屏,所以这里codec为encode。一般录出来的视频不带特效,所以camera data直接送给encode 编码,但是不少三方app 录出来的视频都加了特效,所以会在过GPU 给encode。


ii. Common Recording




i

你可能感兴趣的:(2020-08-06 display 各种场景流程 --显示异常问题处理指导手册 <一>)