「Android」adb调试源码（针对dumpsys SurfceFlinger、trace.txt获取）
首先对adb作简单的阐述，接下来对adb shell dumpsys surfaceflinger服务的dump信息的查看、以及anr问题如何获取trace文件并简单分析。
-×**************************************************************
目录：
一、adb
五、trace分析
-×*************************************************************
一、adb
（1）
三、dumpsys使用
（1）adb shell 进入shell
（2）dumpsys -l 查看所有正在运行的服务名
service list 查看这些服务名称调用了哪个服务
下面列举了其中一些服务名：
| 服务名 | 类名 | 功能 |
|---|---|---|
| activity | activitymanagerservice | ams相关信息 |
| package | packagemanagerservice | pms相关信息 |
| window | windowmanagerservice | wms相关信息 |
| input | inputmanagerservice | ims相关信息 |
| power | powermanagerservice | pms相关信息 |
| batterystats | batterystatsservice | 电池统计信息 |
| battery | batteryservice | 电池信息 |
| alarm | alarmmanagerservice | 闹钟信息 |
| dropbox | dropboxmanagerservice | 调试相关 |
| procstats | processstatsservice | 进程统计 |
| cpuinfo | cpubinder | cpu |
| meminfo | membinder | 内存 |
| gfxinfo | graphicsbinder | 图像 |
| dbinfo | dbbinder | 数据库 |
| 服务名 | 功能 |
|---|---|
| surfaceflinger | 图像相关 |
| appops | app使用情况 |
| permission | 权限 |
| processinfo | 进程服务 |
| batteryproperties | 电池相关 |
| audio | 查看声音信息 |
| netstats | 查看网络统计信息 |
| diskstats | 查看空间free状态 |
| jobscheduler | 查看任务计划 |
| wifi | wifi信息 |
| diskstats | 磁盘情况 |
| usagestats | 用户使用情况 |
| devicestoragemonitor | 设备信息 |
（3）dumpsys <service> 打印具体某一项服务（service就是前面表格中的服务名）
dumpsys cpuinfo //打印一段时间进程的cpu使用百分比排行榜 dumpsys meminfo -h //查看dump内存的帮助信息 dumpsys package <packagename> //查看指定包的信息 dumpsys surfaceflinger //查看sf服务
四、dump surfaceflinger的打印信息分析
surfaceflinger的dump信息主要通过dumpalllocked 函数来获取。
一般包含：
1、layer的信息，layer一般对应于一个surface;
2、opengl的信息。一般是跟gpu比较相关的参数，opengl是标准的接口;
3、display。安卓支持三种类型的display，可以导出display当前的显示状态，也就是各个surface(layer)在各个display的显示属性;
4、surfaceflinger管理graphis buffer的信息。主要是layer申请的帧数据内存;
5、hwcomopser的如果实现dump接口也能知道hwcomposer的一些参数;
6、gralloc的内存分配信息。如果gralloc有实现dump接口的话;
（1）特殊宏的打开
build configuration: [sf] [libui] [libgui]
（2）打印目前正在使用的sync机制
sync configuration: [using: egl_android_native_fence_sync egl_khr_wait_sync]
（3）打印layer
visible layers (count = 9)
count的值来源于layerssortedbyz中layer的数量，接下来就进入各个layer的dump。
例如：
> 0xb3f92000指向当前layer对象的值,括号中是当前layer的名称,id是创建layer时产生的序列号：
+ layer 0xb3f92000 (com.sec.android.app.launcher/com.android.launcher2.launcher) id=87
> 区域信息，两段是两个region的dump,每个region可能包含多个区域,所以这里count也可能不等于1，
前两行的值来源于activetransparentregion,表示的是这个layer里面透明区域的大小，
后两行值来源于visibleregion,表示可见区域的大小：
region transparentregion (this=0xb3f92164, count=1)
[ 0, 0, 0, 0]
region visibleregion (this=0xb3f92008, count=1)
[ 0, 0, 1440, 2560]
> 基本信息：
layerstack= 0, z= 21010, pos=(0,0), size=(1440,2560), crop=(0, 0,1440,2560), isopaque=0, invalidate=0, alpha=0xff, flags=0x00000000, tr=[1.00, 0.00][0.00, 1.00] client=0xb11160c0
对应的dumpalllock中的源码：
result.appendformat(
"layerstack=%4d, z=%9d, pos=(%g,%g), size=(%4d,%4d), crop=(%4d,%4d,%4d,%4d), "
"isopaque=%1d, invalidate=%1d, "
"alpha=0x%02x, flags=0x%08x, tr=[%.2f, %.2f][%.2f, %.2f]\n"
" client=%p\n",
s.layerstack, s.z, s.transform.tx(), s.transform.ty(), s.active.w, s.active.h,
s.active.crop.left, s.active.crop.top,
s.active.crop.right, s.active.crop.bottom,
isopaque(s), contentdirty,
s.alpha, s.flags,
s.transform[0][0], s.transform[0][1],
s.transform[1][0], s.transform[1][1],
client.get());
-
layerstack表示这个layer是保存在哪个layerstack中(不同的display是有不同的layerstack的);
-
z表示z轴坐标,z值越大,layer越靠上;
-
pos的值是layer左上角的位置,这个值比较特殊的是imagewallpaper这个layer的pos值,因为imagewallpaper的大小大于屏幕大小,所以imagewallpaper的pos值在屏幕的外面(note4是pos=(-560,0)).
-
size自然是layer的大小;
- crop代表裁剪区域,这点依然是对于壁纸很明显,因为壁纸layer大小大于屏幕,必须涉及到需要裁剪一部分显示在屏幕上,因此它的裁剪区域是crop=( 560, 0,2000,2560);
- isopaque代表是否是不透明的,只有完全不透明的layer这个值才是1,比如壁纸,像状态栏和launcher他们都是0,代表不是完全不透明;
- invalidate表示这个layer的数据是失效的,这个值绝大多数情况下都是0.因为我们看到的一般都是绘制好的有效的数据.一种情况下这值特别频繁的多见为1,就是刚刚锁屏(解锁)时.因为突然锁屏,会导致绘制的内容和要显示的内容完全不同,导致layer的各种数据要重新计算,所以将layer置为失效;
- alpha表示了这张layer的透明度,这个值跟isopaque是有区别的.isopaque表示了这个layer可以是透明的,也就是没有显示数据的地方,可以透明;而alpha表示透明度,也即是有数据的地方也可以因为透明度而收到影响产生透明的效果;
- flag值含义丰富,它是众多flag或出来的结果，会a影星layer的状态;
- 接下来的一组tr数据代表屏幕的旋转和缩放程度.大多数的layer实际上是不需要旋转和缩放的,因为他们定义的大小就是跟屏幕一致的,所以他们的这组数据是[1.00, 0.00][0.00, 1.00],实际上如果你使用这组数据来做矩阵变换的话,矩阵是不会发生变化的.需要旋转的比较典型的场景是照相机.横着拿相机时它的layer的变换矩阵是[-1.00, 0.00][-0.00, -1.00],也就是旋转180°. 这个值的来源是上层调用setmatrix函数设置的.
- client含义比较简单,值的来源是创建layer时,对应的surfacesession中mnativeclient.这东西也是跟surfacesession一一对应的,也就是跟surfaceflinger连接时一一对应的.从这个值我们可以判断,client值相同的layer,必然来自同一个进程(因为他们是由同一个连接创建出来的).
（4）打印displays信息
首先会打印当前display的数量,数量基于mdisplays的大小,这个容器在surfaceflinger初始化时会生成数据,后面根据收到不同的消息在handletransactionlocked函数中也会调整.
正常情况下是1,也就是只有一个display(built-in screen),当设备连接了hdmi或者使用了屏幕共享等功能时,会有额外的display加入。
displays (2 entries) //这个是连接了hdmi后的数据
+ displaydevice: hdmi screen
type=1, hwcid=1, layerstack=6, (1920x1080), anativewindow=0xb4d94d08, orient= 0 (type=00000000), flips=1173, issecure=1,
securevis=0, powermode=2, activeconfig=0, numlayers=1
v:[0,0,1920,1080], f:[0,0,1920,1080], s:[0,0,1920,1080],transform:[[1.000,0.000,-0.000][0.000,1.000,-0.000][0.000,0.000,1.000]]
mabandoned=0
-bufferqueue mmaxacquiredbuffercount=2, mdequeuebuffercannotblock=0, default-size=[1920x1080], default-format=1, transform-hint=00,
fifo(0)={}
[00:0xb6418c80] state=free , 0xb43ed880 [1920x1080:1920, 1]
[01:0xb43cb300] state=free , 0xb640d970 [1920x1080:1920, 1]
>[02:0xb43cb280] state=acquired, 0xb43ed830 [1920x1080:1920, 1]
+ displaydevice: built-in screen //displaydevice是设备的名字,这个可以调用接口设置,但是比较常见的值一般有:built-in screen,hdmi screen,virtual screen,wfdservice等等
type=0, hwcid=0, layerstack=0, (1080x1920), anativewindow=0xb4d94608, orient= 0 (type=00000000), flips=3140, issecure=1,
securevis=0, powermode=2, activeconfig=0, numlayers=2
v:[0,0,1080,1920], f:[0,0,1080,1920], s:[0,0,1080,1920],transform:[[1.000,0.000,-0.000][0.000,1.000,-0.000][0.000,0.000,1.000]]
五、trace分析
trace.txt生成：当app(包括系统app和用户app)进程出现anr、应用响应慢或watchdog的监视没有得到回馈时,系统会dump此时的top进程,进程中thread的运行状态就都dump到这个trace文件中了。
anr一般有三种类型：
1、keydispatchtimeout(5 seconds) --主要类型 按键或触摸事件在特定时间内无响应
2、broadcasttimeout(10 seconds) broadcastreceiver在特定时间内无法处理完成
3、servicetimeout(20 seconds) --小概率类型 service在特定的时间内无法处理完成
---------------------------------------------------------------
1、adb shell 进入手机的/data/anr文件目录下面查看生成的trace.txt文件
如果ls查看文件列表没有权限，可以先adb root一下
2、adb pull /data/ ./ 将该文件导出，然后分析
---------------------------------------------------------------
log打印了anr的基本信息（adb shell top查看cg进程，adb logcat -v process |grep pid查看日志）,
可以分析cpu使用率得知anr的简单情况;如果cpu使用率很高,接近100%,可能是在进行大规模的计算更可能是陷入死循环;如果cup使用率很低,说明主线程被阻塞了,并且当iowait很高,可能是主线程在等待i/o操作的完成。
对于anr只是分析log很难知道问题所在,我们还需要通过trace文件分析stack调用情况，在log中显示的pid在traces文件中与之对应,然后通过查看堆栈调用信息分析anr的代码：
（此处trace的分析参考 https://blog.csdn.net/qq_25804863/article/details/49111005 ）
----- pid 17027 at 2017-06-22 10:37:39 ----- // anr出现的进程pid和时间 cmd line: org.code:messengerservice // anr出现的进程名（或者进程包名） build fingerprint: 'homecare/qucii8976v3_64:6.0.1/pansen06141150:eng/test-keys' // 下面记录系统版本,内存等状态信息 abi: 'arm64' build type: optimized zygote loaded classes=6576 post zygote classes=13 intern table: 13780 strong; 17 weak jni: checkjni is on; globals=283 (plus 158 weak) libraries: /system/lib64/libandroid.so /system/lib64/libcompiler_rt.so /system/lib64/libjavacrypto.so /system/lib64/libjnigraphics.so /system/lib64/libmedia_jni.so /system/lib64/libwebviewchromium_loader.so libjavacore.so (7) heap: 29% free, 8mb/12mb; 75731 objects dumping cumulative gc timings total number of allocations 75731 total bytes allocated 8mb total bytes freed 0b free memory 3mb free memory until gc 3mb free memory until oome 183mb total memory 12mb max memory 192mb zygote space size 3mb total mutator paused time: 0 total time waiting for gc to complete: 0 total gc count: 0 total gc time: 0 total blocking gc count: 0 total blocking gc time: 0 suspend all histogram: sum: 76us 99% c.i. 0.100us-28us avg: 7.600us max: 28us dalvik threads (15): // signal catcher是记录traces信息的线程 // signal catche(线程名)、(daemon)表示守护进程、prio(线程优先级,默认是5)、tid(线程唯一标识id)、runnable(线程当前状态) "signal catcher" daemon prio=5 tid=3 runnable //线程组名称、suspendcount、debugsuspendcount、线程的java对象地址、线程的native对象地址 | group="system" scount=0 dscount=0 obj=0x12d8f0a0 self=0x5598ae55d0 //systid是线程号(主线程的线程号和进程号相同) | systid=17033 nice=0 cgrp=default sched=0/0 handle=0x7fb2350450 | state=r schedstat=( 4348125 172343 3 ) utm=0 stm=0 core=1 hz=100 | stack=0x7fb2254000-0x7fb2256000 stacksize=1013kb | held mutexes= "mutator lock"(shared held) native: #00 pc 0000000000489e28 /system/lib64/libart.so (art::dumpnativestack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, int, char const*, art::artmethod*, void*)+236) native: #01 pc 0000000000458fe8 /system/lib64/libart.so (art::thread::dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) const+220) native: #02 pc 0000000000465bc8 /system/lib64/libart.so (art::dumpcheckpoint::run(art::thread*)+688) native: #03 pc 0000000000466ae0 /system/lib64/libart.so (art::threadlist::runcheckpoint(art::closure*)+276) native: #04 pc 000000000046719c /system/lib64/libart.so (art::threadlist::dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+188) native: #05 pc 0000000000467a84 /system/lib64/libart.so (art::threadlist::dumpforsigquit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+492) native: #06 pc 0000000000431194 /system/lib64/libart.so (art::runtime::dumpforsigquit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+96) native: #07 pc 000000000043e604 /system/lib64/libart.so (art::signalcatcher::handlesigquit()+1256) native: #08 pc 000000000043f214 /system/lib64/libart.so (art::signalcatcher::run(void*)+452) native: #09 pc 0000000000068714 /system/lib64/libc.so (__pthread_start(void*)+52) native: #10 pc 000000000001c604 /system/lib64/libc.so (__start_thread+16) (no managed stack frames) //main(线程名)、prio(线程优先级,默认是5)、tid(线程唯一标识id)、sleeping(线程当前状态) "main" prio=5 tid=1 sleeping | group="main" scount=1 dscount=0 obj=0x73132d10 self=0x5598a5f5e0 //systid是线程号(主线程的线程号和进程号相同) | systid=17027 nice=0 cgrp=default sched=0/0 handle=0x7fb6db6fe8 | state=s schedstat=( 420582038 5862546 143 ) utm=24 stm=18 core=6 hz=100 | stack=0x7fefba3000-0x7fefba5000 stacksize=8mb | held mutexes= // java 堆栈调用信息(这里可查看导致anr的代码调用流程)(分析anr最重要的信息) at java.lang.thread.sleep!(native method) - sleeping on <0x0c60f3c7> (a java.lang.object) at java.lang.thread.sleep(thread.java:1031) - locked <0x0c60f3c7> (a java.lang.object) // 锁住对象0x0c60f3c7 at java.lang.thread.sleep(thread.java:985) at android.os.systemclock.sleep(systemclock.java:120) at org.code.ipc.messengerservice.oncreate(messengerservice.java:63) //导致anr的代码 at android.app.activitythread.handlecreateservice(activitythread.java:2877) at android.app.activitythread.access$1900(activitythread.java:150) at android.app.activitythread$h.handlemessage(activitythread.java:1427) at android.os.handler.dispatchmessage(handler.java:102) at android.os.looper.loop(looper.java:148) at android.app.activitythread.main(activitythread.java:5417) at java.lang.reflect.method.invoke!(native method) at com.android.internal.os.zygoteinit$methodandargscaller.run(zygoteinit.java:726) at com.android.internal.os.zygoteinit.main(zygoteinit.java:616)
traces中显示的线程状态都是c代码定义的.我们可以通过查看线程状态对应的信息分析anr问题
如: timedwaiting对应的线程状态是timed_waiting
ktimedwaiting, // timed_waiting ts_wait in object.wait() with a timeout 执行了无超时参数的wait函数
ksleeping, // timed_waiting ts_sleeping in thread.sleep() 执行了带有超时参数的sleep函数
zombie 线程死亡，终止运行
running/runnable 线程可运行或正在运行
timed_wait 执行了带有超时参数的wait、sleep或join函数
monitor 线程阻塞，等待获取对象锁
wait 执行了无超时参数的wait函数
initializing 新建，正在初始化，为其分配资源
starting 新建，正在启动
native 正在执行jni本地函数
vmwait 正在等待vm资源
suspended 线程暂停，通常是由于gc或debug被暂停
上一篇： JQuery实现用户名无刷新验证的小例子