「Android」adb調試源碼（針對dumpsys SurfceFlinger、trace.txt獲取）

時間 2019-12-11

標籤 android adb 調試源碼針對 dumpsys surfceflinger trace.txt trace txt 獲取欄目 Android 简体版

原文原文鏈接

首先對ADB做簡單的闡述，接下來對adb shell dumpsys SurfaceFlinger服務的dump信息的查看、以及ANR問題如何獲取trace文件並簡單分析。java

-×**************************************************************linux

目錄：android

1、ADB概述web

2、ADB經常使用命令shell

（1）基本命令數據庫

（2）軟件操做命令緩存

（3）文件操做命令網絡

（4）日誌操做命令app

3、dumpsys使用composer

4、dump SurfaceFlinger的打印信息分析

5、trace分析

-×*************************************************************

1、ADB概述

adb（Android Debug Bridge），安卓平臺調試橋，是鏈接Android手機與PC端的橋樑，經過adb能夠管理、操做模擬器和設備，如安裝軟件、查看設備軟硬件參數、系統升級、運行shell命令等。

手機啓動USB調試模式，設備鏈接電腦。

注：個人手機一加6的USB調試模式打開方式以下：

（1）在手機設置的關於手機找到版本號，雙擊七次打開開發者模式;

（2）在開發者選項中打開USB調試選項;

（3）設備鏈接

2、ADB經常使用命令

（1）基本命令：

一、adb devices 查看設備鏈接狀況

二、adb version 查看版本

三、adb kill-server 關閉adb服務

四、adb start-server 啓動adb服務

五、adb 查看幫助

六、adb shell 進入adb sehll命令

七、adb shell top　　查看手機當前進程佔用手機內存狀況

八、adb shell kill -3 pid 殺掉進程

九、adb logcat -v process |grep 8607 //8607 是進程 PID

（2）軟件操做命令：

　　安裝軟件：

　　　　 adb install

　　　　 adb install <apk文件路徑> :這個命令將指定的apk文件安裝到設備上

　　卸載軟件：

　　　　adb uninstall <軟件名>

　　　　adb uninstall -k <軟件名> 若是加 -k 參數,爲卸載軟件可是保留配置和緩存文件

（3）文件操做命令：

　　從電腦上發送文件到設備

　　 adb push <本地路徑> <遠程路徑>

　　用push命令能夠把本機電腦上的文件或者文件夾複製到設備(手機)

　　從設備上下載文件到電腦

　　 adb pull <遠程路徑> <本地路徑>

　　用pull命令能夠把設備(手機)上的文件或者文件夾複製到本機電腦

（4）日誌操做命令

adb logcat 查看日誌

日誌等級（由上往下級別遞增）：

V verbase，級別最低，瑣碎、不重要的日誌信息

D debug，調試信息

I info，重要信息

W warning，警告信息

E error，錯誤信息

F fatal，嚴重錯誤信息

S slient，無記載

adb logcat --help 查看幫助信息，獲取該命令可配置的參數選項

adb logcat -b <buffer> 加載一個可以使用的日誌緩衝區供查看

buffer選項能夠填爲：

radio 通訊系統

system 系統組件

event event事件模塊

main java層

kernel linux內核

adb logcat [tag:level] 指定標籤，指定級別過濾顯示日誌

例如：adb logcat Test:I

adb logcat -c 清理已存在的日誌

adb logcat -g 打印日誌緩衝區的大小

adb logcat > home/mylog.txt 日誌保存到電腦某路徑

adb logcat -d -f /sdcard/mylog.txt 保存到手機上指定位置（-d 日誌顯示在控制檯）

adb logcat -f /scard/log.txt 輸出到手機指定位置

adb logcat -s System.out 設置標籤（某個字符串），過濾顯示日誌

adb logcat -v <format> 設置日誌輸入格式控制輸出字段

format選項能夠填爲：

brief 顯示優先級/標記和原始進程的PID（默認）

process 只顯示進程PID

tag 只顯示優先級/標記

thread 只顯示進程、線程、優先級/標記

raw

time

long

例如：adb logcat -v process

（5）adb shell命令

adb shell pm list packages 查看二、adb shell pm list packages -f 查看包名對應的apk路徑及名稱

三、adb shell dumpsys　　列出手機全部apk的詳細信息

3、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服務

4、dump SurfaceFlinger的打印信息分析

　　SurfaceFlinger的dump信息主要經過dumpAllLocked 函數來獲取。

　　通常包含：
一、layer的信息，layer通常對應於一個surface;
二、opengl的信息。通常是跟gpu比較相關的參數，opengl是標準的接口;
三、display。安卓支持三種類型的display，能夠導出display當前的顯示狀態，也就是各個surface(layer)在各個display的顯示屬性;
四、surfaceflinger管理graphis buffer的信息。主要是layer申請的幀數據內存;
五、hwcomopser的若是實現dump接口也能知道hwcomposer的一些參數;
六、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]]

5、trace分析

trace.txt生成：當APP(包括系統APP和用戶APP)進程出現ANR、應用響應慢或WatchDog的監視沒有獲得回饋時,系統會dump此時的top進程,進程中Thread的運行狀態就都dump到這個Trace文件中了。

ANR通常有三種類型：

　　一、KeyDispatchTimeout(5 seconds) --主要類型　　按鍵或觸摸事件在特定時間內無響應

　　二、BroadcastTimeout(10 seconds)　　　　　　　　BroadcastReceiver在特定時間內沒法處理完成

　　三、ServiceTimeout(20 seconds) --小几率類型　　Service在特定的時間內沒法處理完成

---------------------------------------------------------------

一、adb shell 進入手機的/data/anr文件目錄下面查看生成的trace.txt文件

　　若是ls查看文件列表沒有權限，能夠先adb root一下

二、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被暫停