一、抓取Systrace

1.1 使用手機抓取

使用Google 預(yù)留的開發(fā)者模式中的 系統(tǒng)跟蹤 功能抓取systrace。

步驟：

設(shè)置--開發(fā)者模式--系統(tǒng)跟蹤

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

比較麻煩，需要安裝環(huán)境，不推薦，有成熟腳本除外。

二、CPU模塊知識點

2.1 CPU頻率，CPU loading 計算

CPU loading 計算公式

CPU 負載loading = Wall duration ÷ 選擇CPU 個數(shù)÷ 選擇CPU的范圍

CPU Loading

2.2 Thread 在CPU中的狀態(tài)

綠色：運行中 Running

對于在CPU上執(zhí)行的進程，需要查看其運行時間、是否跑在該跑的核上、頻率是否夠等。

淺綠色：可運行 Runnable

對于在等待序列中的進程，需要查看是否有過多任務(wù)在等待、等待時間是否過長等。

白色：休眠中 Sleeping

這里一般是在等事件驅(qū)動。

橘色：不可中斷的睡眠態(tài)_IO_Block Uninterruptible Sleep | WakeKill - Block I/O

線程在I / O上被阻塞或等待磁盤操作完成。

紫色：不可中斷的睡眠態(tài) Uninterruptible Sleep

線程在另一個內(nèi)核操作（通常是內(nèi)存管理）上被阻塞。

舉例如下：

Thread 在CPU中的狀態(tài)

2.3 CPU 喚醒關(guān)系查看

首先點擊查看當前線程正在哪個 CPU 中運行

CPU 喚醒關(guān)系查看一

點擊查看 Thread 的 箭頭，既可以查看是被誰喚醒的

CPU 喚醒關(guān)系查看二

三、input 點擊事件處理流程

3.1 Android 點擊事件處理流程概覽

SystemServer AppLaunch_dispatchPtr:Up 處理點擊up事件

SystemServer 通過InputReader讀取屏幕點擊事件后，將點擊事件通過InputDispatcher 進行分發(fā)

SystemServer OutboundQueue 接收存放即將派發(fā)給AppConnection 的點擊事件

SystemServer WaitQueue接收存放已經(jīng)派發(fā)給AppConnection ,但 App還在處理且沒有返回成功的點擊事件

Launcher deliverInputEvent: Launcher 桌面 被input事件喚醒

Camera APP bind 通過跟SystemServer bind 調(diào)用，開始啟動Camera

3.2 Android 點擊事件處理流程圖

Android 點擊事件處理流程圖如下：

Android 點擊事件處理流程圖

3.2 Android 點擊事件處理關(guān)鍵TAG

四、Vsync 事件處理

Vsync 信號可以由硬件產(chǎn)生，也可以用軟件模擬，不過現(xiàn)在基本上都是硬件產(chǎn)生，負責產(chǎn)生硬件 Vsync 的是 HWC,HWC 可生成 VSYNC 事件并通過回調(diào)將事件發(fā)送到 SurfaceFlinger , DispSync 將 Vsync 生成由 Choreographer 和 SurfaceFlinger 使用的 VSYNC_APP 和 VSYNC_SF 信號

4.1 VSYNC_app信號app處理

第一階段：
App 在收到 Vsync-App 的時候，在主線程進行 measure、layout、draw(構(gòu)建 DisplayList , 里面包含 OpenGL 渲染需要的命令及數(shù)據(jù)) 。這里對應(yīng)的 Systrace 中的主線程 doFrame 操作

第二階段：
CPU 將數(shù)據(jù)上傳（共享或者拷貝）給 GPU,這里 ARM 設(shè)備 內(nèi)存一般是 GPU 和 CPU 共享內(nèi)存。這里對應(yīng)的 Systrace 中的渲染線程的 flush drawing commands 操作

第三階段：
通知 GPU 渲染，真機一般不會阻塞等待 GPU 渲染結(jié)束，CPU 通知結(jié)束后就返回繼續(xù)執(zhí)行其他任務(wù)，使用 Fence 機制輔助 GPU CPU 進行同步操作

第四 階段：
swapBuffers，并通知 SurfaceFlinger 圖層合成。這里對應(yīng)的 Systrace 中的渲染線程的 eglSwapBuffersWithDamageKHR 操作
VSYNC_app信號處理流程如下：

VSYNC_app信號處理

4.2 VSYNC_sf 信號SF處理

第五階段：
SurfaceFlinger 開始合成圖層，如果之前提交的 GPU 渲染任務(wù)沒結(jié)束，則等待 GPU 渲染完成，再合成（Fence 機制），合成依然是依賴 GPU，不過這就是下一個任務(wù)了.這里對應(yīng)的 Systrace 中的 SurfaceFlinger 主線程的 onMessageReceived 操作（包括 handleTransaction、handleMessageInvalidate、handleMessageRefresh）SurfaceFlinger 在合成的時候，會將一些合成工作委托給 Hardware Composer,從而降低來自 OpenGL 和 GPU 的負載，只有 Hardware Composer 無法處理的圖層，或者指定用 OpenGL 處理的圖層，其他的 圖層偶會使用 Hardware Composer 進行合成

第六階段 ：
最終合成好的數(shù)據(jù)放到屏幕對應(yīng)的 Frame Buffer 中，固定刷新的時候就可以看到了
VSYNC_sf 信號SF處理流程如下：

VSYNC_sf 信號SF處理

五、Android 繪制一幀流程分析

5.1 顯示一幀流程概覽

程序員Android

5.1.1 Android 顯示一幀大致分為下面 八步：

App 接收到 vsync-app 信號后開始工作。

App 主線程被Message喚醒，執(zhí)行onVsync。

App 執(zhí)行 doFrame ，處理input、animation、traversal、draw等。

App UIThread 跟RenderThread sync 數(shù)據(jù)。

App 執(zhí)行DrawFrame，從SurfaceFlinger(后續(xù)簡稱SF) 的 BufferQueue 中 Dequeue buffer，取出一個bufffer后，執(zhí)行渲染繪制，接著將繪制好的Buffer 通過queuebuffer 放回到。BufferQueue中給 SF消費。

App queuebuffer 后, SF 中對應(yīng)的 app buffer 會增加 +1。

Vsync-sf 到來后，SF 從BufferQueue 中 acquireBuffer一個Buffer 進行消費， 對應(yīng)SF 中的 app buffer 會減 - 1 , SF 消費處理后，通過 releaseBuffer 將buffer 歸還到BufferQueue 中。

SF 通過 bind 跟 Hardware Composer HAL(簡稱HWC) 進行通信，通過一些處理后顯示到手機屏幕上。

5.2 生產(chǎn)者，消費者 BufferQueue 流轉(zhuǎn)圖

生產(chǎn)者，消費者 BufferQueue 流轉(zhuǎn)圖

dequeue(生產(chǎn)者發(fā)起) ：
當生產(chǎn)者需要緩沖區(qū)時，它會通過調(diào)用 dequeueBuffer() 從 BufferQueue 請求一個可用的緩沖區(qū)，并指定緩沖區(qū)的寬度、高度、像素格式和使用標記。

queue(生產(chǎn)者發(fā)起)：
生產(chǎn)者填充緩沖區(qū)并通過調(diào)用 queueBuffer() 將緩沖區(qū)返回到隊列。

acquire(消費者發(fā)起) ：
消費者通過 acquireBuffer() 獲取該緩沖區(qū)并使用該緩沖區(qū)的內(nèi)容

release(消費者發(fā)起) ：
當消費者操作完成后，它會通過調(diào)用 releaseBuffer() 將該緩沖區(qū)返回到隊列

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 接受來自多個來源的數(shù)據(jù)緩沖區(qū)，對它們進行合成，然后發(fā)送到顯示設(shè)備。

SF 送顯圖

SF 跟 HWC 交互圖

vsync-sf 周期到來，SF 開始繪制準備工作

SF 通過 acquirebuffer 從BufferQueue 中取出一幀進行消費

App 對應(yīng)的BufferQueue 在SF acquirebuffer 后對那個的值會 -1

App 對應(yīng)的buffer 值為 2

App 對應(yīng)的buffer值 在SF acquirebuffer 后變?yōu)?1

SF 跟HWC 通過binder 通信處理完后，通過rleasebuffer將buffer 歸還到BufferQueue中，緊接著一幀就可以顯示出來

六、Camx Trace TAG開啟方法

6.1 打開 Camx HAL 層 camx log tag

執(zhí)行以下命令，打開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開關(guān)

重啟后打開kernel trace 開關(guān)

       adb root
       adb remount
       adb shell "echo 1 > /sys/kernel/tracing/events/camera/enable"

審核編輯：劉清