一、抓取Systrace
1.1 使用手機抓取
使用Google 預留的開發者模式中的 系統跟蹤 功能抓取systrace。
步驟:
設置--開發者模式--系統跟蹤
trace文件保存路徑:
/data/local/traces
手機抓取trace
抓取完之后使用adb 命令 pull 出來即可
C:Users >adb pull /data/local/traces . /data/local/traces/: 1 file pulled, 0 skipped. 95.1 MB/s (51342186 bytes in 0.515s) C:Users >
1.2 python 命令抓取
參考命令如下:
python systrace.py -o mynewtrace.html sched freq idle am wm gfx view binder_driver hal dalvik camera input res
比較麻煩,需要安裝環境,不推薦,有成熟腳本除外。
二、CPU模塊知識點
2.1 CPU頻率,CPU loading 計算
CPU loading 計算公式
CPU 負載loading = Wall duration ÷ 選擇CPU 個數÷ 選擇CPU的范圍
CPU Loading
2.2 Thread 在CPU中的狀態
綠色:運行中 Running
對于在CPU上執行的進程,需要查看其運行時間、是否跑在該跑的核上、頻率是否夠等。
淺綠色:可運行 Runnable
對于在等待序列中的進程,需要查看是否有過多任務在等待、等待時間是否過長等。
白色:休眠中 Sleeping
這里一般是在等事件驅動。
橘色:不可中斷的睡眠態_IO_Block Uninterruptible Sleep | WakeKill - Block I/O
線程在I / O上被阻塞或等待磁盤操作完成。
紫色:不可中斷的睡眠態 Uninterruptible Sleep
線程在另一個內核操作(通常是內存管理)上被阻塞。
舉例如下:
Thread 在CPU中的狀態
2.3 CPU 喚醒關系查看
首先點擊查看當前線程正在哪個 CPU 中運行
CPU 喚醒關系查看一
點擊查看 Thread 的 箭頭,既可以查看是被誰喚醒的
CPU 喚醒關系查看二
三、input 點擊事件處理流程
3.1 Android 點擊事件處理流程概覽
SystemServer AppLaunch_dispatchPtr:Up 處理點擊up事件
SystemServer 通過InputReader讀取屏幕點擊事件后,將點擊事件通過InputDispatcher 進行分發
SystemServer OutboundQueue 接收存放即將派發給AppConnection 的點擊事件
SystemServer WaitQueue接收存放已經派發給AppConnection ,但 App還在處理且沒有返回成功的點擊事件
Launcher deliverInputEvent: Launcher 桌面 被input事件喚醒
Camera APP bind 通過跟SystemServer bind 調用,開始啟動Camera
3.2 Android 點擊事件處理流程圖
Android 點擊事件處理流程圖如下:
Android 點擊事件處理流程圖
3.2 Android 點擊事件處理關鍵TAG
TAG名字 | 所在進程 | 備注 |
---|---|---|
AppLaunch_dispatchPtr:Down | SystemServer | 點擊Down事件 |
AppLaunch_dispatchPtr:Up | SystemServer | 點擊up事件 |
InputReader | SystemServer | 點擊事件讀取 |
InputDispatcher | SystemServer | 點擊事件分發 |
oq | SystemServer | OutBoundQueue 點擊事件存放 |
wq | SystemServer | WaitQueue 點擊事件待消費返回 |
deliverInputEvent | Launcher | app 點擊事件消費 |
四、Vsync 事件處理
Vsync 信號可以由硬件產生,也可以用軟件模擬,不過現在基本上都是硬件產生,負責產生硬件 Vsync 的是 HWC,HWC 可生成 VSYNC 事件并通過回調將事件發送到 SurfaceFlinger , DispSync 將 Vsync 生成由 Choreographer 和 SurfaceFlinger 使用的 VSYNC_APP 和 VSYNC_SF 信號
4.1 VSYNC_app信號app處理
第一階段:
App 在收到 Vsync-App 的時候,在主線程進行 measure、layout、draw(構建 DisplayList , 里面包含 OpenGL 渲染需要的命令及數據) 。這里對應的 Systrace 中的主線程 doFrame 操作
第二階段:
CPU 將數據上傳(共享或者拷貝)給 GPU,這里 ARM 設備 內存一般是 GPU 和 CPU 共享內存。這里對應的 Systrace 中的渲染線程的 flush drawing commands 操作
第三階段:
通知 GPU 渲染,真機一般不會阻塞等待 GPU 渲染結束,CPU 通知結束后就返回繼續執行其他任務,使用 Fence 機制輔助 GPU CPU 進行同步操作
第四 階段:
swapBuffers,并通知 SurfaceFlinger 圖層合成。這里對應的 Systrace 中的渲染線程的 eglSwapBuffersWithDamageKHR 操作
VSYNC_app信號處理流程如下:
VSYNC_app信號處理
4.2 VSYNC_sf 信號SF處理
第五階段:
SurfaceFlinger 開始合成圖層,如果之前提交的 GPU 渲染任務沒結束,則等待 GPU 渲染完成,再合成(Fence 機制),合成依然是依賴 GPU,不過這就是下一個任務了.這里對應的 Systrace 中的 SurfaceFlinger 主線程的 onMessageReceived 操作(包括 handleTransaction、handleMessageInvalidate、handleMessageRefresh)SurfaceFlinger 在合成的時候,會將一些合成工作委托給 Hardware Composer,從而降低來自 OpenGL 和 GPU 的負載,只有 Hardware Composer 無法處理的圖層,或者指定用 OpenGL 處理的圖層,其他的 圖層偶會使用 Hardware Composer 進行合成
第六階段 :
最終合成好的數據放到屏幕對應的 Frame Buffer 中,固定刷新的時候就可以看到了
VSYNC_sf 信號SF處理流程如下:
VSYNC_sf 信號SF處理
五、Android 繪制一幀流程分析
5.1 顯示一幀流程概覽
程序員Android
5.1.1 Android 顯示一幀大致分為下面 八步:
App 接收到 vsync-app 信號后開始工作。
App 主線程被Message喚醒,執行onVsync。
App 執行 doFrame ,處理input、animation、traversal、draw等。
App UIThread 跟RenderThread sync 數據。
App 執行DrawFrame,從SurfaceFlinger(后續簡稱SF) 的 BufferQueue 中 Dequeue buffer,取出一個bufffer后,執行渲染繪制,接著將繪制好的Buffer 通過queuebuffer 放回到。BufferQueue中給 SF消費。
App queuebuffer 后, SF 中對應的 app buffer 會增加 +1。
Vsync-sf 到來后,SF 從BufferQueue 中 acquireBuffer一個Buffer 進行消費, 對應SF 中的 app buffer 會減 - 1 , SF 消費處理后,通過 releaseBuffer 將buffer 歸還到BufferQueue 中。
SF 通過 bind 跟 Hardware Composer HAL(簡稱HWC) 進行通信,通過一些處理后顯示到手機屏幕上。
5.2 生產者,消費者 BufferQueue 流轉圖
生產者,消費者 BufferQueue 流轉圖
dequeue(生產者發起) :
當生產者需要緩沖區時,它會通過調用 dequeueBuffer() 從 BufferQueue 請求一個可用的緩沖區,并指定緩沖區的寬度、高度、像素格式和使用標記。
queue(生產者發起):
生產者填充緩沖區并通過調用 queueBuffer() 將緩沖區返回到隊列。
acquire(消費者發起) :
消費者通過 acquireBuffer() 獲取該緩沖區并使用該緩沖區的內容
release(消費者發起) :
當消費者操作完成后,它會通過調用 releaseBuffer() 將該緩沖區返回到隊列
5.3 App ,SF Buffer 交互圖
App ,SF Buffer 交互圖
App 通過bind 向SF dequeuebuffer 進行buffer申請
SF 對端完成對bufferQueue 的dequeuebuffer的申請
App 處理合成完后,通過binder向SF queuebuffer 申請buffer 入隊。
SF 對端通過queuebuffer 完成buffer 對BufferQueue的入隊申請,供SF消費并顯示到屏幕上
5.4 SF 跟 HWC 交互圖
SurfaceFlinger 接受來自多個來源的數據緩沖區,對它們進行合成,然后發送到顯示設備。
SF 送顯圖
SF 跟 HWC 交互圖
vsync-sf 周期到來,SF 開始繪制準備工作
SF 通過 acquirebuffer 從BufferQueue 中取出一幀進行消費
App 對應的BufferQueue 在SF acquirebuffer 后對那個的值會 -1
App 對應的buffer 值為 2
App 對應的buffer值 在SF acquirebuffer 后變為 1
SF 跟HWC 通過binder 通信處理完后,通過rleasebuffer將buffer 歸還到BufferQueue中,緊接著一幀就可以顯示出來
六、Camx Trace TAG開啟方法
6.1 打開 Camx HAL 層 camx log tag
執行以下命令,打開camx trace log tag
adb root adb remount adb shell mkdir /vendor/etc/camera adb shell rm -rf /vendor/etc/camera/camxoverridesettings.txt adb shell touch /vendor/etc/camera/camxoverridesettings.txt adb shell "echo traceGroupsEnable=0x10080 >> /vendor/etc/camera/camxoverridesettings.txt" adb shell "echo traceErrorEnable=TRUE >> /vendor/etc/camera/camxoverridesettings.txt" adb shell "echo traceOutputEnable=0x10080 >> /vendor/etc/camera/camxoverridesettings.txt" adb shell cat /vendor/etc/camera/camxoverridesettings.txt adb reboot
6.2 重啟手機后打開kernel 的trace開關
重啟后打開kernel trace 開關
adb root adb remount adb shell "echo 1 > /sys/kernel/tracing/events/camera/enable"
審核編輯:劉清
-
ARM
+關注
關注
134文章
9207瀏覽量
371056 -
OpenGL
+關注
關注
1文章
85瀏覽量
29408 -
python
+關注
關注
56文章
4813瀏覽量
85301 -
HAL庫
+關注
關注
1文章
121瀏覽量
6477
原文標題:Systrace分析知識點
文章出處:【微信號:哆啦安全,微信公眾號:哆啦安全】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論