|
[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的各项属性。
|
|
|
