[DESCRIPTION]
在测试手机各项功能过程中，经常会遇到概率性复现“屏幕画花了，界面画错乱了等绘制异常问题”，而且概率还非常小；
这类问题请不要直接提交eService，而是先请测试人员及工程师保留住测试现场，然后根据此条FAQ的步骤进行排查；
通常贵司提交问题的时候所提供的资料太少，无法直接定位问题，与其提交了eService之后再又去花时间复现，不如在复现问题的当下，就先按照FAQ的步骤做一个初步排查和分析。
如果在排查过程中，分析问题遇到困难，再将已经排查的结果以及排查过程中每一步所生成的资料和复现问题的log一并提交到eService。
这样的话我们就能获得较全面的资料并接着之前的排查结果做进一步分析，不然的话，我们还是需要贵司安排测试人员再花时间去复现，然后按照步骤抓取我们需要的资料，这大大降低了双方的工作效率，所以这条FAQ就是为了减少双方的工作量。
下图是显示相关的流程图：
[SOLUTION]
在如下3个大的check步骤中，请分别按照每一步的操作来进行排查；如果贵司有定位到某一个问题点，请在提eService时，将问题排查过程写清楚，并提供相应的资料到eService附件中，以便MTK做进一步分析。
1.通过DDMS或GAT tool获取异常界面的屏幕截图
[Android 5.0版本之前]DDMS 截图方法如下：Device --> Screen capture，点击Screen capture，就能抓到当前刷到LCM 屏上的那帧数据,或者通过Eclipse中的DDMS工具的screen capture功能，点击操作面板上的“照相机”图标即可。
=>如果屏幕截图是ok的，那么问题点就在LCM driver或timing，具体问题要具体分析。
=>如果屏幕截图not ok，那么你需要进入第2步去获取并查看FrameBuffer中的数据。
[Android 5.0版本及以后]
Android L版本上抓取到的DDMS截图，不是ovl output，而是GPU composer之后的画面。
若要抓取ovl output，可以输入如下命令
adb shell
system/bin/lcdc_screen_cap /data/fb.bin
2.获取FrameBuffer中的数据
对于android 4.1及以后的版本，通过如下方法抓取FrameBuffer中的数据：
先做如下操作，再dump framebuffer数据
先进入手机中Settings->Developer options->Disable HW overlays
再勾选Disable HW overlays
抓取framebuffer 数据： adb shell cat /dev/graphics/fb0 > /data/fb.bin 然后将fb.bin adb push出来，通过工具查看fb.bin
=>如果此步骤的屏幕截图是ok，那说明是LCM controller做overlay时出了问题。
需要把寄存器值打出来(保存在kernel log中)，再抓kernel log做进一步分析
打印寄存器的值：
请在当前刷屏时，将LCM controller寄存器打印出来，寄存器打印命令如下：
adb shell
echo reg:lcd>sys/kernel/debug/mtkfb
这条命令会将LCM controller的寄存器打印到kernel log中
抓kernel log的方式：要么开启mobile log，要么单独用adb命令抓取kernel log；
用adb命令抓取kernel log的方法是：adb shell cat /proc/kmsg > kernel_log.txt
如果分析问题原因是出在这一步，遇到困难时，请将抓取的资料都提供到eService附件中。
=>如果此步骤的屏幕截图not ok，那么就需要进入第3步，抓取layerdump。
3、抓取layerdump
在异常界面下，手机连接usb，执行抓取layerdump，抓取的方法根据android的版本不同而不同，下面会分别列出不同版本的抓取方法：
android 4.0~4.4的版本，分别介绍在windows环境下和linux 环境下如何抓取layerdump
在Windows系统环境下，将如下内容copy到新建文本文件中，然后保存文件为SF_layerdump_all.bat
保持手机连接usb并且在异常界面下，在电脑端双击鼠标执行该脚本(请在Windows系统下执行)，就会在脚本所在路径下生成一个文件SF_layerdump_all
将SF_layerdump_all和复现问题的mobile log一并提供到eService附件中。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SET raw=%1 SET layerdump=%2
IF "%raw%"=="" SET raw=0 IF "%layerdump%"=="" SET layerdump=-1
adb shell setprop debug.sf.layerdump.raw %raw% adb shell setprop debug.sf.layerdump %layerdump% adb shell dumpsys SurfaceFlinger > SF_layerdump_all.log adb shell mkdir /data/SF_dump adb shell mv /data/*.png /data/SF_dump adb shell mv /data/*.i420 /data/SF_dump adb shell mv /data/*.yv12 /data/SF_dump adb shell mv /data/*.RGBA /data/SF_dump adb shell mv /data/*.RGB565 /data/SF_dump rmdir /S /Q SF_layerdump_all md SF_layerdump_all move SF_layerdump_all.log SF_layerdump_all adb pull /data/SF_dump SF_layerdump_all/ adb shell rm /data/SF_dump/*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
注意：如果异常画面是动态的，不是那种静止不动的画面，那么可以尝试多执行几次layerdump，尽量争取能抓到发生问题时的画面的layerdump
如果不方便在Windows系统下抓取layerdump，那么就在linux系统的Terminal 下，按照如下步骤执行下面的指令:
在复现问题前，下如下这条命令，做设置并打开layerdump的开关：
adb shell setprop debug.sf.layerdump.raw 1
adb shell setprop debug.sf.layerdump -1
在即将开始复现问题前，先将下面的指令准备好，在复现问题的画面，敲回车执行这条命令，就是做layerdump的动作，
如果复现问题的画面是动态的，请多下几次这条命令，尽量把复现问题的画面dump下来
adb shell dumpsys SurfaceFlinger >SF_layerdump_all.log
执行了上面的第3条命令之后，会在手机的/data/SF_dump目录下生成一些xxx.png或*.i420,*.yv12,*.RGBA,*.RGB565等文件，请把data/SF_dump这个目录pull出来提供给我们，还有SF_layerdump_all.log文件也一并需要提供。
android 5.0及以后的版本，在windows环境下如何抓取layerdump
在Windows系统环境下
若异常画面是静态稳定的，将如下内容copy到新建文本文件中，然后保存文件为SF_bqdump_L.bat
@echo off
adb shell rm /data/SF_dump/* adb shell setprop debug.bq.dump "@surface"
adb shell "dumpsys SurfaceFlinger" > SF_bqdump_all.log
adb shell setprop debug.bq.dump ""
rmdir /S /Q SF_bqdump_all md SF_bqdump_all move SF_bqdump_all.log SF_bqdump_all adb pull /data/SF_dump SF_bqdump_all/ adb shell rm /data/SF_dump/*
echo "Please view dump files in folder ‘SF_bqdump_all‘" pause
若异常画面是一闪而过的，则需用如下脚本dump画面刷新过程的几十帧画面，下面是设置30帧：SF_cont_bqdump_L_30.bat
复现问题后，双击执行下面的脚本，接着按命令行提示“按电脑任意键继续”，然后等几秒钟，系统会自动dump复现过程的所有帧到指定目录
@echo off
adb shell rm /data/SF_dump/*
:: Modified this line to set surface count,default is 30 adb shell setprop debug.bq.dump "@surface#30"
adb shell "dumpsys SurfaceFlinger > /dev/null"
pause
adb shell setprop debug.bq.dump "@surface"
adb shell "dumpsys SurfaceFlinger" > SF_bqdump_all.log
adb shell setprop debug.bq.dump ""
rmdir /S /Q SF_bqdump_all md SF_bqdump_all move SF_bqdump_all.log SF_bqdump_all adb pull /data/SF_dump SF_bqdump_all/ adb shell rm /data/SF_dump/*
echo "Please view dump files in folder ‘SF_bqdump_all‘" pause
注意：抓取到layerdump后，请将layerdump的所生成的文件SF_layerdump_all(在Linux环境下就是手机的data/SF_dump目录和SF_layerdump_all.log文件)和复现问题的mobile log一并提交到eService上来。
抓到layerdump之后，根据layerdump的结果，再做下一步分析；
如果layerdump看到的目标画面not ok，则参考如下FAQ做进一步确认，看是app本身的问题还是UI framework绘制的问题；
[DESCRIPTION]
在遇到界面显示异常等问题的时候，需要排查界面异常是由哪个处理过程所引起的，画面显示的过程，大致上可以分为：
1、上层app定义view 大小、位置，和画面对应的layout；
2、View system处理view的这些属性，计算view tree的大小、位置、处理view的绘制逻辑；
3、native framework处理绘图指令，未开启硬件加速绘制时，是使用Skia图形库来执行绘图指令；如果开启了硬件加速，则是GPU来执行绘图指令
当前这个FAQ就是要提供方法来抓取View hierarchy，排查第1、2这两个步骤是否出现问题
[SOLUTION]
抓取方法是：
1、将手机用usb连接至电脑，确保手机软件版本是eng load，或者userdebug load，才可以抓View hierarchy，如果是user load，且没有打开对应的debug权限，则不可以抓；
2、打开Android sdk提供的Android Debug Monitor工具或Eclipse，进入DDMS这个视图界面；
3、打开Devices显示界面，在Devices的进程列表上方的那一排button中，找到最右边的button，将鼠标悬浮在button上方，显示的文字是"Dump View Hierarchy for UI Automator"；
4、在复现了画面显示异常的界面，保持画面不动，点击第3步中的那个button开始dump，完了之后系统会自动打开所dump到的文件，文件名是dump_xxx.uix，xxx通常是一串数字；
5、将鼠标移到文件名上，会悬浮显示出此文件的存放 folder 名称及路径，folder 命名格式为: uiautomatorviewer_xxxxx，xxxxx也是一串数字，将此folder打包提供给我们分析即可；
如果是自己分析该文件，那么直接在已经打开了的文件中，查看异常位置处的view的状态和属性是否正确即可，将鼠标移动到view的位置时，view会被红色虚线框highligh出来，右边的属性列表中会显示出该view的各项属性。